How to fix fatal: the remote end hung up unexpectedly in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 522 views

This error occurs when Git's connection to a remote server is terminated before the operation completes. The most common cause is pushing or cloning large repositories over HTTP, where the default buffer size is insufficient. Increasing the http.postBuffer setting or using SSH typically resolves the issue.

Quick fix

Fixes fatal: the remote end hung up unexpectedly

# Set buffer to 500 MB (recommended starting point)
git config --global http.postBuffer 524288000
  1. Increase the HTTP POST buffer size
  2. Configure settings for slow connections
  3. Disable compression for large transfers
  4. Switch from HTTPS to SSH
git — error
# Set buffer to 500 MB (recommended starting point)
git config --global http.postBuffer 524288000
fatal: the remote end hung up unexpectedly

What this error means

The "fatal: the remote end hung up unexpectedly" error indicates that the remote Git server (like GitHub, GitLab, or Bitbucket) closed the connection before Git finished transmitting or receiving data. This typically happens during push, pull, clone, or fetch operations. The error can occur for several reasons: - **Large file transfers**: When pushing commits that include large files or many changes, the HTTP POST request may exceed server limits or timeout thresholds - **Network instability**: Poor network connectivity, high latency, or intermittent connections can cause the server to drop the connection - **Server-side limits**: The remote repository host may have size limits, timeout settings, or rate limits that terminate long-running requests - **Proxy or firewall interference**: Corporate networks, VPNs, or security software may interrupt connections that take too long or exceed size thresholds The error message itself doesn't indicate the root cause, so troubleshooting involves trying different configuration options and connection methods.

Typical symptoms

  • Push operation fails with 'fatal: the remote end hung up unexpectedly'
  • Clone operation fails partway through receiving objects
  • Error occurs more frequently with large commits or repositories
  • RPC failed message appears alongside the error (e.g., 'error: RPC failed; curl 56')
  • Operation succeeds on retry after failing initially
  • Same repository works over SSH but fails over HTTPS
  • Error appears in CI/CD pipelines during git push or git fetch

Common causes

  1. HTTP POST buffer size too small for the data being transferred (default is 1 MB)
  2. Network timeout - slow connection causing the server to close the connection
  3. Server-side request size limit exceeded (e.g., nginx client_max_body_size)
  4. Proxy server or firewall terminating long-running HTTP connections
  5. Repository or individual files exceed hosting provider's size limits
  6. VPN or network security software interfering with the connection
  7. High network latency causing connection instability (satellite, mobile data)
  8. Antivirus software scanning or blocking large HTTP transfers
  9. SSH key issues when using SSH protocol (permissions, incorrect key)
  10. Rate limiting by the repository hosting provider

How to fix "fatal: the remote end hung up unexpectedly"

1Increase the HTTP POST buffer size

The most common fix is to increase Git's HTTP buffer, which defaults to only 1 MB:

bash
# Set buffer to 500 MB (recommended starting point)
git config --global http.postBuffer 524288000

For very large repositories, you may need even more:

bash
# Set buffer to 1 GB
git config --global http.postBuffer 1048576000

To set this only for the current repository (not globally):

bash
git config http.postBuffer 524288000

After changing this setting, retry your git operation.

2Configure settings for slow connections

If you're on a slow or unstable network, adjust timeout settings:

bash
# Disable low speed limit (prevents timeout on slow connections)
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

These settings tell Git not to abort the connection even if the transfer speed drops very low.

3Disable compression for large transfers

Compression adds CPU overhead and can cause issues with very large transfers:

bash
# Disable compression
git config --global core.compression 0

# Optionally limit pack window size
git config --global pack.window 1

This trades bandwidth for reliability - useful when the issue is timeout-related rather than bandwidth-related.

4Switch from HTTPS to SSH

SSH connections are often more reliable for large transfers and avoid HTTP-related buffer issues:

Check your current remote URL:

bash
git remote -v

Change from HTTPS to SSH:

bash
# GitHub
git remote set-url origin git@github.com:username/repository.git

# GitLab
git remote set-url origin git@gitlab.com:username/repository.git

# Bitbucket
git remote set-url origin git@bitbucket.org:username/repository.git

Ensure your SSH key is set up:

bash
# Check if you have an SSH key
ls -la ~/.ssh/

# Test SSH connection to GitHub
ssh -T git@github.com

# Test SSH connection to GitLab
ssh -T git@gitlab.com

If you don't have an SSH key configured, see your hosting provider's documentation for SSH key setup.

5Push changes in smaller chunks

If you have many commits or large changes, push them incrementally:

bash
# Push commits one at a time
git log --oneline origin/main..HEAD | tail -1
# Get the oldest commit hash, then:
git push origin <commit-hash>:main
# Repeat for remaining commits

Or use a script to push incrementally:

bash
#!/bin/bash
# Push commits in batches of 10
for commit in $(git rev-list --reverse origin/main..HEAD | awk 'NR % 10 == 0'); do
  git push origin $commit:main
done
git push origin HEAD:main

This approach is especially useful when you have a backlog of many commits to push.

6Clone with depth limit for large repositories

When cloning large repositories, use a shallow clone to reduce data transfer:

bash
# Clone only the last 1 commit
git clone --depth 1 https://github.com/username/repository.git

# Clone only the last 10 commits
git clone --depth 10 https://github.com/username/repository.git

# Later, if you need full history:
git fetch --unshallow

For very large repositories, you can also clone only a specific branch:

bash
git clone --depth 1 --branch main --single-branch https://github.com/username/repository.git
7Check for large files in your commit

Large files are a common cause of this error. Find them before pushing:

