How to fix fetch-pack: unexpected disconnect while reading sideband packet in Git

GitINTERMEDIATEMEDIUMUpdated May 28, 2026· 589 views

Git's "fetch-pack: unexpected disconnect while reading sideband packet" means the connection dropped mid-transfer. Fix it with a shallow clone, HTTP tuning, or switching to SSH.

Quick fix

Fixes fetch-pack: unexpected disconnect while reading sideband packet

# Clone only the latest commit of the default branch
git clone --depth 1 <repository-url>
cd <repository-name>

# Then deepen gradually (each step is a separate, smaller fetch)
git fetch --depth 100
git fetch --depth 1000

# Finally pull the complete history
git fetch --unshallow
  1. Retry with a shallow clone, then deepen it
  2. Tune the HTTP transport (HTTPS clones only)
  3. Switch from HTTPS to SSH (or vice versa)
  4. Check for a proxy, VPN, or firewall that times out connections
git — error
# Clone only the latest commit of the default branch
git clone --depth 1 <repository-url>
cd <repository-name>
# Then deepen gradually (each step is a separate, smaller fetch)
git fetch --depth 100
git fetch --depth 1000
# Finally pull the complete history
git fetch --unshallow
fetch-pack: unexpected disconnect while reading sideband packet

What this error means

The "fatal: fetch-pack: unexpected disconnect while reading sideband packet" error means the connection to the remote repository was terminated while Git was still receiving data over its sideband channel. When you clone or fetch, Git uses the "fetch-pack" protocol to negotiate and download a packfile of repository objects. The sideband protocol multiplexes several streams over one connection: packfile bytes on one channel, human-readable progress on another, and server error text on a third. If the underlying connection (TCP, TLS, or the HTTP stream) closes before the transfer completes, Git is left waiting to read more bytes that never arrive and reports this fatal error. The key point is that communication started successfully (so this is not an authentication or DNS problem) but failed partway through. It is most common with large repositories, slow or flaky networks, and intermediaries (proxies, load balancers, VPNs) that cut off long-running connections after a timeout.

Typical symptoms

  • Clone or fetch fails with 'fatal: fetch-pack: unexpected disconnect while reading sideband packet'
  • The error appears after significant download progress (e.g. 'Receiving objects: 47%'), not at the start
  • Operations are intermittent: a retry sometimes succeeds where the previous attempt failed
  • Larger repositories or slower connections fail far more often than small/fast ones
  • Cloning works on some networks but fails on others (corporate VPN, hotel WiFi, CI runners)
  • HTTPS clones fail while SSH clones of the same repo succeed (or vice versa)

Common causes

  1. An unstable or slow network connection causing the TCP/TLS connection to drop mid-transfer
  2. A proxy, firewall, VPN, or load balancer terminating the long-running connection after an idle or absolute timeout
  3. A large repository whose initial transfer takes long enough to hit a server-side or intermediary timeout
  4. Server-side resource limits or timeouts on the Git host aborting the pack upload
  5. HTTP/2 incompatibilities with some proxies/servers that interrupt the stream
  6. Insufficient memory on the client when assembling a very large incoming pack
  7. An outdated Git client with known networking bugs

How to fix "fetch-pack: unexpected disconnect while reading sideband packet"

1Retry with a shallow clone, then deepen it

The most reliable fix is to download less data per request so the transfer finishes before anything times out. Start with a shallow clone, then fill in history incrementally:

bash
# Clone only the latest commit of the default branch
git clone --depth 1 <repository-url>
cd <repository-name>

# Then deepen gradually (each step is a separate, smaller fetch)
git fetch --depth 100
git fetch --depth 1000

# Finally pull the complete history
git fetch --unshallow

Breaking the download into smaller fetches matters because each git fetch is a fresh request that resumes from what you already have. If --unshallow fails, the objects already fetched are kept, so you can simply re-run the failing git fetch step until it completes.

2Tune the HTTP transport (HTTPS clones only)

If you clone over HTTPS, a few HTTP-layer settings directly affect this download.

First, force HTTP/1.1. Some proxies and servers mishandle HTTP/2 streaming and drop the connection mid-pack:

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

Next, relax the low-speed abort. By default Git aborts a transfer that stalls below a threshold; on slow links this triggers the disconnect. The values below tolerate a slow link for up to 10 minutes before giving up:

bash
# Abort only if throughput stays under 1000 bytes/s for 600 seconds
git config --global http.lowSpeedLimit 1000
git config --global http.lowSpeedTime 600

Note: http.postBuffer is sometimes recommended, but it controls the size of data Git *sends* in a single POST and only matters for large *pushes* — it has little effect on the *download* that produces this error, so don't rely on it here.

After changing these, retry the clone.

3Switch from HTTPS to SSH (or vice versa)

