你在自己机器上跑通了 Ollama，本地调着挺顺。现在同事要把他的脚本指过来、或者小团队想共用一台机器上的模型，问题就来了：别人连不上、连上之后又担心谁来都能用。这篇按「先在自己机器上验证、再放到内网、最后才考虑公网」的顺序，把监听配置、访问控制和兜底手段一步步过一遍，凡是要看具体数字的地方都告诉你到站内哪一页去核对。
你在自己机器上把 Ollama 跑通了，本地调着挺顺。现在同事要把脚本指过来，或者小团队想共用一台机器上的模型，问题立刻来了：别人连不上，连上之后又担心谁来都能用。这篇按「先在自己机器上验证、再放到内网、最后才考虑公网」的顺序，把监听配置、访问控制和兜底手段一步步过一遍。
先说结论：大部分「想给别人用」的需求，在内网这一层就能解决，不需要碰公网。真要对外开，也必须先加一层自己的门禁，因为 Ollama 本身不提供账号体系。凡是要看具体数字的地方，比如延迟基线、并发上限、价格与性能对照，都建议到站内对应页面核对当时的数字，别照抄别人的截图。
先分清「给谁用」：本机、内网还是公网
Ollama 默认只监听本机回环地址，所以你自己能调、别人一定调不到，这不是服务坏了，而是默认的安全姿势。按调用方的位置分三档：同一台机器、同一个局域网、公网。三档对应的做法完全不同，最常见的错误是一步跨到公网，结果把自己机器的模型和带宽敞开给所有人。
| 调用方位置 | 典型场景 | 能否直接连默认配置 | 要先做的事 |
|---|---|---|---|
| 同一台机器 | 自己写脚本、本地调试 | 能 | 不用动配置 |
| 同一个局域网 | 同事的电脑、团队内网服务器 | 不能 | 改监听地址 + 放行端口 |
| 公网 | 跨地协作、对外提供接口 | 不能 | 改监听 + 自建鉴权 + 限流 |
| 同一台机器的容器 | Docker 里跑的应用 | 视网络模式而定 | 确认容器能否访问宿主地址 |
- 先问一句「对方和你的机器在不在一个网里」，这一个问题能砍掉大半无效折腾；
- 动手改配置前，到站内 /tools/speed-test 量一遍当前延迟基线，改完才有对照，能区分是网络问题还是模型本身慢；
- 跨地协作不一定要公网，内网穿透、团队自建入口、VPN 都是更省事的选项；
- 如果对方只是偶尔用几次，把命令和模型名发给他、让他自己在本地跑，往往比共用一台机器更省心。
把服务从「只有我能调」改成「内网能调」
核心动作是改监听地址和端口，让服务不再只绑回环地址。改之前先确认这台机器的内网 IP 是固定的，否则别人写死的地址明天就失效，排查起来非常费劲。改完必须重启服务才生效，这是最容易被忽略的一步。
- 确认内网地址固定在路由器或系统网络设置里给这台机器绑定固定内网 IP，别用动态分配；否则把地址告诉别人之后，过几天就连不上了。
- 改监听地址与端口通过环境变量把监听地址改成允许内网访问的地址，并确认端口没有被别的程序占用。不同系统的环境变量写法不一样，站内 ollama_host 环境变量 与 windows ollama 使用教程 分别对应两条路，别混用。
- 重启并本机自测重启服务后，先用本机的新地址调一次，确认配置真的生效了；这一步失败，说明改法有问题，不用去查网络。
- 换一台机器测通到同一局域网的另一台机器上发起请求。本机通、另一台不通，问题基本在防火墙或安全组，而不是 Ollama。
防火墙和端口放行是第二个坑。排查顺序固定下来：本机通、内网不通，先看这台机器的防火墙规则，再看路由器或云安全组，最后才怀疑服务配置。把顺序倒过来查，通常会在错误的地方浪费一两个小时。
别人能连上之后，怎么不让自己这台机器被拖垮
Ollama 自身没有账号体系，所谓「给人用」实际是「给能访问到这个端口的人用」。所以鉴权只能做在它前面：反向代理加账号密码、内网白名单、或者只在 VPN 里开放。哪种都行，但不能不做，裸端口放在内网里也不等于安全。
- 前置鉴权
- 在 Ollama 前面挂一层带账号密码的反向代理，所有请求先过这一层。
- IP 白名单
- 只允许指定的内网地址访问端口，其他人即使知道地址也连不上。
- 限流
- 给单个来源设请求频率上限，防止一个人的脚本把并发占满。
- 超时
- 设置请求超时，避免一个卡住的连接长期占用资源。
- 最大请求长度
- 限制单次请求的输入长度，防止一个超长文本把机器占死。
并发是真正的瓶颈。一个人调看到的是延迟，十个人同时调看到的是排队。上线前先按自己那张卡的并发能力估一遍，站内 /compute/sizing 和 gpu-concurrency-estimate 给了估算思路，具体数字到对应页面核对。另外，盯资源曲线比翻日志有用，显存或 CPU 长期打满，先减并发再查原因。
放出去之前过一遍的检查清单
- 数据边界想清楚：对方发过来的内容会进你的机器，模型输出也会经过你的网络，涉及敏感内容就不该走开放端口；
- 能不开公网就不开；非要开，至少做到只放行指定 IP、加一层自建鉴权、并且定期更换凭据；
- 改配置前备份原文件，配置改乱、端口冲突、别人已经接了你的服务时，要能一句话切回原来的样子；
- 把调用方式一次写清楚给对方：地址、端口、模型名、超时怎么设，少一个都够对方排查半天；
- 留一个临时关闭的开关，出问题时先断开服务再慢慢查，别一边被调用一边调试；
- 上线后头几天盯一下访问来源，出现不认识的高频请求，先关端口再加白名单。
适用边界也要说清楚：这套做法适合小团队内部共用、脚本联调这类场景。如果你要对外提供稳定服务、有多租户或计费需求，Ollama 当前的形态就不合适，应该换成带完整鉴权和配额体系的部署方式，或者直接走云端 API。站内 /sites 和 /rankings 可以对照不同中转与云服务的可信度和价格，具体数字以页面当时显示为准。
下一步先把「谁要调用」这件事确认清楚，再决定动不动监听配置；配置改完用站内工具量一遍延迟和并发表现，比凭感觉判断靠谱。→常见问题
我把监听地址改成 0.0.0.0 了，别人还是连不上，最可能是什么原因？
按顺序排查三件事：服务是否真的重启生效（本机先用新地址自测一遍）、本机防火墙和对方所在网络有没有放行这个端口、对方填的是不是你机器的内网 IP 而不是 localhost。这三步走完基本能定位，剩下的才是路由问题。
Ollama 能不能设个 key 给别人，像云服务那样发一个就完事？
它本身没有内置的密钥体系，站内 ollama api key 相关几篇讲的「key」多是对接上层工具时的占位配置，不是原生鉴权。要发凭据，得在 Ollama 前面架一层反向代理或网关，由那一层来做账号和限额。
同一个人调没感觉，几个人一起用就变卡，是网络问题还是机器问题？
多半是机器侧。单次请求慢看的是生成速度，多人同时请求看的是排队和显存占用，这两件事的瓶颈点不一样。先看显存和 GPU 利用率曲线，长期打满就是算力不够，而不是网络慢，按站内 /compute/sizing 的思路重估一遍再决定加卡还是限制并发。
