很多人第一次给 Ollama 接第三方客户端时，会被要求填一个 API key，翻遍配置文件也找不到，于是怀疑自己装漏了什么。这篇不讲大道理，直接告诉你 Ollama 的鉴权设计是什么样、配置存在哪几个地方、以及连不上时该按什么顺序去验证，避免在错的方向上折腾半天。
很多人第一次给 Ollama 接第三方客户端，界面一打开就要你填 API key，于是回头翻配置文件，翻了一圈什么都没有，开始怀疑自己是不是装漏了组件，或者少装了一个插件。这篇不讲大道理，直接把结论摆前面，然后告诉你配置到底存在哪几个地方，以及连不上时该按什么顺序去查。
核心一句话：Ollama 的默认形态是跑在本机的推理服务，它本身不签发也不校验 key。客户端让你填的那一栏，绝大多数情况下只是占位符，随便填点东西也能连上。真正需要考虑鉴权的，是你把服务开放出去之后的事。所以「查看 API key」这个动作，在多数人机器上其实找不到东西，因为压根不存在。
先确认一件事：Ollama 默认有没有 key
Ollama 的设计目标是在你自己机器上跑模型，默认只监听回环地址，也就是只有本机能访问。这个场景下加鉴权没有意义，因为它假定访问者和模型运行者是同一个人。所以它不生成 key，也没有一个「密钥管理」的入口让你去看。
- 回环地址
- 只接受来自本机的连接，外部设备根本连不上，自然也谈不上鉴权
- 占位符输入框
- 很多客户端要求必填密钥，实际并不校验内容，填个空格也能通过
- 真需要鉴权的情况
- 服务暴露到局域网或公网、多人共用一台机器、或者中间隔了一层反向代理网关
判断自己属于哪种情况很重要。如果你是单人单机、客户端和 Ollama 跑在同一台电脑上，那就不存在 key 的问题，你要解决的是地址填没填对。如果你是团队共用一台机器，或者要把服务给外部程序调用，那 key 这件事不在 Ollama 里解决，而要在你加的那一层网关上解决。
- 只是本机自用，客户端也装在同一台机器：不用找 key，检查地址和端口即可
- 局域网内多台设备想共用：需要先确认监听范围，再考虑是否加一层简单鉴权
- 要对公网暴露：默认配置绝对不要直接用，至少要有反向代理和访问控制
- 已经挂了网关：key 由网关生成和校验，去网关的配置里找，别回头翻 Ollama
配置到底在哪儿：环境变量与服务监听项
既然没有 key 字段，那真正决定对外行为的就换成了另外几样东西：监听地址、端口、并发数、模型存放位置。这些一般不是靠改一个配置文件里的某一行，而是靠启动时的环境变量或者系统服务定义下发。所以你要看的不是「哪个文件里有 key」，而是「当前进程实际生效的参数是什么」。
这里最容易踩的坑是：文件里写过什么不重要，运行时实际生效才重要。你可能在某个脚本里设过监听地址，但服务是通过系统服务或容器启动的，那边的环境变量把脚本里的值覆盖掉了，结果你以为改成功了，其实没生效。看现象永远以运行时为准。
| 你要确认的东西 | 去哪儿看 | 看什么 |
|---|---|---|
| 服务怎么启动的 | 进程列表和服务定义 | 启动命令里带了哪些参数 |
| 监听范围 | 服务启动后的监听端口状态 | 是本机回环还是对外地址 |
| 环境变量 | 系统服务配置或容器配置 | 变量清单里跟地址、端口相关的项 |
| 实际是否生效 | 直接请求服务地址 | 能不能连上、返回什么 |
如果你的部署方式比较杂，比如一部分在容器里、一部分在宿主机上，凭记忆猜很容易猜错。到 /models/deploy 按你实际用的部署方式对一遍口径，比在一个个文件里翻要快得多。
验证顺序：从本机到客户端逐层排除
连不上是最常见的问题，但「连不上」这三个字太笼统，它可能卡在网络层，也可能卡在鉴权层，两者的排查动作完全不一样。所以不要一上来就改客户端配置，先按从里到外的顺序走一遍，每走一步确认一次。
- 先在本机直接请求在运行服务的这台机器上，直接访问它的服务地址，看有没有正常响应。通了说明服务本身活着，问题在后头。
- 再换地址试一次把回环地址换成这台机器的内网地址或主机名再请求一次。这一步是验证监听范围够不够，不通说明只监听了本机。
- 然后从另一台设备试换一台同网络的设备，用内网地址请求。不通就是网络层的事，防火墙、网段、端口开放逐项看。
- 最后才动客户端前面都通了，再去调客户端里的地址和密钥字段。这时候问题范围已经很小，基本就是填错位置。
排查的时候建议先量一条基线。在一切正常的时候记录一次延迟和表现，之后出问题好对照，否则你没法判断是变慢了还是本来就这样。可以用 /tools/speed-test 存一次正常状态下的数据。
客户端那一栏该怎么填
客户端让你填字段的时候，先看清楚每个框问的是什么。很多工具同时有「服务地址」和「密钥」两个输入，填错位置比填错内容更常见——把地址粘进密钥框、把密钥粘进地址框，结果连不上，还以为是 key 有问题。
- 先读字段标签的含义，地址类字段填服务位置，密钥类字段填凭据
- 本机直连场景下，密钥框随便填或留空，重点是地址写对
- 如果前面挂了网关并开了鉴权，凭据由网关侧决定，去网关配置里取
- 把「谁负责鉴权」写清楚再动手，责任方不同，改的地方就不同
三种常见做法对应的责任方是这样的：单人本机直连，没人负责鉴权；局域网共享，多数靠网络层限制，而不是靠 key；要对外，鉴权责任在反向代理或网关上。想清楚自己在哪一档，再决定去哪个地方找那个值。
如果你确实打算把服务开放出去，顺便把当时各家官方接口的计费和方案也看一眼，好判断是自建划算还是直接调云端。具体数字会变，到 /price-watch 核对当时的报价再决定。
下一步如果你正卡在连接问题上，先按上面从本机到客户端的顺序走一遍；想确认自己的部署方式有没有踩到默认配置的坑，去 /models/deploy 按部署形态逐项对一遍。→常见问题
Ollama 到底有没有 API key？
默认没有。它设计成本机自用的推理服务，不签发密钥。你看到的「需要 API key」通常来自客户端模板，或者你中间加了网关。只有当你把服务对外暴露并加了鉴权层时，才会有真正需要填的值，而且那个值归网关管，不在 Ollama 里。
客户端提示鉴权失败是不是 key 填错了？
不一定。先分清是连不上还是被拒：连不上属于网络和监听范围问题，被拒才是鉴权问题。很多人是把主机地址填成了回环地址，外部机器自然访问不到。建议先在本机用同样地址自测一次，再看外部客户端的报错原文。
换了机器或改了配置后连不上，先查什么？
按顺序来：服务有没有起来、监听地址是什么、从哪台机器发起的请求、中间有没有代理。把当前部署方式和配置口径对照一遍，可以到 /models/deploy 核对自己的场景，别一上来就怀疑鉴权。
