在自己机器或内网跑 ollama，很多人只顾着把模型拉起来、接上自己的应用，等发现服务能被同网段任何人调用、甚至被外网摸到，才想起权限这回事。这篇不讲部署怎么跑通，只讲怎么把「谁能访问、能调哪些模型、能触发哪些动作」这几层收窄，给一份可以照着改的清单和排查顺序。
在自己机器或内网跑 ollama，很多人只顾着把模型拉起来、接上自己的应用，等发现服务能被同网段任何人调用、甚至被外网摸到，才想起权限这回事。这篇不讲部署怎么跑通，只讲怎么把「谁能访问、能调哪些模型、能触发哪些动作」这几层收窄，给一份可以照着改的清单和排查顺序。
先明确一件事：ollama 自带的服务形态更像「本机开发服务」，默认假设你在单机自用，所以它不会替你把租户隔离、密钥轮换这些事都做了。想让权限真正可控，大部分动作要发生在它外围——网络设备、反向代理、你自己的调用服务。下面按层拆开讲，每层都给你一个判断标准和可执行的改法。
先把「权限」拆成三层，别混在一起改
第一层是网络可达性：服务监听在哪个地址、哪些机器能连上；第二层是调用鉴权：连上之后有没有凭证校验；第三层是业务约束：应用层允许调用哪些模型、允许触发哪些动作。三层混着调最容易改坏，建议按这个顺序一层层收。
判断你要不要动某一层的标准：如果服务只绑在本机回环地址、且只有本机进程调用，网络层基本不用改；一旦需要跨机调用，网络层和鉴权层就必须一起看。只调一层就上线，往往会出现「以为收紧了其实还留着口子」的情况。
- 网络可达性
- 决定谁的网络包能到达服务端口，是你唯一能靠配置彻底切断的一层
- 调用鉴权
- 决定到达之后要不要出示凭证，ollama 原生不做，通常靠前置代理补
- 业务约束
- 决定这次调用能用哪个模型、能触发什么动作，只能在你自己的服务里做
网络层：把监听地址收到最小范围
先确认当前服务实际绑在哪。默认只绑本机回环时，同网段其他机器是连不上的；一旦为了跨机使用改成了对所有网卡开放，等于把接口交给了整个可达网络。改之前先想清楚「到底哪几台机器要连」，这份名单决定了你要放行的最小范围。
要做跨机访问，优先放在容器网络或内网里，用防火墙规则限定来源网段，而不是直接暴露到一个大网段。是否能只放行某几台机器，取决于你的网络设备能力；拿不准就先按源 IP 做限制，宁可比需要的窄一点，事后按实际报错再放开。
- 确认当前绑定查一遍服务启动参数和实际监听的地址端口，记下来，作为改之前的基线
- 改绑定范围把监听地址从「所有网卡」收到具体的内部地址，或者干脆保持回环、只让本机连
- 加一道来源限制在防火墙或安全组里按来源 IP 或网段放行，只留第一步那份名单里的机器
- 三点复测从本机、从目标机器、从一台不该有权限的机器各测一次，确认该通的通、不该通的确实不通
鉴权与工具权限：ollama 本身能做什么、不能做什么
ollama 的原生接口设计上不提供完整的用户体系与密钥管理，指望它像云端 API 那样「发一个 key 就隔离一个租户」是不现实的。常见的做法是在前面加一层网关或反向代理，由那一层负责校验凭证、限流和记录调用来源。
要限制「只能调哪些模型」，最直接的办法是不要让调用方自由指定模型名：在你自己的服务里把模型名单写死成白名单，收到请求后先比对，不在名单里就拒绝，而不是把请求原样转发给 ollama。要限制「模型能做什么」——比如能不能联网、能不能执行本地命令、能不能读写文件——这类约束不归 ollama 管，取决于你在外面挂的 Agent 或工具链。
| 想限制的东西 | 在哪里做 | 什么情况下不适用 |
|---|---|---|
| 谁的网络包能到达 | 监听地址 + 防火墙/安全组 | 走反向代理时改代理层规则 |
| 谁能调用 | 前置网关或反向代理的凭证校验 | 调用方都在同一台机器上时可弱化 |
| 能调哪些模型 | 你自己服务里的模型白名单 | 用别人托管入口时由对方决定 |
| 能触发哪些动作 | Agent/工具链的动作白名单 | 模型只做纯文本问答时不涉及 |
- 凡是给了模型执行动作能力的地方，都要在那里再设一道白名单和确认步骤
- 把「允许使用的模型名」写进配置文件，不要写在客户端代码里由调用方传参决定
- 自检动作：跑一遍你线上真实的调用路径，看有没有哪一步是客户端直接传模型名、直接触发动作的
- 有就把它收进你自己的配置里，改动后从「应放行」和「应拒绝」两端各测一次
- 凭证要有吊销方式，否则一旦流出你只能靠改网络规则来止血
一份可以直接照着走的收口清单
下面这份清单按顺序做，每一步都有可验证的结果。中间任何一步发现业务要断，先停下来评估回退，不要硬着头皮往下改。
- 列出调用方写下你现在到底有哪几个调用方：本机脚本、同事电脑、内网服务、外部应用，写成清单，清单之外的都应当连不上
- 收网络范围核对监听地址与防火墙规则，让可达范围等于第一步那份清单；改完从清单外的一台机器实测，确认连不上
- 加校验层在 ollama 前面加一层校验，凭证从这层发、从这层吊销；没有这层就说明你目前的隔离只靠网络位置
- 写白名单把所有「允许使用的模型名」和「允许触发的动作」写成配置白名单，放进你控制的服务里
- 留回退路径改绑定或加网关后如果业务断了，你要能在几分钟内退回到能用的状态，否则先别在生产上改
改完出问题，按这个顺序排查
先分「连不上」还是「连上了但被拒」。连不上多半在网络层——绑定地址、端口、防火墙、容器端口映射四处逐项确认。连上了但被拒，多半在鉴权层或应用层白名单：先看凭证是否过期或发错，再看模型名是否不在白名单里，最后看动作是否有额外开关没打开。
排查时不要一次改多个变量。固定住网络层不动，先只调鉴权，再只调白名单，否则你会分不清是哪一层生效了。改完做个最小复现：用一条最简单的请求分别从「应放行」和「应拒绝」两端各打一次，把两端结果都留档，下次再出问题可以直接对比。
- 网络层检查顺序：绑定地址 → 端口 → 防火墙规则 → 容器端口映射
- 鉴权层检查顺序：凭证是否存在 → 是否过期 → 是否发给了正确的调用方
- 应用层检查顺序：模型名是否在白名单 → 动作开关是否打开 → 请求是否被转发时改写
- 每次都留一份「改前 / 改后」的请求与响应记录，作为回退和对比依据
常见问题
ollama 有没有自带的 api key，开了就能限制别人调用？
原生服务侧不提供完整的密钥与多租户体系，靠它自己发 key 来隔离调用方不现实。常见做法是在它前面加一层网关或反向代理，由那一层做凭证校验、限流和来源记录；如果是单机自用、只绑本机回环，那本身就没人能连，也不用折腾鉴权。
我只想限制「只能调某几个模型」，在哪改最省事？
别依赖 ollama 侧，在你自己那层服务里维护模型名白名单：收到请求先比对名单，不在名单里直接返回拒绝，不要原样转发。这样即使别人知道别的模型名也调不动。前提是你的调用方都必须经过你这层，绕过它直连服务的话，白名单形同虚设。
限制了访问之后，同事反馈连不上了怎么办？
先分清是网络不通还是被鉴权拒绝：网络层问题查绑定地址、端口和防火墙放行规则，鉴权层问题查凭证是否发放或过期、模型名是否在白名单。处理时一次只改一个变量，改完让同事按原先的调用方式复测一遍，确认恢复再继续收其他口子。
