诊断命令
别一上来就删仓库重拉，用一组最小命令判断慢在哪一段：解析、TCP/TLS、认证、传输对象，还是 checkout 文件。
# 1. 看 DNS 解析是否稳定
nslookup github.com
nslookup ssh.github.com
# 2. 看 HTTPS 握手和响应时间
curl -I -L https://github.com --connect-timeout 10 -m 20
# 3. 看 SSH 22 端口是否能认证
ssh -T [email protected]
# 4. 看 SSH over 443 是否可用
ssh -T -p 443 [email protected]
# 5. 打开 Git 传输日志
GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone --progress https://github.com/owner/repo.git如果 curl 都很慢，问题多半不在 Git；如果 curl 正常但 git clone 卡住，再看认证、代理和仓库大小。如果只在 CI 慢，本地网络结论不能直接套到 runner。
HTTPS 和 SSH 到底差在哪？
GitHub 文档把 HTTPS 和 SSH 都列为可用认证方式：HTTPS 依赖凭据缓存或 GitHub CLI 登录，SSH 依赖每台机器上的 key、ssh-agent 和远端 URL。速度上没有「永远谁更快」的结论，排查时要看路径。
| 维度 | HTTPS clone | SSH clone |
|---|---|---|
| 常见 URL | https://github.com/owner/repo.git | [email protected]:owner/repo.git |
| 常用端口 | 443 | 22，必要时可用 443 |
| 认证依赖 | credential helper、GitHub CLI | SSH key、ssh-agent、known_hosts |
| 常见慢点 | TLS、凭据提示、HTTP 代理 | 22 端口不通、key 没加载、known_hosts |
| 适合场景 | 公司网络只放行 HTTPS、CI token | 长期开发机器、多仓库推拉 |
GitHub 还提供 SSH over HTTPS port 的做法：测试命令是 ssh -T -p 443 [email protected]，克隆 URL 可写成 ssh://[email protected]:443/OWNER/REPO.git。注意主机名是 ssh.github.com，不是普通的 github.com。首次连接要比对 GitHub 发布的 SSH fingerprint，别盲目确认。
DNS、代理和 Git 配置怎么逐层排查？
第一层看 DNS。nslookup github.com 和 nslookup ssh.github.com 如果时快时慢，HTTPS 与 SSH 都会受影响。团队里可以记录两次解析结果、运营商网络、所在城市和失败时间，不要只写「GitHub 慢」。
第二层看环境变量。很多开发者为了 npm、Docker 或公司网络设置过代理变量，但 Git 不一定按你想的方式使用它们。
# 查看当前 shell 是否带了代理变量
env | grep -i '_proxy'
# 临时只对本次 HTTPS clone 使用代理变量
HTTPS_PROXY=http://127.0.0.1:7890 git clone https://github.com/owner/repo.git
# 临时排除内部域名或本地服务
NO_PROXY=localhost,127.0.0.1,.corp.example.com git clone https://github.com/owner/repo.git
# 查看 Git 自己的代理配置
git config --global --get http.proxy
git config --global --get https.proxy限制要记清楚：HTTP_PROXY、HTTPS_PROXY 主要影响走 HTTP(S) 的工具链；SSH 不会因为这些变量自动变快。SSH 需要看 ~/.ssh/config、ProxyCommand、ProxyJump、端口和 key。不要把个人代理地址写到仓库里的 install 脚本，否则同事和 CI 会被带偏。
第三层看 Git 远端和凭据。用 git remote -v 看当前仓库是 HTTPS 还是 SSH；用 gh auth status 或凭据管理器检查 GitHub CLI 登录；用 ssh-add -l 看 key 是否加载。认证反复弹窗时，传输看起来也会像「慢」。
仓库太大时怎么让 clone 变短？
Git 文档明确说，普通 clone 会拉取完整仓库数据。大仓库、长历史、大二进制、很多 tag 或 submodule 都会拖慢，用轻量方式验证仓库能不能拉下来：
# 只拉默认分支最近历史
git clone --depth 1 --single-branch --no-tags https://github.com/owner/repo.git
# 只拉 main 分支
git clone --depth 1 --single-branch --branch main https://github.com/owner/repo.git
# 延迟下载大文件内容，适合大仓库排查
git clone --filter=blob:none https://github.com/owner/repo.git
# CI 里强制显示进度，避免日志空白
git clone --verbose --progress https://github.com/owner/repo.git
# submodule 多时并发，但别无脑开太大
git clone --recurse-submodules --shallow-submodules --jobs 4 https://github.com/owner/repo.git浅克隆适合 CI、临时排查和只读构建；长期开发不要只靠 --depth 1，因为 bisect、历史追踪、tag 发布可能需要完整历史。大文件应考虑 Git LFS、release artifact 或对象清理，不要把数据库 dump、视频素材塞进主仓库。
团队和 CI 怎么避免每次重查？
团队 runbook 至少记录四件事：仓库推荐 URL、HTTPS/SSH 选择规则、CI clone 参数、网络失败时要贴的日志。GitHub Actions 可先用 actions/checkout 的 fetch-depth 控制历史量；自建 runner 要记录出口网络和 DNS 配置。不要让每个成员自己摸索一套全局 Git config。
如果你经常在共享办公、酒店网络或海外协作环境里切换机器，排查 GitHub、Dashboard、CI 日志时可以准备独立开发者出海稳定专线。它解决的是访问路径抖动，不能替代 SSH key 管理、仓库瘦身和 CI 缓存。
还没恢复时的升级证据
把信息收敛成一张表再升级：
| 证据 | 说明 |
|---|---|
curl -I -L https://github.com 耗时 | 判断 HTTPS 基础连通性 |
ssh -T [email protected] 输出 | 判断 SSH key 与 22 端口 |
ssh -T -p 443 [email protected] 输出 | 判断 SSH 443 备用路径 |
GIT_CURL_VERBOSE=1 日志 | 判断卡在 TLS、认证还是对象传输 |
--depth 1 是否成功 | 判断仓库体积是否主因 |
如果只有某个仓库慢，优先查仓库体积、submodule、LFS 和 tag；如果所有 GitHub 仓库都慢，回到 DNS、网络路径和代理限制。
相关阅读
中文长尾问题的 SOP 写法
开发者搜索经常是故障式长尾，比如「GitHub clone 很慢」「Docker pull 超时」「npm install 卡住」「Stripe 后台打不开」「Cloudflare 登录验证」。这些词要保留，但正文要把它们落到 DNS、代理变量、认证、CI runner、浏览器会话和团队权限上。
| 中文长尾说法 | 工程化排查项 | 团队记录字段 |
|---|---|---|
| GitHub clone 慢 | DNS、HTTPS、SSH、仓库体积 | 协议、耗时、错误日志 |
| Docker pull 超时 | registry、镜像层、代理变量 | 镜像名、runner、出口网络 |
| npm / pnpm 卡住 | registry、lockfile、缓存、代理 | 包管理器、版本、失败阶段 |
| Stripe / Cloudflare 验证 | 设备、浏览器、IP、2FA | 登录设备、角色、时间 |
这样写能覆盖中文长尾，同时保留开发者文章的证据链和可复用 SOP，而不是只给一个“换网络”的泛化建议。