终端 Git 与 curl 不走 Clash？Windows http_proxy 环境变量配置步骤（2026）

现象：浏览器畅通，终端里的 `git`、`curl` 却在超时

很多开发者遇到过同一种割裂：Edge / Chrome 已经能打开 GitHub、npm registry 或境外文档站，桌面上的 Clash（或 Verge / Meta 系图形客户端）状态栏也显示运行中；可是一回到 PowerShell、CMD 或 Git Bash，执行 git clone、curl https://...、部分语言的包管理器下载时，要么长时间卡住，要么直接报连接超时。有人会误以为「开了系统代理」或「勾了 TUN」就应覆盖整机所有进程——实际上，命令行工具大多不会自动读取浏览器那张 PAC，也未必跟随你在图形界面里配置的「仅限浏览器」扩展；它们更常见的行为，是去读进程环境中的 HTTP 代理变量，或使用各自的配置文件（例如 Git 的 http.proxy）。不把这一条链路补齐，就会出现「肉眼所见能上外网，脚本与仓库却始终直连」的体验断层。

本文锁定原生 Windows 会话（宿主机上的终端窗口）：如何把流量显式指向本机 Clash 监听的 mixed-port（常见示例端口为 7890，请以你的配置为准）。这与本站第 21 篇 WSL2 里让 apt、git 走宿主机 Clash 互补：那边要解决的是Linux 子系统里的环回与宿主机 IP；本篇要解决的是Windows 本机命令行如何用 127.0.0.1 接到同一个 mixed-port，二者不要混在一套变量里排查。

💡

读完你应能独立完成三件事：确认 Clash 在本机 mixed-port 上监听且端口未被占用；在当前终端会话（或用户级持久环境）里写好 HTTP_PROXY / HTTPS_PROXY；为 Git 单独配置或与全局变量一致的代理，并能用一条 curl 命令验证再走分支排查。

为什么「系统代理开着」不等于终端自动走 Clash

Windows「设置 → 网络和 Internet → 代理」里的手动代理或脚本地址（PAC），主要服务对象是遵循 WinHTTP / 系统代理栈的应用（不少 Chromium 内核浏览器会接入这一套）。但很多控制台程序在历史上更接近 Unix 惯例：先看大小写不完全统一的 HTTP_PROXY、HTTPS_PROXY、http_proxy、ALL_PROXY 等环境变量；少数工具只看其中几种，极少数还会忽略全局变量除非你显式传递参数。Clash 在开启TUN 模式或虚拟网卡接管路由时，确实能让更多进程的 IP 层流量「看起来像全局翻墙」，但并不是每一种 CLI 场景都能在不经调试的前提下立刻受益——版本差异、DNS、IPv6、以及进程是否走了虚拟网卡，都会影响观测结果。于是更稳妥的工程习惯仍是：在你确定的终端会话里，把代理写清楚；排障时再对照连接日志。

若你希望深入「路由层接管」与策略分流的全貌，可并行阅读 Clash TUN 模式详解；本文刻意保持在HTTP 代理端口 + 环境变量 / Git 配置这一层，便于复制粘贴与团队协作对齐。

先确认：mixed-port、监听地址与本机连通

在填写任何代理 URL 之前，请先在 Clash 图形客户端或配置中确认mixed-port（或单独打开的 HTTP 端口）是多少，并确认在该端口上确实有进程监听。若你看到客户端报错端口占用、无法拉起内核，可先对照 7890 端口与 mixed-port 占用排查，避免一边改环境变量一边其实是端口根本没起来。

对仅在同一台 Windows 上打开的终端而言，代理地址通常写成 http://127.0.0.1:端口 即可：不需要像 WSL2 那样再去推算宿主机 IPv4。前提是 Clash 在本机的环回地址上接受了入站连接——绝大多数默认配置即是如此。若你曾在客户端里把监听改成仅限局域网接口或自定义 IP，请以实际监听地址为准。

PowerShell：会话级变量（临时生效）

适合「只在当前窗口做克隆或调试」的场景：打开 PowerShell，先设置当前进程可见的环境变量（关闭窗口后即失效）：

# Replace 7890 with your Clash mixed-port
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY   = "http://127.0.0.1:7890"

之所以 HTTPS 流量仍常见地写成 http://127.0.0.1:端口，是因为此处指向的是本地 HTTP 代理协议的 CONNECT 隧道入口，而不是「明文 HTTP 直连境外」。这与 curl、Git、多数包管理器的惯例一致。

随后在同一窗口执行验证：

curl.exe -v https://www.google.com/generate_204

若你能看到 TLS 握手完成且返回码合理，说明curl 已吃到代理变量。若仍直连失败，可加对照：curl.exe -v -x http://127.0.0.1:7890 https://...，强制指定代理以区分「变量未生效」与「端口不可达」。

PowerShell：写入用户环境变量（新开终端仍保留）

