GitHub打不开、clone只有20KB/s？中国开发者完整加速指南

git clone 一个几百MB的仓库，速度稳定在20KB/s，预计还需3小时；网页端图片和头像加载不出来，Release页面的安装包下到一半直接断掉——这大概是每个在中国大陆写代码的人的日常。

先给结论： 如果只是想快速拉下某个仓库，用浅克隆/部分克隆把传输量砍掉90%；如果是SSH端口22连不上，把SSH切到443端口；如果仓库在Gitee有镜像或你有仓库管理权，用Gitee官方导入转为国内下载；如果要长期稳定开发，给git配置代理或直接使用 JetStream VPN 的智能分流——GitHub流量走香港/日本低延迟节点，国内服务不受影响。下面逐个展开。

为什么GitHub在国内这么慢？

GitHub本身没有对任何地区限速，慢的根源在传输链路上：

1. 跨境链路拥挤：GitHub的服务器和主要基础设施部署在海外，数据要经过国际出口才能到达国内。出口带宽有限，高峰期丢包率明显上升，而TCP在高丢包环境下会主动降速——这就是clone速度从几MB/s掉到几十KB/s的直接原因。

2. CDN节点不覆盖大陆：GitHub的静态资源、头像、Release附件分别由不同的CDN域名分发（如 github.githubassets.com、avatars.githubusercontent.com、objects.githubusercontent.com），这些CDN在中国大陆没有可用节点，请求要绕到境外POP点，于是出现”网页能开但图片全挂”、“Release下载几KB/s”的典型症状。

3. 连接不稳定而非完全不通：GitHub大多数时候不是”打不开”，而是握手慢、传输中断率高。clone大仓库时间越长，中途失败的概率越大，而 git clone 一旦中断只能从头再来。

理解了这一点，加速思路就清晰了：要么减少传输量，要么换一条更好的链路。

方案一：浅克隆与部分克隆（零成本立刻见效）

大多数时候你并不需要仓库的完整历史。Git原生支持只拉取必要数据，在慢速链路上这是性价比最高的操作。

浅克隆（shallow clone）——只要最新代码：

# 只克隆最近1次提交，传输量通常减少80%以上
git clone --depth 1 https://github.com/torvalds/linux.git

# 只要某个分支，进一步减少数据
git clone --depth 1 --branch main --single-branch https://github.com/vuejs/core.git

# 后续需要完整历史时再补全
git fetch --unshallow

部分克隆（partial clone）——保留完整历史但按需下载文件：

# 拉取全部提交历史，但blob（文件内容）用到时才下载
git clone --filter=blob:none https://github.com/rust-lang/rust.git

# 超大仓库还可以配合稀疏检出，只取需要的目录
git clone --filter=blob:none --sparse https://github.com/microsoft/vscode.git
cd vscode
git sparse-checkout set src/vs/editor

优点： 不依赖任何外部服务，命令行直接生效；对CI/CD场景尤其友好。

局限： 只是减少传输量，链路本身还是慢；git log -p、git blame 等操作在partial clone下会触发按需拉取，仍受网络影响。

方案二：SSH走443端口（解决”端口22连不上”）

不少公司内网、酒店和运营商网络会干扰或封锁22端口的SSH流量，表现为 ssh: connect to host github.com port 22: Connection timed out。GitHub官方为此提供了443端口的SSH服务，域名是 ssh.github.com。

编辑 ~/.ssh/config，加入：

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

验证是否生效：

ssh -T git@github.com
# 看到 "Hi <username>! You've successfully authenticated..." 即成功

之后所有 git@github.com:xxx/yyy.git 形式的remote无需任何改动，自动走443端口。

优点： GitHub官方通道，稳定可靠；一次配置永久生效。

局限： 只解决”连不上”的问题，不解决”速度慢”——443端口的SSH流量依然走同一条跨境链路。

方案三：Gitee官方镜像导入（国内平台中转）

如果你只是要”读”某个开源仓库的代码，可以利用 Gitee 的官方仓库导入功能：登录Gitee后选择”从GitHub导入仓库”，粘贴原仓库地址，Gitee会在国内服务器上生成一份镜像，之后从Gitee clone，速度通常可以跑满家用带宽：

# 从Gitee镜像克隆（服务器在国内，实测参考可达5-20MB/s）
git clone https://gitee.com/<你的账号>/<导入的仓库>.git

许多知名开源项目在Gitee上已有官方或社区维护的镜像，导入前可以先搜索一下。

优点： 免费；国内直连速度快；适合只读场景和一次性拉取。

局限： 镜像同步有延迟，需要手动或定时更新；无法向上游提PR、参与Issue讨论；私有仓库和完整的GitHub协作生态（Actions、Codespaces、Copilot等）都不适用。

顺带提醒： 网上流传的两类”免费加速”方式请谨慎对待——公共加速代理站（各类前缀代理域名）经常失效，且你的clone流量会经过陌生第三方服务器，存在安全与稳定性风险；修改hosts文件依赖手动维护的IP，GitHub的CDN节点IP变动频繁，今天能用明天失效，还容易引发证书告警。这两种方式都不建议作为长期方案。

