GitHub 与 npm 终端总超时？为 Clash 配置 HTTP 代理与 Git 代理（Windows / macOS / Linux）

为什么浏览器通了，终端还会挂

桌面浏览器一般会读取操作系统的「系统代理」或 PAC，并在发起 HTTPS 前把流量交给本机代理端口。终端里的命令行工具则五花八门：有的会读系统代理（并不保证），有的只认环境变量，还有的（典型如部分 git 场景）需要你在 Git 配置里显式写明代理 URL。再加上 GitHub、npm registry、对象存储与 CDN 主机名分散，任何一环走了不该走的直连，就会表现为「偶发成功、经常超时」。

另一个常见误区是把问题误判成「TLS 坏了」。在跨境链路上，直连失败、握手重试、中间设备干扰都会让 OpenSSL 日志看起来像证书或协议异常；若你把同一 URL 放到已走代理的浏览器里却正常，优先怀疑路由与出口，而不是急着关闭证书校验。

• 系统代理 ≠ 全局生效：未继承该设置的 Shell、服务、CI 本地任务仍可能直连。
• 仅设 HTTP_PROXY 不够：HTTPS 流量常看 HTTPS_PROXY；部分工具会读小写变量名，建议成对设置。
• Git 有独立配置：未设置 http.proxy / https.proxy 时，可能与环境变量行为不一致。

在 Clash 侧先确认端口与模式

打开你的 Clash 配置或客户端概览，记下混合端口（mixed-port）或分别的 HTTP、SOCKS 端口。下文以「HTTP 代理在本机 127.0.0.1:7890」为例；若你的端口不同，请整篇替换数字。确保 Clash 处于规则或全局下对你的目标域名确实走代理，而不是被规则误送到直连；这一点可与 《DNS 与 fake-ip 排查》交叉核对，避免「fake-ip 与终端解析」不一致导致诡异超时。

HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY

以下变量被大量工具识别（名称区分大小写因实现而异，实践中可同时导出大写与小写以覆盖更多程序）：

• HTTP_PROXY / http_proxy：明文 HTTP 与部分库的代理入口。
• HTTPS_PROXY / https_proxy：HTTPS 请求常用；与 HTTP 代理 URL 形式相同（指向本机 Clash 即可）。
• ALL_PROXY / all_proxy：一些运行时把它当作兜底；可设为 SOCKS，例如 socks5h://127.0.0.1:7891。
• NO_PROXY / no_proxy：绕过代理的主机列表，常用 localhost,127.0.0.1,::1，以及内网段（按你环境追加）。

在类 Unix 系统当前 Shell 会话中，可临时验证：

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export no_proxy=localhost,127.0.0.1,::1
export NO_PROXY="$no_proxy"
curl -I https://github.com

若 curl 返回正常响应头，而未导出变量时超时，即可确认问题在「终端未走代理」而非远端站点本身。

macOS 与 Linux：持久化到 Shell 配置

把上述 export 写入你日常使用的 Shell 启动文件（如 ~/.zshrc、~/.bashrc），保存后执行 source ~/.zshrc 或重新打开终端。团队协同时注意：不要把包含敏感订阅或令牌的内容写进代理行；此处仅是本机回环地址，风险较低。

若你使用 SSH 登录远程 Linux 再执行 git / npm，代理需要在远端会话里可用：要么在远端同样配置回环代理（远端也跑 Clash 或转发端口），要么改用 SSH 动态转发等方案——这已经超出「本机 Clash」范围，需单独评估安全域。

Windows：PowerShell、CMD 与持久环境变量

在 PowerShell 当前会话可设：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -I https://github.com

需要写入用户级持久变量时，可使用「系统属性 → 环境变量」图形界面，或在 PowerShell 中调用 [Environment]::SetEnvironmentVariable。改完后重新打开终端应用，避免旧进程缓存旧值。

若你在 Windows Terminal 里混用 WSL，请记住：WSL 与 Windows 不是同一个网络命名空间，127.0.0.1 在 WSL 内指向 Linux 自身。要在 WSL 里访问 Windows 上的 Clash，通常需要使用宿主 IP或镜像网络模式；请直接对照 《WSL2 与 Clash》中的表格逐步核对，本篇不再重复端口转发细节。

Git：http.proxy、https.proxy 与 GitHub

即使环境变量正确，部分 Git 版本或封装仍可能让你感觉「Git 不听话」。为 Git 单独指定代理是最稳的补丁之一：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# For SSH remotes, proxy jump is a different topic; HTTPS clone uses the above.

若你希望仅 GitHub 走代理，可使用带 URL 的配置键（示意）：

git config --global http.https://github.com.proxy http://127.0.0.1:7890

撤销时：

git config --global --unset http.proxy
git config --global --unset https.proxy

使用 SSH 协议 [email protected]: 时，流量不经上述 HTTP 代理，而走 SSH 22 端口；需要代理时通常要配置 ProxyCommand 或改用 HTTPS 远端。选型时请在团队规范与安全要求之间取舍。

npm、pnpm 与 Yarn

npm 会尊重 HTTP_PROXY / HTTPS_PROXY 环境变量；也可使用专用配置：

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

企业内网常配合私有 registry；此时仍建议保留合理的 NO_PROXY，避免内网包错误地绕一大圈。若安装依赖时仍卡在 tarball 下载，请用 npm config get registry 确认 registry 主机，并在 Clash 日志里观察该主机是否命中预期策略。

pnpm 与 Yarn 系列同样优先读取环境变量；遇到缓存目录权限或离线模式干扰时，先排除 npm_config_ 前缀的环境残留，再复测网络。

何时用 SOCKS 与 ALL_PROXY

某些库或语言运行时对 SOCKS 支持更好，或在 HTTP 代理链路上行为异常，可尝试：

export ALL_PROXY=socks5h://127.0.0.1:7891

其中端口 7891 仅为示例，请与你的 Clash SOCKS 端口一致；socks5h 让代理端解析域名，降低本地 DNS 污染对 CLI 的影响。若你不确定端口，优先在 Clash 界面核对，而不是猜测。

验证顺序建议

常见问题

变量都设了仍然超时

检查 Clash 是否监听在预期地址（仅 127.0.0.1 还是 0.0.0.0）、是否有第二个 VPN 或过滤器抢占路由、以及规则是否把该 CDN 域名送到错误策略组。

证书或 TLS 报错

先确认是否真为证书问题：同一命令在走代理与直连下是否表现不同。不要随意全局关闭校验；若经过公司解密代理，需要按合规流程安装信任根。

CI 与本机不一致

CI 环境通常默认无代理；需要在流水线配置里显式注入环境变量，或使用自建 runner 与网络策略对齐。

实操检查清单

• 记下 Clash mixed-port / HTTP / SOCKS 实际值。
• 为 Shell 持久化 HTTP(S)_PROXY 与 NO_PROXY。
• 为 Git 设置 http.proxy 或按主机名限定代理。
• 为 npm 校验 registry，并视需要设置 proxy / https-proxy。
• WSL 场景改看宿主 IP 与镜像网络，而非盲目使用 127.0.0.1。

小结

终端工具不会自动共享浏览器的「系统代理」心智；把 Clash 的本地入口用标准变量与 Git 配置对齐，是解决 GitHub、npm 超时最高性价比的一步。需要图形客户端与内核能力时，可从 下载页选择合适版本起步。

立即免费下载 Clash，开启流畅上网新体验