ollama set api key

很多人本地跑 Ollama 一路畅通，接上自己的应用或对外暴露端口才发现：官方默认不吃 API Key，谁都能调。这篇不讨论模型好坏，只把「配置与使用 API Key 完成鉴权调用」这件事拆成几条可执行动作——先确认你面对的是官方服务还是中转层，再决定 Key 从哪里来、写在哪、怎么验证。

Key 从哪来：三条常见路径

Ollama 本身跑在本机时默认不校验任何 Key，你给它设一个环境变量只是给自己或中间层看的。真正需要 Key 的场景，是你在 ollama 前面加了一层服务、代理或对外接口。Key 从哪来，基本就三条路，先对号入座再动手。

路径一：平台 Key

来自云服务商或第三方托管平台的账号体系，去厂商控制台领取，作用对象是那家平台，不是本地 ollama

路径二：自建签发

在 Nginx、Caddy 或自写中间件里比对一串固定字符串，谁访问你的 ollama 谁带这个串

路径三：中转站分发

由中转站统一发 Key，你拿到的是它的额度凭证，用前先核对它的探测结果和价格口径

• 先问自己：这个 Key 是给谁校验的？本机脚本直接调用不需要它
• 如果是给厂商平台校验，去对应厂商页面领取，别在本地环境变量里瞎编一个
• 如果是给自己网关校验，Key 就是你自己定的一串随机字符，写进中间件配置里
• 如果是中转站发的，先拿它当第三方服务看待，用前做一次连通与计费口径核对
• 确认完来源再决定环境变量名怎么写，名称跟着调用方走，不要混用

1. 判定调用方写下请求最终打到哪个地址。打到本机端口就是本地调用，本节可跳过；打到外部域名才需要 Key。
2. 按来源取 Key平台 Key 去厂商控制台复制；自建 Key 自己生成随机串并只存在服务端；中转站 Key 找发放方领取。三类不要互相替代。
3. 本地设进环境变量用 export 或写进启动脚本，让客户端读到即可。验证方法是打印变量确认非空，再发一次请求看是否返回鉴权结果。
4. 做一次无 Key 对照把 Key 临时置空再请求一次，应当被拒；如果照样成功，说明你的校验层没挂上或路径没走对。

配完怎么验证：一套排查顺序

配置改完别急着高兴，Key 这东西最容易出现「我以为生效了」。按下面四步走一遍，每一步都有明确的通过标准和不通过时的排查方向。

1. 先裸连，不带 Key 发一次用一个最简单的请求打到 Ollama 服务端口，比如列出本地模型列表这类只读接口。能正常返回，说明服务进程、监听地址、端口映射这几层没问题；连不上就先把服务本身修好，别去怀疑 Key 配置。
2. 带上 Key 再发一次同一个请求，这次把 Key 按你配置方式带上（Header 或环境变量）。观察状态码的变化：从能通变成 401 或 403，说明鉴权层确实拦在前面了，这一步就算过。如果状态码完全没变，说明你配的中间件或反向代理根本没接管这个端口。
3. 故意用错 Key，确认真的被拒把 Key 改成一个明显错误的字符串，再发一次同样的请求。预期是被拒绝。如果错的 Key 也能过，那就是配了个摆设，鉴权规则写成了放行全部，或者白名单把来源 IP 全放开了。
4. 换机器、换网络再试一次换一台不在同一网段、不走同一个出口的机器重复第二步。如果本机能过、别处不能过，多半是监听地址只绑了本地回环、防火墙只放行了某个网段，或者代理规则里对来源做了限制。

• 每一步只改一个变量，不要同时换 Key 又换地址，出了问题定不了位。
• 验证用的请求尽量选只读接口，避免误删或误改数据。
• 401 和 403 含义不同：前者通常是没有凭证或凭证无效，后者是凭证有效但没权限，先分清再排查。
• 请求头和环境变量两种传 Key 的方式，如果你都配了，注意哪一层优先，别只看其中一层。

这套顺序不适用于你把 Ollama 只绑在本地回环、压根不打算对外提供服务的场景——那种情况下没有鉴权层是设计如此，不是配置错误。另外，如果前面还挂了公司统一的网关，状态码可能被网关改写，这时候要去看网关自己的日志，而不是只看 Ollama 的日志。各家中转和官方接口的鉴权差异，可以到 文档与指南中心（/docs） 对照着看，具体参数以你手上那份配置为准。

什么时候别急着加 Key，先收口

先别急着生成一串 Key。Ollama 默认的调用口子本来就适合本地或内网用，你真正要先确认的是：这个地址到底会不会被外面碰到。判断顺序很简单——能不能只绑本机回环地址，能不能只在局域网里访问，能不能让调用方都走同一个内网出口。这三条只要能落地一条，就先做收口，成本比配 Key 低得多，排障也干净。

如果确认必须对外，别只做鉴权这一件事。鉴权挡的是「没有凭证的人」，挡不住「有凭证但被刷」和「凭证被滥用」。真正兜底的是三件套同时在场：鉴权决定谁能调，限流决定能调多快，日志留痕决定出事之后能查到是谁在什么时候调了什么。缺任何一项，被刷爆或被白嫖时你都只能干看着。

1. 先查监听地址看服务启动参数和配置文件里的监听项，确认是不是绑在了所有网卡上；改完用本机之外的机器试连一次，连不上就说明收口成功。
2. 再定来源范围如果只能内网用，就在主机防火墙或安全组里限定来源网段，只放开需要的端口；验证方法是换一个不在白名单里的地址去连，应当被拒绝。
3. 最后补三件套确实要对外时，依次配上鉴权、限流和访问日志；验证方式是拿错误凭证请求应被拒、短时间高频请求应被限、每次请求都应能在日志里找到对应记录。

最常见的误解是「加了 Key 就等于安全」。Key 本身也是字符串，泄露路径一点都不少：明文写在代码里提交到仓库、被打印进日志、贴进聊天记录、写进前端能看到的配置。这些情况和没有 Key 差别不大，甚至更危险，因为你以为已经防住了。Key 要放环境变量或密钥管理里，日志里对凭证字段做脱敏，别在报错信息里回显。