Linux下HTTP代理不是“配一次就全局生效”，而是按工具分层生效：curl认http_proxy环境变量，git优先读自己的http.proxy配置，apt完全不看环境变量，只认/etc/apt/apt.conf.d/里的Acquire::http::Proxy。
直接说结论：Linux下HTTP代理不是“配一次就全局生效”，而是按工具分层生效——curl认http_proxy环境变量，git优先读自己的http.proxy配置，apt完全不看环境变量，只认/etc/apt/apt.conf.d/里的Acquire::http::Proxy。硬塞export http_proxy=...到~/.bashrc，反而会让curl localhost:3000也走代理，本地开发直接崩。
curl / wget 为什么设了 http_proxy 还不走代理？
常见错误是变量名写错或赋值格式非法：
-
http_proxy必须全小写；HTTP_PROXY在curl里能 fallback，但git、wget、apt只认小写 - 等号
=两边不能有空格：export http_proxy=http://p:8080✅，export http_proxy = http://p:8080❌ - 必须带
http://前缀，哪怕代理本身是 HTTPS ——https_proxy才走 TLS 隧道，http_proxy只是告诉客户端“往这个地址发 CONNECT 请求” - 没执行
export，变量只是 shell 内部变量，子进程（比如你运行的curl）根本看不到
no_proxy 写成 *.example.com 为什么无效？
no_proxy不是 glob 或正则，是后缀匹配列表，且逗号分隔、不支持通配符（除非程序自己实现）：
- ✅
export no_proxy="localhost,127.0.0.1,.example.com"——.example.com会匹配api.example.com和www.example.com - ❌
export no_proxy="*.example.com"—— 大多数工具直接忽略 - ❌
export no_proxy="192.168.*.*"—— 不生效；curl支持 CIDR 如192.168.0.0/16，但git不支持 - 务必显式包含
localhost、127.0.0.1、::1，否则本地服务调用可能被意外转发
apt / yum / dnf 怎么单独配代理？
它们根本不读http_proxy环境变量，只认各自配置文件里的硬编码键名：
-
apt：写入/etc/apt/apt.conf.d/80proxy，内容为Acquire::http::Proxy "http://10.0.0.1:8080";（注意末尾分号不能丢） -
yum（RHEL/CentOS 7）：追加proxy=http://10.0.0.1:8080到/etc/yum.conf；不支持https_proxy字段，https_proxy对yum无效 -
dnf（RHEL/CentOS 8+）：同yum，但支持proxy_ssl_verify=0绕过证书校验（慎用） - 验证是否真走代理：
sudo apt update -o Debug::Acquire::http=true 2>&1 | grep "Connecting to"，看到连接目标 IP 才算生效
Git clone 超时却没走代理？
Git 默认不读http_proxy，它有自己的配置层级：
- 强制走代理：
git config --global http.proxy http://10.0.0.1:8080 - 取消代理：
git config --global --unset http.proxy - 若代理需认证，URL 中密码含
@、/等字符，必须先 URL 编码（如ab@c/d→ab%40c%2Fd），否则解析失败 - 临时覆盖单次操作：
git -c http.proxy=http://p:8080 clone https://github.com/user/repo
最易被忽略的点：systemd 服务、cron 任务、GUI 应用启动的终端，都不加载~/.bashrc，所以写在里面的export对它们完全无效；需要单独用Environment=注入，或改用/etc/environment（但该文件不支持export语法，只接受KEY=VALUE行）。
