How to Troubleshoot Slow `ollama pull` Model Downloads

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag can be very slow in some regions, and the download process is not always stable.

If your issue looks like repeated interruptions halfway through a large model download, with errors such as TLS handshake timeout or unexpected EOF, the bottleneck may not be registry.ollama.ai itself, but the actual download path after the redirect.

This article walks through a simple troubleshooting approach: first get the real model file URLs, then confirm where the traffic actually ends up, and finally optimize only the domains that matter.

Get the model file download URLs

You can use the following project to extract the manifest and blob download URLs for an Ollama model directly:

https://github.com/Gholamrezadar/ollama-direct-downloader

Using gemma4:latest as an example, you can extract links like the following.

Manifest URL

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Blob URLs

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

If you only want a quick verification, you can also download the manifest and blobs directly with curl:

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

The real download URL after the redirect

If you try downloading one of the blobs with wget, you will notice that the request does not stay on registry.ollama.ai. It gets redirected to a Cloudflare R2 object storage URL:

`1`	`wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a`

There are a few key details in the log:

registry.ollama.ai returns 307 Temporary Redirect
The final download URL lands on *.r2.cloudflarestorage.com
The large file transfer is actually being served by the object storage domain behind the redirect

This matters because if your proxy or routing rules only cover registry.ollama.ai but not *.r2.cloudflarestorage.com, downloads can still be slow or repeatedly interrupted.

Here is one example of an actual redirect log:

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

Adjust your network settings

Once you confirm the real download path, the troubleshooting direction becomes much clearer.

If you are using a proxy, split routing, or custom DNS, check these first:

Whether registry.ollama.ai and *.r2.cloudflarestorage.com are using the same stable route
Whether your proxy rules cover only the former but miss the latter
Whether your current outbound path is suitable for sustained multi-GB downloads

The key issue here is not simply whether the official site opens, but whether the redirected object storage path is stable enough for long-running large-file transfers. In many cases, the real bottleneck is the Cloudflare R2 layer rather than the registry domain in front of it.

Before-and-after comparison

Here is one real-world example while downloading gemma4:31b-it-q8_0.

Before adjusting the network path, the download was slow and failed midway:

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

After the adjustment, the same model download became noticeably faster and more stable:

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

This does not mean every network environment will see the same improvement, but it does support one useful conclusion: the bottleneck may be the actual large-file download path rather than the Ollama client itself.

A more practical troubleshooting order

If you run into the same issue, this order usually works well:

Run ollama pull or ollama run once and confirm the issue is reproducible.
Test a blob URL with wget or curl -L and confirm whether it redirects to *.r2.cloudflarestorage.com.
Adjust your proxy or routing only for the real download domain, then test speed and stability again.

The benefit of this order is that each step validates one clear hypothesis, so you do not have to troubleshoot blindly.

Conclusion

When ollama pull is slow, the problem is often not that registry.ollama.ai is unreachable, but that the Cloudflare R2 path actually serving the large files is unstable.

So instead of retrying over and over, a better approach is to identify the real download path first and optimize the network route where the traffic actually lands.

Model Downloads on KnightLi Blog