The two transports take different network paths, so if one is being interrupted the other often works — SSH in particular usually bypasses HTTP proxies.

bash
# Instead of: https://github.com/user/repo.git
# Use the SSH URL:
git clone git@github.com:user/repo.git

If you don't have an SSH key set up yet:

bash
# Generate a key
ssh-keygen -t ed25519 -C "your_email@example.com"

# Start the agent and add the key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Copy the PUBLIC key and add it in your Git host's SSH key settings
cat ~/.ssh/id_ed25519.pub

If you are already on SSH and failing, try the HTTPS URL instead — the reverse swap is just as valid.

4Check for a proxy, VPN, or firewall that times out connections

Intermediaries that cut off long-lived connections are a frequent cause, especially on corporate networks.

bash
# See what proxy Git is currently using
git config --global --get http.proxy

# If you must use a corporate proxy, set it explicitly
git config --global http.proxy http://proxy.example.com:8080

Things to try:

- Temporarily disconnect from the VPN and clone directly, if your network policy allows it.
- Switch to a more stable network (wired Ethernet, or a mobile hotspot) to rule out a flaky link.
- Combine with the shallow clone in Step 1 so the transfer completes before any idle timeout fires.

5Update Git to a current version

Older clients have known networking and HTTP/2 bugs that can surface as this error. Updating is low-risk and sometimes resolves it outright.

bash
# Check your current version
git --version

# Ubuntu/Debian (official up-to-date PPA)
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git

# macOS with Homebrew
brew upgrade git

# Windows
git update-git-for-windows

Re-run the clone after upgrading.

6Reduce client memory pressure for very large repos

On memory-constrained machines, assembling a huge incoming pack can fail. Lowering the delta search window reduces memory use during the operation (at the cost of slightly larger local packs):

bash
git config --global pack.window 10

This mainly helps when the failure correlates with the machine running low on memory. If memory is not the bottleneck, prefer the shallow clone in Step 1 instead — it is the more direct fix for a transfer that keeps disconnecting.

Advanced notes

### Understanding the sideband protocol

Git's pack protocol can multiplex multiple streams over one connection using "sidebands":
- Channel 1: packfile data (the actual repository objects)
- Channel 2: progress text (what you see as "Receiving objects: ...", printed to stderr)
- Channel 3: fatal error messages from the server

"Unexpected disconnect while reading sideband packet" means Git was mid-read on one of these channels when the connection closed, so it never received a clean end-of-stream.

### Large files and Git LFS

If the repository contains large binaries, the transfer takes longer and is more likely to hit a timeout. For repositories that store big assets, Git Large File Storage (LFS) keeps the main pack small:

bash
git lfs install
git lfs track "*.psd"
git lfs track "*.zip"

Existing large blobs already in history must be migrated (e.g. with git lfs migrate) or removed from history to take effect.

### CI/CD and containers

Cloning large repos inside containers over HTTPS is especially prone to this error because of layered network paths. Mitigations:
- Use git clone --depth 1 (or --filter=blob:none for a partial clone) when CI does not need full history.
- Prefer SSH over HTTPS where the runner supports it.
- Where possible, cache or mount the repository instead of cloning fresh each run.

### A note on settings that do NOT help

Several settings circulate in forum answers but target local repack/gc, not the network download that triggers this error: pack.deltaCacheSize, pack.windowMemory, pack.packSizeLimit, core.packedGitLimit, and core.packedGitWindowSize govern how Git reads/writes packs on disk, not how it receives a pack over the wire. Disabling core.compression likewise rarely helps and only increases bytes transferred. Focus on the transport-level fixes (shallow clone, HTTP/1.1, low-speed limits, SSH, proxy/timeouts) instead.

Frequently asked questions

What does "fetch-pack: unexpected disconnect while reading sideband packet" mean?
The "fatal: fetch-pack: unexpected disconnect while reading sideband packet" error means the connection to the remote repository was terminated while Git was still receiving data over its sideband channel. When you clone or fetch, Git uses the "fetch-pack" protocol to negotiate and download a packfile of repository objects. The sideband protocol multiplexes several streams over one connection: packfile bytes on one channel, human-readable progress on another, and server error text on a third.
How do I fix "fetch-pack: unexpected disconnect while reading sideband packet"?
Git's "fetch-pack: unexpected disconnect while reading sideband packet" means the connection dropped mid-transfer. Fix it with a shallow clone, HTTP tuning, or switching to SSH.
What causes "fetch-pack: unexpected disconnect while reading sideband packet"?
An unstable or slow network connection causing the TCP/TLS connection to drop mid-transfer A proxy, firewall, VPN, or load balancer terminating the long-running connection after an idle or absolute timeout A large repository whose initial transfer takes long enough to hit a server-side or intermediary timeout
Is the "fetch-pack: unexpected disconnect while reading sideband packet" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading