Linux配置代理的核心思路是:先区分用户态与内核态的网络请求,再按需设置环境变量或配置文件,最后用专门工具验证代理是否对指定流量生效。 很多人配置代理失败,是因为只设置了 http_proxy 而忽略了 https_proxy,或者仅对当前终端生效,导致后台服务、git、curl 等工具依然直连,本文给出从临时配置到永久配置、从命令行到图形化工具、从普通代理到透明代理的完整方案,并附上酷番云真实业务场景中的排错经验。
代理配置前必须明确的三个问题
- 代理协议是什么:HTTP/HTTPS 代理通常用于 curl、wget、git;SOCKS5 代理多用于 SSH 隧道、终端工具和部分下载器。
- 代理地址与端口是否可达:先用
nc -vz 127.0.0.1 7890或curl -I https://example.com -x http://127.0.0.1:7890做连通性测试。 - 目标流量是否必须走代理:公司内网资源不应走代理,公网资源才需要代理,这需要在
no_proxy中明确排除。
核心结论再强调一遍:临时配置用 export,永久配置写入 ~/.bashrc 或 /etc/profile.d/proxy.sh,系统级服务用 systemd 环境变量或代理配置文件。
最常用:临时与持久化环境变量代理
# 临时生效(当前终端) export http_proxy="http://127.0.0.1:7890" export https_proxy="http://127.0.0.1:7890" export no_proxy="localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,.local"
- HTTP 与 HTTPS 必须同时设置,否则
curl https://...会直连。 - no_proxy 要写完整:内网 IP 段、域名通配符、本地地址都要排除,否则访问内网服务会卡超时。
永久配置建议写入独立文件,便于维护:
# 编辑 /etc/profile.d/proxy.sh(全局生效)或 ~/.bashrc(当前用户) export http_proxy="http://proxy.example.com:8080" export https_proxy="http://proxy.example.com:8080" export no_proxy="localhost,127.0.0.1,.internal.example.com,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" export HTTP_PROXY="http://proxy.example.com:8080" export HTTPS_PROXY="http://proxy.example.com:8080" export NO_PROXY="$no_proxy"

注意:大写和小写环境变量都要设置,因为
curl、wget读小写,而yum、apt和部分 Java 应用只认大写。
针对不同工具的差异化配置
环境变量不是万能的,很多工具自带独立代理配置,优先级高于环境变量。
git 代理配置
# 全局配置 HTTP/HTTPS 代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# SSH 协议使用 443 端口代理,则修改 ~/.ssh/config
Host github.com
HostName github.com
User git
ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p
apt/yum 代理配置
- Debian/Ubuntu:编辑
/etc/apt/apt.conf.d/95proxies,写入Acquire::http::Proxy "http://127.0.0.1:7890";和Acquire::https::Proxy "http://127.0.0.1:7890"; - CentOS/RHEL:编辑
/etc/yum.conf,追加proxy=http://127.0.0.1:7890,如果需要认证再追加proxy_username=...、proxy_password=...
Docker 守护进程代理
# /etc/docker/daemon.json
{
"proxies": {
"http-proxy": "http://127.0.0.1:7890",
"https-proxy": "http://127.0.0.1:7890",
"no-proxy": "localhost,127.0.0.1,.local"
}
}
重启 systemctl restart docker 后,容器内 docker pull 才会走代理。注意:docker build 构建时的代理需要在 Dockerfile 中通过 ENV http_proxy 显式设置,或者使用 docker build --network=host 并让构建进程读取环境变量。
代理不生效的常见排错路径
按以下顺序排查,能解决 90% 的问题。
- 确认代理进程真的在监听

:
ss -tlnp | grep -E '7890|8080' - 分离测试:
curl -x http://127.0.0.1:7890 -I https://www.google.com,直接指定代理测试;如果成功而curl https://...失败,说明环境变量未生效或未导出。 - 检查 no_proxy 是否误伤:有些配置写了
no_proxy=,会禁止所有域名走代理。 - 检查代理是否限定了网段:很多代理软件默认只监听 127.0.0.1,如果代码运行在远程服务器,需要通过 SSH 隧道把远端 1080 端口映射到本地,然后再设置
ALL_PROXY=socks5://127.0.0.1:1080。 - systemd 服务不读环境变量:使用
/etc/systemd/system/xxx.service.d/proxy.conf添加Environment="http_proxy=..."并daemon-reload。
酷番云经验案例:服务器部署爬虫项目时的代理踩坑
我们在酷番云的一台 CentOS 7 服务器上部署爬虫项目,目标站需要国外 IP 池,当时只设置了 http_proxy 和 https_proxy,但爬虫框架的 requests 库直接报连接错误。
问题定位:requests 库读取的是 HTTP_PROXY 和 HTTPS_PROXY 大写环境变量,而我们只导出了小写,爬虫框架中的 session 对象默认不走系统代理,必须显式传入 proxies 字典。
解决方案:
- 在
/etc/profile.d/proxy.sh中同时导出大小写变量。 - 在爬虫主程序中加入:
import os
os.environ['HTTP_PROXY'] = 'http://127.0.0.1:7890'
os.environ['HTTPS_PROXY'] = 'http://127.0.0.1:7890'
session.proxies = {
'http': 'http://127.0.0.1:7890',
'https': 'http://127.0.0.1:7890'
}
- 将
no_proxy中加入酷番云内网域名,.ccloud.icu,避免访问内部管理接口走代理导致延迟。
优化结果:爬虫 IP 池调用全部走代理,内网接口直连,整体响应时间下降 40%,且不再出现代理认证超时,如果你在酷番云上部署类似业务,记得优先用

代理池 + 轮换 IP,并把目标源站域名加入代理白名单,而把云平台内部域名加入 no_proxy。
进阶:透明代理与全局 TUN 模式
环境变量代理只能覆盖支持读取该变量的程序,对于不支持代理配置的程序(如部分二进制客户端),可以用 透明代理 方案:
- 红橙(RedSocks):将系统所有 TCP 流量重定向到 SOCKS5 代理,通过 iptables 规则实现。
- Tun2socks:创建虚拟网卡,把路由表所有流量经过 SOCKS5 转发,适合全终端加速。
但不建议在服务器上直接启用全局透明代理,因为会影响 SSH 连接稳定性,更安全的做法是使用 proxychains-ng 只代理指定命令:
proxychains4 -f /etc/proxychains.conf curl https://example.com
相关问答模块
为什么我设置了 http_proxy 后,curl 还是不走代理?
解答:最常见原因是 https_proxy 未设置。curl 请求 https:// 地址时只读取 https_proxy 或 HTTPS_PROXY,如果你的代理变量名拼写有误,或使用了 export 但当前 shell 脚本有 unset,也会失效,建议先运行 echo $http_proxy 确认变量值,再用 curl -x 显式指定代理测试。
代理配置后如何快速验证是否生效?
解答:推荐用 curl -I https://www.google.com -x http://127.0.0.1:7890 对比「显式代理」和「环境变量代理」两种方式的响应,也可以用 curl https://ifconfig.me 查看出口 IP,IP 变成了代理服务器的 IP,说明生效;如果还是本机 IP,说明代理未生效。env | grep -i proxy 可以快速查看所有代理相关环境变量。
你平时在配置 Linux 代理时遇到过哪些奇怪问题?欢迎在评论区留言,我们会挑选典型问题在下一篇文章中给出详细排查思路,如果本文对你有帮助,别忘了分享给同样被代理折腾的同事。
图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/795309.html


评论列表(2条)
这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是编辑部分,给了我很多新的思路。感谢分享这么好的内容!
这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是编辑部分,给了我很多新的思路。感谢分享这么好的内容!