GitHub 拉取慢、克隆失败怎么办

GitHub 网页能打开，命令行操作却经常卡住——这种「网页正常，命令行不正常」的情况很常见，原因通常不是网络整体不通，而是 git 操作用的协议和网页用的不是一回事。这一点在国内的网络环境下格外明显，命令行工具越常用，越容易撞上这个坑，也是这篇文章要先讲清楚的地方。

不管叫它科学上网工具、加速器还是别的名字，它解决的都是最基础的一层：让请求能送到 GitHub 的服务器。至于命令行走哪个协议、账号要不要二次验证、额度还剩多少，是另外三件不归这条线路管的事，混在一起排查只会浪费时间。下面先讲清楚为什么会卡，再给两条能直接抄的命令，最后说说大仓库和 LFS 免费额度这类容易被误会成网络问题的情况。

打不开、克隆卡住、推送失败：先分清楚是哪一层

第一层是网络。GitHub 网页在国内经常需要网络工具才能稳定打开，这一层解决好了，登录、看代码、提交 issue 基本都没问题，这也是唯一一层科学上网工具能完整负责的部分，剩下三层都要靠别的方法解决。

第二层容易被忽略：git 操作本身走的协议和网页不一定是同一条链路。网页用的是普通 HTTPS 请求，命令行如果配置成 git 协议或者 SSH，走的端口和链路特征都不一样——网页能打开，不代表 clone、push 这些命令就一定顺利，这是网络里更细一层的问题，同样归网络工具管，只是需要换个入口，很多人第一次遇到这种情况都会先怀疑账号或者仓库权限，其实多半只是协议不对。

第三层是账号本身的验证。登录新设备、更换常用的登录地点，或者短时间内多次输错密码，GitHub 都可能要求二次验证或者临时冻结登录，这是账号安全机制在起作用，和网络稳不稳定没关系，换节点解决不了，也不需要解决，按提示走完验证流程就能恢复。

第四层是 GitHub 自己的额度限制：接口调用频率、Git LFS 的免费传输额度，都是平台自己的计费和风控策略，用超了就会被限速或者拒绝，这一层同样不归网络管，等下一个周期或者升级账号才会恢复。

把远程地址换成 HTTPS，多数克隆问题能解决

git 协议（git://）本身不加密，不少网络环境对它的容忍度比 HTTPS 低，拉取到一半突然断开，很多时候就是这个原因。换成 HTTPS 地址，走的端口和网页浏览一样，能明显减少这类中途断开。

git clone https://github.com/user/repo.git
git remote set-url origin https://github.com/user/repo.git

第一条命令用 HTTPS 直接克隆一个新仓库；第二条把已经克隆好的旧仓库，从 git 协议或者 SSH 换成 HTTPS，不用重新克隆一遍。仓库特别大、经常在传输一半时超时的话，再调大一次缓冲区：

git config --global http.postBuffer 524288000

这条命令把 HTTP 传输的缓冲区调大，对大仓库、大文件的克隆和推送都有帮助，是长期设置，只需要执行一次，不需要每次克隆前都重新设置。如果团队里其他人也遇到同样的超时，这条命令同样适用，值得写进项目自己的说明文档里，而不是每次都重新搜索一遍。

连接与操作的步骤

打开快橙连接后，先在浏览器里打开 GitHub 网页，确认能正常登录、看到仓库列表。这一步正常，说明网络这一层没问题。

找一个小仓库试着克隆，确认命令行这条链路也是通的。如果网页正常但命令行卡住，大概率是协议的问题，回头检查地址是不是 HTTPS，而不是继续怀疑整条网络。

大仓库克隆容易在中途超时，调大缓冲区之后重新执行一次命令。重新执行会从头开始，但调整之后整个过程更不容易在中途掉线，网络本身越不稳定，这一步的作用越明显。

如果仓库里有 Git LFS 管理的大文件，克隆完成后单独确认一下这些文件是否完整。不完整的话重新执行拉取命令，LFS 支持只重传缺的那部分，不用整个仓库重来，这一点在网络不太稳定的环境下尤其省时间。

常见报错和情况

• fatal: unable to access 加上连接被重置：多数是网络没连稳，先确认基础网络能不能打开网页版。
• 克隆到一半就停住，不再有进度：常见于 git 协议被中途掐断，换成 HTTPS 地址通常能解决。
• 大仓库总是卡在某个百分比：调大 http.postBuffer，再重新执行一次命令。
• 推送时反复要求输入账号密码或者令牌：这是 GitHub 的身份验证流程，和网络无关，按提示生成一个访问令牌代替密码即可。
• 登录时突然弹出二次验证：新设备或者新地点登录触发的正常安全检查，不是账号出了问题。
• LFS 文件显示下载完成，打开却是一小段文本：说明 LFS 没有正确初始化，先执行一次 LFS 相关的初始化命令再重新拉取。
• clone 完成但某些文件是空的或者损坏：多半是传输中途出错但没有报错提示，删掉本地目录重新克隆一次比逐个文件排查更快。
• 提交（push）之后网页上看不到最新内容：先确认命令行提示是不是成功，网页缓存偶尔会有几十秒延迟，刷新一次通常就好，不用急着重新推送一遍。

大仓库和 LFS，还能做的几件事

GitHub 对接口调用频率和 Git LFS 的免费传输都有自己的额度，这是平台的计费策略，不是网络限制。额度用完之后，操作会被限速或者拒绝，等下一个计费周期或者升级账号才能恢复，换多少个节点都没用，这一点从一开始就该有预期。

大仓库克隆建议避开自己网络最繁忙的时间段，同时不要一边克隆一边做其他占带宽的事情，比如下载大文件，两件事抢同一条线路，哪个都容易失败，分开进行反而更快。持续集成或者自动部署脚本里的克隆步骤，同样会受协议和额度这两层影响，排查思路和手动操作是一样的。

团队协作的仓库，把常用的大文件走 LFS 单独管理是 GitHub 官方推荐的做法，能减少普通克隆时传输的体积，这一点和网络工具选得好不好没有关系，是仓库本身的结构问题，值得在项目早期就定下来，而不是等仓库已经很大了再回头改。

接口调用频率的限制通常按账号计算，团队里每个人用自己的账号操作，比共用一个账号更不容易撞到额度上限，这也是官方建议的用法，和连接质量没有关系，自动化脚本尤其容易忽略这一点，共用一个令牌跑多个任务往往是额度用得快的真正原因。

总结

GitHub 拉取慢、克隆失败，通常不是一个原因：网页打不开是网络，命令行单独卡住是协议选择的问题，登录要二次验证和额度用尽是 GitHub 自己的机制。分开看，才不会把时间都花在重连网络上，却漏了真正该改的那一条设置，这一点对日常开发和自动化脚本都一样适用。

快橙把最基础的网络这一层连稳，剩下的把地址换成 HTTPS、大仓库调大缓冲区，两条命令基本就能解决大部分克隆和推送问题。如果同时还在为Notion 同步卡住或者Figma 卡顿发愁，思路是一样的：先确认网络，再看是不是某个具体环节的问题。注册后每天有免费试用时长，先拿一个仓库测一遍。