搜索 K
Appearance
如果你只想拿一个能跑的答案,抄这段就够了:
# PowerShell(当前会话生效,最稳)
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7891"
$env:NO_PROXY = "localhost,127.0.0.1,::1,*.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16":: CMD
set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890# Git(只对 HTTPS 远端生效,SSH 需要另配)
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890三条铁律,记住能省你三天时间:
curl.exe、git、npm、Go/Rust 工具链一律不看它。7890(HTTP/Mixed)与 7891(SOCKS5);v2rayN 系通常是 10809/10808,请自行替换。用错端口的表现是 Failed to connect to 127.0.0.1 port 7890,别去怀疑节点。Windows 的网络接管链路是分层且碎片化的,很多人只按了 UI 上那个开关,就以为万事大吉。
第一层:WinINET。 注册表路径 HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings,ProxyEnable + ProxyServer 两个值。浏览器、Electron 应用(VS Code、Slack、Discord)、部分 .NET Framework 应用读它。这也是"开系统代理浏览器能上"的原因。
第二层:WinHTTP。 完全独立的一套栈,服务于 Windows 服务、BITS、Windows Update、部分企业 VPN 客户端。用 netsh winhttp 配置,默认不跟随 IE 设置。想同步得手动 netsh winhttp import proxy source=ie。这条链路和 Git、curl 依然无关。
第三层:应用自带网络栈。 这是终端场景的主战场:
curl.exe(Win10 1803+ 内置)来自 libcurl,只认环境变量 http_proxy / HTTPS_PROXY / ALL_PROXY,完全不读注册表。Invoke-WebRequest 基于 .NET Framework,会读 IE 设置;而 PowerShell 7 基于 .NET Core,默认不读 IE 设置。这是"PowerShell 5.1 能下包、pwsh 7 却超时"的根因。http.proxy 配置或环境变量,同样不看注册表。net/http、Rust 的 reqwest 都读 HTTP_PROXY 系环境变量。第四层:SOCKS 与 UDP。 HTTP 代理只处理 TCP,且要求客户端实现 CONNECT。SSH 协议走的是裸 TCP,不会被 http.proxy 接管;DNS 的 UDP 53 查询也不会。要彻底覆盖,只能靠 TUN 模式在 WFP/路由层做流量劫持。
为什么终端对链路质量如此敏感? 因为命令行工具绝大多数是长连接 + 大流量 + 无重试缓冲的场景(git clone、docker pull、pip install)。丢包率从 0.1% 涨到 1%,TCP 拥塞窗口就会频繁折半,配合 BBRv3 的带宽探测收敛,实测吞吐可能直接掉 60% 以上。这也解释了为什么"网页能开、clone 卡死"很常见——网页是短连接小包,能忍;clone 是长肥管道,忍不了。
| 维度 | 系统代理开关 | 环境变量 | 客户端端口映射(HTTP/SOCKS) | TUN 模式 |
|---|---|---|---|---|
| 命令行覆盖率 | 约 |