Git设置代理后仍连接失败？先分清HTTPS与SSH

Git设置代理后仍连接失败，先确认仓库使用HTTPS还是SSH，再查实际读取的代理配置。http.proxy用于HTTP传输，不能拿它修复SSH密钥认证问题。

本文面向已安装Git、已有合法仓库访问权限的用户。命令按Git 2.56文档核对，适用于Windows、macOS和Linux终端；旧版本若不支持config get，请查本机帮助。以下未在你的设备实测。

先确认实际仓库地址

在已有仓库目录运行：

git ls-remote --get-url origin

这条命令只展开地址，不连接远端，并会考虑insteadOf重写规则，见官方说明。没有origin时换成实际远程名称；首次克隆则检查所复制的网址及重写配置。

• https://开头：检查HTTP代理、证书与仓库账号权限。
• git@主机:路径或ssh://开头：使用SSH，继续查SSH连接与密钥。
• 本地路径：不属于本文的网络代理排查。

不要仅凭仓库网页能打开判断Git正常，浏览器和Git可能走不同路径。

HTTPS：查配置来源再做对照

在失败命令所在目录查询，网址换成实际仓库地址：

git config get --show-origin --url=https://github.com/OWNER/REPO.git http.proxy

配置文档说明了URL匹配和来源查询。重点看是否读到旧端口或URL专用设置；没有输出不代表一定直连，还可能使用代理环境变量。命名远程也可能有自己的proxy设置。

先确认客户端正在监听HTTP或混合端口，再做单条测试：

git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/OWNER/REPO.git

7890和仓库路径均为占位值。-c不写入持久配置；URL专用、远程专用设置或排除规则仍需检查。能列出引用说明本次远程读取成功，不代表大文件传输或推送也正常。

若本地代理端口也无法连接，先按curl代理排查检查监听与排除规则。代理类型不清楚可看SOCKS5设置说明。

SSH：别继续叠加HTTP设置

SSH仓库失败时，先区分“连接超时”和Permission denied (publickey)。后者应检查实际SSH程序、加载的密钥及仓库授权，不要把私钥发给客服。

需要保留SSH时，按所用SSH客户端文档核对连接配置；不同系统的代理辅助工具不能照搬。仓库提供HTTPS入口时，也可用其正式HTTPS地址做读取对照，不必立刻修改远程地址。更换协议后认证方式也会变化。

按错误阶段结束排查

407优先查代理认证；证书错误查时间、信任链或组织要求的证书，不关闭验证；仓库认证或权限错误则核对账号与访问范围。每次只改一项，记录原值，恢复无效改动；分享日志前删除令牌、代理密码和私有仓库信息。

常见问题

Git要同时设置http.proxy和https.proxy吗？

不用。Git官方HTTP配置项是http.proxy，也用于HTTPS仓库传输；不要把环境变量HTTPS_PROXY和Git配置名混为一谈。

ls-remote成功，为什么clone仍失败？

它只验证列出远程引用这一步。克隆还涉及对象下载，子模块或LFS可能使用其他地址，需保留失败阶段的完整错误。

删掉全局代理就能恢复吗？

不一定。仓库本地、URL专用、远程专用配置或环境变量仍可能生效。先查询来源，只移除确认为错误的条目，不批量清空组织配置。