GitHub 克隆和推送出问题，先分清是连不上还是连得上但很慢
执行 git clone 或 git push 时，终端要么长时间没有输出，最后报 connect to host github.com port 22: Connection timed out，要么能开始传输但速度只有几十 KB/s。这两种情况看起来都是 GitHub 访问慢，处理办法却完全不同：前者是 22 端口这条 SSH 通路不通，改走 443 端口的 SSH 就能解决；后者是传输阶段速度低，需要看线路和传输参数。本文先给出判断 SSH 22 端口是否可达的三条命令，再给出 GitHub 官方文档提供的 443 端口配置，最后说明克隆速度低时怎么分段定位。内容对照 GitHub 官方文档与 Git 官方文档整理，查阅日期为 2026 年 9 月 20 日。
第一步：用三条命令判断是哪种情况
不要一上来就改配置，先用三条只读命令把问题范围缩小。它们都不会修改任何东西，可以放心执行。
- 测 22 端口是否可达：
nc -vz -w 5 github.com 22。这条命令只做 TCP 连接测试，5 秒内没有成功就说明 22 端口这条通路有问题。 - 测 443 端口的 SSH 服务是否可达：
nc -vz -w 5 ssh.github.com 443。GitHub 官方文档说明，ssh.github.com 这个主机名的 443 端口提供 SSH 服务。 - 测 HTTPS 通路：
curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_appconnect}\n" https://github.com，返回 200 说明网页通路正常，同时给出连接和握手耗时。
如果第一条失败、第二条成功，结论很明确：22 端口不通而 443 可用，直接按下一节改配置。如果三条都成功但克隆仍然很慢，则跳到后面的传输阶段部分。如果三条都失败，说明到 GitHub 的基础通路本身有问题，先检查终端里的代理变量和 DNS，再看出口线路。
SSH 改走 443 端口：配置写法与首次连接的警告
GitHub 官方文档给出了两种用法。只想测试的话，执行 ssh -T -p 443 git@ssh.github.com，看到认证成功的提示就说明这条通路可用。要长期使用，编辑 ~/.ssh/config，加入下面这段配置：
Host github.com
Hostname ssh.github.com
Port 443
User git保存之后执行 ssh -T git@github.com 验证。因为配置是按 Host 名称匹配的，已有仓库的远程地址（形如 git@github.com:用户名/仓库名.git）不需要修改，clone、pull、push 会自动走 443 端口。如果只想对某一条命令生效，也可以直接使用官方给出的完整地址形式：git clone ssh://git@ssh.github.com:443/用户名/仓库名.git。
切换到 443 后出现 known_hosts 警告怎么办
官方文档提醒，第一次切换到 443 端口后，可能出现主机未在 known_hosts 中找到，或者被以另一个名称记录的警告。文档给出的处理原则是：核对 SSH 指纹，只有当指纹与 GitHub 公布的指纹之一一致时，才可以回答同意。不要不看指纹就直接输入 yes，这一步是防止连接到错误的服务器。
443 端口的配置放在哪一层更合适
只在个人机器上使用的话，写在 ~/.ssh/config 即可，对该用户的所有仓库生效。团队里如果只有部分成员的网络环境有问题，不建议改仓库里的配置文件，让有问题的成员各自修改自己的 SSH 配置，其他人不受影响。CI 环境同理，通常 CI 机器到 GitHub 的通路本来就是通的，不需要改。
克隆和推送很慢：分段定位传输阶段
连得上但传输慢的情况，需要看清楚慢在哪一段。Git 提供了几个官方文档里说明的环境变量，可以直接打开跟踪输出：GIT_CURL_VERBOSE=1 会输出底层 HTTP 库的全部消息，效果类似 curl -v；GIT_TRACE=1 输出常规跟踪；GIT_TRACE_PACKET=1 输出网络操作的包级跟踪。例如：
GIT_CURL_VERBOSE=1 git clone https://github.com/用户名/仓库名.git观察输出停在哪里：停在连接和 TLS 握手阶段，说明是通路问题；握手很快但后面的数据一直很少，则是传输速度问题。SSH 方式下对应的排查工具是 ssh -vT git@github.com，v 越多输出越详细。
怎么让 Git 在速度太低时主动放弃并重试
Git 有两个配置项可以处理长时间的低速传输：http.lowSpeedLimit 和 http.lowSpeedTime。当 HTTP 传输速度低于前者设定的数值并持续超过后者设定的秒数，Git 会中止这次传输。设置一个合理的阈值，让卡住的连接尽早失败，配合重新执行，比一直等待更省时间。（我查阅的官方配置页面在抓取时被截断，这两项的说明以你本机 git help config 的输出为准。）
仓库很大时怎么减少传输量
如果只需要最新代码，可以使用 git clone --depth 1 做浅克隆，只拉取最近一次提交的内容，传输量通常会小很多，后续需要完整历史时再补拉。走 HTTPS 时如果需要经过代理，可以用 git config --global http.proxy 代理地址 设置，代理地址需要换成你实际使用的地址。
判断表与线路自测
| 现象 | 更可能的原因 | 优先动作 |
|---|---|---|
| connect to host github.com port 22 超时 | 22 端口出站不通 | 改用 ssh.github.com 的 443 端口 |
| 22 不通，443 的 nc 测试成功 | 只是 22 这条通路的问题 | 写入 ~/.ssh/config 并验证 |
| 三条命令都超时 | 基础通路或 DNS 有问题 | 检查代理变量和 DNS，再看出口线路 |
| 连接正常，传输速度很低 | 线路带宽或稳定性问题 | GIT_CURL_VERBOSE 观察，多时段对比 |
| 大仓库克隆经常中途失败 | 长连接被打断 | 浅克隆，配合低速阈值和重试 |
对于传输慢的情况，建议用你自己环境的数据说话：同一台机器上，分早、中、晚各克隆一次同一个中等大小的仓库，记录总耗时，再把上面 curl 命令的 time_connect 数值一并记录。换一个网络环境重复一遍，就能判断慢是出现在某个时段、某个网络，还是一直如此。如果确认是出口线路的问题，可以给开发机换一条更稳定的出口。NasaCode 提供通用的全球加速能力，也针对 Claude Code、Cursor、IDE 这类开发工具场景做了直连优化，GitHub 拉取和推送走的是同一条线路；是否改善仍以你的耗时记录为准。
小结
SSH 22 端口超时先用 nc 判断，443 端口可用就把 ssh.github.com 写进 SSH 配置；克隆慢则用 GIT_CURL_VERBOSE 看停在哪个阶段，再决定是调整传输参数还是评估出口线路。命令和配置项以 2026 年 9 月 20 日查阅的官方文档为准，版本升级后请用 git --version 和官方文档重新核对。
延伸阅读
