Git "RPC failed; curl 92/56 HTTP/2" on Clone in CI

The clone started over HTTP/2 and the multiplexed stream was reset mid-transfer. Some proxies and load balancers mishandle long HTTP/2 streams for large packs; forcing HTTP/1.1 usually clears it.

What this error means

A clone or fetch of a large repo dies with RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly or curl 56 Recv failure: Connection reset by peer, often partway through "Receiving objects". Small repos are fine; the big one fails, sometimes at a different point each run.

error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly:
PROTOCOL_ERROR (err 1)
fatal: the remote end hung up unexpectedly
fatal: early EOF

Common causes

A proxy/LB mishandling HTTP/2 streams

An intermediary that does not cleanly proxy long HTTP/2 streams resets the connection on a big pack, surfacing as curl 92 or curl 56.

A large pack over an unstable link

A multi-gigabyte transfer is more likely to hit a transient reset; the bigger the repo, the more a single blip aborts the whole clone.

How to fix it

Force HTTP/1.1 for Git

Pinning HTTP/1.1 avoids the HTTP/2 stream-reset path entirely and is the most reliable fix for curl 92.

git config --global http.version HTTP/1.1
git clone https://github.com/org/big-repo.git

Shrink the transfer or raise the buffer

A shallow clone moves far less data; a larger post buffer helps proxies that choke on long streams.

git clone --depth 1 https://github.com/org/big-repo.git
# or
git config --global http.postBuffer 524288000   # 500 MB

Retry the transient reset

When the reset is a one-off, a bounded retry around the clone clears it.

for i in 1 2 3; do
  git clone https://github.com/org/big-repo.git && break
  echo "clone failed (attempt $i), retrying..."; sleep 5
done

How to prevent it

• Set http.version HTTP/1.1 on runners behind HTTP/2-incompatible proxies.
• Use shallow clones in CI unless full history is required.
• Raise http.postBuffer for large monorepos behind buffering proxies.

Related guides