Ollama Pull Failing with "max retries exceeded"? Fix EOF, Connection Resets, and Stuck Downloads (2026)

By RunAIHome Team · 10 min read
ollamalocal-llmtroubleshootingdownloadnetworking

TL;DR: ollama pull failing with “max retries exceeded: EOF” or “connection reset by peer” is almost always a network problem between you and Ollama’s Cloudflare storage — not a broken model. Re-run the pull first: it resumes from the blobs already on disk instead of starting over. If it keeps dying, the usual culprit is a corporate proxy or SSL-inspection appliance choking on Ollama’s parallel connections, and the fixes for that are narrower than most guides claim.

What you’ll be able to do after this guide:

  • Read the exact error string and tell whether it’s your network, a proxy, or a full disk.
  • Get a stalled download to finish by resuming instead of re-downloading gigabytes.
  • Know which environment variable actually ships in Ollama — and which popular “fixes” do nothing.

Honest take: Try the pull again before you change a single setting. Ollama caches partial blobs, so a second or third attempt often walks the download the rest of the way. Only start editing environment variables after re-running has clearly stopped making progress.

What the error actually means

When you run ollama pull llama3.1:8b and it stops with something like:

Error: max retries exceeded: EOF
Error: max retries exceeded: unexpected EOF
Error: max retries exceeded: ... read: connection reset by peer
Error: max retries exceeded: ... dial tcp 172.67.182.229:443: i/o timeout