bash
# Find large files in your working directory
find . -type f -size +50M -not -path './.git/*'

# Find large files in git history
git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  awk '/^blob/ {print substr($0,6)}' | \
  sort -rnk2 | \
  head -20

If you find large files that shouldn't be in the repository:
- Add them to .gitignore
- Consider using Git LFS (Large File Storage) for files that need versioning
- Remove them from history using git filter-repo if already committed

8Enable Git debugging for more details

Get verbose output to understand exactly where the failure occurs:

On Linux/macOS:

bash
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1
git push

On Windows (PowerShell):

powershell
$env:GIT_TRACE_PACKET=1
$env:GIT_TRACE=1
$env:GIT_CURL_VERBOSE=1
git push

This will show detailed information about the HTTP requests and responses, helping identify whether the issue is:
- Connection timeout
- Server rejection (look for HTTP 413 or 408 status codes)
- SSL/TLS issues
- Authentication problems

9Check proxy and firewall settings

Corporate networks often have proxies or firewalls that interfere with large transfers:

Check current proxy settings:

bash
git config --global --get http.proxy
git config --global --get https.proxy

If you need to use a proxy:

bash
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080

If proxy is causing issues, try without it (if network allows):

bash
git config --global --unset http.proxy
git config --global --unset https.proxy

For VPN issues, try:
- Temporarily disconnecting from VPN
- Using SSH instead of HTTPS
- Contacting your IT department about git traffic whitelisting

10Try a different network

If other solutions don't work, the issue may be network-specific:

- Switch from WiFi to mobile data (or vice versa) to test
- Try a different WiFi network if available
- Restart your router to get a fresh connection
- Reinstall network drivers on Windows if issue persists across networks

If the operation works on a different network, the issue is likely:
- ISP-level traffic shaping
- Network equipment limitations
- Firewall or security software on the original network

In CI/CD environments, this may indicate network issues with the build runner.

Advanced notes

Understanding Git's Smart HTTP Protocol:

Git uses "Smart HTTP" for transfers over HTTP/HTTPS. When pushing data larger than the http.postBuffer size (default 1 MB), Git switches to HTTP/1.1 chunked transfer encoding. Some servers and proxies don't handle chunked encoding well, causing connection drops.

Server-Side Configuration:

If you control the Git server or reverse proxy, check these settings:

nginx:

nginx
# Increase max body size (default is 1MB)
client_max_body_size 500M;

# Increase timeouts
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Apache:

apache
# Increase timeout (in seconds)
Timeout 600
ProxyTimeout 600

Git Pack Internals:

When you push, Git creates a "pack" of objects. The pack size depends on:
- Number of new objects (commits, trees, blobs)
- Compression settings
- Delta encoding effectiveness

For extremely large pushes:

bash
# Create smaller packs
git config pack.packSizeLimit 100m

# Reduce memory usage during packing
git config pack.threads 1
git config pack.windowMemory 100m

Git LFS for Large Files:

If you regularly work with large files, consider Git LFS:

bash
# Install Git LFS
git lfs install

# Track large file types
git lfs track "*.psd"
git lfs track "*.zip"
git lfs track "*.mp4"

# Add the .gitattributes file
git add .gitattributes
git commit -m "Configure Git LFS"

SSH Buffer Configuration:

For SSH connections, you can similarly increase buffer sizes:

bash
git config --global ssh.postBuffer 524288000

Curl Error Codes:

The error often appears with "RPC failed; curl XX" where XX indicates:
- curl 18: Transfer closed with outstanding read data remaining
- curl 56: Failure with receiving network data (CURLE_RECV_ERROR)
- curl 55: Failed sending network data
- curl 7: Failed to connect to host

Debugging Network Issues:

For persistent issues, capture a network trace:

bash
# On Linux
tcpdump -i any -w git-push.pcap port 443 &
git push
kill %1
# Analyze with Wireshark

CI/CD Specific Considerations:

In CI/CD pipelines, this error often indicates:
- Insufficient memory for the git operation
- Network throttling on shared runners
- Docker networking issues when using containers

Consider using git clone --depth for CI builds to reduce data transfer.

Frequently asked questions

What does "fatal: the remote end hung up unexpectedly" mean?
The "fatal: the remote end hung up unexpectedly" error indicates that the remote Git server (like GitHub, GitLab, or Bitbucket) closed the connection before Git finished transmitting or receiving data. This typically happens during push, pull, clone, or fetch operations. The error can occur for several reasons: - Large file transfers: When pushing commits that include large files or many changes, the HTTP POST request may exceed server limits or timeout thresholds - Network instability: Poor network connectivity, high latency, or intermittent connections can cause the server to drop the connection - Server-side limits: The remote repository host may have size limits, timeout settings, or rate limits that terminate long-running requests - Proxy or firewall interference: Corporate networks, VPNs, or security software may interrupt connections that take too long or exceed size thresholds The error message itself doesn't indicate the root cause, so troubleshooting involves trying different configuration options and connection methods.
How do I fix "fatal: the remote end hung up unexpectedly"?
This error occurs when Git's connection to a remote server is terminated before the operation completes. The most common cause is pushing or cloning large repositories over HTTP, where the default buffer size is insufficient. Increasing the http.postBuffer setting or using SSH typically resolves the issue.
What causes "fatal: the remote end hung up unexpectedly"?
HTTP POST buffer size too small for the data being transferred (default is 1 MB) Network timeout - slow connection causing the server to close the connection Server-side request size limit exceeded (e.g., nginx client_max_body_size)
Is the "fatal: the remote end hung up unexpectedly" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading