浏览器能上网，Git 和 curl 却连不上？Windows 终端代理排查
浏览器能打开网站，Git 和 curl 却超时，先检查终端程序是否使用了正确的代理入口。浏览器成功只能证明它自己的访问路径可用；终端还可能受到代理环境变量、Git 配置和 DNS 解析方式影响。推荐顺序是：确认本地端口 → 单次 curl 测试 → 检查环境变量 → 单独验证 Git。
作者：小仓 · 资料核对日期：2026-09-29
本文面向 Windows PowerShell，适用于本机代理客户端已经运行、浏览器可访问目标站点的情况。命令用于定位问题，不是机场或节点的实测排名。概念不清楚时，可先看VPN、机场和代理的区别。
一、先找对本地代理协议和端口
在客户端设置里确认本地监听地址、HTTP 或混合端口、SOCKS 端口。这里要填写电脑上的代理入口，不是机场订阅链接，也不是远端节点端口。
| 客户端提供的入口 | 代理地址示例 | 注意事项 |
|---|---|---|
| HTTP 或支持 HTTP 的混合端口 | http://127.0.0.1:7890 |
7890 仅为示例，必须换成实际端口 |
| SOCKS5 端口 | socks5h://127.0.0.1:1080 |
1080 同样只是示例，不能与 HTTP 端口混用 |
目标网站是 HTTPS，不代表本地代理地址也必须写成 https://。HTTP 代理可以通过 CONNECT 为 HTTPS 建立隧道；代理地址中的协议描述的是连接代理的方式。参见curl 的 HTTP 代理说明。
二、用 curl 做一次可解释的测试
打开 PowerShell，先执行 curl.exe --version 和 git --version，记录版本。下面使用明确的 curl.exe，并把示例端口替换成真实值：
$proxyUrl = 'http://127.0.0.1:7890'
curl.exe -q --proxy $proxyUrl --noproxy 'localhost,127.0.0.1' --head --connect-timeout 10 --max-time 20 https://github.com
-q 放在首个参数位置，跳过默认 curl 配置文件；--proxy 指定本次代理；--noproxy 将本次绕过列表限定为两个回环地址，避免已有的 NO_PROXY 让 GitHub 绕过代理。--head 只请求响应头，连接阶段最多等待 10 秒，整个请求最多 20 秒。参数依据curl 官方手册。
不要只看第一行 200 Connection established：它表示代理隧道建立，后续 TLS 或目标响应仍可能失败。应查看完整输出和最终响应。返回 301、403 或 405 也不等于网络完全不通；它们可能分别涉及跳转、访问策略或请求方法。这次测试不下载页面正文，也不能证明大文件克隆稳定。
需要核对 curl 是否连到本地入口时，可加 --verbose，同时查看客户端对应时间的连接记录。日志分享前删去认证头、账户、令牌及带密码的代理地址。
三、检查 HTTPS_PROXY、ALL_PROXY 和 NO_PROXY
单次指定代理成功、普通命令失败时，再检查配置来源：
| 项目 | 应检查什么 |
|---|---|
HTTPS_PROXY |
HTTPS 请求是否指向仍在运行的本地端口 |
ALL_PROXY |
是否遗留旧代理；存在协议专用变量时，它通常只是后备 |
NO_PROXY |
是否包含目标域名或 *，导致绕过代理 |
这些是 curl 支持的约定，不能推定每个终端工具都完全相同。HTTPS_PROXY 的值可以是 http://127.0.0.1:实际端口；变量名对应目标请求协议，值对应代理入口。规则见curl 代理环境变量文档。
若确实需要在当前窗口试用环境变量，可以保存旧值、执行测试后恢复：
$previousHttpsProxy = $env:HTTPS_PROXY
try {
$env:HTTPS_PROXY = $proxyUrl
curl.exe -q --head --connect-timeout 10 --max-time 20 https://github.com
} finally {
$env:HTTPS_PROXY = $previousHttpsProxy
}
这次故意不覆盖 NO_PROXY，便于与上一节对照；结果不同时，应检查绕过列表。PowerShell 中这样修改变量只影响当前进程及随后启动、继承其环境的子进程，已经打开的 IDE 不会自动获得修改。依据Microsoft 环境变量文档。
四、curl 正常后，再查 Git 自己的配置
先在发生问题的仓库目录查看匹配目标 URL 的代理配置及来源：
git config get --show-origin --url=https://github.com/git/git.git http.proxy
旧版 Git 不支持 config get 时，可用 git config --show-origin --get-urlmatch http.proxy https://github.com/git/git.git。无输出不代表一定直连，环境变量仍可能生效。还要留意按 URL 设置的代理，以及 remote.<name>.proxy。参见Git 配置文档。
接着用公开仓库验证一次 HTTPS Git 请求：
git -c "http.https://github.com/git/git.git.proxy=$proxyUrl" ls-remote https://github.com/git/git.git HEAD
这里的 -c 只为本次命令传入配置；ls-remote 读取远端引用。出现提交 ID 和 HEAD，说明此次引用查询成功，不证明私有仓库权限或完整克隆速度。长时间无响应可按 Ctrl+C 停止；这个 Git 示例没有继承前面 curl 的超时参数。
如果实际仓库地址是 git@github.com:组织/仓库.git，走的是 SSH，应按 SSH 的连接路径排查，不能把 HTTP 代理配置当成通用修复。
五、按失败阶段决定下一步
| 观察到的现象 | 优先检查 |
|---|---|
| 连接本地地址被拒绝 | 客户端是否运行、端口是否填错、是否监听该地址 |
| 代理返回 407 | 代理认证要求，而非先改仓库密码 |
| 目标域名解析失败 | 实际使用的代理协议、绕过列表和解析位置 |
| TLS 证书校验失败 | 系统时间、证书链、工具使用的信任库 |
| 公开仓库可读，私有仓库失败 | 仓库地址、账户权限与凭据 |
证书错误不要用关闭校验作为长期修复。不同 curl 构建可能采用不同信任库，浏览器成功不能直接证明终端信任链正确。参见curl 证书验证说明。
socks5 与 socks5h 为什么结果不同？
对 curl 而言，socks5:// 由 curl 解析目标域名，socks5h:// 把目标域名交给 SOCKS 代理处理。它改变的是这次连接的解析分工，不代表整台电脑的 DNS 都被代理，也不保证代理端最终怎样查询。参见curl SOCKS 文档。
什么时候需要回到系统网络排查？
若浏览器也开始失败，或多种应用同时断网，就不再是单一终端配置问题。可按Windows 11 的 VPN 联网排查清单检查基础连接、DNS 与路由。
建议保留一条记录：测试时间、程序版本、代理协议和端口、目标 URL、失败阶段、脱敏后的错误。每轮只改变一个设置，这样才能判断是哪一步改善了结果。
评论