方案四：给git配置代理（精准控制，只加速GitHub）

如果你本地已经有代理客户端在运行（如JetStream配合 Clash Verge 等工具，通常会在本机开放一个SOCKS5/HTTP端口），可以让git的流量定向走代理，其他流量不受影响。

HTTPS方式clone的代理配置：

# 只对github.com生效（推荐），以本地SOCKS5端口1080为例
git config --global http.https://github.com.proxy socks5://127.0.0.1:1080

# 如果客户端提供的是HTTP代理端口（如Clash类工具常见的7890）
git config --global http.https://github.com.proxy http://127.0.0.1:7890

# 取消代理
git config --global --unset http.https://github.com.proxy

注意 http.https://github.com.proxy 这种写法是按域名限定的：只有访问GitHub时走代理，公司内网Git服务器、国内镜像源都不受影响。

SSH方式clone的代理配置（写入 ~/.ssh/config）：

Host github.com
    HostName ssh.github.com
    Port 443
    User git
    ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

Windows用户可以用Git自带的connect工具替代nc：

Host github.com
    HostName ssh.github.com
    Port 443
    User git
    ProxyCommand connect -S 127.0.0.1:1080 %h %p

具体端口号以你代理客户端的设置页为准。

优点： 粒度精准，只有git流量走代理；对终端、IDE内置Git同时生效。

局限： 只覆盖git命令本身——浏览器访问GitHub网页、下载Release、go get/pip install 拉取GitHub依赖等场景需要另行配置，配置成本随场景数量增加。

方案五：JetStream VPN智能分流（一次配置，覆盖全场景）

方案四的痛点在于”按工具逐个配置”：git配了，浏览器没配；终端配了，Docker拉镜像又超时。如果你每天的工作都离不开GitHub、npm、Docker Hub这一整套海外开发生态，更省心的做法是在系统层面解决链路问题。

JetStream VPN 针对开发者场景做了几件事：

• 智能分流：内置规则自动识别流量——GitHub、npm、PyPI等海外服务走VPN隧道，国内网站、支付、视频保持直连，不需要来回开关；
• 低延迟节点：香港、日本、新加坡节点物理距离近，延迟低，git这类多次往返握手的协议受益明显；对Release大文件下载的提速尤其直观，实测参考可从直连的几十KB/s提升到数MB/s量级；
• 安全底线：AES-256加密传输，RAM-only服务器架构，断电即清空，不落盘存储任何连接数据。

连接后无需任何git配置，原始地址直接可用：

# 开启JetStream智能分流后，直接clone原始地址
git clone https://github.com/pytorch/pytorch.git

# Release大文件下载同样直接生效
curl -LO https://github.com/cli/cli/releases/download/v2.63.0/gh_2.63.0_linux_amd64.tar.gz

Android用户可以在这里下载JetStream客户端，桌面端配置见官网。如果你同时在做AI开发，模型下载的加速思路类似，可以参考《Hugging Face模型下载太慢？中国用户完整加速指南》；关于网络延迟对AI编程工具链的影响，《解码AI编程的延迟鸿沟》有更深入的分析。

推荐策略： 浅克隆/部分克隆是好习惯，任何时候都值得用；SSH over 443解决连通性；日常开发用JetStream智能分流打底，git层面无需再做任何配置。

各方案对比总结

常见问题

git clone到99%突然失败，怎么办？

这是慢链路下的典型问题：clone时间越长，中断概率越大。三个建议：用 --depth 1 把clone时间从小时级压到分钟级；改用 git fetch 逐步拉取（fetch支持在已有对象基础上续传，不像clone失败即归零）；或先解决链路问题再clone。

配置了代理，为什么SSH方式的clone还是慢？

http.proxy 只对 https:// 开头的remote生效。SSH方式（git@github.com: 开头）需要在 ~/.ssh/config 里用 ProxyCommand 单独配置，见方案四。分不清时用 git remote -v 查看当前仓库用的是哪种协议。

GitHub网页能打开，但Release下载只有几KB/s？

网页HTML和Release附件走的是不同域名：附件由 objects.githubusercontent.com 分发，这个CDN域名在国内的可达性通常比主站更差。方案四的git代理管不到浏览器下载，这种场景要么复制链接用配置了代理的 curl/wget 下载，要么开启JetStream智能分流后直接在浏览器点击下载。

浅克隆的仓库还能正常push和提PR吗？

可以。--depth 1 的仓库可以正常commit和push到有权限的分支。只有涉及完整历史的操作（如 git rebase 跨越浅克隆边界、git log 查看早期提交）会受限，此时执行 git fetch --unshallow 补全历史即可。

结语

GitHub访问慢是链路问题，不是单点问题，所以没有一招通吃的”银弹”——但组合拳很有效：浅克隆减少传输量、SSH over 443保证连通性、Gitee镜像应付一次性拉取，JetStream智能分流兜底日常开发的全部场景。 把这套配置花十分钟做完，之后每一次 git clone、每一次Release下载，都不用再盯着KB/s的进度条发呆。

相关阅读：

• 《Hugging Face模型下载太慢？中国用户完整加速指南》
• 《解码AI编程的延迟鸿沟》