Ollama “max retries exceeded”: Fix the Proxy on the Server, Then Update to v0.40.15

Bottom line: Error: max retries exceeded on ollama pull means one download part failed six times in a row. The useful half of the line is after the colon. A common pattern is that the manifest succeeds, then a Cloudflare R2 blob fails. Put HTTPS_PROXY on the Ollama server process, not only in your shell, and update to stable v0.40.15. We reproduced a broken-proxy path on Linux with v0.40.15 on November 9, 2026.

How to read the message

A typical form from GitHub #18842 (Ollama 0.35.1):

pulling manifest
Error: max retries exceeded: Get "https://….r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/…": …

The first half never changes. After the colon you may see no such host, i/o timeout, connection refused, or EOF. Ollama’s FAQ says model pulls need internet access and, behind a proxy, you should set HTTPS_PROXY on the server; it also warns against setting HTTP_PROXY, which can break client→server traffic.

Manifest OK, blob fails

The registry returns a manifest first; the large files redirect to Cloudflare R2. #18729 (closed) reported that from 0.35.0 some builds bypassed HTTPS_PROXY for blob downloads and dialed R2 directly—fatal on networks that require a forward proxy. Related: #18716. Because #18729 is closed, do not write that the bug is still unfixed upstream. If you still hit it, say “still reported by users” with your version and date (e.g. #18842 on 0.35.1; that reporter later said 0.40.6 worked).

The quieter failure mode: you export HTTPS_PROXY in a terminal, but the macOS app / Linux systemd unit never sees it.

What we ran on Nov 9, 2026

Linux box, Ollama v0.40.15, OLLAMA_HOST=127.0.0.1:11434.

1. Started ollama serve with HTTPS_PROXY=http://127.0.0.1:1 (nothing listening). A pull failed early with proxyconnect tcp: dial tcp 127.0.0.1:1: connect: connection refused. That shows the server must own the proxy settings.

2. Split traffic with NO_PROXY=registry.ollama.ai and a dead proxy for everything else. The UI sat on pulling manifest, then ended with:

Error: max retries exceeded: Get "https://….r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/…": proxyconnect tcp: dial tcp 127.0.0.1:1: connect: connection refused

So the registry path reached an R2 URL; the blob failed through the server’s bad proxy and collapsed into max retries exceeded.

3. After removing the bad proxy, pulls can reach the registry again. We deleted the temp models dir afterward. We did not reproduce ISP-level blocks claimed in some issue comments.

What to do, in order

1. Update to current stable

ollama -v

Stable as of the GitHub release on 2026-11-04 is v0.40.15. Upgrade via the official installer, package, or Docker tag, then check ollama -v again.

2. Set HTTPS_PROXY on the server process

From the FAQ:

• macOS app: launchctl setenv HTTPS_PROXY "http://proxy:port", then restart Ollama.
• Linux systemd: systemctl edit ollama.service, add Environment="HTTPS_PROXY=http://proxy:port" under [Service], then daemon-reload and restart.
• Windows: set a user env var, quit the tray app, start Ollama again from the Start menu.
• Docker: pass -e HTTPS_PROXY=….

A shell-only export is not enough for the app/service.

3. Prove R2 is reachable

If curl to the registry and to an *.r2.cloudflarestorage.com URL also fails, fix network/DNS/proxy first.

4. Retry the pull

ollama pull resumes partial files. Keep the full error line and ollama -v if it still fails.

FAQ

Is this the same as pull model manifest: 412?

No. 412 means the model needs a newer Ollama—see pull model manifest: 412. max retries exceeded is a download retry budget.

More Ollama / llama.cpp errors

Use the lookup table. Format errors: format that is no longer supported.