1. 慢在哪个环节先把病根分清楚1.1 三种“慢”长得完全不一样身边经常有朋友甩过来一句“GitHub 好慢啊克隆一个仓库几 KB 每秒有没有什么办法”我问得最多的第一句话是你到底是克隆慢、推送慢还是拉取时总断这三个“慢”表面看都是网络问题实际原因差得很远。克隆慢多跟连接建立、协议协商有关你可能卡在握手阶段而不是带宽不够。推送慢很多时候是 Git 客户端自身的缓冲区、压缩策略和认证流程在拖后腿服务器那边反而没问题。至于拉取中断则十有八九是 Git 默认的超时阈值太“玻璃心”网络稍微抖一下就主动掐断连接。不把这三类情况分开看直接去网上抄一堆配置很可能白折腾。我见过不少人把http.postBuffer、core.compression、http.version全抄了一遍结果问题依旧因为方向就搞错了。这就像感冒了吃胃药配方再对也没用。所以这篇内容我不会只丢给你几行命令就算完而是先教你 60 秒内判断自己是哪种慢再针对性地给方案。核心的三行 Git 配置指令会覆盖到 80% 的克隆/推送慢场景剩下的 20%我会用几个更直接的操作技巧来补漏。1.2 一个 60 秒的分段诊断法拿到一台新电脑、或者在某条网络下报怨 Git 慢时我一般按下面这四步做诊断每步都用不了 15 秒。第一步在终端里ping github.com看延迟和丢包。如果延迟在几十毫秒到一百多毫秒之间说明基础链路还能用如果出现超时或丢包严重那你遇到的慢甚至可能不是 Git 配置能解决的得先解决连通性问题。第二步执行curl -I https://github.com观察返回响应头要多久。如果 HTTPS 握手阶段就花了十几秒甚至卡住那问题大概率出在协议协商环节这时候把 Git 的 HTTP/2 降级成 HTTP/1.1往往会立竿见影。第三步找一个小仓库实际克隆一下看显示的速度到底是多少。注意看速度数字的分布如果速度一直稳定在几十 KB那是传输层受限如果速度忽快忽慢、最后直接fatal: The remote end hung up unexpectedly或者RPC failed那是被超时策略掐断的。第四步推送到一个测试仓库观察Counting objects之后的进度条。如果卡在Writing objects或者经常报HTTP 413那就是缓冲区设置的问题了。做完这四步你应该心里有数自己是属于连接慢、传输慢、还是会断线。接下来要做的就是对号入座去调参数。2. 三条核心 Git 配置指令覆盖 80% 的克隆/推送慢2.1 第一行固定 HTTP/1.1绕开握手卡顿很多人在克隆时遇到的问题不是下载速度本身而是连接建立阶段卡死。Git 在很多版本里默认会尝试使用 HTTP/2 协议这个协议本身确实先进多路复用、头部压缩都是好东西但在一些不稳定的网络环境下HTTP/2 的握手协商反而成了拖累——连接建立时的往返次数更多一旦某个环节被干扰就会一直卡在remote: Enumerating objects阶段大半天不出进度。我的做法很直接在全局配置里强制 Git 使用 HTTP/1.1git config --global http.version HTTP/1.1这一行命令的意思是以后所有通过 HTTPS 进行的 Git 操作都固定用 HTTP/1.1 协议来传输。HTTP/1.1 虽然“古老”但它足够稳定连接建立的开销低在弱网环境下反而比 HTTP/2 表现更可靠。我实测过不少次有些仓库在默认协议下克隆速度只有几十 KB改成 HTTP/1.1 之后就稳定到了 MB 级。原因不是 HTTP/1.1 更快而是它把那些不必要的协商开销省掉了。如果你手头用的是很老版本的 Git可能没有这个配置项建议先把 Git 升级到较新版本再执行不然会提示未知配置项。注意这条配置是全局的会影响你所有通过 HTTPS 操作的仓库不只是 GitHub。如果你平时也用 GitLab、Gitea 之类的服务这条配置同样生效目前看对它们没有负面影响可以放心用。2.2 第二行调大 postBuffer专治“推不上去”推送慢或者推送失败和克隆慢是两码事。最常见的报错是error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413第一次见到这个报错的人可能会一脸懵这其实是因为推送时 Git 需要通过 HTTPS 把对象数据 POST 给远端服务器而客户端本地默认的 HTTP 缓冲区大小有限。当你要推送的内容很大比如仓库里带了几百 MB 的素材、安装包或者模型文件缓冲区一满连接就会被掐断于是推送永远卡在最后一步。解决办法是调大http.postBuffer的值官方默认单位是字节我习惯直接设成 500MBgit config --global http.postBuffer 524288000这个数字就是 500MB 的字节数。设成这么大之后Git 在推送大对象时就不会因为缓冲区耗尽而中断了。如果你只是偶尔推送大仓库也可以不设成全局只给特定仓库设置git config http.postBuffer 524288000区别在于少了一个--global只会对当前仓库生效。我自己一般直接全局设置因为大缓冲区对小仓库没有副作用而且你永远不知道下一个仓库会不会突然冒出个大文件。这里要澄清一个很多人有的误解postBuffer不是把你的网络带宽变大而是允许一次 POST 请求携带更多数据。它解决的是“数据量超过单次传输能力导致失败”的问题而不是“传输速率慢”的问题。但“推送失败”和“推送慢”经常是伴随出现的推送失败意味着你要反复重试重试本身就是最大的时间浪费所以这个参数对推送体验的提升非常明显。2.3 第三行放开超时限制专治“卡死在 0%”如果你遇到的不是推送失败而是克隆到一半突然报错或者进度条长时间不动后直接退出那大概率是 Git 的“低速超时”机制在作祟。Git 默认有个叫http.lowSpeedLimit的选项它和http.lowSpeedTime配合工作当传输速率低于某个阈值且持续时间超过设定值Git 会认为连接已经“死”了主动断开。这个机制的初衷是好的防止用户干等着一条死连接。但在弱网环境下它反而成了最大的坑——明明只是网络抖了一下Git 就暴力退出你前面的下载全白费了。我的处理方式很简单直接把这两项调整到几乎不会触发git config --global http.lowSpeedLimit 0 git config --global http.lowSpeedTime 999999第一条是把低速阈值设成 0意味着 Git 不会因为“太慢”而断开第二条是把持续判断的时间拉长到 999999 秒约等于 11 天半基本就是“永远等”。如果你不太放心完全不限制想保留一定的防呆机制可以设置成一个保守的值比如git config --global http.lowSpeedLimit 1000 git config --global http.lowSpeedTime 60意思是“如果传输速度持续 60 秒低于 1KB/s才判定为断线”。这个设置比默认值宽容得多但又不至于让 Git 真的傻等一晚上。提示这三行配置只是“解除限制”不是“提速神器”。它们能让 Git 不再主动掐断你的连接但真正要提升传输速度还得看下面第 3 章的操作。3. 比改配置更管用的几条克隆/拉取阶段的实操提速3.1 浅克隆只拉最新代码不拉全量历史很多仓库历史悠久比如那些积累了十年的老项目完整克隆下来动辄几个 GB。可你只是想看看源码、跑个 demo根本用不到全部历史提交。这时候最有效的提速方式是告诉 Git只要最新这一版历史别给我了。git clone --depth1 https://github.com/xxx/yyy.git--depth1就是浅克隆的开关Git 只会下载最新一次提交对应的文件内容。仓库体积往往可以从几百 MB 缩到几十 MB克隆时间自然大幅缩短。浅克隆也有代价你无法查看历史提交记录也不能直接切换到旧的 commit。如果后面你需要完整历史了可以执行git fetch --unshallow把缺失的历史记录补回来。不过这里有个前提你最初是通过浅克隆方式拉取的如果直接用别的方式拿到仓库这个命令不适用。我自己的习惯是临时看项目用浅克隆真正打算长期维护或参与开发就完整克隆。分清楚使用场景能节省大量时间。3.2 单分支克隆连其他分支都省了在浅克隆的基础上还可以再做一步减法——只拉某个特定分支git clone --depth1 --branch main --single-branch https://github.com/xxx/yyy.git--branch main指定分支名--single-branch告诉 Git 只下载这个分支的引用其他分支一概不拉。这样做的好处是即使仓库里有很多分支、很多 tag也完全不影响你这次克隆的体积。如果你的 Git 版本是 2.23 以上还有一个更高级的玩法--filterblob:none。它的原理是“按需下载文件内容”。什么意思呢就是克隆时只拉仓库的目录结构和提交记录具体的文件内容也就是 Git 术语里的 blob等真正 checkout 到工作区时才去下载。git clone --filterblob:none https://github.com/xxx/yyy.git这种方式特别适合那些文件巨大但结构分散的仓库——比如包含大量素材或历史快照的项目。它配合浅克隆一起使用时效果更佳体积和传输时间都可以再压缩一截。当然这类高级参数依赖服务端支持GitHub 这边是兼容的放心用。3.3 走 443 端口的 SSH 通道最稳的备选方案很多时候克隆慢不是因为 GitHub 服务器不给力而是因为某些网络环境下对 SSH 默认的 22 端口不太友好甚至直接超时。这时候有一个 GitHub 官方支持的替代方案在 443 端口上走 SSH。443 端口是 HTTPS 的默认端口通常网络环境不会对它做严格限制。GitHub 提供了一个专门用于 SSH 连接的端点ssh.github.com端口 443。首先确认你已经有 SSH key 并配置到了 GitHub 账号里。然后在~/.ssh/config文件里写入这一段Host github.com HostName ssh.github.com Port 443 User git之后你再去执行git clone gitgithub.com:xxx/yyy.git或者git push连接就会自动走ssh.github.com:443而不用改仓库的 remote 地址。想验证通道是否通可以执行ssh -T -p 443 gitssh.github.com如果能收到类似Hi xxx! Youve successfully authenticated的提示说明通道没问题接下来克隆和推送都会走这个更稳的连接。我在不少网络环境里实测过用 443 端口走 SSH 确实比默认的 22 端口更稳速度也更可预期。这个方案完全是 GitHub 官方提供的不需要安装任何额外工具配置一次长期有效。3.4 顺手检查一下 DNS 解析如果你的 GitHub 连接是“时快时慢、偶尔抽风”还有一种可能DNS 解析出来的 IP 不是最优节点。GitHub 在全球有多个接入点不同地区访问时DNS 可能会把你引导到一个延迟较高的 IP。诊断方法很简单nslookup github.com看看解析出来的 IP 是否合理。如果你用的是运营商默认 DNS有时解析结果并不理想。可以尝试把电脑或路由器的 DNS 改成公共 DNS 服务比如阿里的223.5.5.5、腾讯的119.29.29.29再重新解析对比一下。要注意的是公共 DNS 解决的是“解析到错误节点”的问题不是“物理距离”的问题。如果网络本身的出口带宽有限换 DNS 也不会有质的飞跃。所以这一步通常作为辅助手段配合前面的操作一起用。4. 推送方向从“推不上”到“秒推”的实操经验4.1 用 SSH key 免密推送彻底告别卡在输密码推送慢还有一个被忽略的原因每次推送都要输用户名密码。如果用的是 HTTPS 协议Git 在推送时会反复弹窗让你认证在网络条件差的时候就特别容易卡在认证环节或者因为密码输入错误而反复重试。解决方案就是切换到 SSH 协议用 SSH key 免密认证。生成密钥就一行命令ssh-keygen -t ed25519 -C your_emailexample.com一路回车即可。生成的公钥默认在~/.ssh/id_ed25519.pub把里面的内容复制到 GitHub 的Settings - SSH and GPG keys页面里。然后在本地验证一下ssh -T gitgithub.com看到成功认证提示后就把仓库的 remote 地址改成 SSH 格式git remote set-url origin gitgithub.com:xxx/yyy.git之后推送就再也不用输密码了。这一步省下的时间看上去不多但体验上的提升是实打实的——你不用在每次推送时盯着终端等待认证也不怕密码输错被打回重来。如果你所在网络对 22 端口不友好记得把 4.3 里讲的 443 端口方案一起用上把~/.ssh/config配置好SSH 推送的稳定性会再上一个台阶。4.2 大仓库推送前的“瘦身”操作推不上去、或者推送特别慢很多时候不是网络问题而是仓库本身太“肥”了。GitHub 对单个文件有 100MB 的硬性限制超过这个大小会直接拒绝推送。即便没超过 100MB几十 MB 的资源文件塞进 Git 仓库每次推送都要重新打包压缩速度自然上不来。我有一次推一个带 300MB 素材的仓库怎么推都失败最后发现是仓库里混进了一个巨大的打包文件。处理方式是把大文件从 Git 追踪中移除git rm --cached giant-file.zip--cached参数的意思是只从 Git 的版本控制里移除但保留本地文件。移除后提交然后再推送。如果仓库历史里已经有大文件了光删当前版本还不够需要用工具把历史里的脏文件也清理掉。我常用的工具是git filter-repogit filter-repo --path giant-file.zip --invert-paths这个命令会把指定路径从整个历史里抹掉然后强制推送覆盖远端历史。注意操作前一定要备份因为这会重写历史团队成员需要重新克隆。另外推送时还可以关掉 Git 的压缩处理减少 CPU 消耗git config --global core.compression 0压缩级别设为 0意味着 Git 不再对要推送的数据做压缩。带宽会多消耗一些但 CPU 负担轻了推送过程的耗时会下降。这个参数适合大仓库、高带宽场景小仓库没必要关关了反而可能因为传输数据变大而更慢。最后提醒一句别把 GitHub 当网盘用。真正的静态大文件应该走 Git LFS 或独立的对象存储让 Git 只管理代码本身推送速度才会真正快起来。4.3 一个仓库推多个远端省一半等待时间有时候你不想把鸡蛋全放在一个篮子里比如同一个仓库既要推到 GitHub又要推到公司内网的 Git 服务器。按常规做法你得分别git push origin main和git push internal main两条命令前后执行等于把同样的数据传两遍。Git 其实支持一个 remote 关联多个地址实现“一推多发”git remote add all https://github.com/xxx/yyy.git git remote set-url --add all gitgitlab.company.com:xxx/yyy.git然后把默认推送目标切到allgit push all main这样一条命令GitHub 和公司服务器会同时收到数据。虽然总带宽不变但省去了手动执行两次推送的等待和中断风险尤其在网络不稳定的情况下少执行一次命令就少一次失败的可能。5. 我踩过的坑常见报错与排查速查表5.1 报错速查表下面这张表是我在实际使用中遇到过的典型报错原因和解法都可以直接照着处理报错信息原因解法error: RPC failed; HTTP 413 curl 22postBuffer 太小POST 数据超限调大http.postBuffer建议 500MB 起error: RPC failed; curl 92 HTTP/2 stream 0HTTP/2 流被重置协议层卡住切换http.version为 HTTP/1.1fatal: The remote end hung up unexpectedly超时策略太严格或打包数据量过大调低lowSpeedLimit关闭压缩检查仓库大文件ssh: connect to host github.com port 22: Connection timed out22 端口被网络策略限制改用ssh.github.com的 443 端口 SSHFailed to connect to github.com port 443: Operation timed out到 443 端口的链路不稳定错峰重试、更换网络、检查 DNS 解析unable to access ... SSL connect error系统时钟偏差导致 TLS 握手失败同步系统时间更新 Git 到新版这些报错我基本都在真实环境里遇到过。特别是HTTP 413和HTTP/2 stream这两个几乎成了“大仓库推送失败”的代名词。看到它们第一反应不用去怀疑网络先看自己的 Git 客户端参数。5.2 三个高频场景的实测案例给你说三个我实际处理的案例看完你大概就有感觉了。第一个案例某次我在不稳定的网络环境下克隆 Spark 源码仓库默认配置下进度条一直卡在Receiving objects: 0%等了十分钟纹丝不动。当时我第一反应就是 HTTP/2 握手出了问题停掉克隆后执行了git config --global http.version HTTP/1.1重新克隆进度条马上就开始走了速度稳定在 1MB/s 以上十分钟不到拉完整个仓库。第二个案例一个朋友推送他的 App 工程仓库里有个 300MB 的素材包一次次在最后关头报RPC failed; HTTP 413。他一度以为是 GitHub 限制了上传大小其实不是。我让他执行了git config --global http.postBuffer 524288000再配合git config --global core.compression 0同一个仓库一次性推送成功。后来检查发现素材包里其实有个不该入库的巨大压缩文件清理掉之后推送速度又明显快了一截。第三个案例是“拉取中断”的典型在某个延迟特别高的网络里拉 Laravel 框架总是下载到一半就fatal: The remote end hung up unexpectedly。我起初以为是网络太差但反复断在差不多的位置让我意识到是超时判定太敏感。执行了git config --global http.lowSpeedLimit 0和git config --global http.lowSpeedTime 999999之后同样的网络下顺利拉完了。说白了GitHub 慢是一个“综合性”问题但 80% 的坑都能用这三行配置救回来。剩下的 20%靠浅克隆和 443 端口 SSH 补齐。把这些沉淀成自己的操作习惯之后我基本再没为克隆或推送浪费时间。如果你现在手里正好有个仓库拉不下来、推不上去别急着折腾镜像或者换网络。先把那三行指令敲了再按照报错速查表对号入座。我这几条经验是踩过不少坑才总结出来的照着走能少走很多弯路。