Git HTTPS 克隆报 Could not resolve proxy，清除全局代理后仍失败
Git HTTPS 报代理无法解析时，只清除一个全局键可能无效。追踪配置文件、URL 专用设置、remote 代理和环境变量，再按实际出处修正并核验连接。
通过 HTTPS 克隆仓库时，Git 可能在开始下载前退出：
fatal: unable to access 'https://code.example.com/team/project.git/': Could not resolve proxy: old-proxy
浏览器能打开仓库页面，执行过 git config --global --unset https.proxy 也没有变化。先确认 Git 使用的代理地址从哪里来。报错中的 old-proxy 是代理主机名，不是仓库服务器；检查目标网站的 DNS，未必能解释代理为什么无法解析。
本文处理 Git 自带 HTTP(S) 传输中的代理解析失败。SSH 地址、代理认证失败、连接超时和证书校验失败，需要按各自错误处理。示例域名、代理名和路径均是占位值。
HTTPS 请求也要检查 http.proxy
Git 的 http.proxy 用于 HTTP(S) 传输，并非只对 http:// 地址生效。不要把 Git 配置键 https.proxy 与环境变量 https_proxy 混为一谈：它们属于不同的配置机制。只删除前者，不能保证清除了 Git 实际使用的代理。
此外，--global 只指定用户级配置。系统配置、当前仓库配置、包含进来的文件、URL 专用设置和当前进程的环境变量，都可能仍然提供代理。重复同一条 unset 命令，仍无法判断实际生效的是哪一项。
在报错的同一个终端、同一个工作目录读取配置：
git --version
git config --show-origin --get-regexp "^(http|https)\..*proxy$|^remote\..*\.proxy$"
这会列出相关键值及配置出处。输出可能包含代理账号和密码，只在受控终端查看；对外提供记录时隐藏凭据。没有匹配项时，查询可无输出并返回非零状态，这不意味着 Git 没有从环境读取代理。
这里使用仍兼容的 --get-regexp 等旧式查询语法。较新的 Git 已提供 config get 等子命令；若安装版本不支持 --show-origin，应先使用本机帮助确认可用语法，或升级到受支持版本，再追踪出处，不要根据一份手工打开的文件推断全部配置。
克隆失败时，目标目录可能还没有有效仓库，无需先进入那个目录。对于已有仓库的 fetch 失败，则要在该仓库内查询，否则可能漏掉它自己的配置及条件包含规则。
分清通用设置、URL 设置和 remote 设置
如果结果包含 http.proxy，记下它来自哪个文件；若是类似 http.https://code.example.com/.proxy 的键，它只对匹配 URL 生效。匹配更具体的路径可以优先于更宽泛的地址，因此只看通用键可能漏掉真正的值。
用实际 HTTPS 地址检查匹配结果：
git config --get-urlmatch http.proxy https://code.example.com/team/project.git
这一步检查 Git 的 URL 配置匹配，不负责展示环境变量，也不能代替已有 remote 的专用代理检查。若原命令使用 origin，继续核对：
git remote get-url origin
git config --show-origin --get-all remote.origin.proxy
origin 要替换成实际 remote 名。remote.<name>.proxy 可以覆盖 HTTP 代理设置。get-url 还会展开 URL 重写规则；如果得到的地址与预期不同，应以实际访问地址检查匹配配置，而不是只围绕输入时看见的域名。
不要把正常的公司代理一律当作残留。若当前网络必须使用它，处理方向是核对代理主机名、端口和所需网络连接；只有确认不再需要那条代理时，才考虑移除或禁用。
检查终端继承的代理变量
Git 配置没有代理，仍可能从环境获得 https_proxy、HTTPS_PROXY、all_proxy 或 ALL_PROXY。HTTP 请求还要检查小写 http_proxy；不要假定大小写写法在所有协议下都等效。
以下命令适用于 Bash，包括 Linux、macOS 终端中的 Bash 和 Windows Git Bash；它只报告变量是否存在，不打印内容：
for name in http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY; do
if printenv "$name" >/dev/null; then
printf '%s is set\n' "$name"
fi
done
“已设置”并不代表一定生效，还要结合协议、Git 配置和代理排除规则判断。浏览器、IDE、Git Bash 和 Windows CMD 也不一定继承同一份环境。在系统设置中删除变量后，已经打开的终端或 IDE 可能仍保留旧环境，需要从更新后的父进程重新启动再检查。
若已确认 Git 配置没有有效代理，且当前网络允许直连，可以用子 Shell 临时排除这些环境变量，再尝试只读取远端引用：
(
unset http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
git ls-remote https://code.example.com/team/project.git HEAD
)
括号内的 unset 不会清除外层终端的变量。这段仅适用于 Bash 等支持该语法的 Shell，不要原样粘贴进 CMD 或 PowerShell。它也不会清除 Git 配置里的代理；若仍显示同一个代理名，继续查配置出处、启动包装脚本或 IDE 注入的参数。
已有 remote 可先做一次临时直连对照
对于已有仓库，确认允许直连后，可临时禁用指定 remote 的代理：
git -c remote.origin.proxy= ls-remote origin HEAD
末尾的等号必须保留，表示把这个配置值设为空字符串。该设置只作用于这次 Git 命令，不会写入配置文件。它针对已有的 origin，不适用于尚未建立该 remote 的克隆目录。
如果原命令报代理无法解析，而这次能列出远端引用，说明直接访问路径可用，原来的代理选择值得继续修正。如果错误变为目标主机无法解析、连接失败或认证失败，只能说明故障阶段变了，不能宣称仓库访问已经恢复。
只修改已经确认的出处
永久调整前，备份实际配置文件并记录原值。若明确确认失效项就是用户级普通 http.proxy，并且同名值都应移除，才执行：
git config --global --unset-all http.proxy
如果值来自仓库本地、系统级或 include 文件，不能照搬这条命令。应修改查询结果标出的文件及准确键名；系统级策略由管理员维护，包含文件也不要误当成主配置的一部分去覆盖。不要删除整份 .gitconfig，里面可能还有身份、签名及其他正常设置。
“删除值”和“把值设为空”也有区别：删除某一层后，其他层或环境中的代理可能重新生效。已有仓库若确定只有这一个 remote 应直连，可有意设置本地空值：
git config --local remote.origin.proxy ""
这会持续禁用该仓库中 origin 的代理。若原来已有本地值，需要保存它以便恢复；若原来没有这项，回退时删除新加的键即可：
git config --local --unset-all remote.origin.proxy
如果问题来自环境变量，应修正真正设置它的启动文件、系统用户环境或 IDE 启动配置，而不是每次开终端手动清空。需要代理的其他工具可能共用这些变量，变更前应确认影响范围。
用原来的入口复查
调整后，在原来报错的终端或 IDE 中重试相同 HTTPS 地址。可先运行 git ls-remote 检查远端通信，再进行正常克隆或 fetch。对于空仓库，没有 HEAD 行不一定表示通信失败，应同时查看退出状态和错误输出。
修复标准是原来的代理解析错误消失，且所需仓库操作实际成功；一次临时直连成功并不代表持久配置已经改对。整个处理不需要关闭 http.sslVerify，也不需要用 reset、强制推送或删除本地提交来修复网络代理。