[{"data":1,"prerenderedAt":201},["ShallowReactive",2],{"blog:how-to-use-github-in-china":3},{"zh-CN":4,"en":110},{"blocks":5,"faq":94},[6,9,11,15,17,19,21,23,26,28,32,34,36,38,41,60,62,65,76,79,81,83,85,87,90,92],{"type":7,"html":8},"p","GitHub 网页能打开，命令行操作却经常卡住——这种「网页正常，命令行不正常」的情况很常见，原因通常不是网络整体不通，而是 git 操作用的协议和网页用的不是一回事。这一点在国内的网络环境下格外明显，命令行工具越常用，越容易撞上这个坑，也是这篇文章要先讲清楚的地方。",{"type":7,"html":10},"不管叫它科学上网工具、加速器还是别的名字，它解决的都是最基础的一层：让请求能送到 GitHub 的服务器。至于命令行走哪个协议、账号要不要二次验证、额度还剩多少，是另外三件不归这条线路管的事，混在一起排查只会浪费时间。下面先讲清楚为什么会卡，再给两条能直接抄的命令，最后说说大仓库和 LFS 免费额度这类容易被误会成网络问题的情况。",{"type":12,"id":13,"html":14},"h2","bp-why","打不开、克隆卡住、推送失败：先分清楚是哪一层",{"type":7,"html":16},"第一层是网络。GitHub 网页在国内经常需要网络工具才能稳定打开，这一层解决好了，登录、看代码、提交 issue 基本都没问题，这也是唯一一层科学上网工具能完整负责的部分，剩下三层都要靠别的方法解决。",{"type":7,"html":18},"第二层容易被忽略：git 操作本身走的协议和网页不一定是同一条链路。网页用的是普通 HTTPS 请求，命令行如果配置成 git 协议或者 SSH，走的端口和链路特征都不一样——网页能打开，不代表 clone、push 这些命令就一定顺利，这是网络里更细一层的问题，同样归网络工具管，只是需要换个入口，很多人第一次遇到这种情况都会先怀疑账号或者仓库权限，其实多半只是协议不对。",{"type":7,"html":20},"第三层是账号本身的验证。登录新设备、更换常用的登录地点，或者短时间内多次输错密码，GitHub 都可能要求二次验证或者临时冻结登录，这是账号安全机制在起作用，和网络稳不稳定没关系，换节点解决不了，也不需要解决，按提示走完验证流程就能恢复。",{"type":7,"html":22},"第四层是 GitHub 自己的额度限制：接口调用频率、Git LFS 的免费传输额度，都是平台自己的计费和风控策略，用超了就会被限速或者拒绝，这一层同样不归网络管，等下一个周期或者升级账号才会恢复。",{"type":12,"id":24,"html":25},"bp-https","把远程地址换成 HTTPS，多数克隆问题能解决",{"type":7,"html":27},"git 协议（\u003Ccode>git:\u002F\u002F\u003C\u002Fcode>）本身不加密，不少网络环境对它的容忍度比 HTTPS 低，拉取到一半突然断开，很多时候就是这个原因。换成 HTTPS 地址，走的端口和网页浏览一样，能明显减少这类中途断开。",{"type":29,"lang":30,"code":31},"code","bash","git clone https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo.git\ngit remote set-url origin https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo.git",{"type":7,"html":33},"第一条命令用 HTTPS 直接克隆一个新仓库；第二条把已经克隆好的旧仓库，从 git 协议或者 SSH 换成 HTTPS，不用重新克隆一遍。仓库特别大、经常在传输一半时超时的话，再调大一次缓冲区：",{"type":29,"lang":30,"code":35},"git config --global http.postBuffer 524288000",{"type":7,"html":37},"这条命令把 HTTP 传输的缓冲区调大，对大仓库、大文件的克隆和推送都有帮助，是长期设置，只需要执行一次，不需要每次克隆前都重新设置。如果团队里其他人也遇到同样的超时，这条命令同样适用，值得写进项目自己的说明文档里，而不是每次都重新搜索一遍。",{"type":12,"id":39,"html":40},"bp-steps","连接与操作的步骤",{"type":42,"items":43},"steps",[44,48,52,56],{"title":45,"body":46},"第一步：连接并测试基础网络",[47],"打开\u003Ca href=\"\u002Ffeatures\u002F\">快橙\u003C\u002Fa>连接后，先在浏览器里打开 GitHub 网页，确认能正常登录、看到仓库列表。这一步正常，说明网络这一层没问题。",{"title":49,"body":50},"第二步：小仓库先测试协议是否正确",[51],"找一个小仓库试着克隆，确认命令行这条链路也是通的。如果网页正常但命令行卡住，大概率是协议的问题，回头检查地址是不是 HTTPS，而不是继续怀疑整条网络。",{"title":53,"body":54},"第三步：大仓库分批处理或者调大缓冲区",[55],"大仓库克隆容易在中途超时，调大缓冲区之后重新执行一次命令。重新执行会从头开始，但调整之后整个过程更不容易在中途掉线，网络本身越不稳定，这一步的作用越明显。",{"title":57,"body":58},"第四步：确认 LFS 文件完整下载",[59],"如果仓库里有 Git LFS 管理的大文件，克隆完成后单独确认一下这些文件是否完整。不完整的话重新执行拉取命令，LFS 支持只重传缺的那部分，不用整个仓库重来，这一点在网络不太稳定的环境下尤其省时间。",{"type":61},"downloads",{"type":12,"id":63,"html":64},"bp-errors","常见报错和情况",{"type":66,"items":67},"list",[68,69,70,71,72,73,74,75],"\u003Cstrong>\u003Ccode>fatal: unable to access\u003C\u002Fcode> 加上连接被重置\u003C\u002Fstrong>：多数是网络没连稳，先确认基础网络能不能打开网页版。","\u003Cstrong>克隆到一半就停住，不再有进度\u003C\u002Fstrong>：常见于 git 协议被中途掐断，换成 HTTPS 地址通常能解决。","\u003Cstrong>大仓库总是卡在某个百分比\u003C\u002Fstrong>：调大 \u003Ccode>http.postBuffer\u003C\u002Fcode>，再重新执行一次命令。","\u003Cstrong>推送时反复要求输入账号密码或者令牌\u003C\u002Fstrong>：这是 GitHub 的身份验证流程，和网络无关，按提示生成一个访问令牌代替密码即可。","\u003Cstrong>登录时突然弹出二次验证\u003C\u002Fstrong>：新设备或者新地点登录触发的正常安全检查，不是账号出了问题。","\u003Cstrong>LFS 文件显示下载完成，打开却是一小段文本\u003C\u002Fstrong>：说明 LFS 没有正确初始化，先执行一次 LFS 相关的初始化命令再重新拉取。","\u003Cstrong>clone 完成但某些文件是空的或者损坏\u003C\u002Fstrong>：多半是传输中途出错但没有报错提示，删掉本地目录重新克隆一次比逐个文件排查更快。","\u003Cstrong>提交（push）之后网页上看不到最新内容\u003C\u002Fstrong>：先确认命令行提示是不是成功，网页缓存偶尔会有几十秒延迟，刷新一次通常就好，不用急着重新推送一遍。",{"type":12,"id":77,"html":78},"bp-limits","大仓库和 LFS，还能做的几件事",{"type":7,"html":80},"GitHub 对接口调用频率和 Git LFS 的免费传输都有自己的额度，这是平台的计费策略，不是网络限制。额度用完之后，操作会被限速或者拒绝，等下一个计费周期或者升级账号才能恢复，换多少个节点都没用，这一点从一开始就该有预期。",{"type":7,"html":82},"大仓库克隆建议避开自己网络最繁忙的时间段，同时不要一边克隆一边做其他占带宽的事情，比如下载大文件，两件事抢同一条线路，哪个都容易失败，分开进行反而更快。持续集成或者自动部署脚本里的克隆步骤，同样会受协议和额度这两层影响，排查思路和手动操作是一样的。",{"type":7,"html":84},"团队协作的仓库，把常用的大文件走 LFS 单独管理是 GitHub 官方推荐的做法，能减少普通克隆时传输的体积，这一点和网络工具选得好不好没有关系，是仓库本身的结构问题，值得在项目早期就定下来，而不是等仓库已经很大了再回头改。",{"type":7,"html":86},"接口调用频率的限制通常按账号计算，团队里每个人用自己的账号操作，比共用一个账号更不容易撞到额度上限，这也是官方建议的用法，和连接质量没有关系，自动化脚本尤其容易忽略这一点，共用一个令牌跑多个任务往往是额度用得快的真正原因。",{"type":12,"id":88,"html":89},"bp-final","总结",{"type":7,"html":91},"GitHub 拉取慢、克隆失败，通常不是一个原因：网页打不开是网络，命令行单独卡住是协议选择的问题，登录要二次验证和额度用尽是 GitHub 自己的机制。分开看，才不会把时间都花在重连网络上，却漏了真正该改的那一条设置，这一点对日常开发和自动化脚本都一样适用。",{"type":7,"html":93},"\u003Ca href=\"\u002Forder\u002F\">快橙\u003C\u002Fa>把最基础的网络这一层连稳，剩下的把地址换成 HTTPS、大仓库调大缓冲区，两条命令基本就能解决大部分克隆和推送问题。如果同时还在为\u003Ca href=\"\u002Fblog\u002Fhow-to-use-notion-in-china\u002F\">Notion 同步卡住\u003C\u002Fa>或者\u003Ca href=\"\u002Fblog\u002Fhow-to-use-figma-in-china\u002F\">Figma 卡顿\u003C\u002Fa>发愁，思路是一样的：先确认网络，再看是不是某个具体环节的问题。注册后每天有免费试用时长，先拿一个仓库测一遍。",[95,98,101,104,107],{"q":96,"a":97},"git clone 总是卡在一半就断开，是什么原因？","常见原因是用了 git 协议或者仓库太大，长连接对线路稳定性要求更高。换成 HTTPS 地址、或者调大传输缓冲区，多数情况能解决。",{"q":99,"a":100},"为什么网页能登录，命令行 clone 却不行？","网页走的是普通 HTTPS 请求，命令行如果用的是 git 协议或者 SSH，走的端口和链路不完全一样，网页正常不代表命令行那条也通。",{"q":102,"a":103},"登录时总是要求二次验证，是账号被盯上了吗？","不是，这是 GitHub 自己的账号安全机制，新设备或者新地点登录时会要求，和网络稳不稳定没有关系，按提示完成就行。",{"q":105,"a":106},"Git LFS 的文件下载到一半失败，要怎么办？","先确认基础网络稳定，再重新执行一次拉取命令，LFS 支持断点续传。如果是免费额度用完，那是 GitHub 的计费策略，换网络工具解决不了。",{"q":108,"a":109},"快橙能让 clone 和 push 都不卡吗？","快橙负责把网络这一段连稳，协议选择和额度限制由 GitHub 自己决定，工具能做的是让传输有条件顺利完成。详见\u003Ca href=\"\u002Ffeatures\u002F\">功能介绍\u003C\u002Fa>。",{"blocks":111,"faq":185},[112,114,116,118,120,122,124,126,128,130,132,133,135,136,138,140,158,159,161,171,173,175,177,179,181,183],{"type":7,"html":113},"GitHub's website opens fine while the command line keeps stalling — this "the site works, the terminal doesn't" pattern is common, and the cause is usually not the network as a whole but the fact that git operations and the website do not necessarily use the same protocol.",{"type":7,"html":115},"A circumvention tool handles the most basic layer: getting a request to GitHub's servers at all. Whether the protocol is right, how large the repo is, and whether the account needs a second verification step are three separate things that have little to do with connection stability, and treating them as one problem just wastes time.",{"type":7,"html":117},"People call this class of tool all kinds of things, but they all mean the same layer: the route that carries a request to GitHub's servers. Which protocol the command line uses, whether the account needs a second check, and how much quota is left are three separate things that route does not own. This guide explains why things stall, gives two commands you can copy directly, and closes with large repos and LFS quotas — the part most often mistaken for a network problem.",{"type":12,"id":13,"html":119},"Failing to open, stalled clones, failed pushes: which layer is it",{"type":7,"html":121},"The first layer is the network. GitHub's website often needs a network tool to open reliably from mainland China. Get this layer right and logging in, reading code and filing issues all work — and this is the only layer a circumvention tool fully owns; the other three need a different fix.",{"type":7,"html":123},"The second layer is easy to overlook: the protocol git itself uses is not necessarily the same path as the website. The website runs a plain HTTPS request; if the command line is configured for the git protocol or SSH, the port and path characteristics are different — the website loading is no guarantee that clone or push will go smoothly. This is a finer-grained network issue, and it still falls under "network," just through a different door. Most people's first instinct here is to suspect the account or repo permissions, when it's usually just the wrong protocol.",{"type":7,"html":125},"The third layer is account verification itself. Logging in from a new device, a new usual location, or after a few wrong password attempts can all get GitHub to ask for a second verification step or briefly lock the login — that is account security doing its job, unrelated to connection stability. Switching nodes does not fix it, and it does not need fixing; just complete the prompt.",{"type":7,"html":127},"The fourth layer is GitHub's own quota policy: API rate limits and Git LFS's free transfer allowance are the platform's own billing and abuse-prevention rules. Go over them and things get throttled or refused until the next billing cycle or an upgrade — also not something the network owns.",{"type":12,"id":24,"html":129},"Switch the remote to HTTPS and most clone problems go away",{"type":7,"html":131},"The git:\u002F\u002F protocol is unencrypted, and plenty of network environments tolerate it worse than HTTPS — a pull that drops suddenly halfway is very often exactly this. Switching to an HTTPS URL puts you on the same port ordinary web browsing uses, which noticeably cuts down on that kind of mid-transfer disconnect.",{"type":29,"lang":30,"code":31},{"type":7,"html":134},"The first command clones a new repo directly over HTTPS. The second switches an already-cloned repo from the git protocol or SSH to HTTPS without re-cloning it. If a repo is large enough to keep timing out mid-transfer, raise the buffer once as well:",{"type":29,"lang":30,"code":35},{"type":7,"html":137},"This raises the HTTP transfer buffer, which helps both cloning and pushing large repos and large files. It's a one-time, persistent setting — no need to set it again before every clone. If teammates hit the same timeout, the same command applies to them; it is worth putting in the project's own docs instead of everyone searching for it separately.",{"type":12,"id":39,"html":139},"Connecting and working with a repo, step by step",{"type":42,"items":141},[142,146,150,154],{"title":143,"body":144},"Step one: connect and test the basic connection",[145],"Open \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">FastOrange\u003C\u002Fa>, connect, then open GitHub's website in a browser and confirm you can log in and see your repo list. That working confirms the network layer is fine.",{"title":147,"body":148},"Step two: test the protocol with a small repo",[149],"Try cloning a small repo to confirm the command-line path is open too. If the website works but the command line stalls, the protocol is the likely culprit — go check that the URL is HTTPS rather than continuing to doubt the network as a whole.",{"title":151,"body":152},"Step three: batch large repos or raise the buffer",[153],"A large repo tends to time out mid-transfer. Raise the buffer and run the command again — it starts over from scratch, but is far less likely to drop again once the buffer is bigger, and the less stable the network, the more this step matters.",{"title":155,"body":156},"Step four: confirm LFS files downloaded completely",[157],"If the repo has files managed by Git LFS, check they came through intact after cloning. If not, run the pull again — LFS only re-transfers what's missing rather than starting the whole repo over, which saves real time on a shaky connection.",{"type":61},{"type":12,"id":63,"html":160},"Errors people actually hit",{"type":66,"items":162},[163,164,165,166,167,168,169,170],"\u003Cstrong>\u003Ccode>fatal: unable to access\u003C\u002Fcode> plus a reset connection.\u003C\u002Fstrong> Mostly an unsteady network — confirm the basic connection can open the website first.","\u003Cstrong>A clone stalls partway with no more progress.\u003C\u002Fstrong> Usually the git protocol getting cut off mid-transfer; switching to an HTTPS URL usually clears it.","\u003Cstrong>A large repo always stalls at the same percentage.\u003C\u002Fstrong> Raise \u003Ccode>http.postBuffer\u003C\u002Fcode> and run the command again.","\u003Cstrong>Push keeps asking for a username and password or token.\u003C\u002Fstrong> That's GitHub's authentication flow, unrelated to the network — generate an access token to use instead of a password when prompted.","\u003Cstrong>A two-factor prompt suddenly appears at login.\u003C\u002Fstrong> A normal security check triggered by a new device or location, not a sign anything is wrong with the account.","\u003Cstrong>LFS says a file downloaded, but opening it shows a short text stub.\u003C\u002Fstrong> LFS was not initialized correctly — run the LFS init step once, then pull again.","\u003Cstrong>A clone finishes but some files are empty or corrupted.\u003C\u002Fstrong> Usually a transfer error that never surfaced as an error message — deleting the local folder and re-cloning is faster than checking files one by one.","\u003Cstrong>The website doesn't show the latest content right after a push.\u003C\u002Fstrong> Confirm the command line actually reported success first; the website's cache can lag a few dozen seconds, and a refresh usually clears it without re-pushing.",{"type":12,"id":77,"html":172},"More on large repos and LFS",{"type":7,"html":174},"GitHub has its own quota for API call rates and free Git LFS transfer — that is the platform's billing policy, not a network limit. Go over it and operations get throttled or refused until the next billing cycle or an account upgrade; no number of node switches changes that, so it's worth expecting going in.",{"type":7,"html":176},"For large clones, avoid your own network's busiest hours, and don't clone while doing something else bandwidth-heavy like a large download — the two compete for the same route and both tend to fail. CI or deployment scripts that clone hit the same protocol and quota layers as a manual clone, and the troubleshooting approach is identical.",{"type":7,"html":178},"For team repos, routing common large files through LFS is GitHub's own recommended approach, and it cuts down what a normal clone has to transfer — that has nothing to do with which network tool you use; it's a structural choice worth making early rather than after the repo has already grown large. Rate limits are generally tracked per account, so each teammate using their own account runs into the ceiling far less often than everyone sharing one — also the officially recommended setup, and unrelated to connection quality. Automated scripts are the easy place to miss this: one shared token running several jobs is usually the real reason a quota burns fast.",{"type":12,"id":88,"html":180},"In summary",{"type":7,"html":182},"Slow pulls and failed clones on GitHub are rarely one cause: the website not opening is the network, the command line stalling on its own is a protocol choice, and two-factor prompts or an exhausted quota are GitHub's own mechanisms. Keeping them apart saves you from reconnecting the network over and over while the setting that actually needs changing sits untouched — true for everyday work and for automation scripts alike.",{"type":7,"html":184},"\u003Ca href=\"\u002Fen\u002Forder\u002F\">FastOrange\u003C\u002Fa> keeps the most basic network layer steady. From there, switching to HTTPS and raising the buffer on large repos — two commands — clears most clone and push problems. If you're also fighting \u003Ca href=\"\u002Fen\u002Fblog\u002Fhow-to-use-notion-in-china\u002F\">Notion stuck mid-sync\u003C\u002Fa> or \u003Ca href=\"\u002Fen\u002Fblog\u002Fhow-to-use-figma-in-china\u002F\">Figma stuttering\u003C\u002Fa>, the approach is the same: confirm the network first, then look for the one specific layer actually at fault. Every registered account gets free trial time each day — test it against a real repo first.",[186,189,192,195,198],{"q":187,"a":188},"git clone keeps stalling halfway and disconnecting. Why?","Common causes are the git:\u002F\u002F protocol or a repo that is simply large — a long-lived transfer is sensitive to route stability. Switching to an HTTPS URL, or raising the transfer buffer, fixes most cases.",{"q":190,"a":191},"Why does the website log in fine while the command line clone doesn't work?","The website runs over a plain HTTPS request. If the command line is set to the git protocol or SSH, it uses a different port and path — the website working says nothing about whether that one is open.",{"q":193,"a":194},"I keep getting asked for two-factor verification when I log in. Is my account being targeted?","No — that is GitHub's own account security, triggered by a new device or a new location. It has nothing to do with how stable the connection is; just complete the prompt.",{"q":196,"a":197},"A Git LFS file fails partway through downloading. What do I do?","Confirm the basic connection is stable, then run the pull again — LFS resumes rather than restarting from scratch. If it's a used-up free quota, that's GitHub's own billing policy, and no network tool changes that.",{"q":199,"a":200},"Can FastOrange keep clones and pushes from stalling?","FastOrange keeps the network leg steady. Protocol choice and quota limits are GitHub's own call — what a network tool can do is give the transfer the conditions to finish. See \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">what the app does\u003C\u002Fa>.",1791881578629]