本地跑 Ollama，再用 Docker 起的 Dify、Open WebUI、RAGFlow 之类应用去连，十次有八次报连接被拒绝或者超时。多数人第一反应是模型没起来，其实宿主机服务跑得好好的，问题出在容器看到的「宿主机」跟你以为的不是同一台机器，加上 Ollama 默认只听本地回环。这篇按排查顺序走一遍：先确认监听地址，再看容器用哪种网络模式，最后验证端口和地址怎么写。
本地跑着 Ollama，另一头用 Docker 起了 Dify、Open WebUI、RAGFlow 这类应用去连，结果报连接被拒绝或者直接超时。多数人第一反应是模型没起来，跑去翻模型列表、重拉一遍，其实宿主机上的服务活得好好的。问题往往出在两件事：容器眼里的「宿主机」跟你以为的不是同一台机器，而 Ollama 默认只肯听本地回环。
这篇不绕概念，按排查顺序走：先确认监听地址放没放开，再看容器用的是哪种网络模式、地址该写什么，最后按三步验证顺序收口。每一节都给可复制的动作和判断标准，也会说清什么情况下这套做法不成立。
先解决监听地址，服务默认不听外面
Ollama 默认绑在回环地址上，只接受本机进程发来的请求。容器哪怕和它跑在同一台物理机上，从服务角度看也属于「外部来源」，连不上是正常现象，不是故障。所以排查第一步不是看容器，而是先让服务愿意听外面。
做法是启动前设置绑定地址的环境变量，把它从回环改成所有网卡（也就是常见的那个全零地址）。改完必须重启服务才生效，不同系统的重启方式不一样：用系统服务管的走服务重启命令，手动前台跑的直接结束进程再起一次。验证方式是看启动日志里打印的监听地址有没有变，或者干脆在本机上换一个非回环地址访问一次接口，能通就说明放开了。
- 机器直接暴露在公网、且没有防火墙或反代兜底时，不要随手改成全零地址。
- 宿主机上还有别的服务共用同一个端口时，先确认端口归属，别把别人的服务顶掉。
- 多人共用的开发机，改监听之前最好跟同事打个招呼，避免别人本地调用突然多出一条外部入口。
- 容器跑在另一台机器上时，改监听也不够，还得看后一节的网络模式和端口暴露。
再看容器网络模式，决定「宿主机」该写什么
监听放开之后，第二个坑是地址写法。桥接模式下容器有自己独立的 IP，容器里的回环地址指向的是容器自身，不是宿主机，所以填回环地址必然失败。这种情况要么换成宿主机在桥接网络里的网关地址，要么直接用宿主机在局域网中的实际地址。host 模式下容器和宿主机共用网络栈，回环地址才成立，但会带来端口冲突，部分桌面系统上的表现也不太一致。
| 容器网络模式 | 容器里该写什么地址 | 注意事项 |
|---|---|---|
| 桥接（默认） | 宿主机在桥接网络里的网关地址，或宿主机局域网实际地址 | 写回环地址一定不通，因为指向容器自己 |
| host | 回环地址可用 | 共用端口，容易和宿主机其他服务撞车 |
| 自定义网络（多容器编排） | 走服务名，同网络内直接互连 | 不要把宿主机地址硬编码进镜像 |
| 容器在另一台机器上 | 宿主机所在机器的可达地址 | 改监听不够，还要确认端口对外暴露 |
判断口径很简单：看「谁跟谁在同一层」。同一个编排网络里的服务互相直接用服务名；容器和宿主机之间用网关地址或局域网地址；跨机器就老老实实走可达地址加端口暴露。如果你用的是托管容器服务或者远程开发机，容器和 Ollama 根本不在同一台机器，上面这节的做法都不成立，得直接看端口暴露和访问控制那一层。
三步验证顺序，别跳着改
很多人在这一步反复折腾，是因为一次改了好几处，最后分不清是哪一处起了作用。按顺序来，每步只验证一件事，出问题时定位范围会小很多。
- 第一步：宿主机上换非回环地址访问用宿主机在局域网中的地址去访问模型接口，能通说明监听确实放开了。不通就回到上一节，先别碰容器。
- 第二步：进容器内部访问同一地址用最小工具在容器里发一次请求，别一上来就重启整个应用栈。能通说明网络层没问题，不通就是网络模式或者地址写错了。
- 第三步：回到应用里填地址前两步都通了再来改应用配置。这时如果还不通，问题基本在地址格式或应用缓存，而不是网络。
判断标准可以记成一句话：宿主机能通、容器内不通，问题在网络模式；两边都不通，问题在监听或防火墙；只有应用不通，问题在填的地址格式或者配置没生效。
地址里最容易写错的几处
- 端口写错或者漏写，尤其是服务改过默认端口的情况。
- 协议前缀缺失或写成了另一套协议，很多客户端对前缀比较敏感。
- 结尾多一个或少一个斜杠，有的应用会把两种写法当成不同路径。
- 把网关地址和局域网地址搞混，两者在一定条件下能互换，但不是所有网络模式都行。
- 填完只看界面上的笼统提示，不去翻应用日志里的原始报错，等于自断线索。
常见组合怎么填，以及改完不生效怎么办
几种典型搭配的填写形态差别不小：本地开发单机，容器和 Ollama 同在一台机器，走网关地址；局域网里另一台机器上跑的模型，走那台机器的可达地址；编排文件里多个容器互连，直接写服务名。编排场景下不要把宿主机地址硬编码进镜像，用环境变量或者编排文件里的配置项注入，换机器时才不用重新打镜像。
- 服务没重启
- 环境变量改了但进程还是旧的，最先怀疑这一条。
- 环境变量只对当前终端生效
- 换一个终端或者换个用户就丢了，需要写进服务配置。
- 编排文件里另有覆盖
- 你在宿主机改了配置，容器里的编排文件里还写着旧地址。
- 容器缓存旧配置
- 重建容器比反复重启更干净，尤其是配置来自构建阶段时。
什么情况下值得换个思路，别让容器去连宿主机：跨机器、多人共用、需要稳定地址的场景，把模型服务也放进同一个容器网络里更省事。地址固定、不依赖宿主机环境变化，排查面也小很多。反过来，如果只是本机自己用、偶尔跑一下，改监听加网关地址就够了，不必上编排。
如果你还在挑用哪家模型接口或者哪个中转，站内整理了各家在线接口的价格与模型资料，也有中转站可信度检测和工具目录。具体数字和当下的服务状态，去下面的页面看当时的记录，比自己记结论更靠谱。
下一步要横向比较在线接口价格、或者查某个中转站的可信度，站内都有现成的对照页面，顺着链接看当时的数字和检测记录就行。→常见问题
容器里到底该填 127.0.0.1 还是宿主机 IP？
看容器的网络模式。桥接模式下 127.0.0.1 指向容器自己，填它一定连不上，要填宿主机在局域网里的地址或桥接网关地址；host 模式下容器共用宿主机网络，127.0.0.1 才成立。不确定就先在容器里试着访问两种地址，哪个通用哪个。
改了绑定地址还是连不上，最先查什么？
按顺序查三件事：服务有没有真的重启并加载了新配置；宿主机的防火墙或安全组有没有放行那个端口；容器里访问宿主机其他端口通不通。前两项占大多数。如果只有这一个端口不通，多半是监听没生效；如果所有端口都不通，是网络模式或防火墙的问题。
把 Ollama 绑到所有网卡有什么风险？
等于把这个模型接口开放给了能访问到该地址的所有人，默认没有鉴权，别人可以直接调你的模型、占你的显存。局域网内自用问题不大，公网机器上必须加防火墙规则或前置一层带鉴权的反向代理。开了之后建议把地址和访问范围记下来，定期回看。
