linux ollama 设置 api key

在 Linux 上把 Ollama 跑起来不难，难的是它默认不带任何鉴权：只要 11434 端口暴露出去，同网段谁都能直接调你的模型和显存。这篇按运维视角给一套可落地的做法——先判断你到底要不要钥匙，再决定是反代加一层还是干脆别暴露端口，最后给出改完配置的验证顺序。

在 Linux 上把 Ollama 跑起来确实不难，装完就能用本机脚本调。麻烦的是它默认不带任何鉴权：只要监听地址对外、端口能通，同网段甚至公网谁都能直接调你的模型，占你的显存，还能顺手把你的模型列表翻一遍。所以这篇不讲安装，只讲鉴权这件事该怎么做。

整篇按运维视角推进：先判断你到底需不需要钥匙，再决定是在前面反代加一层，还是干脆别把端口露出去；最后给一套改完配置的验证顺序。所有涉及具体数字的地方（接口延迟基线、不同方案的价格换算），到站内对应页面看当时的数就行，别照抄别人的博客。

先判断：你的 Ollama 到底需不需要鉴权

很多人的问题是还没搞清楚自己属于哪种场景，就先动手改配置。判断标准其实很简单：看调用方来自哪里，而不是看你觉得「应该没事」。本机脚本、本机跑的面板，跟同网段同事发来的请求，风险完全不是一个量级。

• 只用 127.0.0.1 本机调用，比如本机脚本、本机面板，鉴权不是必须，重点是别手贱把监听地址改成对外
• 把服务开给局域网同事、CI 机器或公网时，鉴权就是必需品，因为 Ollama 官方接口本身不做密钥校验
• 最容易踩的是中间情况：装了面板、给同事开了端口、又挂了隧道，表面看只在局域网，实际外网扫得到
• 判断顺序建议先跑一遍 ss 或 netstat 看真实监听地址，再决定要不要加壳，而不是先改配置再补理由

1. 看清监听地址用 ss -lntp 或 netstat -lntp 找到 11434 对应的进程和监听地址，是 127.0.0.1 还是 0.0.0.0，这一步决定后面所有动作
2. 列出真实调用方把调用来源列成清单：本机、同网段、跳板机、CI、公网。只要有任何一个不在信任范围内，就按需要鉴权处理
3. 给端口做一次外部探测从非本机位置直接请求端口，能返回内容就说明还有裸露口，先收口再谈别的

反代加锁：不改 Ollama 本体，在前面挡一层

Ollama 本体没有内置的密钥概念，所以最稳的做法是不动它，在它前面放一层反向代理，由反代负责校验。这样升级 Ollama、换模型都不会影响鉴权逻辑，边界也清晰：反代入口对外，Ollama 本体只听 127.0.0.1。

反代这层顺手还能做限流、按 key 区分调用方、记访问日志，这些是 Ollama 自己给不了的。不适用的场景也很明确：客户端既不能自定义请求头、又不支持 Basic 认证时，这条路改造量会明显变大，得先拿一个真实客户端试通再上。

• 反代只转发必要路径，别把整个根路径无差别放出去
• 入口建议套 HTTPS，否则头里的 key 等同于裸奔
• 日志里不要打印完整的 key 和 Authorization 头
• 给不同调用方发不同的 key，出事时能定位到人而不是关掉整个服务

监听地址、防火墙与进程托管三件套

这三件事任何一件出问题，前面做的鉴权都可能形同虚设。顺序上先定监听地址，再配防火墙，最后确认进程托管方式，因为托管方式决定了环境变量写在哪才不会被重启丢掉。

• 监听地址由环境变量控制，改之前先确认是哪一份配置文件或 systemd 单元在生效，别改了不生效还反复重启
• 防火墙按默认拒绝、按需放行：只放反代入口端口，11434 不要对整段内网开放
• 用 systemd 托管时环境变量写进单元文件，不要只写在登录 shell 里，否则重启后丢配置
• 改完先 systemctl daemon-reload 再重启服务，跳过这一步改动不会生效
• 验证时在本机、同网段另一台、外网三个位置各测一次，确认只有该通的地方通

这里没有可以照抄的端口号或网段，具体填什么取决于你的网络划分。真要对比不同部署方式的接口延迟、吞吐基线，到站内的速度测试页看当时的测量结果，别拿别人环境里的数当自己的参考。

改完怎么验：一套排查顺序

验证的关键不是「能不能调通」，而是「不该通的那次有没有失败」。很多配置看着成功，其实只是恰好绕过了检查，比如反代只挡了健康检查路径、或者客户端悄悄吞掉了认证头。

1. 先验端口从非本机位置直接请求 11434，能通就说明还有裸露口，先收口再继续后面步骤
2. 再验钥匙带 key 和不带 key 各发一次同样的请求，不带 key 的那次必须明确失败，而不是照样返回内容
3. 验业务接口鉴权通过后，再看模型列表、推理请求是否正常返回，排除只挡了健康检查、真接口照样裸奔的假象
4. 验多实例如果你跑过多个实例，确认它们没有抢同一个端口，否则会出现请求偶发失败的玄学现象

排查顺序建议固定成：端口、钥匙、业务接口、多实例。按这个顺序走，基本不会在错误的方向上浪费时间。数字类比对——比如某条链路延迟是否正常——去站内页面核对当时的数据，而不是凭印象判断。