现象:浏览器正常,终端工具却直连失败
很多开发者在系统里配好了代理,浏览器访问正常,但打开终端跑 curl、git clone、npm install 却依旧直连失败。根本原因是系统代理设置和命令行工具读取的代理配置是两套机制,互不相通。
原因一:大小写与作用域问题
不同工具读取代理变量的规则差异
HTTP_PROXY 和 http_proxy 在部分工具里是两个不同的变量,curl 两者都识,但部分语言运行时只识小写。另外,用 export 声明的变量只对当前 shell 会话及其子进程生效,新开的终端窗口或 CI 运行环境默认不会继承。git 更特殊,它优先读 ~/.gitconfig 里的 http.proxy 配置项,即使环境变量设对也会被配置文件里的旧值覆盖。
原因二:系统代理不等于进程级代理
系统网络设置里的代理开关主要面向图形化应用(浏览器、邮件客户端等),大多数命令行工具并不会主动读取这个系统设置,必须通过环境变量或工具自身配置文件单独告知。这也是为什么浏览器能连但终端不行的根本原因。
原因三:NO_PROXY 配置不当
NO_PROXY 用于声明哪些地址不走代理,常见错误有两种:一是把内网地址段写得过宽,误将需要走代理的域名也排除在外;二是完全未配置,导致访问内网服务(比如公司内部 GitLab)也被绕道进代理,反而报错。
逐项验证方法
| 排查项 | 验证命令 | 预期结果 |
|---|---|---|
| 环境变量是否生效 | env | grep -i proxy | 大小写变量都能看到预期值 |
| git 是否走了自己的配置 | git config --global --get http.proxy | 为空或与环境变量一致 |
| NO_PROXY 是否误排除目标域名 | echo $NO_PROXY | 不包含需要走代理的域名 |
| 实际请求是否真走代理 | curl -v https://example.com | 日志里能看到 CONNECT 代理握手记录 |
NasaCode 的解决思路
与其逐个工具配环境变量,不如直接用 NasaCode 客户端的智能路由在系统层接管流量,不依赖单个工具是否主动识别代理变量,从根本上避免“浏览器行但 CLI 不行”这类参差。
常见问题
为什么 sudo 命令下代理又失效了?
sudo 默认会清空当前用户的环境变量,需要用 sudo -E 保留环境,或在 /etc/sudoers 里显式白名单代理相关变量。
Docker 容器内为什么看不到宿主机的代理设置?
容器是独立网络命名空间,宿主机的环境变量默认不会传递进去,需要在 docker run 时用 -e 显式传入或在 Dockerfile 里单独声明。
