Can’t pull/update models: Error: max retries exceeded

快速结论：该报错通常出现在 ollama pull 或模型更新阶段，Ollama 需要从 Cloudflare R2 的 blob 下载地址拉取模型数据时，连接在重试后仍失败。优先排查本机到该下载域名（*.r2.cloudflarestorage.com）的网络连通性、代理/公司网络策略，以及 Ollama 版本。

适用环境：Ollama 0.35.1（问题反馈版本），操作系统 Linux，显卡 Nvidia，CPU AMD；用户处于公司网络环境。Python、CUDA、PyTorch 版本在 Issue 中未确认。Issue 末尾反馈升级到 0.40.6 后恢复正常。

最快修复方案：将 Ollama 升级到 0.40.6 后重试拉取；Issue 中该版本被反馈为“works now”。若仍失败，需从网络层面检查能否访问报错中的 R2 下载地址。

注意事项：升级到 0.40.6 只是该 Issue 中用户反馈的恢复结果，Issue 没有给出根因复现或正式修复说明，因此不能确认所有同类报错都由版本问题导致。评论中提到的 La Liga 网络封锁属于推测，建议 VPN 也是推测性建议，并未在该 Issue 中验证；公司网络、防火墙、代理或 DNS 仍可能是实际限制来源。

问题场景

用户执行 ollama pull qwen3-embedding:latest，以及在更新 qwen3.5:9b-q8_0、gpt-oss:20b 等模型时，Ollama 进入 pulling manifest 后，请求指向 Cloudflare R2 的模型 blob 下载 URL，最终以 Error: max retries exceeded 失败。完整日志显示底层错误为 dial tcp ...:443: i/o timeout，即 TCP 连接 443 端口超时。

报错原文

pulling manifest
Error: max retries exceeded: Get "https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/.../data?X-Amz-Algorithm=..."

Error: max retries exceeded: Get "https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/.../data?X-Amz-Algorithm=AWS4-HMAC-SHA256&...": dial tcp 172.64.66.1:443: i/o timeout

✖  FAILED   gpt-oss:20b — Error: max retries exceeded: Get "https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/.../data?X-Amz-Algorithm=AWS4-HMAC-SHA256&...": dial tcp 172.64.190.1:443: i/o timeout

Issue 中的 -q8_0、qwen3-embedding:8b-q8_0 等都指向 Ollama 模型下载链路。注意：Issue 原始命令的目标模型名称由用户提供，清理后的数据不能据此推断应为其他模型名；这里保留原始命令 ollama pull qwen3-embedding:latest。

原因分析

最直接的证据是完整日志中的 dial tcp 172.64.66.1:443: i/o timeout 与 dial tcp 172.64.190.1:443: i/o timeout：Ollama 已经拿到 R2 blob 的签名下载 URL，但在建立到对应 IP 的 443 连接时超时，重试耗尽后报 max retries exceeded。因此可能原因包括：

本机或公司网络无法直连 Cloudflare R2 下载域名/对应 IP；
公司网络代理、防火墙、出口策略或 DNS 解析导致连接被阻断；
Ollama 客户端版本在下载链路或重试逻辑上的问题，用户在升级到 0.40.6 后恢复，但 Issue 未说明具体修复点，只能视为版本相关的一种可能。

评论里提到 #18716 和“La Liga/网络封锁”，但发起者未确认，建议 VPN 也属于评论者推测，不能作为已确认根因。

环境排查

确认 Ollama 版本：执行 ollama --version，与 Issue 中的 0.35.1 对照。
确认主机是否能访问报错中的 R2 域名及 443 端口；注意签名 URL 包含有效期，不要直接公开完整 URL。
检查公司网络是否要求代理；Issue 中未提供代理配置，未验证代理设置是否能解决问题。
检查 DNS 解析结果是否与日志中的 IP（如 172.64.66.1、172.64.190.1）一致。
Linux 下可用 curl -I 或 nc -vz 测试连通性；Issue 未给出这些命令的输出，因此这些仅为排查手段，不是已验证修复步骤。
GPU/CPU/CUDA/PyTorch 与拉取阶段关系不大，Issue 未提供相关版本，不据此下结论。

解决步骤

先记录当前 Ollama 版本，确认是否为 0.35.1 或相近旧版本。
将 Ollama 升级到 Issue 中反馈可用的 0.40.6，然后重新执行原来的拉取命令。Issue 末尾仅说明“works now with 0.40.6”，这是该讨论中唯一明确报告的恢复结果。
如果升级后仍报 max retries exceeded，或底层仍是 i/o timeout，在公司网络环境下联系网络管理员检查到 dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com 及 Cloudflare R2 相关地址的 443 出站访问。
如网络侧确认存在临时封锁或出口限制，可优先尝试更换网络环境后再拉取；评论中“Try a VPN”只是建议，未在 Issue 中验证，需遵守公司网络与合规要求。
重试前可保留完整报错（不要截断 URL 和底层超时信息），便于判断是 HTTP 层重试失败还是 TCP 连接超时。

验证方法

重新执行 ollama pull <原模型名>，确认不再出现 Error: max retries exceeded，且拉取能进入下载并完成。若仍失败，重点看错误末尾是否仍有 dial tcp ...:443: i/o timeout；若存在，说明网络连通性问题仍在，升级本身未解决。Issue 中最终反馈为升级到 0.40.6 后可用，但未提供完整成功日志。