Roxi先看实际失败的是 HTTPS 还是 SSH
git remote -v
git config --show-origin --get-regexp 'http\..*proxy|remote\..*\.proxy'https:// 开头的远程地址走 Git 的 HTTP 传输；[email protected]:owner/repo.git 这类地址走 SSH。Git 的 http.proxy 不会自动接管 SSH。查看结果时留意是否包含私有仓库名、用户名或凭据，向别人反馈前遮盖。未查到代理设置时，第二条命令可能返回非零状态，并不代表 Git 损坏。
到客户端设置中确认本机 HTTP/mixed 端口、SOCKS 端口和内核是否运行。本文的 7890、7891 只是示例，不是所有工具的默认值。控制 API 端口、网页面板端口和代理端口不能互换。
第一步：用 curl 的单次参数验证代理入口
curl --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -I https://github.com
curl --proxy socks5h://127.0.0.1:7891 --connect-timeout 8 --max-time 20 -I https://github.com只执行与你的监听端口类型对应的一条。socks5h 让代理处理目标主机名，而 socks5 通常在本地解析；这能帮助区分 DNS 与代理连接问题。HTTP 代理访问 HTTPS 网站时一般使用 CONNECT，URL 中的 http:// 描述的是到本地代理的协议，不表示目标网页的 HTTPS 被关闭。
连接 127.0.0.1 被拒绝，先修客户端监听；本地连接成功但目标超时，再看节点、规则和 DNS。注意 NO_PROXY/no_proxy 可以让某些目标绕过显式代理；如果你曾设置它，先检查是否包含目标域名。不要盲目清空公司需要的内网例外。
第二步：让一次 Git 请求使用代理
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD返回提交哈希和 HEAD 说明这次 Git HTTPS 访问成功。它不证明你的私有仓库权限正常；私有仓库仍可能要求正确的认证。优先用公开仓库验证通路，再回到真正的仓库操作，把网络问题与账号授权分开。
若浏览器能访问而此命令失败，检查 Git 是否还存在 URL 专属代理、远程专属代理或自带证书配置。Windows 的 WinHTTP 代理又是另一套机制，netsh winhttp show proxy 的结果不能代表 Git、浏览器及所有软件都走同一路径。
第三步：确有需要时，只保存到当前仓库
git config --local http.proxy http://127.0.0.1:7890
git config --show-origin --get-all http.proxy保存前先记下原值。当前仓库配置通常比全局配置更容易控制影响范围，不会让别的内网项目跟着指向你的本地端口。不要把带密码的代理 URL 放进远程仓库地址或公开脚本。更换客户端端口后，需要同步调整已保存的配置。
git config --local --unset-all http.proxy如果用了 URL 专属或 remote 专属配置，删除普通 http.proxy 并不会清理它们；按第一节查到的来源定位，编辑前备份对应文件。不要为解决一个仓库把整个 ~/.gitconfig 删除。
SSH 远程地址需要另走一条排查线
GitHub 提供通过 ssh.github.com 的 443 端口连接 SSH 的方式，可用于测试某些只限制 22 端口的环境。它仍然是 SSH 协议，不是把 SSH 变成 HTTPS，也不能保证穿过只允许网页代理的网关。企业 Git 服务不一定提供相同入口。
ssh -T -p 443 [email protected]首次连接先按 GitHub 官方文档核对主机密钥指纹，不要对未知指纹直接确认。成功认证时 GitHub 会提示不提供 shell；也可能以非零状态结束，应读提示文字。需要持久配置或经过 SOCKS 的 SSH 链路时，按官方说明处理 ProxyCommand 等选项，不能照搬 HTTP 代理变量。
验证成功后，恢复正常安全检查
不要设置 http.sslVerify=false、GIT_SSL_NO_VERIFY 或使用 curl -k 作为网络修复。证书链出错应检查时间、CA、Git 安装以及企业管理证书。最后在原终端和新终端各运行一次真实拉取；退出代理客户端后，确认不会留下指向关闭端口的永久配置。