Ollama 下載模型 pull 速度很慢的排查與解決辦法

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

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 位址

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：

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，那下載仍然可能很慢，甚至反覆中斷。

下面是一次實際抓到的跳轉日誌：

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 時的表現。

調整前，下載速度較慢，而且會在中途報錯：

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 鏈路不夠穩定。

所以更有效的做法不是反覆重試，而是先把真實下載鏈路找出來，再針對實際流量落點做優化。

網路排查 on KnightLi的博客