Git

How to Resolve "RPC Failed; curl 56 OpenSSL SSL_read: Connection Was Reset" in Git

4 min read by DebuggedIt

Quick answer

A git clone or git push dies partway through with a low-level SSL/curl error instead of finishing. This is a transport-layer failure — the connection to the...

A git clone or git push dies partway through with a low-level SSL/curl error instead of finishing. This is a transport-layer failure — the connection to the remote (usually GitHub, GitLab, or a corporate proxy) got cut off mid-transfer, most often on large repositories or slow/unstable networks.

The Problem

Cloning or pushing a large repository fails midway with:

$ git clone https://github.com/youruser/bigrepo.git
Cloning into 'bigrepo'...
remote: Enumerating objects: 45213, done.
remote: Counting objects: 100% (45213/45213), done.
error: RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 104
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

It can also appear during a push of a large commit (e.g., after adding big binary files):

$ git push origin main
Enumerating objects: 812, done.
Writing objects: 62% (504/812), 210.45 MiB | 1.02 MiB/s
error: RPC failed; curl 56 OpenSSL SSL_read: Connection was reset, errno 104
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

Why It Happens

curl error 56 means the connection was reset by the remote side or a network device in between, after the transfer was already in progress. Git's default HTTP buffer settings and connection handling weren't tuned for very large transfers, so this shows up most on:

  • Large repositories or a single large push (big binary assets, generated files, or a huge initial commit).
  • Unstable Wi-Fi or a VPN that drops long-lived connections.
  • Corporate proxies or firewalls that terminate connections lasting longer than a configured timeout.
  • Git's http.postBuffer defaulting too low for the transfer size, causing Git to negotiate the connection in a way that's more prone to being cut off.
  • An outdated Git or curl/OpenSSL version with known HTTP/2 handling bugs against GitHub's servers.

The Fix

The most reliable first fix is increasing Git's HTTP post buffer size, which reduces how often large transfers get chunked and re-negotiated:

git config --global http.postBuffer 524288000

This sets the buffer to 500 MB. Retry the clone or push:

git clone https://github.com/youruser/bigrepo.git

If that alone doesn't fix it, force Git to use HTTP/1.1 instead of HTTP/2, since HTTP/2 multiplexing has had compatibility issues with some proxies and older curl builds:

git config --global http.version HTTP/1.1

Also try lowering the low-speed thresholds so Git doesn't get impatient on slow connections, and disable compression which can help on some flaky networks:

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

If you're behind a corporate proxy, confirm it's configured correctly and isn't the one dropping the connection:

git config --global --get http.proxy

Switching from HTTPS to SSH entirely sidesteps a lot of these HTTP-transport issues, since SSH uses a different, typically more stable connection handling:

git remote set-url origin git@github.com:youruser/bigrepo.git
git clone git@github.com:youruser/bigrepo.git

For a clone that keeps failing partway through, a shallow clone can get you unblocked by transferring less history at once, then you can deepen it afterward:

git clone --depth 1 https://github.com/youruser/bigrepo.git
cd bigrepo
git fetch --unshallow

Still Not Working?

If the error persists even with a large buffer and SSH, update Git itself — older Git and curl builds have had specific bugs interacting with GitHub's HTTP/2 and TLS 1.3 handling:

git --version
curl --version

On Ubuntu/Debian, update through the official Git PPA rather than the default repo, which often lags behind:

sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git

If the connection still resets consistently at the same point, test whether it's your network specifically by trying the same clone from a different network (mobile hotspot is a quick test) — if it succeeds there, the issue is a firewall, proxy, or router on your original network dropping long connections rather than anything in Git's configuration.

You might also like