很多人第一次在本地起 Ollama，去后台翻半天找不到 API key，就以为装漏了什么。其实本地服务默认就是裸奔的，能不能加锁、要不要加锁，取决于它暴露在哪。这篇把「有没有 key」「怎么自己加」「什么时候不用加」三件事讲清楚，顺带说清和官方云 API key 的区别。
很多人第一次在本地把 Ollama 跑起来，习惯性地去翻设置页面找 API key，翻了半天没找到，就怀疑是不是装漏了什么组件。其实不是漏装，是本地服务默认压根就没有「密钥」这个概念。它在你的机器上开一个端口，谁能在本机发 HTTP 请求，谁就能直接调用模型，中间没有校验环节。
所以这篇要回答的其实是三个连在一起的问题：本地到底有没有 key；如果没有，什么情况下你得自己加一道；以及加的时候该怎么加才不折腾。顺带还要把一件事掰开——本地自托管的那套东西，和云平台给的 API key 根本不是一回事，混着用很容易踩坑。
先确认：本地 Ollama 默认没有 API key
本地服务的默认姿态是「只监听本机回环地址」，也就是说只有这台机器上的进程能连上它。在这种前提下，服务方没有动机去设计密钥体系，因为访问者本来就只有你自己。你打开浏览器或写个脚本直接请求那个本地端口，不需要带任何 token 就能拿到结果。
- API key
- 云端服务用来区分调用者身份、统计用量、做计费的凭证；本地自托管没有计费环节，也就没有它存在的土壤
- 回环地址
- 通常指本机自己访问自己的那个地址，外部机器连不上，是默认且最安全的监听方式
- 占位符
- 某些客户端强制要求填 key 字段，本地使用时填一个任意字符串即可，服务端不看
- 默认只监听本机，本机任何进程都能调用，不存在密钥概念
- 所谓「key」是云端那套计费口径的产物，本地自托管没有账单要算
- 客户端里那个「填 API Key」的输入框，本地使用时留空或填占位符就行
- 看到「去后台复制 key」的说法，先确认它讲的是本地还是云端
什么情况下才需要自己加一道鉴权
加不加锁，判断标准只有一条：这个端口有没有可能被你这台机器之外的东西碰到。只在本机自己调，加鉴权就是给自己找麻烦，每次写代码还得处理密钥注入。反过来，只要监听地址改成了对外，或者机器处在有其他人的网络里，那就必须考虑加一道。
| 使用场景 | 是否需要自己加鉴权 | 理由 |
|---|---|---|
| 单人整机自用，只在本机写脚本调用 | 不需要 | 访问面就是你自己，加锁只增加配置成本 |
| 改成对外监听，但网段只有可信设备 | 建议先做网段限制 | 网络层挡住比应用层验密码更省事，也更难绕过 |
| 对外监听且网络里有不可信设备 | 需要 | 不设门槛等于把算力接口开放给所有人 |
| 临时演示、跑完就关 | 可以不加 | 暴露窗口很短，但要确认演示结束就收回监听范围 |
需要说清楚不适用的情况：如果你的机器本身已经暴露在公网、又没有任何防火墙或网段隔离，那么单靠代理层加一个自造密钥并不算稳妥，密钥会被嗅探或暴力尝试，这时候应该先解决网络暴露问题，而不是急着上口令。
自己套鉴权的可行做法与顺序
核心思路是别去改服务本体，那会把升级和排障都变成负担。正确姿势是在它前面放一层反向代理或网关，由那一层负责校验请求头里的自定义密钥，通过就转发，不通过就直接拒绝。顺序很重要，先收窄网络面，再谈口令。
- 第一步：收窄监听范围把服务改成只监听你真正需要的地址，或者用防火墙只放行可信网段。验证方法：从一台不在白名单里的机器发起请求，应该连不上，而不是被拒绝。
- 第二步：在代理层校验自定义密钥在反向代理里读请求头中你约定的那个字段，匹配不上就返回拒绝状态。注意别用默认示例头名，自己起一个不容易被猜到的名字。
- 第三步：给调用方一份配置模板把密钥从代码里抽出来，放进环境变量或单独的本地配置文件，模板里只留占位符。验证方法：搜索整个代码仓库，不应该出现真实密钥字符串。
- 第四步：双向验证本机不带密钥请求应被拒，带正确密钥应能正常返回；换一个错误密钥同样应被拒。三次都能复现，才算配置生效。
# 验证思路示意：不带密钥直接请求，应当被拒绝；带上约定的头，应当能通。
# 实际头名与端口按你自己的代理配置来，不要照抄示例。
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:PORT/api/tags
curl -s -o /dev/null -w "%{http_code}\n" -H "X-Your-Own-Header: your-secret" http://127.0.0.1:PORT/api/tags别和官方云 API key 混为一谈
这是最容易出岔子的地方。云平台的 key 是用来计费和划配额的，它背后有一套账号体系在跑；本地自托管两者都没有，自然也不需要那种东西。但很多客户端为了兼容云端接口，会在设置里强行要求填一个 key 字段，于是有人就以为本地也得去申请一个。
| 对比项 | 本地自托管 | 云端平台 |
|---|---|---|
| 有没有密钥概念 | 默认没有 | 有，且是核心凭证 |
| 密钥用来干什么 | 不存在，或仅用于你自建的代理层 | 标识调用者、计费、配额控制 |
| 客户端里那个 key 输入框 | 留空或填占位符 | 必须填真实密钥 |
| 同时用两边时怎么配 | 建议单独一份配置 | 建议单独一份配置，别共用环境变量 |
还有一种常见混淆：教程里说的 key 其实来自中转站。中转站是帮你转发请求的第三方服务，它当然要发一个 key 给你用来识别流量。这种 key 和本地服务没有半点关系，填错地方只会得到一个看不懂的报错。想搞清楚各类中转服务的可信度，可以到 /sites 看看站内整理的检测维度。
上线前对照清单
把服务从「自己玩玩」变成「别人也能连」之前，照着下面几项过一遍，比事后救火省事。这份清单不涉及具体数值，涉及到具体配置项时，到 /tools/speed-test 之类站内页面核对当时的说明即可。
- 监听地址范围是不是你真正想要的那一个，有没有多开
- 防火墙和网段限制是不是先于口令生效，顺序别颠倒
- 自定义密钥有没有进过代码仓库、聊天记录或截图
- 错误返回是否可读，会不会所有失败都笼统地报超时
- 有没有记录谁在用、用了多少，方便日后排查异常流量
- 演示或临时用途结束后，有没有把监听范围收回本机
本地服务的安全性不来自密钥，来自它到底能被谁碰到。下一步如果你同时在用官方云 API 和中转站，或者正打算挑一家中转，建议先去站内把各家的价格口径和可信度核对一遍，再决定要不要为本地那台机器也套上一层代理。→
常见问题
本地 Ollama 到底有没有 API key？
默认没有。它设计成只在本机跑，请求进来即处理，不校验身份也不计费。你找不到 key 不是装错了，而是本来就没有这个机制。只有当它被暴露到局域网或公网时，才需要自己在前置一层补上校验。
客户端提示要填 API key，本地部署时填什么？
填不填通常都不影响本机调用，很多客户端只是沿用云端那套表单。可以留空，也可以填一个占位字符串，只要代理层没开校验就不会拦你。如果确实开了校验，就填你在代理层自己设的那个值。
加了鉴权还是被人连上了，一般是什么原因？
多数是校验没落在最外层，或者监听地址同时留着一条绕过代理的入口。排查顺序是：先看请求实际打到了哪个端口，再看代理是否真的拒绝了不带密钥的请求，最后看有没有第二条监听路径没被覆盖。
