403 Forbidden on ollama pull behind corporate proxy even though curl works

快速结论：该报错常见于 Ollama 以 systemd 服务运行、出站流量经过企业代理（本例为 Blue Coat CA）的环境；curl 手动请求 registry 能通，但 ollama pull 返回 403。优先排查代理对 Ollama 客户端请求的处理方式（连接建立、token 获取链路），而不是继续只查 CA 证书或环境变量是否存在。

适用环境：RHEL 9.2；Ollama 0.40.0（amd64 linux，Go 1.26.0），以 systemd 服务运行；企业代理加 Blue Coat CA；服务内配置了 HTTPS_PROXY、HTTP_PROXY、NO_PROXY、SSL_CERT_FILE，Issue 已验证代理变量在运行进程内可见、CA 已被信任。

最快修复方案：暂无确认的一步修复方案。Issue 中可复现的线索是：开启 GODEBUG=http2debug=1,netdns=go+2 后，日志显示 Ollama 经代理建立的 HTTP/2 连接在获取 registry token 时返回 UNAUTHORIZED，后续 manifest 请求得到 403；而带 --insecure 时表现为 connection reset by peer。可优先尝试用该 GODEBUG 设置确认出站请求卡在哪个环节，再交由代理侧核查。

注意事项：GODEBUG 只用于诊断，不是修复；--insecure 走明文 HTTP，在不安全的网络上存在风险，且在本 Issue 中并未解决问题，只是错误形态不同。Issue 讨论链未给出最终确认的根因与仓库层面的修复提交，以上处理属于排查方向，不能当作已验证结论。

问题场景

用户在 RHEL 9.2 上以 systemd 服务方式运行 Ollama，处于需要经过企业代理（Blue Coat CA）出网的内网环境，执行 ollama pull <model> 拉取任意模型时，在 pulling manifest 阶段失败。同一环境用 curl 通过代理访问同一个 manifest 端点正常，以 ollama 用户显式带代理执行 curl 也正常，说明不是基础的网络连通性或 CA 信任问题。

报错原文

$ ollama pull <model>
pulling manifest
Error: 403:

# 仅开启 OLLAMA_DEBUG=1 时服务端日志：
[GIN] | 200 | 127.0.0.1 | HEAD "/"
[GIN] | 200 | 127.0.0.1 | POST "/api/pull"

# 带 --insecure 时：
Error: pull model manifest: Get "http://registry.ollama.ai/v2/library/qwen3.8/manifests/latest" read tcp read: connection reset by peer

原因分析

从排查日志看，Ollama 经代理与 registry.ollama.ai:443 建立了 HTTP/2 连接，但 /v2/token 请求的响应体为 {"errors":[{"code":"UNAUTHORIZED","message":"unauthorized"}]}，随后 manifest 请求被拒为 403。因此最可能的根因是代理或中间设备改变了 Ollama 客户端请求（认证头、token 交换链路、HTTP/2 行为），导致 registry 侧的鉴权链路没能走通，而不是 curl 能访问就代表 Ollama 客户端一定能访问。另一种可能原因是代理对 HTTP/2 或特定 User-Agent/请求头的处理与 curl 不一致。上述均为根据 Issue 日志的推断，讨论链未给出确认的根因。

环境排查

确认 Ollama 版本（Issue 为 0.40.0）与运行方式是否为 systemd 服务，并确认 HTTPS_PROXY、NO_PROXY、SSL_CERT_FILE 在服务进程环境中实际生效。
确认是否有 HTTP_PROXY 被误设，Issue 中提出可尝试去掉 HTTP_PROXY。
确认企业代理的 CA 已在系统与 Go 客户端信任链中生效（Issue 中 CA 信任已确认）。
确认代理是否对 HTTP/2、请求头或 token 接口有额外限制，必要时与代理管理员核对 registry.ollama.ai 的出站策略和日志。
使用 GODEBUG=http2debug=1,netdns=go+2 观察出站连接与 token 请求的详细日志。

解决步骤

在 systemd 服务环境中加入 GODEBUG=http2debug=1,netdns=go+2，重启 Ollama 服务后重新执行 ollama pull <model>。
查看服务日志中 /v2/token 请求的响应：若出现 UNAUTHORIZED，说明请求已到 registry，但鉴权/token 链路被代理干扰，应转查代理对 HTTP/2 和请求头（如 authorization、accept、user-agent）的处理。
在服务配置中尝试移除 HTTP_PROXY，仅保留 HTTPS_PROXY 和 NO_PROXY，重启后重试（Issue 文档中曾建议排除 HTTP_PROXY）。
作为对照实验可测试 ollama pull --insecure <model>，以确认是否与 TLS/HTTP2 处理相关；注意该方式走明文 HTTP，仅用于诊断。
若日志显示代理侧握手或响应异常，向代理管理员提供时间点和目标域名 registry.ollama.ai，核对该时段代理日志与拦截规则。