Git clone 慢主因是网络链路卡在 GitHub 的 CDN、DNS 或 TLS 握手，可通过 --depth=1 跳过历史、替换为国内代理域名（如 github.com.cnpmjs.org）、配置 http.postBuffer 和 lowSpeed 参数三类操作解决 90% 场景。
Git clone 慢，不是 Git 本身的问题，而是网络链路卡在 GitHub 的 CDN、DNS 或 TLS 握手上。直接改 git config、换域名、跳过历史，三类操作就能解决 90% 的场景。
用 --depth=1 跳过完整历史记录
如果你只是想跑通代码、验证功能、或者本地构建，根本不需要整个提交历史。默认 git clone 会拉下所有分支 + 所有 commit，动辄几百 MB 甚至几个 GB。
-
--depth=1只取 HEAD 提交，体积常压缩到 1/10 以内 - 适合 CI 构建、临时调试、文档阅读等一次性使用场景
- 若后续需要完整历史，进目录后执行
git fetch --unshallow即可恢复（注意：需远程支持，部分镜像站不支持该操作） - 搭配
--branch更精准，比如git clone --depth=1 --branch=v1.2.0 https://github.com/etcd-io/etcd.git
把 github.com 换成国内可直连的代理域名
HTTPS 请求走的是标准端口和证书链，但域名解析和 CDN 节点选择决定了实际走哪条物理路径。直接替换 host 或 URL 是最轻量的绕行方式。
- 常用有效域名（截至 2026 年 4 月仍稳定）：
githubproxy.cc、github.com.cnpmjs.org、ghproxy.com - 原命令：
git clone https://github.com/torvalds/linux.git - 加速写法：
git clone https://github.com.cnpmjs.org/torvalds/linux.git - 子模块也得同步改：编辑项目根目录下的
.gitmodules，把每个url = https://github.com/xxx改成url = https://github.com.cnpmjs.org/xxx，再运行git submodule sync和git submodule update --init --recursive - 注意：
githubproxy.cc不支持 SSH，只适用于 HTTPS 场景
配 http.postBuffer 和 lowSpeed 防止超时中断
很多“clone 卡住”其实是 Git 自身的低速保护机制在作祟——它默认认为连续 30 秒上传/下载速率低于 1 KB/s 就算失败。而国内跨境链路常有抖动，容易误判。
- 执行这三条配置即可放宽限制：
git config --global http.postBuffer 524288000git config --global http.lowSpeedLimit 0git config --global http.lowSpeedTime 999999 -
postBuffer主要影响大文件 push，但对某些含大 blob 的 clone 也有帮助 -
lowSpeedLimit 0表示关闭速率下限检查，lowSpeedTime是超时窗口，设大一点更稳妥 - 这些是客户端行为调整，不影响服务端，也无需权限，适合 CI 环境或受限服务器统一部署
别碰 /etc/hosts 直接绑 IP（除非你真测过）
网上流传的 hosts 方案看似简单，实则隐患最多：GitHub 的 CDN IP 经常轮换，且不同地区最优节点差异极大。随便粘贴一个“别人测过的 IP”，很可能反而更慢，甚至导致 fatal: unable to access 'https://github.com/xxx/': Failed to connect to github.com port 443。
- 真要用 hosts，必须自己测：
nslookup github.com+ping -c 5 xxx.xxx.xxx.xxx+curl -I -s -w "%{http_code}\n" -o /dev/null https://github.com - 要加的不只是
github.com，还有github.global.ssl.fastly.net和codeload.github.com，漏一个就可能卡在 submodule 或 release 下载环节 - 改完必须刷新 DNS：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder（macOS）、ipconfig /flushdns（Windows） - 更推荐用代理域名方案替代——它本质是服务端做 DNS+CDN 调度，比本地 hosts 更可靠
真正卡住的时候，先看是「完全没反应」还是「进度条停在某个百分比」。前者大概率是 DNS 或连接层问题，优先试代理域名；后者多是低速超时或大包阻塞，postBuffer 和 --depth=1 最快见效。子模块多的项目，别指望一招搞定，得组合着来。
