Fix Git RPC failed: curl 92 HTTP/2 PROTOCOL_ERROR on push

You're trying to push a large repository and Git dies with RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR. Annoying, but there's a quick way out.

The fix

Run these two commands in your repo, then push again:

git config http.version HTTP/1.1
git config http.postBuffer 524288000
git push origin main

That's it for most people. If the push still fails after 500MB of buffer, the real problem is almost always the remote server's HTTP/2 implementation choking on large frames, not your Git.

Why this works

What's actually happening here is that Git talks to GitHub, GitLab, or Bitbucket over HTTP/2 by default when the remote supports it. HTTP/2 multiplexes many streams over a single TCP connection and uses a binary framing layer. When you push a large packfile — say 800MB of blobs — curl (which Git uses under the hood) writes that pack in chunks. If the server resets the stream mid-transfer, curl reports code 92, which literally means "HTTP/2 stream was not closed cleanly." The stream got torn down before the END_STREAM flag arrived.

The reason step one (HTTP/1.1) works is that it sidesteps the framing layer entirely. HTTP/1.1 sends the pack as a single chunked body over one connection with no multiplexing. There's no stream ID to reset. The failure mode that produces curl 92 simply doesn't exist on HTTP/1.1.

The reason step two (postBuffer) works is subtler. Git's default is 1MB. For small pushes, that's fine — the pack gets buffered and sent. For large pushes, Git streams the pack so it doesn't eat your RAM. But some servers, especially behind reverse proxies with aggressive timeouts, will kill a connection that takes too long to send. Bumping the buffer to 500MB tells Git to hold more in memory and send it in fewer, larger writes, which finishes faster and stays under the proxy's idle timeout.

If you're on a metered connection or a slow uplink, 500MB of buffering can stall your machine. Drop to 100MB (104857600) if you're on a laptop on hotel Wi-Fi.

If that doesn't fix it

Less common variations of the same symptom show up in a few situations:

• Corporate proxy killing the connection. Zscaler, Forcepoint, and Squid all rewrite HTTP/2 traffic. Force HTTP/1.1 and disable proxy buffering. With Squid: proxy_buffering off. With Zscaler, request a bypass for github.com.
• Push is too large for a single request. Anything over ~2GB won't work regardless of buffer size because GitHub's own limits kick in. Split the history with git filter-repo or push in stages using git push origin :refs/heads/main for intermediate commits.
• MTU issues on VPN. If you're on OpenVPN or WireGuard with a bad MTU, large packets get dropped silently. Test with ping -M do -s 1472 github.com. If it fails, lower your MTU to 1400.
• Old curl. Curl versions before 7.66 have known HTTP/2 bugs that produce exactly this error. Check with curl --version and update via your package manager.
• Git LFS misconfigured. If you have LFS pointers but LFS isn't set up correctly on the remote, the push tries to send the actual blobs and blows up. Run git lfs push --all origin separately.

Prevention

Set these once globally and you'll never see curl 92 again on this machine:

git config --global http.version HTTP/1.1
git config --global http.postBuffer 524288000
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

The last two tell Git to ignore slow-transfer timeouts from the remote. If you routinely push large repos, also install Git LFS and put your binaries in it. A 4GB Photoshop file doesn't belong in Git history — LFS stores the blob out-of-band and your push stays small.

One more thing: don't ignore this error if it happens on a repo with a clean history. Repeated curl 92 on small pushes means something is actually wrong — a flaky NIC, a failing switch port, or a remote server having a bad day. The HTTP/1.1 workaround masks it; it doesn't fix it.