How to fix error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8) in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 373 views

The 'RPC failed; curl 92' error occurs when Git's HTTP/2 connection to a remote server is unexpectedly closed. This typically happens due to HTTP/2 protocol issues, slow networks, or proxy/firewall interference.

Quick fix

Fixes error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)

git config --global http.version HTTP/1.1
  1. Force Git to use HTTP/1.1 instead of HTTP/2
  2. Increase Git's HTTP buffer size
  3. Use shallow clone then fetch full history
  4. Switch from HTTPS to SSH
git — error
git config --global http.version HTTP/1.1
error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)

What this error means

The "RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)" error indicates that Git's communication with the remote server (like GitHub, GitLab, or Bitbucket) was interrupted during an HTTP/2 connection. RPC (Remote Procedure Call) is the mechanism Git uses to communicate with remote servers. When you clone, push, pull, or fetch from a remote repository, Git opens an HTTP/2 connection to transfer data. Error code 92 from curl specifically means "HTTP/2 stream error" - the HTTP/2 stream was not properly closed by either the client or server. The "CANCEL (err 8)" portion indicates the stream was cancelled, often due to timeout, network instability, or the server/middlebox not handling HTTP/2 correctly. This error is particularly common with large repositories, slow internet connections, or when operating behind corporate proxies or firewalls that may not fully support HTTP/2.

Typical symptoms

  • Git clone fails partway through downloading objects
  • Git push fails with 'RPC failed' followed by curl 92 error
  • Git fetch or pull operations terminate unexpectedly
  • Error message includes 'send-pack: unexpected disconnect while reading sideband packet'
  • Operation works on fast networks but fails on slower connections
  • Error appears intermittently, sometimes succeeding on retry
  • Clone works for small repos but fails for larger repositories

Common causes

  1. HTTP/2 protocol incompatibility between client and server or a middlebox (proxy/firewall)
  2. Slow or unstable internet connection causing timeouts
  3. Corporate proxy or firewall interfering with HTTP/2 connections
  4. VPN connection causing network instability
  5. Large repository size combined with bandwidth limitations
  6. Antivirus software or security tools intercepting HTTPS traffic
  7. Git's default buffer size too small for the data transfer
  8. Server-side issues or temporary GitHub/GitLab outages

How to fix "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)"

1Force Git to use HTTP/1.1 instead of HTTP/2

The most common and effective fix is to configure Git to use HTTP/1.1, which avoids HTTP/2 stream issues:

bash
git config --global http.version HTTP/1.1

This tells Git to fall back to HTTP/1.1 for all HTTPS operations. After setting this, retry your operation:

bash
# Retry clone
git clone https://github.com/user/repo.git

# Or retry push
git push origin main
2Increase Git's HTTP buffer size

For large repositories or slow connections, increase the buffer size to allow larger data chunks:

bash
# Increase buffer to 500MB
git config --global http.postBuffer 524288000

# Or for a more conservative 150MB
git config --global http.postBuffer 157286400

This is often used in combination with the HTTP/1.1 fix for best results.

3Use shallow clone then fetch full history

For large repositories, clone with minimal history first, then fetch the rest:

bash
# Clone with only the latest commit
git clone --depth 1 https://github.com/user/repo.git

# Navigate into the repository
cd repo

# Fetch remaining history in smaller chunks
git fetch --unshallow

If --unshallow also fails, fetch history incrementally:

bash
git fetch --depth=100
git fetch --depth=500
git fetch --unshallow
4Switch from HTTPS to SSH

SSH connections don't use HTTP/2 and may be more reliable, especially behind proxies:

bash
# Generate SSH key if you don't have one
ssh-keygen -t ed25519 -C "your_email@example.com"

# Add SSH key to ssh-agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Copy public key and add to GitHub/GitLab
cat ~/.ssh/id_ed25519.pub

Add the public key to your GitHub/GitLab account settings, then clone using SSH:

bash
git clone git@github.com:user/repo.git
5Disable or configure proxy settings

If you're behind a proxy, it may be interfering with the connection. Try bypassing it temporarily:

