ollama pull model_name:tag 在有些地區下載速度會很慢，而且過程並不穩定。
如果你遇到的是大模型下載到一半反覆中斷、報錯 TLS handshake timeout 或 unexpected EOF，那麼問題很可能不只是 registry.ollama.ai 本身，而是後續跳轉到的實際下載鏈路。
這篇文章記錄一次簡單直接的排查思路：先拿到模型檔案的真實下載地址，再確認最終流量落到哪裡，最後只針對關鍵網域做網路優化。
取得模型檔案的下載地址
可以借助下面這個專案，把 Ollama 模型對應的 manifest 與 blob 下載地址直接提取出來：
https://github.com/Gholamrezadar/ollama-direct-downloader
以 gemma4:latest 為例，可以提取出類似下面這些連結。
Manifest 位址
1
|
https://registry.ollama.ai/v2/library/gemma4/manifests/latest
|
Blob 位址
1
2
3
4
|
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
|
如果你只是想快速驗證，也可以直接用 curl 下載 manifest 與 blob：
1
2
3
4
|
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"
|
跳轉後的真實下載地址
嘗試用 wget 下載其中一個 blob，會發現請求並不是一直停留在 registry.ollama.ai，而是會繼續跳轉到一個 Cloudflare R2 物件儲存地址：
1
|
wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
|
從日誌裡可以看到幾個關鍵資訊：
registry.ollama.ai 回傳了 307 Temporary Redirect- 最終下載地址落在
*.r2.cloudflarestorage.com
- 真正承載大檔案傳輸的，實際上是後面的物件儲存網域
這一步很重要，因為它說明如果你的代理或分流規則只覆蓋了 registry.ollama.ai，但沒有處理 *.r2.cloudflarestorage.com，那下載仍然可能很慢，甚至反覆中斷。
下面是一次實際抓到的跳轉日誌：
1
2
3
4
5
6
7
8
9
10
11
|
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]
|
調整網路設定
確認真實下載鏈路之後，排查方向就會清晰很多。
如果你正在使用代理、分流或自訂 DNS，建議優先檢查下面幾件事：
registry.ollama.ai 與 *.r2.cloudflarestorage.com 是否走了同一條穩定線路- 代理規則是否只覆蓋了前者，而漏掉了後者
- 目前出口是否適合持續下載數 GB 到數十 GB 的大檔案
這類問題的關鍵並不是「能不能打開官網」，而是「跳轉後的物件儲存鏈路是否穩定、是否能長時間持續傳輸」。很多時候，真正需要優化的是 Cloudflare R2 這一層，而不是前面的 registry 網域。
調整前後的對比
下面是一次實際下載 gemma4:31b-it-q8_0 時的表現。
調整前，下載速度較慢，而且會在中途報錯：
1
2
3
4
|
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
|
調整後，再次下載同一個模型時，速度和穩定性都有明顯改善：
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
|
這並不代表所有網路環境都能得到同樣結果，但至少說明了一點：瓶頸很可能不在 Ollama 用戶端本身，而在實際的大檔案下載鏈路。
一個更實用的排查順序
如果你也遇到類似問題，可以按這個順序來：
- 先執行一次
ollama pull 或 ollama run，確認問題是否穩定重現。
- 再用
wget 或 curl -L 測一個 blob 位址，確認是否跳轉到 *.r2.cloudflarestorage.com。
- 最後只針對真實下載網域調整代理或分流，再重新測試速度和穩定性。
這樣做的好處是，每一步都在驗證一個明確假設，不需要盲目試錯。
結論
ollama pull 下載慢，很多時候並不是因為 registry.ollama.ai 無法存取，而是因為真正承載大檔案下載的 Cloudflare R2 鏈路不夠穩定。
所以更有效的做法不是反覆重試，而是先把真實下載鏈路找出來，再針對實際流量落點做優化。