如果你管理过 VPS（虚拟专用服务器）或独立服务器，大概率遇到过这样的场景：登录服务器执行 git clone 拉取代码，进度条卡在 Receiving objects 很久不动，最后直接报 SSL read error（SSL，安全传输协议，负责加密网络连接）或连接超时。本地电脑访问 GitHub 往往还算顺畅，一到服务器上就明显变慢，这是很多运维人员都头疼的问题。本文会帮助你解决这个问题。
GitHub 访问慢的核心原因在于：从境内服务器到 GitHub 托管服务器的网络路径绕行严重、线路拥堵，跨国链路在高峰期丢包率明显上升。git clone 又是典型的长连接、大流量传输，一旦链路抖动，整个克隆过程就可能前功尽弃。这篇文章会教你几种在服务器端切实可行的 git clone 加速做法，帮助你根据场景选择最合适的方案。
为什么服务器上 git clone 特别容易失败
在动手加速之前，先弄清楚问题出在哪一层，可以避免选错方案。
- 默认克隆会把全部历史提交和全部分支都下载下来，像 Linux 内核这类大型仓库体积超过 3GB，境内直连下载动辄几十分钟甚至中途断开
- 服务器到 GitHub 的路由通常要绕行境外节点，晚高峰丢包率可能超过 5%，TCP（传输控制协议）窗口被反复压缩，速度自然上不去
- 不少服务器默认只开放了部分出站端口，GitHub 的 HTTPS 443 端口连通质量取决于线路，而 SSH 协议的 22 端口有时反而更稳定
理解了这些，就能明白加速的思路其实只有两条：要么减少需要传输的数据量，要么换一条更快的网络路径。下面分别展开。
方案一：浅克隆与稀疏检出，从数据量下手
最推荐优先尝试的方法是浅克隆，它不改变网络路径，只减少下载内容，稳定性提升立竿见影。部署场景通常只需要最新代码，根本不需要完整历史。
# 只拉取最近 1 次提交，大型仓库体积可减少 90% 以上
git clone --depth 1 https://github.com/user/repo.git
# 后续更新时同样只拉最新提交
git pull --depth 1
# 如果之后需要补全历史，再执行
git fetch --unshallow
实测一个约 800MB 的仓库，完整克隆在境内服务器直连耗时超过 20 分钟，改用 --depth 1 后下载量降到 60MB 左右，2 分钟内完成。如果你只关心仓库里的某个子目录，还可以配合稀疏检出进一步缩小范围：
git clone --depth 1 --filter=blob:none --sparse https://github.com/user/repo.git
cd repo
git sparse-checkout set src docs
一套组合对 CI（持续集成）流水线尤其有效，构建前拉代码的时间常常能从十分钟级压缩到一分钟以内。部署类任务如果同时涉及页面性能优化，可以进一步阅读这篇TTFB 与网站加速指南。
方案二：使用镜像站与加速代理，换一条更快的路
如果浅克隆后速度仍不理想，说明瓶颈在链路本身，这时需要借助第三方镜像或加速代理。这类服务的原理是在网络可达性更好的节点上缓存 GitHub 仓库，你的服务器只需从镜像站拉取。
# 常见的做法：把克隆地址中的域名替换为镜像域名
git clone --depth 1 https://mirror.example.com/https://github.com/user/repo.git
# 也可以全局替换已有仓库的地址
git remote set-url origin https://mirror.example.com/https://github.com/user/repo.git
使用镜像站需要注意三点：
- 镜像站属于第三方服务，存在缓存延迟和可用性风险，重要项目克隆完成后建议执行
git log核对提交是否完整 - 部分镜像只同步热门仓库，冷门仓库首次访问可能触发回源，速度未必更快
- 生产服务器的代码来源应尽量可控，镜像地址建议只作为临时手段，不要长期写死在部署脚本里
对于自建了境外中转机器的团队，也可以在服务器上为 git 配置 HTTP（超文本传输协议）代理，让克隆流量从中转节点过一遍：
# 仅对 github.com 走代理，不影响其他站点
git config --global http.https://github.com.proxy http://127.0.0.1:7890
# 不需要时取消
git config --global --unset http.https://github.com.proxy
这种做法的前提是你自己拥有可靠的境外中转资源，公网上来历不明的免费代理不要用，代码可能被中间人窥探或篡改。
方案三：SSH 协议与连接复用，减少握手损耗
当 HTTPS 直连质量差时，切换协议有时会有意外收获。GitHub 的 SSH（安全外壳协议）端口走的是另一条传输方式，部分线路下比 HTTPS 更稳定：
# 测试 22 端口连通性
ssh -T git@github.com
# 如果 22 端口不通，GitHub 官方支持走 443 端口的 SSH
ssh -T -p 443 git@ssh.github.com
确认可用后，把远程地址从 https://github.com/user/repo.git 改成 git@github.com:user/repo.git 即可。对于需要频繁 fetch 的监控或同步类任务，再配合 SSH 连接复用，可以省掉每次握手的时间：
# ~/.ssh/config 中添加
Host github.com
HostName ssh.github.com
Port 443
User git
ControlMaster auto
ControlPath ~/.ssh/ssh-%r@%h:%p
ControlPersist 600
这套配置让 10 分钟内的多次 git 操作共用一条已建立的连接，每次操作能省下 1-3 秒的握手开销，在链路抖动的环境下减少握手次数也等于减少失败机会。如果你还在纠结服务器本身怎么选，可以参考这篇服务器配置与性能优化的入门内容。
方案四：本地缓存仓库，多机部署只拉一次
如果你需要把同一个仓库部署到多台服务器，或者 CI 任务反复克隆同一仓库，更聪明的做法是维护一份本地裸仓库缓存，内网机器之间互相拉取，速度完全取决于内网带宽：
# 在内网一台机器上建立缓存仓库，首次从 GitHub 同步
git clone --mirror https://github.com/user/repo.git /srv/git-cache/repo.git
# 定时更新缓存（可加入 crontab 每 30 分钟执行）
git -C /srv/git-cache/repo.git remote update --prune
# 其他服务器从内网缓存克隆，速度通常能跑满内网带宽
git clone --depth 1 file:///srv/git-cache/repo.git repo
一台拥有千兆内网的服务器从缓存克隆，1GB 的仓库十几秒就能完成，相比每次都跨国拉取，这是多机场景下收益最大的方案（缓存同步走的是内网带宽，即服务器之间传输数据的通道容量，通常远快于公网）。注意 --mirror 建立的仓库只用于同步，不要直接在上面开发。如果你的业务接下来要迁移到独立服务器，可以看看独立服务器产品页的配置说明。
如何为你的场景选择合适的方案
四种方案并不互斥，可以按场景组合使用。给你一个简单的选择参考：
- 单次部署、仓库不大：直接用
--depth 1浅克隆，零成本见效最快 - 仓库大且历史必需：先试 SSH 走 443 端口，再考虑可靠的镜像站
- 多台服务器或频繁 CI 构建：搭建本地缓存仓库，一次同步全网受益
- 拥有自建境外中转：为 git 单独配置代理，链路可控且不影响其他流量
如果你需要进一步提升服务器上各类跨国下载任务的成功率，建议把这些方案按优先级逐步落地：浅克隆改动最小，先用起来；缓存仓库收益最大，适合作为中期目标。
如果你正在优化服务器的整体部署流程，除了 git clone，数据库备份上传、系统镜像下载同样受跨国链路影响，选择一台境内访问质量好的 VPS 主机往往能从根源上减少这类问题，Hostease 的 VPS（虚拟专用服务器）产品在这方面的线路表现可以了解一下。相关的基础环境准备也可以参考虚拟主机产品页。建议先用浅克隆把最紧急的部署问题解决掉，再根据业务规模逐步引入缓存仓库等长期方案。把加速手段写进部署脚本之前，务必先在测试环境跑通一次完整流程，确认克隆下来的代码可以正常构建，再推广到生产环境。