很多人装完 Ollama，本机跑得好好的，一到局域网另一台机器、容器里的应用或者手机上去连，就提示连不上。多数情况不是模型的问题，而是服务默认只绑在本机回环地址上，外部请求根本进不来。这篇按「先判断、再改绑定、最后验证和回退」的顺序走一遍，告诉你环境变量改哪几个、不同系统怎么设、改完为什么还可能不通，以及什么场景下不建议直接把端口摊到公网。
很多人装完 Ollama，本机跑得好好的，一到局域网另一台机器、容器里的应用或者手机上去连，就提示连不上。多数情况不是模型的问题，而是服务默认只绑在本机回环地址上，外部请求根本进不来。这篇按「先判断、再改绑定、最后验证和回退」的顺序走一遍，讲清环境变量改哪几个、不同系统怎么设、改完为什么还可能不通。
改绑定地址本身不难，难的是改完还连不上时，能判断出到底是配置没生效、端口没放开，还是防火墙和路由在挡。所以下面每一步都配了「怎么验证」，不做无效重启。动手前建议先把当前环境变量的值记下来，后面回退能省不少事。
先确认：到底是绑定地址的问题，还是别的地方卡住
「本机能用、外部不能用」是最典型的绑定症状：服务只监听回环地址，只有本机自己发起的请求能进。但如果本机自己也连不上，那就不是绑定问题，先去查 Ollama 进程到底有没有起来、有没有崩过。这两种情况排查方向完全不同，先分清能省掉一半时间。
| 现象 | 大概率原因 | 先查什么 |
|---|---|---|
| 连接被拒绝 | 没绑对外，或进程没起 | 服务状态与实际监听地址 |
| 连上但一直超时 | 防火墙、安全组、路由 | 端口放行规则与网段连通性 |
| 返回 404 或空结果 | 路径或端口写错 | 调用的完整地址与端口号 |
| 本机也不通 | 进程没起来或崩了 | 服务日志与端口占用 |
- 在服务所在机器上先自测本机接口通不通，通了再往外测，不要一上来就从另一台机器试
- 容器里跑的场景要额外注意：容器内的回环地址和宿主机不是一回事，绑回环在容器里同样出不去
- 区分失败的三种表现——被拒绝、超时、返回异常，它们指向的原因不一样
- 自测阶段想顺便量个延迟基线，可以到 /tools/speed-test 看检测口径
要改的是哪个环境变量，值怎么写
核心就一个变量：把监听地址从回环地址改成对外可达的地址。值一般写成「主机 + 端口」的形式，端口沿用默认的那个即可，不用为了改绑定顺便换端口，换端口只会多一个变量。主机部分写 0.0.0.0 表示监听所有网卡，写具体某张网卡的 IP 则只在那张网上可达，后者范围更小、安全性更好一点。
- 回环地址
- 只接受本机自己发起的连接，外部机器连不进来
- 0.0.0.0
- 监听所有网卡，同网络里谁都能连，范围最大
- 指定网卡 IP
- 只在那张网卡对应的网络上可达，范围可控
改之前先确认当前值是什么，避免覆盖别人已经设好的配置。另外别把绑定地址和模型目录、服务端口这几个变量混在一起改，它们解决的是完全不同的问题，一次改一堆，出问题时根本不知道是哪条引起的。基础设施相关的入门概念可以对照 /ai-dict/category/infra 里的术语。
三个平台怎么落地设置
同样是设一个环境变量，不同系统生效的路径差别很大，设置位置错了会出现「明明改了却没生效」的情况。下面按服务形态分三类说，重点是改完要让托管它的那层重新读取配置。
- Linux 下的服务改的是服务单元里的环境变量配置，改完要让服务重新加载配置再重启；只重启不改配置文件，或者只改文件不重载，都不会生效。验证方式是看实际监听地址是否已经变。
- macOS 下的应用通常是图形化应用形态，服务由应用托管，环境变量的设置方式和命令行不同。设错位置会被应用自己的默认值盖掉，改完要确认应用是否真的以新变量重启。
- Windows 下区分「临时会话设置」和「永久写入系统环境变量」两种做法。前者关掉终端就失效，后者需要重开服务进程才吃到，改完别只开一个新终端测试就下结论。
- Docker 场景在启动参数里传这个变量，同时确认端口映射把容器内那个端口映射出来了。只设变量不映射端口，一样连不上，这是容器场景最常见的坑。
改完怎么验证，不通怎么退回
验证要一层层往外推，不要跳步。先在服务所在机器本机自测，再换同网段另一台机器用局域网 IP 测，最后用应用侧真实的调用方式测。哪一层开始断，问题就落在哪一层，后面的配置就不用再动了。
- 局域网通、外网不通，问题基本不在 Ollama，而在防火墙、安全组或路由，别再去改绑定地址
- 回退很快：把变量改回原来的地址并重启服务即可，所以改之前一定把原值记下来
- 绑定到对外地址意味着同网络里任何人知道地址和端口就能调你的模型，只在内网、有防火墙或反代挡在前面时才这么干
- 直接把端口摊到公网不建议；对数据出内网有要求的场景，也不适用这种做法
如果想对照一下当前各家服务在外部可达性、端口策略上的差异，到 /rankings 看当时的对比就行，别凭印象拍脑袋。
改完还是不通，按这个顺序查
改完仍不通，绝大多数不是变量写错，而是别的环节在挡。按下面顺序一层层排除，每查一步都确认一次现象，不要同时改多个地方。
- 确认配置被吃进去了看服务实际监听的地址和端口，跟配置里写的是否一致。不一致就是改了文件没生效或没重载。
- 查端口占用确认端口没有被别的进程占着，也没有被本机防火墙规则拦掉。
- 查跨网段与云上规则跨网段或跨云主机的场景，检查安全组、NAT 和路由规则。这类问题改环境变量永远解决不了。
- 最后查应用侧地址里该不该带协议头、端口有没有写全、有没有被代理层改写。连接报错的具体排查口径可以走到 /tools/verify 核对。
排查顺序的核心是：先证明配置生效，再证明网络可达，最后才怀疑应用写法。反过来查，很容易在应用配置里绕半天，其实服务根本没绑对外。
下一步改完绑定地址、确认能在局域网调通之后，建议顺手核对一下服务当前的可用性检测口径，避免把偶发的网络抖动当成配置问题。→常见问题
为什么我在本机能访问 Ollama，换台机器就不行？
最常见的原因就是服务只绑在本机回环地址上，外部请求进不到这个接口。解决办法是把监听地址改成对外可达的地址后重启服务。但也别一上来就认定是这个，先排除防火墙、安全组和端口映射，尤其是容器和跨网段场景，改绑地址不一定有效。
绑 0.0.0.0 有什么风险？
等于把接口摊给所有能连到你机器的网络。纯内网、有防火墙或反向代理在中间挡着，一般可以接受；如果这台机器有公网入口，就相当于把一个没有鉴权的模型接口挂到公网上，谁扫到都能用，算力和数据都不安全。这种场景建议只绑具体内网网卡，或者前面加一层带鉴权的网关。
改完环境变量重启了，还是不生效怎么办？
先确认服务进程真的读到了新值，很多系统上你改的是终端会话变量，而服务是由另一套机制拉起来的，两者不共享。其次是看服务实际监听的地址和端口有没有变。这两步都对，问题就不在环境变量上了，转去查防火墙、端口占用和调用方配置。
