Linux服务器通过Bash脚本设置代理失败问题咨询

阿华AIGC实验室

2026-5-26

为什么命令行直接设置代理能成功，而Bash脚本中设置后执行sudo yum list却失败？

这问题核心是环境变量的作用域和sudo的环境重置机制在搞鬼，我给你拆解清楚：

核心差异点

1. 环境变量的生效范围完全不同

命令行场景：你直接在当前用户的shell进程里执行export http_proxy="http://proxy.company.com:8080/"，这个代理变量会被添加到当前shell的环境中。后续执行sudo yum list时，如果你的sudo配置允许保留这类变量，yum进程就能继承到代理配置，自然能成功。
脚本场景：Bash脚本是在一个独立的子shell进程中运行的——你在脚本里export的代理变量，只属于这个子shell，出了这个子shell就失效了。当脚本执行到sudo yum list时，sudo默认会把环境变量重置为安全的默认值，根本不会继承子shell里的代理变量，所以yum找不到代理配置就失败了。

2. sudo的环境处理逻辑

sudo默认会清除大部分用户环境变量，目的是避免权限提升时带入不安全的配置。但命令行场景下，如果你当前shell的代理变量被sudo的env_keep配置允许保留（比如/etc/sudoers里有相关设置），那sudo启动的yum就能拿到这些变量；而脚本里的变量只存在于子shell，sudo完全看不到。

实用解决办法

给你几个靠谱的方案：

方案1：在sudo命令中直接传递代理变量
把脚本里的sudo yum list改成下面这样，直接把代理变量传给sudo启动的yum进程：
```
sudo http_proxy="http://proxy.company.com:8080/" https_proxy="http://proxy.company.com:8080/" yum list
```
方案2：让sudo默认保留代理变量
用visudo命令编辑/etc/sudoers（必须用visudo，避免语法错误导致sudo失效），添加一行配置：
```
Defaults env_keep += "http_proxy https_proxy"
```
这样以后所有sudo命令都会保留这两个代理变量，脚本里的export就能正常生效了。
方案3：让脚本在当前shell中执行
不要直接运行脚本（比如./your_script.sh），而是用source或.命令执行：
```
source your_script.sh
# 或者简写为
. your_script.sh
```
这样脚本会在当前shell进程里运行，export的变量会进入当前shell环境，之后sudo就能继承到代理配置（前提是sudo的env_keep允许）。