GitHub SSH 22 端口超时怎么办？443 连接与代理路径排查

GitHub 网页能打开，SSH 拉取却在 22 端口超时，可以先测试官方提供的 ssh.github.com:443 入口。这里仍然运行 SSH 协议，并没有把仓库访问变成 HTTPS；也不能保证任何代理或网络都放行它。先做单次测试，区分端口连接、主机验证与密钥认证，再决定是否保存配置。GitHub 的 SSH 443 说明

资料核对日期：2026-10-05。本文针对通常使用的 GitHub.com；官方说明此方法不适用于 GitHub Enterprise Server，也不支持具有数据驻留要求的 GitHub Enterprise Cloud。专有实例应查其管理员提供的连接方式。

先确认 Git 用的是 SSH 还是 HTTPS

查看自己仓库的远端配置，区分两种常见格式：

远端示例	协议	本文端口测试是否相关
git@github.com:OWNER/REPO.git	SSH	相关
https://github.com/OWNER/REPO.git	HTTPS	应先检查 HTTPS 连接路径

这两个示例中的仓库名只是占位符。检查时无需公开完整远端地址，尤其不要贴出带令牌的 URL。网页可以打开，也不能证明 Git 的协议、解析方式和代理路径相同。

如果远端是 HTTPS，先参考本站 终端里的 curl 与 Git 代理排查。为 HTTP 请求填写代理地址，不能据此推断独立运行的 SSH 已使用相同代理。

做一次明确的 443 测试

在已经安装 OpenSSH 的终端中运行：

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

注意主机是 ssh.github.com，不是直接把 github.com 的端口换成 443。-p 指定端口，-T 禁用伪终端分配。ConnectTimeout 用于建立连接及初始 SSH 握手、密钥交换，不是整个认证流程的总时限；后续需要输入密钥口令时，仍可能等待输入。OpenSSH 命令说明、连接超时参数

首次连接这个主机和端口时，可能出现主机密钥确认。先对照当前 GitHub 官方 SSH 指纹，确认匹配后再接受。不要为了消除提示关闭主机验证；若出现主机密钥变更警告，先调查变更原因，不能直接删除整份 known_hosts。

本文没有对你的节点或设备做实际连接测试。命令的用途是让你在当前网络收集结果，不能据此宣称某个服务已经可用。

按失败阶段判断下一步

结果或错误	当前证据说明什么	下一步
无法解析主机名	尚未得到可用目标地址	检查解析路径与域名输入
连接超时或被拒绝	尚未完成正常连接	比较 22 与 443，查看路由和代理路径
主机密钥验证失败	主机信任校验没有通过	核对官方指纹及现有记录
Permission denied (publickey)	已进入密钥认证环节	检查账号、公钥与本地选用的密钥
认证成功但仓库操作失败	账户认证不等于仓库授权	核对远端地址、组织及仓库权限

成功时，GitHub 会提示已认证的账号并说明不提供 shell。该测试的退出码可能是 1；GitHub 官方文档明确说明这是预期情况，不能只凭非零退出码判定网络失败。还应确认提示中的账号是自己打算使用的账号。GitHub SSH 连接测试

若 22 超时而 443 认证成功，这支持“当前路径下两个入口的结果不同”，但不足以识别是哪一台防火墙限制了 22。若两者都超时，也不能仅凭网页成功认定是 SSH 密钥问题；密钥认证通常在网络连接之后。

单次测试成功后再保存主机配置

希望继续使用原来的 git@github.com:... 远端格式时，可以备份用户目录下的 .ssh/config，在核对既有 Host 规则之后使用官方配置：

Host github.com
    HostName ssh.github.com
    Port 443
    User git

它让匹配 github.com 的 SSH 连接转向替代入口，不需要修改每个仓库的远端。若文件已有该主机的配置，合并所需项，保留账号密钥等原设置，不要反复追加互相覆盖的片段。GitHub 官方配置示例

在支持相应参数的 OpenSSH 中，可以检查最终采用的配置：

ssh -G github.com

该命令计算配置后退出，不会执行连接。查找输出中的 hostname、port 和 user，再运行 ssh -T git@github.com 验证实际认证；配置显示正确也不能替代网络测试。OpenSSH 的 -G 参数

为什么开了浏览器代理，SSH 仍可能失败

端口号不会改变协议。HTTP 代理如何允许建立连接、客户端是否接管 SSH 流量，需要分别核对，不能因为端口为 443 就认定它与网页请求一样。

OpenSSH 的 ProxyCommand 可通过辅助程序建立连接，但辅助程序及参数取决于平台；网上某条 nc 示例不一定适用于你的 Windows 环境。ProxyJump 则表示通过 SSH 跳板，不是填写 HTTP 或 SOCKS URL 的位置。先查当前客户端支持的方式，再做单次验证。OpenSSH 代理参数

终端的 SSH 测试成功，Git 仍失败时，还应检查 Git 是否指定了另一条 SSH 命令。core.sshCommand 以及 GIT_SSH_COMMAND 可改变 Git 调用的命令，不能假定两个进程必然使用同一配置。Git 配置说明

用相同条件复查，保留回退办法

修改配置之前保存原文件，并记录原来失败的具体命令。单次入口测试通过后，只应用这项主机配置，再重试原任务；不要同时更换密钥、删除账号凭据和调整整个代理规则。如果配置后出现新问题，恢复备份，再比较结果，才能知道变化是否由这一步引入。

复查时保持终端环境和当前网络一致。若公司网络与个人网络的结果不同，只能说明测试条件不同，应结合允许的网络策略分析，不能据此判断任一节点的长期可靠性。提交问题给服务方时，写明失败发生在连接、主机验证、认证还是仓库操作，并保留对应的简短错误信息；一句“GitHub 连不上”不足以确定需要处理哪一层。

可记录：测试时间、网络、远端协议、22 与 443 的结果、失败阶段、有效主机配置，以及认证账号是否符合预期。日志分享前遮去令牌和私密路径，不提供私钥文件。将这几个阶段分开，才能决定是检查代理路径、修正密钥，还是处理仓库权限。