bash
# Check current proxy settings
git config --global --get http.proxy
git config --global --get https.proxy

# Unset proxy temporarily
git config --global --unset http.proxy
git config --global --unset https.proxy

If you need the proxy, ensure it's properly configured:

bash
# Set proxy with authentication if needed
git config --global http.proxy http://username:password@proxy.example.com:8080
6Adjust timeout settings for slow connections

If you're on a slow connection, increase timeout settings:

bash
# Prevent Git from timing out on slow connections
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999

These settings tell Git to not abort even if data transfer is very slow.

7Try a different network connection

Network issues are a common cause. Try these options:

- Disconnect VPN: VPNs can add latency and cause instability
- Switch to mobile hotspot: Test if your regular network is the issue
- Use wired connection: If on WiFi, try Ethernet
- Retry at different time: Server load may vary throughout the day

After changing networks, retry your Git operation.

8Temporarily disable antivirus/firewall

Security software can intercept and modify HTTPS traffic:

Windows:
- Temporarily disable antivirus real-time protection
- Add Git and your repository folder to exclusions

macOS:
- Check System Preferences > Security & Privacy for any security tools

Corporate environments:
- Contact IT about HTTPS inspection or TLS interception policies
- Request an exception for git operations

Always re-enable security software after testing.

9Reset Git HTTP settings to defaults

If the above fixes don't work or cause other issues, reset to defaults:

bash
# Remove custom HTTP settings
git config --global --unset http.version
git config --global --unset http.postBuffer
git config --global --unset http.lowSpeedLimit
git config --global --unset http.lowSpeedTime

Then try a combination approach with fresh settings.

Advanced notes

### Understanding curl Error Codes

The number 92 in the error message is curl's error code for "HTTP/2 stream error". Other related curl errors you might see:
- curl 56: Failure in receiving network data
- curl 18: Partial file transfer
- curl 55: Failed sending network data

### HTTP/2 vs HTTP/1.1

HTTP/2 uses multiplexed streams over a single TCP connection, which can be more efficient but also more complex. Some issues with HTTP/2:

- Middleboxes (proxies, firewalls) may not properly support HTTP/2
- Stream multiplexing can cause issues with large transfers
- Some older server configurations don't handle HTTP/2 edge cases well

HTTP/1.1 is simpler and more universally supported, which is why downgrading often fixes the problem.

### WSL (Windows Subsystem for Linux) Notes

If you're using Git in WSL, you may experience this error more frequently due to:
- Network translation between Windows and Linux
- Different DNS resolution behavior
- Resource sharing with Windows

Consider using Git for Windows directly, or configure Git in WSL to use Windows credentials:

bash
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

### CI/CD Pipeline Considerations

In CI/CD environments where you can't easily change network settings:

1. Use SSH keys instead of HTTPS tokens
2. Set http.version HTTP/1.1 in the pipeline's Git configuration
3. Consider using a Git mirror closer to your CI infrastructure
4. Implement retry logic for clone operations

yaml
# Example GitHub Actions retry
- name: Checkout with retry
  uses: actions/checkout@v4
  with:
    fetch-depth: 0
  env:
    GIT_HTTP_VERSION: "1.1"

Frequently asked questions

What does "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CAN" mean?
The "RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)" error indicates that Git's communication with the remote server (like GitHub, GitLab, or Bitbucket) was interrupted during an HTTP/2 connection. RPC (Remote Procedure Call) is the mechanism Git uses to communicate with remote servers. When you clone, push, pull, or fetch from a remote repository, Git opens an HTTP/2 connection to transfer data.
How do I fix "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CAN"?
The 'RPC failed; curl 92' error occurs when Git's HTTP/2 connection to a remote server is unexpectedly closed. This typically happens due to HTTP/2 protocol issues, slow networks, or proxy/firewall interference.
What causes "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CAN"?
HTTP/2 protocol incompatibility between client and server or a middlebox (proxy/firewall) Slow or unstable internet connection causing timeouts Corporate proxy or firewall interfering with HTTP/2 connections
Is the "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CAN" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading