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 代理时遇到过哪些奇怪问题？欢迎在评论区留言，我们会挑选典型问题在下一篇文章中给出详细排查思路，如果本文对你有帮助，别忘了分享给同样被代理折腾的同事。
本文地址：https://www.htstack.com/news/205239.shtml
特别声明：本网站部分文章内容由 AI 技术辅助生成，旨在为您提供基础信息参考。请注意，AI 生成内容可能存在时效性偏差或与本公司实际政策不完全一致的情况，本文章所展示的产品介绍、服务流程、价格及优惠信息，均不构成最终服务承诺，实时准确信息请咨询在线客服。
