很多人把 Ollama 装在一台能出网的机器上，装完 ollama serve 就直接对外开了端口，以为它像云厂商那样自带 API Key——结果一查文档发现根本没有这个开关。这篇不讲怎么选模型、也不讲装在哪，只解决一件事：Ollama 本身没有内置鉴权，你要通过哪几种做法给它补上一层 Key 和访问控制，以及每种做法在什么情况下不适用。
很多人装完 Ollama，跑一句 ollama serve，看到端口能通，就默认它像云厂商那样自带 API Key：填个地址、填个 Key、完事。结果翻文档翻了半天，发现根本没有「API Key」这个开关可以设。这不是你漏看了某个参数，而是 Ollama 的接口设计里压根没把「身份」当回事——它只管你连不连得上端口。
所以这篇不聊模型怎么选、也不聊装在哪台机器上，只解决一件事：Ollama 本身没有内置鉴权，你想给它补一层 Key 和访问控制，有哪几条路可走，每条路在什么情况下不适用，以及怎么验证自己真的挡住了。先认清现状再动手，比照着别人的配置抄一遍要省事。
先认清现实：Ollama 默认没有 API Key 这个概念
本机回环地址上的调用不需要任何凭据，请求直接打到模型上就返回。真正决定「谁能用」的是监听地址：默认只绑本地时，外部根本连不进来；一旦改成对外监听，任何能连到这个端口的人都能直接调你的模型，中间没有一道问「你是谁」的环节。
| 你的场景 | 是否需要加鉴权 | 建议做法 |
|---|---|---|
| 只在本机跑，客户端也在这台机器上 | 可选项，不加也能用 | 保持回环监听即可 |
| 监听地址已改成对外，但只有自己用 | 建议加 | 反向代理或网关，二选一 |
| 多人共用一台机器上的模型 | 建议加 | 网关统一发 Key，顺带统计用量 |
| 内网机房、家里 NAS，不跨公网 | 可以不加 | 用网络层隔离代替 Key |
- 只要监听地址不是回环地址，就按「对外服务」对待，别用「反正就我一个人用」说服自己。
- 判断要不要加，看的是暴露面，不是使用人数：一个人用但端口开着，风险一样存在。
- 先别急着上代理，很多人的问题其实出在监听地址没改回来，而不是缺 Key。
做法一：用反向代理加一层 Key 校验
最常见的做法是 Nginx 或 Caddy 挡在前面，用请求头里的自定义字段、Basic Auth 或 Token 做校验，校验通过再转发到 Ollama 的本地端口。Ollama 那边完全不用动，代理层还能顺手加限速、访问日志和 IP 白名单，代价是多了一个要维护的组件。
- 改回本地监听先确认 Ollama 只绑在回环地址上，只让代理能访问它，别让代理和外部入口同时可达。
- 写代理规则在代理配置里加一段校验逻辑，命中自定义请求头或凭据才转发，其余直接返回拒绝；配置完先本地 curl 测一遍。
- 验证拦截效果用不带凭据的请求打代理地址，确认被挡下来，而不是被悄悄放过。
- 量延迟变化对比加代理前后的响应时间，基线数据可以到 /tools/speed-test 跑一轮再比。
不适用的情况也要说清楚：如果你的客户端根本不支持自定义请求头，比如一些图形界面只让你填一个地址栏，那这一层就卡住了，要么换客户端，要么走下面的网关方案。另外代理层加得越复杂，出问题时排查链路就越长，单人自用不太值得。
做法二：交给网关或聚合层统一发 Key
把 Ollama 注册到一个统一网关或聚合平台后面，由平台分配 Key、做额度和用量统计，客户端只对接平台地址。适合团队里多人共用一个本地模型、又想知道谁用了多少的场景；单人自用反而多此一举，等于给自己加了一个要维护的中间层。
接之前先确认兼容性：不同网关对 Ollama 原生接口和 OpenAI 兼容接口的支持范围不一样，你的客户端走的是哪套协议，直接决定能不能接上。别等配完了才发现协议对不上，白折腾一轮。
- 协议确认
- 先看清客户端发的是 Ollama 原生路径还是 OpenAI 兼容路径，再挑对应网关。
- Key 归属
- Key 由平台签发，客户端只认平台地址，不再直连本机端口。
- 用量口径
- 各家平台的计费口径和限制差异挺大，可到 /ai-nav/category/ai-model-platform 逐个核对当时的说明。
做法三：不加 Key，改用网络层隔离
把 Ollama 绑在回环地址或内网地址上，只让同一台机器或同一内网段访问，用防火墙规则卡住来源。适合机房内网、家里 NAS、单人开发机这类环境，配置成本最低，也不会因为 Key 泄漏出问题——因为压根没有 Key 可泄。
但这条路边界很清楚：一旦需要跨公网访问，隔离就失效了，这时候必须回到前两种做法，别指望改个端口号就算安全。端口号只是换了个门牌，门还是没锁。
判断标准只有一句：这个地址能不能被公网直接连上。能，就必须有 Key 或网关；不能，隔离才是成立的。
落地清单与排查顺序
按下面这个顺序逐级加码，别一上来就堆三套方案。每加一层就验证一次，确认是这一层在起作用，而不是别的地方碰巧挡住了。
- 第一步：确认监听地址查服务启动参数或配置文件，确认是不是只绑了本地；不是就先改回来。
- 第二步：确认调用方能力客户端能不能带自定义请求头、能不能改 Base URL，这决定你走代理还是只能上网关。
- 第三步：按顺序加码本机自用 → 内网隔离 → 反向代理 → 网关，够用就停，别过度设计。
- 第四步：做断连验证用不带凭据的请求打一遍，确认确实被挡下来，而不是你以为挡住了。
- 第五步：分清楚失败类型调用失败时先分清是连不上还是被拒，排查思路可参考 /ollama-api-connection-fail 那篇的整理。
- 只在本机用，代理和网关都可以省，把监听地址管好就够。
- 要跨公网又只有自己用，反向代理是最轻的一档，维护成本可控。
- 团队多人共用一个模型，网关更合适，Key 和用量都有人管。
- 内网环境不想加组件，用防火墙卡来源，前提是永远不跨公网。
常见问题
Ollama 到底有没有官方的 API Key 设置？
没有内置的 Key 开关。它默认信任所有能连上端口的请求，所谓「设置 API Key」实际是在它前面加反向代理、网关，或者干脆用网络隔离限制来源。所以别去找那个不存在的配置项，把精力放在前置层上。
只在本地跑，还需要加鉴权吗？
如果服务只绑回环地址、只有本机客户端访问，加鉴权收益很低，做好别把端口暴露出去就行。一旦你为了让手机或另一台机器连上而改成对外监听，就该按对外服务处理，至少加 IP 白名单或代理校验。
加了代理之后客户端连不上，从哪查起？
先确认代理转发到的地址和端口对不对，再确认客户端带没带约定好的请求头；最后看是不是协议不匹配——有的客户端走 Ollama 原生接口，有的走 OpenAI 兼容格式，接错路径就会一直报连接失败。
