CentOS虚拟机代理配置失败怎么办？详细步骤教程

CentOS虚拟机代理配置失败，九成情况下是环境变量只对当前Shell生效、代理地址格式有误、或软件压根没读取系统代理设置这三个原因造成的，逐一排查后按本文步骤操作即可解决。

排查代理不生效的第一步：分清你是在哪里设的代理

很多人配置代理失败,是因为把代理写错了地方，CentOS虚拟机里代理设置分为三个层级，搞清楚自己卡在哪一层，问题就解决了一半。

加载中

虚拟机修改虚拟机CPU与内存、虚拟机教程

db2022

2.5万1044

原视频地址

• Shell环境变量层：只在当前终端窗口生效，关掉窗口就失效
• 系统全局层：写入/etc/profile或/etc/environment，对所有用户和终端生效
• 应用单独配置层：如yum、wget、Docker等各自读取不同的配置文件，不认系统全局变量

判断方法是打开终端,输入ip addr show确认网络连通状态，再执行curl -I http://mirrors.aliyun.com看看是否能正常返回HTTP响应头，如果连镜像站都ping不通，那和代理配置没有任何关系，先解决网络问题。

CentOS 7代理配置不生效最多见的两个坑

环境变量只对当前会话有效

在命令行直接执行export http_proxy=http://192.168.1.100:7890，当前窗口立刻生效，一旦关闭终端或者重启虚拟机就全部丢失，这是CentOS 7代理配置新手最容易踩的坑。

正确做法是把配置写进用户级或系统级配置文件：

vim ~/.bashrc

在文件末尾追加：

export http_proxy=http://192.168.1.100:7890
export https_proxy=http://192.168.1.100:7890
export ftp_proxy=http://192.168.1.100:7890
export no_proxy=localhost,127.0.0.1,192.168.1.0/24

保存后执行source ~/.bashrc让配置立即生效，很多人忽略了一个细节：代理服务器地址前面的http://协议头绝对不能省略，直接写168.1.100:7890会导致curl报错。

代理端口不通或防护墙拦截

代理服务器配置好后,很多人在CentOS虚拟机里反复测试，却一直提示Connection refused或connect timed out

，先确认宿主机代理软件是否允许局域网连接，以Clash为例，需要开启“Allow LAN”选项，否则虚拟机访问宿主机的7890端口会被直接拒绝。

判断端口连通性的标准命令：

nc -vz 192.168.1.100 7890

返回Connected to 192.168.1.100说明端口正常，返回Connection refused说明代理软件没开或没允许局域网访问，在宿主机防火墙里放行对应入站规则也是常见排查点，Windows和Linux宿主机分别设置。

curl http_proxy 不生效？代理配置正确顺序更重要

很多时候代理配置本身没问题,只是curl在用的时候出了岔子，有一个细节容易被忽略：curl优先读取~/.curlrc中的配置，其次是当前环境变量。

如果你想测试某个代理是否可用,不依赖环境变量，直接指定代理地址更稳妥：

curl -x http://192.168.1.100:7890 -I https://www.google.com

如果这条命令能正常返回HTTP/2 200，那就说明你的代理服务器本身是通的，问题出在别的地方，如果返回Received HTTP code 502 from proxy after CONNECT，说明代理服务端连接上游超时，和CentOS虚拟机无关。

centos虚拟机代理命令在yum和wget中不生效的单独配置法

yum代理单独配置

yum不读取系统的http_proxy环境变量，必须单独写在配置文件中，这是很多人在CentOS 7代理配置教程里找不到答案的坑：用yum安装软件时速度照样慢，是因为yum压根没走代理。

vim /etc/yum.conf

在[main]段落后追加：

proxy=http://192.168.1.100:7890

如果代理需要认证,再追加两行：

proxy_username=你的用户名
proxy_password=你的密码

保存后执行yum clean all && yum makecache测试，能快速刷出缓存列表，说明代理已经对yum生效，这个方法也适用于CentOS 8/9/Stream版本。

wget代理配置

