Fix 'RPC failed' and 'the remote end hung up unexpectedly'

Does this match your situation?

• 'error: RPC failed; curl 56 Recv failure: Connection was reset'
• 'fetch-pack: unexpected disconnect while reading sideband packet'
• 'fatal: the remote end hung up unexpectedly'
• 'fatal: early EOF' or 'index-pack failed'
• The clone reaches 40 or 80 percent and restarts or dies, repeatedly.
• Small repositories clone fine; one large one never completes.

Step-by-step fix

1. Clone shallow, then deepen

   The transfer fails because it is one long-running stream. --depth 1 asks for the latest commit only, which is a fraction of the data and usually completes first time. Unshallowing afterwards is a separate request you can retry as often as you need without losing what you already have.

   step 1Copy

   git clone --depth 1 <url>
   cd <repo>
   git fetch --unshallow
   
   # still too big? deepen gradually:
   git fetch --depth 100
   git fetch --depth 1000
   

2. Switch to SSH

   curl 56 and HTTP/2 stream errors come from the HTTP transport. SSH uses a different protocol and different infrastructure, and often succeeds immediately on a network where HTTPS keeps resetting.

   step 2Copy

   git clone git@github.com:user/repo.git
   
   # existing repository:
   git remote set-url origin git@github.com:user/repo.git
   

3. Force HTTP/1.1

   A great many of these failures are HTTP/2 multiplexing problems introduced by a proxy, a VPN or an antivirus product that inspects traffic. Downgrading the protocol version is a one-line test that frequently resolves it outright.

   step 3Copy

   git config --global http.version HTTP/1.1
   git clone <url>
   

4. Raise the buffer for a large push

   For pushes specifically, Git's 1 MB HTTP buffer can cause a single large object to be chunked awkwardly. Raising it helps on older Git and older servers; on modern versions it usually changes nothing, so try it after the steps above rather than first.

   step 4Copy

   git config --global http.postBuffer 524288000    # 500 MB
   

   ⚠️Widely quoted as the fix for everything. It is not — treat it as a last resort for pushes, not the first thing to try.

5. Give a slow link more patience

   Git aborts a transfer that falls below a minimum speed for a set time. On a genuinely slow connection those defaults cause failures that are nothing to do with the repository.

   step 5Copy

   git config --global http.lowSpeedLimit 0
   git config --global http.lowSpeedTime 999999
   

6. Resume rather than restart

   A clone that failed mid-checkout may still have most of the objects. Re-running fetch in the partial repository continues from where it stopped, which beats deleting the folder and starting from zero.

   step 6Copy

   cd <partial-repo>
   git fetch --all
   git checkout main
   

Why this works

Git transfers history as a single packfile negotiated over one connection. The server computes it, streams it, and the client indexes it — and because that stream has to survive from beginning to end, anything that interrupts it discards the whole transfer rather than part of it. curl 56, early EOF and 'unexpected disconnect while reading sideband packet' are all the same event described from different layers: the stream stopped before the pack was complete. That is why every effective fix works by making the stream shorter or the path more reliable rather than by repairing anything. Shallow cloning asks for less data, SSH takes a different route, and HTTP/1.1 avoids the multiplexing layer that inspection proxies most often mangle.

If that didn’t work

• Try a different network — tethering to a phone rules the local link in or out in minutes.
• Disable antivirus HTTPS scanning temporarily; it terminates and re-establishes long connections.
• On a huge repository, git clone --filter=blob:none gives full history without file contents until needed.
• If the server itself is failing, ask an administrator to run git gc on it — an unpacked repository is slow to serve.

How to stop it happening again

• Use --filter=blob:none or --depth for large repositories you only need to build.
• Prefer SSH remotes on unreliable or heavily inspected networks.
• Keep binaries in Git LFS so packfiles stay small enough to transfer in one go.
• Push regularly — one push of six months' work is exactly what fails.

Commands used in this guide

Frequently asked questions