很多后端同学第一次调 Ollama 的接口，习惯性去找「密钥」那一栏，翻遍文档也没找到，于是怀疑自己装错了版本。另一类情况是：本地跑得好好的，一放到内网给同事用，就被人问「这玩意谁都能调，安全吗」。这篇把 Ollama 的鉴权现状说清楚，再给你一套自己加鉴权层、控制超时并发、留好日志的落地做法。
很多后端同学第一次调 Ollama 的接口，习惯性去翻「密钥」那一栏，结果翻遍文档也没找着，于是回头怀疑自己是不是装错了版本、少了哪个组件。另一类情况是：本地自己跑得好好的，一旦放到内网给同事用，就被人追着问「这玩意谁都能调，安全吗」。这篇把 Ollama 的鉴权现状讲清楚，再给你一套自己加鉴权层、控制超时并发、留好日志的落地做法。
先说结论方向：Ollama 的默认形态是「本机服务」，它的安全边界靠的是网络可达性，不是令牌。你要不要额外加一层，取决于这个接口最终给谁用、从哪台机器能访问到。下面四节按「认清现状 → 决定是否加门 → 接入细节 → 上线前自查」的顺序讲。
先认清：Ollama 默认没有 API Key 这回事
Ollama 安装完默认只监听本机回环地址，调用方不带任何密钥就能发请求。换句话说，它的「鉴权」其实是「只有这台机器能访问」，而不是靠令牌校验。这个设计对单机自用很省事，但也意味着一旦你动了监听地址，防线就没了。
- 判断依据看两点：服务监听地址是不是只绑在本机回环，以及端口有没有暴露到公网或内网其他机器；
- 如果只监听本机，那外部机器连 TCP 都连不上，等于天然隔离，不需要额外密钥；
- 一旦你把监听地址改成对外可访问，等于把一个没有门锁的接口挂到网上，任何人都能消耗你的显卡和电费；
- 判断方法很土但有效：从另一台机器上直接发一条最简单的请求，能通就说明已经对外开放了。
| 当前状态 | 是否已对外 | 建议动作 |
|---|---|---|
| 只绑本机回环，仅本机脚本调用 | 否 | 不用动，保持默认 |
| 改过监听地址，同内网机器能访问 | 是 | 至少上内网访问控制或机器白名单 |
| 端口映射到了公网或跳板机 | 是 | 必须自己加一层网关校验密钥，并限流 |
要给外部用，就得在前面加一层门
如果接口确实要给别的机器或别的团队用，常规做法是别去改 Ollama 自身，而是在它前面放一个自己写的反向代理或轻量网关。由这层负责校验密钥、限流、记日志，通过之后再转发给本地服务。这样做的好处是 Ollama 保持干净，鉴权逻辑你能完全掌控。
- 确定密钥传递方式让调用方把密钥放在请求头里传，服务端拿固定字符串或配置中心里的值比对。别把密钥写进前端代码，也别提交到代码仓库，用环境变量或专门的密钥管理服务更稳。
- 做路径白名单只转发你允许的那些推理接口路径，管理类、配置类的接口不要一起放出去，免得有人顺手改你的运行参数。
- 按调用方分配独立密钥不要一个密钥全公司共用。每个调用方一个，出问题时能按密钥反查是谁在打，也方便单独吊销某一家。
- 验证一次失效路径上线前手动吊销一个测试密钥，确认被吊销后请求确实被挡住，而不是还在后面继续跑。
什么情况下这套网关不值得做：如果只是几个同事在内网偶尔用一下，与其自建网关，不如直接用内网访问控制加机器白名单，成本更低，维护面也更小。判断标准就一条——调用方是否可控、是否都在同一可信网段。
接入时真正会踩的坑：超时、并发、流式
鉴权之外，后端接入最容易翻车的是这三件事。它们和模型大小、显卡显存强相关，没有一组通用参数能照抄，只能先量基线再定配置。想知道当时各类硬件上的实测延迟，到站内 /tools/speed-test 跑一轮，再回代码里分档设值。
- 超时：本地推理的首字延迟和模型大小、显存强相关，先量出基线再定超时，别照抄云端接口那套偏紧的值。连接超时和读取超时要分开设，读取超时给足余量；
- 并发：同一张卡上同时跑多个请求会互相抢显存，表现是全部变慢甚至直接报错。用信号量或队列把并发压住，超出的请求排队，而不是让它直接失败；
- 流式：流式输出要处理半路断开。客户端读到一半连接断了，得能重连或降级成非流式，否则前端会一直转圈；
- 日志：至少记四样——请求时间、耗时、输入输出长度、状态码。事后能一眼看出是慢还是错。
| 现象 | 大概率原因 | 先查什么 |
|---|---|---|
| 所有请求一起变慢 | 本地并发超过显存承载 | 把并发上限调低，看是否恢复 |
| 部分请求超时 | 读取超时定得太紧 | 用同样的输入单跑一次，量实际耗时 |
| 前端一直转圈 | 流式连接中途断开 | 日志里找状态码和中断位置 |
| 突然全部报错 | 显存被别的进程占用 | 看卡上还有没有别的任务在跑 |
这里没有一组「最佳参数」能套用所有机器。显卡型号、显存大小、模型体量不同，能扛的并发和合理超时都不一样。稳妥的做法是先按保守值上线，观察一段时间再逐步放宽，而不是一开始就顶到硬件极限。
上线前过一遍这张清单
- 鉴权：外部可访问的接口是否都经过网关校验；密钥是否按调用方隔离；是否做过一次密钥失效演练；
- 资源：并发上限是否写死并压测过；显存不够时的表现是否可预期，是排队还是报错，前端能不能区分处理；
- 可观测：有没有一条能按请求 ID 串起来的日志；错误率突增时能不能第一时间看出来，而不是等用户投诉；
- 边界：确认哪些接口只对内、哪些对外，别让一个配置改动把管理接口顺带放出去；
- 回滚：改监听地址或加网关后，有没有一条能快速退回原状的操作路径。
一句话概括这里的取舍：Ollama 默认没密钥，是因为它默认只给本机用；你要打破这个前提，就得自己补上那层门，而不是去找一个不存在的密钥配置项。
下一步想知道你这台机器实测能扛多少延迟、什么并发开始劣化，去站内跑一轮速度测试，把基线拿到手再回代码里设超时和并发，比凭感觉拍数值靠谱得多。→常见问题
Ollama 到底有没有 API Key？
默认没有。它开箱就是本机可直连的接口，不带密钥校验，鉴权靠监听地址只绑本机来实现。所以你会找不到「填密钥」的地方，这不是配置漏了。需要对外提供服务时，密钥要由你在前面的代理或网关层自己加。
不加密钥直接暴露端口有什么风险？
任何能访问到那个端口的人都能调用模型，消耗你的显卡、电费和机器资源，也能看到你发过去的内容。如果这台机器还在内网里，等于给内网开了一个没有门禁的入口。要么别暴露，要么在前面加一层校验。
本地接口调用超时了怎么调？
先分清是连接慢还是推理慢：连接超时通常说明服务没起来或端口不对，读取超时要看模型大小和显存是否吃紧。到 /tools/speed-test 量一次基线延迟，再据此把读取超时设成基线的几倍，别一刀切。同时压住并发，避免排队把等待时间拖长。