若你希望图形界面启动的普通终端默认带上代理，可把变量写入用户环境（不需要管理员时也常用这种做法）：在 PowerShell 中执行 [Environment]::SetEnvironmentVariable(...)，或通过「系统属性 → 环境变量」手动新建用户变量 HTTP_PROXY、HTTPS_PROXY。注意：已经打开的 IDE / 终端不会自动刷新，需要关掉重开才会读到新值。

团队内部若要切换「全天代理」与「仅翻墙会话」，更常见的做法是不写持久全局变量，而是在项目文档里固定一组会话命令；或在脚本开头显式 $env:...，避免同事的内网仓库也被误送进隧道。

CMD：`set` 与 `setx`

在命令提示符当前窗口临时生效：

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890

若要用 setx 写入用户级持久变量，请注意 setx 的行为特点：不会影响当前 CMD 会话，新开 CMD 才会生效；且过长字符串需谨慎截断（官方文档对长度有限制）。写入前建议备份原有用户变量或先在图形界面核对。

`NO_PROXY`：别让内网与国内镜像误走隧道

当你把全局代理指向境外节点时，务必同步维护例外列表：NO_PROXY（或 no_proxy）里列出公司 Git、私有 npm/registry、局域网段主机名等。示例（按需增减）：

# PowerShell session example
$env:NO_PROXY = "localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.corp.example.com"

否则容易出现「国外站能上，反而拉不下来自家镜像」的反直觉故障——那不是 Clash 坏了，而是本该直连的流量被送错了出口。

Git 代理：`git config` 与环境变量并存关系

对使用 https:// 远端仓库的场景，Git 会参考 http.proxy / https.proxy，也会继承环境中的代理变量（具体优先级在不同 Git 版本与实现细节上略有差异，实践中二者择一保持清晰往往更省事）。可直接写入全局配置：

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

若某仓库必须直连，可对单仓库取消：

git config --local http.proxy ""
git config --local https.proxy ""

若你使用 [email protected]:user/repo.git 这类 SSH 协议，HTTP 代理变量不会接管 SSH 的 TCP；要让 SSH 也走本地隧道，需要另配 ProxyCommand 或等价方案——这已经超出「填 mixed-port 就行」的范畴，多数克隆海外公开仓库的团队会直接改用 HTTPS 远端以降低心智负担。

Git Bash / MSYS：继承 Windows 变量与 `export`

从开始菜单启动的 Git Bash一般会继承你在 Windows「用户环境变量」里配置的 HTTP_PROXY 等；若你仅在某个 PowerShell 窗口里临时 $env:...，Git Bash 不会自动共享那一段会话内存。要在 Bash 会话内生效，可直接：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

可把上述两行写入 ~/.bashrc（注意这会长期影响该环境的交互 shell）；CI、自动化脚本则更推荐「调用前 export」而非依赖个人登录会话。

推荐验证顺序：curl → Git → 业务脚本

与其一上来就 clone 巨型单体仓库，不如先用最小命令确认链路：curl 或 curl.exe（在 Git Bash 里若要绕过 MSYS 的路径改写，常用 curl.exe）、随后 git ls-remote https://...，最后再跑依赖外部源的构建脚本。若某一步失败，请打开连接日志与规则命中，对照请求是否进入 Clash、命中哪条规则——这比盲目怀疑账号或 SSH key 更有效。

常见误区小结

误以为 mixed-port「只能 SOCKS」

mixed-port在主流内核语义里通常同时承载 HTTP 代理与 SOCKS；对 curl、Git、多数开发者工具而言，写成 http://127.0.0.1:端口 指向 mixed 服务即可。若某工具仅支持 SOCKS，再改用 socks5://127.0.0.1:端口 并对照文档逐一验证。

只靠浏览器插件翻墙

插件往往只劫持浏览器标签页内的 HTTP(S)；终端进程默认不走插件。要让 CLI 稳定，请以系统环境变量或 Git 配置为准，而不是指望插件规则外溢。

下班不关代理变量导致内网异常

持久化的用户级 HTTP_PROXY 在你接入公司 VPN 或回到家中局域网时，仍可能生效；遇到「突然间连不上内部仓库」时，优先检查代理残留与 NO_PROXY。

尚未装好 Windows 客户端时先看安装篇

若你连 mixed-port、订阅导入都尚未就绪，请先按 Clash Verge Rev Windows 教程跑通最小闭环，再回到本文填终端变量——否则容易出现「变量写得都对，但内核没在监听」的假阳性。

对比之下，开源内核在长连接稳定性与分流颗粒度上的体验往往优于拼凑多款临时工具；尤其在多人协作仓库与 CI 对齐代理写法时，一套明确的 HTTP 代理端口约定能显著降低沟通成本。日常你若需要在浏览器外维持一致的上网入口，与其在每个脚本里硬编码境外 IP，不如把本地 mixed-port当作团队共识里的「出站语义锚点」，再用规则文件消化境内外分流。

需要核对 YAML 字段含义或策略组语义时，可从本站使用文档中心查表；若要为本机挑选可持续更新的图形客户端与内核组合，优先通过 Clash 客户端下载页获取对应平台的安装指引，而不是把 Release 页当成唯一入口。→ 立即免费下载 Clash，开启流畅上网新体验