故障排查

Git 还在连接旧代理：怎样查出配置来自哪里？

代理端口已经改了，只有某个 Git 仓库仍连旧地址？先查配置来源与作用域，再区分 URL 匹配、remote 覆盖和启动环境，避免清空全局配置。

2026/10/27 · 3 项官方来源

先看重点先用 show-origin 与 show-scope 找到旧代理的来源，再分别检查 URL 匹配和 remote 覆盖。只清除一个全局值，不能证明其他来源已经消失。

先固定失败的仓库和启动方式

Clash 已换端口，curl 显式代理也能返回页面，Git 却继续报连接旧端口失败。此时先记录“在哪个仓库、用哪个终端或 IDE、执行什么命令”，不要反复添加全局代理值。同一台电脑上，一个仓库正常、另一个失败，正是检查配置来源的线索。

本文处理 Git 的 HTTP/HTTPS 传输。若远程实际是 SSH，先看HTTPS 与 SSH 的代理边界；若所有终端工具都失败，先做终端入口检查。这里的示例不代表你的代理、账户或仓库已经实测通过。

在出问题的仓库目录先查询取回地址，下面这条命令会考虑 insteadOf 重写，但不连接远端：

git ls-remote --get-url origin

origin 必须替换为实际 remote 名称；没有这个 remote 时先确认仓库，不能拿报错当成网络失败。若结果已变成 SSH，后面的 HTTP 代理检查不适用。取回和推送还可能使用不同地址，本文的读取验证不证明推送权限。

把值、作用域和文件来源一起查出来

先在本机查看，不要把原始输出贴到公开位置。代理 URL 可能带密码，路径可能含用户名，仓库地址也可能暴露内部项目。以下查询只筛选代理相关键，但输出仍需要脱敏。

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

这条命令不修改配置。重点看三部分：system/global/local/worktree/command 表示作用域，file 后的路径或 command line 表示来源，最后是键和值。没有匹配项时可能返回非零退出码且不输出结果；这不等于网络故障。出现 unknown option 则先核对 Git 版本和本机帮助。

同一个普通键可能出现在多处；默认读取过程里，后读到的单值通常覆盖前面的值。global 查询只看用户级文件，不能证明当前仓库没有 local、可选 worktree 或命令级配置。include/includeIf 还会引入其他文件，因此应看实际来源，别只凭“我已经改了 .gitconfig”判断。

本文沿用兼容较多已安装版本的查询写法；当前官方文档也提供 git config get 子命令。不要把不同写法的选项随意拼接，先按自己的版本帮助使用。

为什么改了 http.proxy，特定仓库仍不变

除了同名键的作用域，还要看键本身是否针对 URL 或 remote。三种情况不能合并成“最后一行总生效”：

http.proxy：HTTP 传输的普通代理设置。
http.https://example.com/.proxy 一类键：只对匹配 URL 生效，更具体的匹配可能决定结果。
remote.origin.proxy：指定 remote 的代理选择；官方定义空字符串为对该 remote 禁用代理，不等于“没有配置”。

对实际 HTTPS URL 单独查询匹配结果，下例域名和路径只是占位：

git config --get-urlmatch http.proxy https://example.com/team/repo.git

把 URL 换成上一步确认的地址，并去掉不应公开的凭据。这个查询帮助判断 HTTP URL 匹配，不是完整的网络路径探测，也不会替你检查 named remote 的覆盖。再回到来源列表，单独核对所用 remote 的 proxy 项。URL 匹配查询与来源查询分开执行，不把 show-origin/show-scope 选项直接拼进这条旧式查询。

例如普通值已从 7890 改到 7897，某个站点专用键仍是 7890，就不能继续靠重复写普通值解决。删除用户级普通键后仍有旧入口，也可能是仓库文件或条件引入文件提供了它；先确认来源，再决定是否应改。

终端查不到，不代表 IDE 没有另一套输入

Git 的 HTTP 代理还可能来自 http_proxy、https_proxy、all_proxy 等环境变量；NO_PROXY 可能使目标绕过代理。配置查询不列出所有这些环境输入，也不能证明代理最终被采用。

IDE 启动时间、内置 Git、终端所用 Git 和工作目录都可能不同。先在发生故障的环境核对 Git 版本、仓库目录和该应用的 Git 设置；终端刚改了变量，早已启动的 IDE 未必同步。若启动脚本使用了 git -c，另开终端运行 config 也不会复现那次调用的命令级值。

只检查与故障相关的启动项或变量。不要输出整个环境、关闭证书校验，或清空凭据助手来“试试看”；代理入口、网站认证和证书信任属于不同问题。

用同一个 remote 做一次临时对照

先确认该 remote 本来使用 HTTPS、目标和代理均获准访问、实际 HTTP/mixed 端口已知。下例只给这一次调用指定 remote.origin.proxy，查询远端 HEAD，不克隆、推送或改配置文件：

git -c remote.origin.proxy=http://127.0.0.1:7890 ls-remote origin HEAD

两处 origin 都应对应同一个实际 remote，7890 只是示例端口。这不是让你清除 NO_PROXY 或绕过组织策略；已有排除规则仍应核对。若需要代理认证，使用既有认可的凭据方式，不把密码写进命令或代理 URL。

只做一次，迟迟没有结果时可在约 15 秒后按 Ctrl-C 停止；这不是命令自带的总超时保证。返回 HEAD 引用及对象 ID，只能说明本次只读操作完成，不证明长时间传输、其他仓库或写入权限。若仓库本来没有可返回的 HEAD，空输出也不能简单当作连接失败。

临时指定入口后成功，而原调用仍报旧端口，可以继续比对来源与启动参数；这仍不是“所有配置都修好了”。连接拒绝先查监听；407 查代理认证；401/403、明确权限拒绝或证书错误应停止在对应层，不换账号、协议或出口规避。

只修已确认的来源，并保留恢复记录

记下原文件路径、作用域、完整键名和原值，在本地保留备份；含凭据的备份不要上传。
确认这项配置由自己维护后，只编辑确证过期的值。受管理的 system 配置或团队 include 文件交由维护者处理，不靠更高权限覆盖。
重新执行来源查询和 URL 匹配查询，再在原启动环境对同一个 remote 做一次只读检查。需要重开 IDE 时先保存工作。
若结果变差，恢复本次改动的那一项并复查；不要删除整份 .gitconfig、.git/config 或凭据文件。

上面的 -c 随该次 Git 调用结束失效，无须额外 unset。不要把空代理值当成“恢复原状”：它在某些配置中有明确的禁用含义。求助时给出脱敏后的来源、键名、错误类型与发生环境，按日志脱敏方法隐去账号、令牌、代理密码和私有路径。

官方参考

2026/10/27 核对官方说明；查询示例仅在临时构造的离线配置中核对语法与作用域，不代表用户网络实测。