…the download itself is fine. Ollama pulls model layers (“blobs”) over HTTPS from Cloudflare R2 storage — the host in the logs looks like dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (issue #8167). “max retries exceeded” means Ollama tried a transfer several times, and each attempt was cut off before it finished. EOF, “unexpected EOF,” and “connection reset by peer” are three flavors of the same thing: the connection dropped mid-transfer. The i/o timeout variant means it never connected at all.

So this is not a corrupt file, a wrong tag, or a GPU problem. It’s the bytes not arriving. That narrows the fix list a lot.

Fix 1: Just run the pull again (the one everyone skips)

Ollama stores each layer as a content-addressed blob under your models directory (~/.ollama/models/blobs by default). Partially downloaded blobs stay on disk. When you re-run the same ollama pull, it doesn’t start from zero — it resumes from what’s already there.

This is why users pulling enormous models report that the download “continues instead of requiring a re-download” after an EOF (issue #8167). A 4 GB model like Mistral that dies at 40% will pick up near 40% on the next attempt, not 0%.

Practical routine:

# Run it 2-3 times. Watch the starting percentage climb each time.
ollama pull llama3.1:8b
ollama pull llama3.1:8b
ollama pull llama3.1:8b

On a flaky home connection (rural DSL, congested Wi-Fi, a VPN that renegotiates), three or four attempts frequently finish a model that no single attempt could. If the percentage climbs each time, your only “problem” is patience. If it resets to 0% or refuses to progress past the same point every time, move on to the network-specific fixes below.

Fix 2: You’re on a corporate network (SSL inspection)

This is the single most common cause of a pull that never completes no matter how many times you retry — and the most misunderstood.

Ollama opens multiple parallel connections to speed up a download. On a home network that’s a feature. On a corporate network running an SSL-inspection appliance — Palo Alto GlobalProtect, Zscaler, Forcepoint — it’s a problem. The appliance intercepts and re-encrypts every HTTPS stream, and a burst of parallel connections plus sustained multi-gigabyte transfers overwhelms it. Connections start terminating with EOF after roughly 10 seconds (issue #12624). The tell: small models under ~500 MB download fine, anything over ~1 GB fails. That size split is the fingerprint of inspection-appliance timeouts, not general connectivity loss.

Here’s where accuracy matters, because most guides get this wrong. You will see people recommend OLLAMA_NUM_PULL_PARTS=1 or OLLAMA_DOWNLOAD_PARTS=1 to cut the parallelism. Neither variable exists in shipping Ollama. OLLAMA_NUM_PULL_PARTS is an open, unmerged pull request (PR #9321); OLLAMA_DOWNLOAD_PARTS was only ever a proposal in issue #12624. Setting them does nothing.

The variable that is in current Ollama (as of v0.32.0, released July 13 2026) is OLLAMA_MAX_TRANSFER_STREAMS, default 4, defined in Ollama’s envconfig/config.go. Lowering it reduces concurrent transfer streams, which is exactly what a struggling inspection appliance needs. It’s worth trying on the service:

# Linux (systemd service) — see the env-var note at the end
sudo systemctl edit ollama
# add under [Service]:
#   Environment="OLLAMA_MAX_TRANSFER_STREAMS=1"
sudo systemctl daemon-reload && sudo systemctl restart ollama

Set it low (1 or 2) and retry. If that still doesn’t get you there, the honest answer is that the appliance, not Ollama, is the blocker. The reliable fixes are organizational:

  • Pull off the corporate network. A phone hotspot or home connection downloads the blobs; they live on disk afterward and work fine back on the corporate LAN.
  • Ask IT to whitelist ollama.com and *.r2.cloudflarestorage.com from SSL inspection.
  • Transfer the blobs manually from a machine that can download them (copy the entire models/blobs and models/manifests tree).

Fix 3: Your proxy is the problem (not the solution)

A subtle trap: setting HTTPS_PROXY gets you past the initial connection but then causes EOF during the transfer. One user on Windows set HTTPS_Proxy to get around a dial tcp ... i/o timeout, which fixed the connect phase but introduced “max retries exceeded: EOF” mid-download instead (issue #8533, Ollama 0.5.7).

Ollama reads the standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY variables (confirmed in envconfig/config.go). Two things go wrong:

  1. The proxy itself drops long transfers. If a proxy is required on your network, combine it with a lowered OLLAMA_MAX_TRANSFER_STREAMS so you’re not hammering it with parallel streams.
  2. You set the proxy in your shell, but the Ollama service doesn’t see it. On Linux and macOS, ollama usually runs as a background service that never reads your .bashrc. The proxy has to be set where the service reads it (see the note at the end) — the same gotcha that bites OLLAMA_MODELS and OLLAMA_HOST.

If you don’t actually need a proxy, unset it and retry — a stray HTTPS_PROXY left over from some other tool is a classic cause of downloads that used to work and suddenly don’t.

Fix 4: Connection resets and timeouts on a normal network

If you’re at home with no proxy and no corporate filtering, and re-running (Fix 1) isn’t finishing, you’re looking at plain connectivity to the registry or the CDN. Confirm each hop:

# Can you reach the registry at all?
curl -I https://ollama.com

# Can you reach the CDN that serves the blobs?
curl -I https://registry.ollama.ai

A hang or reset here — rather than a clean HTTP response — points at DNS, your ISP, or the route to Cloudflare. Things that genuinely help:

  • Restart the Ollama service and your router. A stale connection state on either end produces resets that a restart clears.
  • Try a different DNS resolver (1.1.1.1 or 8.8.8.8). Some ISP resolvers return bad or slow answers for Cloudflare storage hosts, which shows up as the i/o timeout variant.
  • Drop the VPN. A VPN that renegotiates keys mid-transfer will reset Ollama’s connections; the timing lines up suspiciously well with EOFs every few minutes.
  • Retry at a different time. A genuine CDN-side hiccup is transient. If curl to the hosts above succeeds but pulls fail, wait and try again before assuming it’s your setup.

Fix 5: Out of disk space (the silent one)

Model blobs are large — a Q4_K_M 8B is roughly 5 GB, a 70B around 43 GB. If your drive fills mid-pull, the transfer dies and the error can look network-shaped even though the network was fine. Check before you blame Cloudflare:

df -h ~/.ollama/models

If the volume holding your models directory is full, that’s your answer. Free space, or move the model store to a bigger drive with OLLAMA_MODELS — we walk through that in Ollama filling your C: drive? Move model storage with OLLAMA_MODELS. If you’re pulling to a NAS, know the tradeoffs first — see when NOT to use a NAS for local LLMs.

Before you fight the download: does the model even fit?

It’s worth a sanity check that the model you’re pulling will actually run on your card before you spend an afternoon on the transfer. Our best local AI models by VRAM tier guide maps model sizes to GPUs. If it won’t fit locally and you just need it once, renting a GPU by the hour on RunPod sidesteps both the download fight and the VRAM wall. For wiring a local model into your editor once it’s downloaded, aicoderscope.com covers the coding-tool side, and aifoss.dev digs into the open-source stack.

Where to set Ollama environment variables (so they actually work)

Every fix above that uses an environment variable fails silently if you set it in the wrong place. Ollama runs as a background service, and the service doesn’t read your interactive shell.

  • Linux (systemd): sudo systemctl edit ollama, add Environment="OLLAMA_MAX_TRANSFER_STREAMS=1" under [Service], then sudo systemctl daemon-reload && sudo systemctl restart ollama. A shell export does nothing here.
  • macOS: launchctl setenv OLLAMA_MAX_TRANSFER_STREAMS 1, then quit and reopen the Ollama app. This is not persistent across reboots — you’ll need a LaunchAgent for that.
  • Windows: Quit Ollama from the system tray, set the variable in Edit environment variables for your account (or setx OLLAMA_MAX_TRANSFER_STREAMS 1), then relaunch Ollama.

This is the same principle behind our other Ollama fixes — Ollama not using the GPU and Ollama keeps reloading the model both come down to setting variables where the service reads them. Once your model is finally down and you want it faster, see Ollama slow? how to get more tokens per second.

FAQ

Will re-running ollama pull start the download over from 0%? No. Ollama caches partial blobs on disk and resumes from where it left off, which is why retrying is the first thing to try. If it does reset to 0% every time, the partial blob is likely being rejected — check disk space and try a different network.

Does OLLAMA_NUM_PULL_PARTS=1 fix stalled downloads? It does nothing, because that variable isn’t in shipping Ollama — it’s an unmerged pull request (#9321). The same is true of OLLAMA_DOWNLOAD_PARTS. The variable that actually exists is OLLAMA_MAX_TRANSFER_STREAMS (default 4).

Small models download but big ones fail with EOF. Why? That size split is the classic signature of an SSL-inspection appliance on a corporate network timing out on large parallel transfers (see Fix 2). Pull off the corporate network or have IT whitelist Ollama’s hosts.

I set HTTPS_PROXY and now pulls fail mid-download. A proxy can fix the initial connection but drop long transfers. If you need the proxy, pair it with a lowered OLLAMA_MAX_TRANSFER_STREAMS. If you don’t, unset it — a leftover proxy variable is a common cause.

Can I download the model somewhere else and copy it over? Yes. Copy the entire models/blobs and models/manifests directories from a machine that completed the pull. Ollama is content-addressed, so the blobs are portable.

Is this a bug in Ollama? Mostly no — it’s your network path to Cloudflare storage. Ollama’s retry-and-resume behavior is designed for exactly these flaky conditions, which is why the fix is usually “retry” or “reduce parallelism,” not “wait for a patch.”

Sources

Last updated July 15, 2026. Ollama’s networking behavior and environment variables change between releases; verify against the current envconfig/config.go before relying on a specific variable name.

Was this article helpful?