wget同样有自己的一套配置,写在/etc/wgetrc或~/.wgetrc中：

http_proxy = http://192.168.1.100:7890
https_proxy = http://192.168.1.100:7890
use_proxy = on

配置完成后wget -O /dev/null https://www.google.com测试，注意观察终端里有没有Proxy request sent, awaiting response这行字，出现即代表代理正在起作用。

Docker容器和Kubernetes节点场景下的代理配置差异

很多人在虚拟机里装了Docker或Kubernetes组件后,发现容器内网络不通，就以为是虚拟机代理配置失败了，其实Docker守护进程和容器本身是两个网络命名空间，宿主机的代理环境变量根本传递不进去。

配置Docker拉取镜像走代理：

mkdir -p /etc/systemd/system/docker.service.d
vim /etc/systemd/system/docker.service.d/http-proxy.conf

写入：

[Service]
Environment="HTTP_PROXY=http://192.168.1.100:7890"
Environment="HTTPS_PROXY=http://192.168.1.100:7890"
Environment="NO_PROXY=localhost,127.0.0.1"

重载配置并重启Docker：

systemctl daemon-reload
systemctl restart docker

运行中的容器使用宿主代理，可以在docker run时加上-e http_proxy=http://192.168.1.100:7890 -e https_proxy=http://192.168.1.100:7890参数传入，Kubernetes节点上配置代理更麻烦一些，需要改动kubelet的systemd unit文件，同样是在Environment字段里追加代理变量，这里多说一句，如果你的代理服务器本身在宿主机上，那么把代理地址写为168.1.100这种局域网IP要比写0.0.1更加靠谱，因为容器网络无法直接访问宿主机的回环地址。

配置全局代理后重启失效的终极解决方式

每次重启虚拟机代理就失效,要手动重新执行一遍export，说明之前的配置没写对地方。/etc/profile在用户登录时加载，但如果你在开机的过程中使用systemd服务拉取镜像或下载文件，这些服务不会读取这个文件。

正确的全局生效配置位置是/etc/environment：

vim /etc/environment

http_proxy=http://192.168.1.100:7890
https_proxy=http://192.168.1.100:7890
ftp_proxy=http://192.168.1.100:7890
no_proxy=localhost,127.0.0.1

修改后重启验证：reboot，开机后打开终端输入echo $http_proxy，能返回代理地址即代表配置成功，这两种方式都适合CentOS 7代理配置的场景：/etc/profile适合交互式登录Shell，/etc/environment适合系统级服务读取环境变量。

CentOS 7代理配置常见疑问解答

代理配置成功但ping不通外网是怎么回事？

ping走的是ICMP协议,代理只转发HTTP/HTTPS/FTP等应用层流量，不处理ICMP包，所以ping www.google.com超时是正常现象，测试代理应该用curl -I https://www.google.com或访问网页来判断。

公司网络环境下yum源connect timed out怎么处理？

公司网络的代理认证方式和公共代理服务器有所不同,NTLM或Kerberos认证协议yum并不直接支持，两种解法：第一种，在/etc/yum.conf中配置带用户名密码的代理地址；第二种，在公司内网找一台不需要认证的透明代理服务器，填写其IP和端口即可，还有少数公司网络会锁定特定域名，内网镜像源才是最优解，用代理访问公司外网域名反而会被拦截。

SSL证书报错和代理配置有关联吗？

有一定关联,代理服务器会解密并重新加密HTTPS流量，如果想要完全信任代理的证书，需要执行：

cp your-proxy-ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

执行完这两条命令,curl和yum就不会再提示自签名证书报错，整个CentOS虚拟机的代理配置才算完整收尾，如果你使用的是公共代理服务且出现SSL错误，直接跳过证书校验仅用于临时调试场景，生产环境务必采用正规证书链。

CentOS虚拟机代理配置失败问题,本质上就是个排查链路顺序的问题：先排查网络连通性，再检查端口是否可达，然后区分不同应用代理读取的配置文件位置，最后核对代理协议和认证方式，按照这个顺序走一遍，多数情况下能在十分钟内找到症结所在。