GitHub Slow Clones and Failed Pulls in China

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.

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.

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.

Failing to open, stalled clones, failed pushes: which layer is it

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.

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.

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.

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.

Switch the remote to HTTPS and most clone problems go away

The git:// 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.

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

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:

git config --global http.postBuffer 524288000

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.

Connecting and working with a repo, step by step

Open FastOrange, 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.

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.

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.

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.

Errors people actually hit

• fatal: unable to access plus a reset connection. Mostly an unsteady network — confirm the basic connection can open the website first.
• A clone stalls partway with no more progress. Usually the git protocol getting cut off mid-transfer; switching to an HTTPS URL usually clears it.
• A large repo always stalls at the same percentage. Raise http.postBuffer and run the command again.
• Push keeps asking for a username and password or token. That's GitHub's authentication flow, unrelated to the network — generate an access token to use instead of a password when prompted.
• A two-factor prompt suddenly appears at login. A normal security check triggered by a new device or location, not a sign anything is wrong with the account.
• LFS says a file downloaded, but opening it shows a short text stub. LFS was not initialized correctly — run the LFS init step once, then pull again.
• A clone finishes but some files are empty or corrupted. 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.
• The website doesn't show the latest content right after a push. 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.

More on large repos and LFS

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.

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.

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.

In summary

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.

FastOrange 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 Notion stuck mid-sync or Figma stuttering, 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.