How to Fix Git Error RPC Failed curl 56 Recv Failure

When cloning a large repository, pushing a commit containing massive media files, or pulling updates over a slow connection, Git may abort the network stream and return one of the following RPC (Remote Procedure Call) errors:

error: RPC failed; curl 56 Recv failure: Connection was reset
fatal: the remote end hung up unexpectedly

Alternatively, you may receive a status warning stating: "error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413".

These errors mean the network library Git uses (libcurl) encountered a buffer overflow, connection timeout, or gateway upload limit during HTTPS data transmission.

In this guide, we will analyze why Git RPC transfers fail and walk you through four configuration fixes to bypass these limits.

The Cause: HTTP Buffers and Network Timeouts

By default, Git communicates with servers like GitHub or GitLab using the HTTPS protocol (https://github.com/...). This transport relies on the curl library to send data packages.

If a repository contains gigabytes of files or deep commit histories, the default Git buffer sizes are too small to chunk the data. When the payload exceeds limits, the proxy gateway drops the connection (HTTP 413) or the system socket resets (curl 56).

Fix 1: Increase the Git postBuffer Limit

The most direct fix is to increase the maximum size of the buffer Git uses to chunk HTTP POST requests.

Run the configuration command in your terminal:

# Set postBuffer size limit to 500MB (value in bytes)
git config --global http.postBuffer 524288000

This allocates more memory to buffer large pushes or fetches before shipping packets over HTTPS, preventing buffer overflows.

Fix 2: Switch from HTTPS to SSH Protocol

HTTPS connections are bound by server proxy limits (like Nginx's maximum client body size). The SSH protocol (git@github.com:...) operates using raw TCP sockets, bypassing web server proxies and buffers completely.

If you have SSH keys configured on your account, update your repository's remote URL:

# 1. Inspect active remote URL
git remote -v

# 2. Change remote URL to SSH format
git remote set-url origin git@github.com:your-username/your-repo.git

# 3. Retry operations
git pull

Using SSH is the most stable method for handling repositories exceeding a few gigabytes in size.

Fix 3: Run a Shallow Clone (--depth 1)

If you cannot clone a massive repository because the connection drops midway, avoid downloading the entire history of every file since the project's creation.

Instead, execute a Shallow Clone to download only the latest commit state:

# Clone only the single most recent commit revision
git clone --depth 1 https://github.com/user/large-repo.git

This reduces the initial transfer size from gigabytes to megabytes. Once the project is successfully cloned to your disk, you can retrieve the rest of the commit history in small stages if needed:

# Pull remaining history chunks in batches
git fetch --depth 100
# Or download the complete history repository
git fetch --unshallow

Fix 4: Adjust Compression and Network Settings

Sometimes, compressing large files during transfer consumes too much CPU and RAM, causing connections to drop. You can disable Git's compression setting temporarily:

# Disable compression during transmission
git config --global core.compression 0

Additionally, if your network connection is slow, increase the active timeout duration curl allows:

# Configure HTTP connection timeout limit
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

Conclusion

Git RPC network failures are triggered by HTTP buffer constraints and gateway timeout thresholds. To resolve these transfer blocks, expand your local buffer memory using git config --global http.postBuffer, switch repository remote links from HTTPS to SSH, run shallow clones utilizing the --depth 1 flag to pull minimal histories, and disable compression parameters on heavy payloads.