故障排查

Git HTTPS 能拉取，SSH 却超时：先分清代理入口和认证错误

从远程地址判断 Git 使用 HTTPS 还是 SSH，区分端口超时、公钥认证和仓库权限，再选择可撤销的修复，不把 HTTP 代理设置套到 SSH。

发布于 2026/10/22 · 更新于 2026/10/22 · 7 项可核验来源

先看重点先看远程地址：https://… 与 git@github.com:… 走的不是同一种传输。Git 的 HTTP 代理配置不会自动接管 OpenSSH。连接超时、公钥被拒、仓库无权限也应分开处理；不要先换节点或重建密钥。

浏览器能打开 GitHub，或同一个项目通过 HTTPS 能拉取，却不能通过 SSH 访问，并不能证明整个代理失效。本文处理 GitHub.com 上这两条传输路径的差别；如果所有终端请求都失败，先看浏览器正常、终端不联网的入口检查。下列命令是诊断方法，不代表在你的电脑或节点上完成了实测。

先确认失败的是哪一条远程地址

在出问题的本地仓库目录运行：

git remote -v

分别看 fetch 与 push 对应的地址。https://github.com/OWNER/REPO.git 属于 HTTPS；git@github.com:OWNER/REPO.git 是常见 SSH 写法，ssh://git@github.com/OWNER/REPO.git 也是 SSH。OWNER、REPO 是占位符，不能直接照抄。若拉取与推送使用了不同 URL，一边成功不代表另一边已经验证。

记录当前地址供恢复，但不要公开含令牌的 URL 或私有仓库名称。检查是否已有团队配置的 URL 重写或 SSH 主机别名；存在这些设置时，实际连接目标可能与短地址不同。不要为了排查先清空全局 Git 或 SSH 配置。

用只读操作确认 HTTPS 路径

如果仓库本来使用 HTTPS，优先验证现有入口。下例在单次命令中给 Git 指定本机 HTTP 代理，只读取公开 Git 仓库的 HEAD 引用，不克隆整个项目，也不修改远端：

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

7890 必须改成当前客户端真实的 HTTP 或 mixed 端口；-c 仅对这次 Git 调用生效，不会写入全局配置。端口选择见HTTP、SOCKS 与 mixed 端口区别。这里的 HTTP 指本机代理入口，目标仓库仍使用 HTTPS。

返回 HEAD 的引用和对象 ID，说明这次公开仓库的读取完成；它不证明你的私有仓库权限、推送权限或长时间传输稳定。若本地代理拒绝连接，先查监听地址；若收到认证或访问拒绝，就处理该授权问题，不通过换协议、账号或出口规避。命令迟迟无响应时可按 Ctrl-C 停止，保留原始错误。

Git 官方将 http.proxy 定义为 HTTP 传输配置。给它增加更多全局值，不能让 SSH 自动走这个入口。系统代理开关也不等于所有 SSH 连接被接管；TUN 是否接住连接还取决于当前路由与规则，不能从开关颜色判断。

SSH 超时与公钥拒绝怎样分层

只有你原本就有该账户的 SSH 使用权限、且网络允许 SSH 时，才测试既有配置：

ssh -T -o ConnectTimeout=10 git@github.com

GitHub SSH 用户名是 git，不是你的个人登录名。首次遇到主机身份提示，先对照文末官方指纹页；不要盲目接受，也不要关闭主机校验。若出现主机密钥变化警告，停止核查，不能靠删除 known_hosts 整个文件消除提示。

连接超时或拒绝连接：还未完成认证，先定位主机、端口与网络路径；它本身不能证明密钥错误。参见连接错误的不同阶段。
Permission denied (publickey)：已经进入 SSH 身份验证，检查正在使用的既有密钥是否属于正确账户，按官方认证排查处理。此时不要把端口切换当成授权修复。
提示认证成功，但不提供 shell：这是 GitHub 的正常测试结果，并非要求你开通 shell；官方说明该测试即使成功也可能以退出码 1 结束，不能只凭非零退出码判失败。
SSH 测试成功，仓库读取仍被拒：再核对仓库地址、账户与该仓库权限。账户认证通过并不自动授予所有仓库访问权。

必要时在同一次命令加 -v 看连接到了哪个主机、端口，以及用了哪份配置；求助只摘录脱敏后的错误段，不发私钥或整份调试日志。本文不要求创建新密钥、管理员运行 Git 或扩大账户权限。

确需 SSH 时，核对官方 443 入口

网络管理员允许 GitHub SSH、但普通 22 端口路径不可用时，GitHub.com 提供 ssh.github.com:443。它仍是 SSH，不是 HTTPS 网页，也不保证能穿过只接受 HTTP 的代理。若组织明确禁止 SSH，应采用获准的访问方式，不能用改端口绕过。

ssh -T -o ConnectTimeout=10 -p 443 git@ssh.github.com

主机必须是 ssh.github.com，不能只把 github.com 的端口改成 443。该方案不适用于 GitHub Enterprise Server 和带数据驻留的 Enterprise Cloud；自建平台须查自己的官方入口。此处仍需核验主机指纹和原有身份，认证拒绝时停止，不能循环更换路径。

确认入口与授权均正常后，可用明确 URL 对自己的仓库做一次只读验证，而不是马上覆盖全局 SSH 配置：

git ls-remote ssh://git@ssh.github.com:443/OWNER/REPO.git HEAD

将 OWNER/REPO 替换为你有权读取的仓库。若结果正确且确实需要长期使用，可按 GitHub 官方文档配置仅匹配 github.com 的 Host 条目；先备份原文件，保留已有团队配置，不添加宽泛的 Host * 规则。普通 HTTP 代理不因此变成 SSH 代理，客户端外层仍可能有独立限制。

修复后怎样验证和撤销

按你实际需要的协议复查同一仓库：远程地址正确、只读引用能返回、实际日常拉取可完成，才算这条使用路径恢复。不要拿公开仓库测试代替私有仓库权限验收，也不要为了验证网络执行一次无意义的 push。推送失败需另查远程 push 地址及写入权限。

本文的 git -c 与显式 SSH 测试参数在命令结束后就失效，无须永久清理。若随后按官方说明改过 SSH Host 条目，只恢复这次添加或修改的段落；若改过仓库 remote，按记录恢复原 fetch/push 地址，不删除其他配置。首次接受并核验的主机记录可以保留，不应整文件清除。

最后记录“哪一种协议、哪个入口、失败在哪一层”。这比“换节点后似乎好了”更便于下一次定位；两条协议都失败时再检查共同的网络和客户端因素，避免把代理、身份和仓库权限混为一个问题。

资料来源

以下官方资料于 2026/10/22 核对；示例不包含账户凭据，也不代替组织的网络访问政策。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题