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

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:

# 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.

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:

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:

# 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.

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

# Instead of: https://github.com/user/repo.git
# Use the SSH URL:
git clone [email protected]:user/repo.git

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

# Generate a key
ssh-keygen -t ed25519 -C "[email protected]"

# 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.

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

# 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.

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

# 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.

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):

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.