浏览器能用，终端却不通？curl、Git 的代理设置与排错

浏览器能打开 GitHub，终端里的 git 却一直等；Clash Verge Rev 的系统代理已经打开，curl 仍然连接失败。遇到这种情况，先确认一件事：这条命令有没有使用客户端的本机代理端口？ 浏览器正常，只能说明浏览器的那条连接可用。

下面先用 curl 验证入口，再检查 Git。示例适用于在安装了代理客户端的同一台电脑上运行命令。还没完成订阅导入和首次连接，可以先按新手指引操作；需要安装软件时，从客户端下载页选择适合系统的安装包。

如果需要更稳定的线路，可以从文末的机场推荐中选择。

01　先找客户端的入口，不是节点服务器的端口

系统代理是一项供应用使用的设置，应用是否遵循它，要看自身实现。命令行程序也有各自的参数和配置，不能把系统代理开关当作所有工具的统一开关。Clash Verge Rev 名词解释

打开客户端设置，找到当前的 HTTP 代理端口或混合端口。Mihomo 的混合端口同时接受 HTTP 和 SOCKS5 代理请求。这里要填的是电脑上客户端监听的端口，不是订阅里某条节点的服务器端口，也不是用于控制面板的 API 端口。Mihomo 代理端口说明

本文假设本机 HTTP／混合端口是 7897，因此入口写成 http://127.0.0.1:7897。7897 只是示例，请把后面所有命令中的数字换成你的实际端口。 客户端需要保持运行，配置也要已经加载。

02　用一条 curl 命令，确认接线是否正确

先在 macOS 或 Linux 终端运行：

curl --proxy http://127.0.0.1:7897 --head --max-time 20 https://example.com

Windows PowerShell 使用下面这一条，明确调用 curl 程序：

curl.exe --proxy http://127.0.0.1:7897 --head --max-time 20 https://example.com

Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的别名，参数和 curl 程序不同。写成 curl.exe 可以避免把两者混用；如果提示找不到程序，先确认 curl 已安装并能从终端调用。Microsoft 的别名说明

这条命令只为当前请求指定代理，用 --head 请求响应头，并用 --max-time 20 限制总等待时间。它不会写入终端配置文件。example.com 是便于说明的测试地址，也可以替换成你实际要访问的公开 HTTPS 页面。curl 参数说明

先看最后有没有来自目标网站的响应，再看客户端的连接记录。访问 HTTPS 时，输出前面可能出现 200 Connection established，它表示代理隧道建立，并不是目标页面已经成功返回。后面的 TLS 握手和网站请求仍然可能失败。HTTP 代理隧道说明

想看连接过程，在命令末尾加上 --verbose。留意它是否连接了你指定的 127.0.0.1 和端口，以及失败发生在连接代理、建立隧道还是访问目标之后。日志可能包含请求头和认证信息，求助时只保留与报错有关的部分。curl 详细输出说明

同时打开客户端的连接页，重新执行命令，按目标域名查找新记录。若显示 DIRECT，请求也可能已经正确进入客户端，只是命中了直连策略。需要改变出口时，应检查规则、代理组与实际出口，而不是继续换本机端口。

03　加了代理参数，还要留意绕过设置

curl 也能从环境变量读取代理配置。最常见的是 http_proxy、https_proxy、ALL_PROXY，以及控制哪些地址不走代理的 no_proxy／NO_PROXY。它们不是一个意思：

• http_proxy 和 https_proxy 分别对应访问 HTTP、HTTPS 目标时使用的代理；对 curl，HTTP 那个变量应使用小写名称。
• ALL_PROXY 是没有相应协议专用设置时的后备，不会无条件压过前两项。
• no_proxy／NO_PROXY 是绕过清单。它匹配目标时，即使命令写了 --proxy，curl 也可以跳过代理；值为 * 会匹配所有目标。

这些行为见 curl 官方书籍的代理环境变量说明。如果明确指定代理后仍看不到本机连接，检查绕过清单，比反复开关系统代理更有针对性。

还有一个容易写错的地方：HTTPS 目标不要求把本机代理地址写成 https://。 https_proxy 描述的是要访问哪类目标，变量值里的协议则描述怎样连接代理。如果客户端提供的是普通 HTTP 代理入口，值仍是 http://127.0.0.1:7897；不能只因为目标网站使用 HTTPS，就擅自改成 https://127.0.0.1:7897。curl 代理地址格式

排查期间，先保留单次命令写法就足够了。等连接确认正常，再决定是否给常用工具设置长期代理；不要同时修改环境变量、Git 全局配置和终端启动文件，否则很难判断究竟是哪一项生效。

04　curl 通了，再单独检查 Git

对通过 HTTPS 访问的 Git 仓库，可以先做一次只读检查：

git -c http.proxy=http://127.0.0.1:7897 ls-remote https://github.com/git/git.git HEAD

这条命令读取公开仓库的引用信息，不下载整个项目，也不向仓库推送内容。成功时通常会输出一行提交 ID 和 HEAD。-c 把配置交给这一次 Git 命令，不会把它保存为所有仓库的默认值。Git 命令选项、ls-remote 说明

这里的配置名就是 http.proxy，它也用于 Git 的 HTTPS 传输。如果 curl 已正常而这条命令失败，先确认测试的是同一代理入口，再检查 Git 自己的设置。在出现问题的仓库目录中，可以只读查看：

git config --show-origin --get-regexp '^(http\..*proxy|remote\..*\.proxy|url\..*\.insteadof)$'

没有输出可能只是没有匹配配置，不需要因此新增一堆设置。有输出时，重点看来源文件、是否有旧端口、按网址设置的代理、某个 remote 的独立代理，或把 HTTPS 地址改写成 SSH 的规则。网址专用设置、remote 设置与普通 http.proxy 的作用范围不同，不能只查全局那一项。配置值也可能带认证信息，不要直接公开整段输出。Git 配置说明

如果仓库地址形如 git@github.com:某人/项目.git，它使用的是 SSH。 上面的 http.proxy 不负责 SSH 连接。先确认实际协议，再决定使用仓库提供的 HTTPS 地址，还是按 SSH 的方式单独配置；不要为了让测试命令通过，直接覆盖项目现有的 remote 地址。Git 支持的仓库地址形式

05　根据失败位置，缩小检查范围

无法连接 127.0.0.1:7897、立即拒绝连接。 先检查客户端是否仍在运行、端口是否写对，以及命令是不是在另一套环境里执行。连接还没有进入本机代理时，换远端节点通常无助于解决这个入口问题。

已经连上本机代理，建立隧道或访问目标时超时。 查看客户端对应连接和日志，确认实际出口，再用同一目标比较节点。本站免费节点的可用性会变化，浏览器之前打开的缓存页面也不能证明当前连接可用；具体比较方法见节点超时与测速排查。

得到 403、429 或其他 HTTP 错误。 先确认回应来自哪个环节，再检查目标服务的访问规则、登录要求或请求频率。收到 HTTP 回应与“请求内容符合预期”是两件事，不能把每个非 200 都解释成代理没开。

提示证书校验失败。 检查具体的域名、系统时间、证书链和工具使用的信任库；企业网络若要求专用证书，应按其正式配置处理。不要把 curl -k 或关闭 Git 的 sslVerify 当作长期修复，它们会跳过重要的校验。curl 证书验证说明

06　最后确认：命令到底在哪台“电脑”里运行？

127.0.0.1 指向的是命令所在环境的回环接口。在远程 SSH 会话里，它指的是远程服务器；在容器、虚拟机或 WSL 中，也不能直接假定它等于宿主机代理。某些环境提供宿主机转发或回环互通，但要以实际网络模式为准。可对照 WSL 网络模式与 Docker 网络说明。

如果浏览器在宿主机、命令在另一套环境里，先回到宿主机终端验证本文命令。宿主机能通，再处理两套环境之间怎样连接，不要先把客户端监听改成所有网卡、关闭防火墙来碰运气。本文的本机端口示例不等于已经配置好了跨环境访问。

只需要 curl 和 Git 时，先把它们各自的入口设置清楚。确实有多种应用无法方便地配置代理，再参考系统代理与 TUN 的选择。判断这次排查是否完成，要同时看到：命令进入了正确入口、客户端选择了预期出口、实际请求成功返回。