ollama openai api key

很多人把 Ollama 跑起来后想用 OpenAI SDK 直接打过去，结果卡在鉴权这一层：本地默认要不要 Key、加了反向代理后 Key 该写在哪、401 报错到底是谁拦的。这篇按「先搞清鉴权归属、再动手配置、最后逐层验证」的顺序走一遍，给本地调试和对外暴露两种场景分别给判断标准。

很多人把 Ollama 在本机跑通之后，第一反应是掏出 OpenAI SDK 直接打过去，结果卡在鉴权这一层：到底要不要填 api_key、填了会不会被校验、本地不填会不会报错、挂了反向代理之后 Key 又该写在哪。这几个问题的答案不完全一样，混在一起想就会反复试错。

这篇按「先搞清鉴权归属、再动手配置、最后逐层验证」的顺序走一遍。本地调试和对外暴露是两种场景，判断标准也不同：本机默认不校验 Key，加了代理之后鉴权发生在中间层，走中转站时验的是对方的账和额度。搞清这一点，401 就不会再让人一头雾水。

先分清：Key 是谁的，谁在验

Ollama 本机默认监听回环地址，服务本身不校验 Key。你在 SDK 里随便填一个字符串也能通，但这跟「Ollama 支持 API Key」是两回事：它只是没有校验逻辑，并不是认了这个 Key。如果前面挂了 Nginx、API 网关或中转层，鉴权就发生在那一层，Key 是那层签发的，Ollama 自己依然不管。

• 用 OpenAI SDK 时 api_key 参数往往只是占位符，不填会直接报错，但不代表服务端真的验过它
• 本机直连不校验 Key，一旦把监听地址改到全网卡又把端口放开，就等于关掉了门锁
• 挂在反向代理后面的场景，Key 由代理层校验，报错的来源和本地直连完全不同
• 走中转站或云托管时，Key 由对方签发，验的是对方的账和额度，排查方向应该先看对方状态

三种接法，配置位置完全不同

配置位置搞错是最常见的时间浪费。纯本机直连的重点不在 Key，而在把 base_url 指向本地端口、把模型名跟 pull 下来的 tag 逐字对齐。经反向代理对外的重点在代理层：鉴权规则、来源限制、频率限制都写在那一层，Ollama 端什么都不用改。走中转站的场景里，配置反而是最简单的，难点在排查时要先看对方的状态页而不是本地日志。

1. 本机直连base_url 指向本地端口，api_key 随便填一个非空字符串避免 SDK 报参数错误；验证方法是发一句极短的请求，能返回内容就说明路径和模型名对了
2. 经反向代理对外把 Key 校验、频率限制、来源限制都放在代理层；验证方法是先不带鉴权头请求一次，能被拒绝说明规则生效，再带上正确的 Key 请求一次确认放行
3. 走中转站Key 由对方签发，本地只填 base_url 和对方给的 Key；验证方法是最小请求跑通后，再看对方的用量记录是否同步增长

还有一点容易踩：OpenAI 兼容层通常只覆盖一部分端点，有些原生能力在兼容接口里没有对应的字段。别默认它和官方接口 1:1 等价，遇到某个参数不生效时，先确认兼容层有没有实现，而不是反复怀疑 Key。想要了解各家托管服务实际覆盖了哪些端点，可以到 /sites 里对照着看。

逐层验证的固定顺序

排查鉴权问题最忌讳同时改好几个地方。固定一个自下而上的顺序，每层只解决一个变量，很快就能定位到底是哪一层在拦。下面这套顺序在本地和代理场景都适用。

• 第一层：不带任何鉴权头，直接请求健康检查或模型列表，确认服务本身活着
• 第二层：加上 Key 再请求同一接口，如果第一层通过而这一层 401，说明是中间层在拦，去查代理规则
• 第三层：用 OpenAI SDK 发一次最小请求，确认路径前缀、模型名和返回结构对得上
• 第四层：换成你的真实提示词，重点看流式输出与超时设置，超时和重试的坑通常在这一步才暴露
• 把每一步的请求命令记下来，换环境时可以照着复现，比口头描述快得多

# 第一层：不带头，确认服务活着
curl -s http://127.0.0.1:11434/api/tags | head

# 第三层：用兼容接口发最小请求
curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer placeholder' \
  -d '{"model":"你的模型tag","messages":[{"role":"user","content":"hi"}],"max_tokens":8}'

要对外暴露时的检查清单

本机玩玩和对外提供是两码事。一旦监听地址绑到全网卡，就等于把一个不校验 Key 的服务放到网上，扫描器几小时内就能找到。下面这份清单是上线前的最低要求，任何一项没做成都建议先别开公网端口。

另外，本地推理的资源上限是硬的。并发不限制的话，表现往往不是出错，而是整个服务无响应。上线前到站内的安全与合规分区过一遍术语与要求，把数据流向和留存策略说清楚，比事后补文档省事。各家托管服务在鉴权和限额上的默认策略差别不小，可以到 /rankings 对照各家能力再决定。

对不上号时的排查顺序

报错信息本身不会告诉你问题在哪一层，靠分类去猜更快。下面按错误类型给出排查方向，每条都配一个能立刻做的动作。

1. 401 或 403先判断是本地还是中间层：临时绕过代理直连一次，如果直连通了，问题就在代理的鉴权规则上，去核对头字段名和 Key 是否被截断
2. 404通常是路径前缀问题。兼容层和原生接口的路径写法不一样，两边各试一次就知道该用哪个前缀
3. 模型名报错把模型列表接口打出来，跟你配置里的字符串逐字对，注意大小写和 tag 后缀，多一个字符都不行
4. 能连上但输出为空或截断往流式和超时方向查，跟 Key 没有关系。先把流式关掉、把超时调大各试一次，
5. 换机器后行为变化优先怀疑环境变量和端口映射，而不是 Key 失效。容器里 localhost 指向的是容器自己，不是宿主机

• 判断责任层：先分清是本地服务、代理层还是中转站的问题，再动手改配置
• 保留证据：每次请求的完整命令和返回头都记下来，尤其是请求经过了几层
• 别同时改两处：一次只动一个变量，否则改好了也不知道是哪一步生效的
• 拿不准时换一个已知能用的客户端再试一次，排除 SDK 自身参数带来的干扰

鉴权问题难查，不是因为复杂，而是因为没人愿意先数清楚这个请求经过了几层。