你本地用 Ollama 跑着模型，应用却装进了 Docker 容器，一调用就报连接被拒绝或者解析不了域名。这篇不聊模型选型，只解决一件事：让容器里的代码稳定访问到宿主机上的 Ollama 服务。下面给的是判断标准加可执行动作，每一步都能直接对着做，最后附一套连不通时的排查顺序。
你本地用 Ollama 跑着模型，测试脚本跑得挺好，应用一装进 Docker 容器就报连接被拒绝，或者干脆解析不了域名。这种报错八成不是模型的问题，而是容器网络和监听地址这两层没过。下面只解决一件事：让容器里的代码稳定访问到宿主机上的 Ollama。判断标准加可执行动作，每步都能对着做，最后有一套连不通时的排查顺序。
读之前先记住一个前提：这篇讲的是「容器和 Ollama 在同一台机器上」的场景。如果容器跑在另一台机器、或者跑在 K8s 集群里，下面这些宿主机地址的写法基本不成立，得换思路，文里会单独点出来。
先搞清容器为什么连不上宿主机
容器默认有自己的网络命名空间，容器里的 localhost 指的是容器自己，不是宿主机。很多人在应用配置里写 localhost 加端口，宿主机上跑得好好的，进了容器就必然连不上，因为那个端口在容器里根本没人监听。这是第一层坑，也是最常见的。
- 容器内的 localhost 指向容器自身，宿主机服务要用另一套地址去指
- 宿主机上 Ollama 默认只监听回环地址，来自容器网桥的请求会被直接拒掉
- Linux 和 macOS、Windows 上，指向宿主机的写法不一样，跨平台照抄会踩坑
- 判断方法：先在宿主机上用命令行请求一次模型列表接口，确认服务活着，再进容器里试，分清是服务问题还是网络问题
按平台选对「宿主机地址」的写法
Mac 和 Windows 上的 Docker Desktop 提供内置域名，容器里用这个域名就指向宿主机，不用去猜 IP，也不用翻网卡配置。这是最省事的一种，优先用它。Linux 上没有这个内置域名，要么用网桥的网关地址，要么启动容器时挂上 host 网络模式，让容器和宿主机共用同一套网络栈。
| 运行环境 | 容器里指向宿主机的写法 | 注意点 |
|---|---|---|
| macOS + Docker Desktop | 使用内置的宿主机域名 | 直接写域名即可，不用改网络模式 |
| Windows + Docker Desktop | 同上，用内置域名 | WSL 里跑 Docker 时行为一致 |
| Linux 默认网桥 | 用网桥网关地址 | 网关地址到站内网络配置类页面按当时环境核对 |
| Linux + host 网络模式 | 容器直接用宿主机的地址 | 端口会与宿主机冲突，编排时留意 |
- 内置宿主域名
- Docker Desktop 给容器留的一个固定名字，解析后指向宿主机，省去查 IP
- 网桥网关
- 默认网络里，容器通往宿主机的那个出口地址，Linux 上常用它
- host 网络模式
- 容器不再独立隔离网络，直接和宿主机共用一套接口和端口
无论用哪种写法，都建议把地址做成环境变量，而不是硬编码在代码里。换机器、换编排文件、本地和测试环境切换时，只改一处配置就行。什么情况下这套写法不适用：容器和 Ollama 不在同一台机器上时，宿主机地址这个词本身就没意义了，得改成 Ollama 对内网开放，并补上访问控制。
让 Ollama 愿意接受外部连接
地址写对了也可能连不上，因为服务端根本不肯接外来的请求。Ollama 默认只监听回环地址，需要改一个监听地址的环境变量，让它不止听本机。这个变量的准确名称和取值，到站内的术语与配置类页面核对当时的写法，别照着记忆改。
- 改监听配置给 Ollama 的启动环境加上监听地址变量，让它绑定到愿意接受请求的地址上，容器侧才有机会连进来。
- 放开端口确认宿主机防火墙、云主机安全组没有拦这个端口，容器到宿主机这个方向也要放行，只放行一半一样连不通。
- 重启服务环境变量只在服务启动时读取，改完要重启 Ollama 进程本身，只重启容器不会让宿主机上的服务读到新配置。
- 回归验证从容器里再请求一次模型列表接口，能返回结果才算这一层过了，别只看配置文件。
连不通时的排查顺序
报错分不清原因时，按固定顺序往下走，别东一榔头西一棒子。顺序的核心逻辑是：先证明服务活着，再证明网络通，最后才怀疑配置。每一步都有明确的观察点。
- 在宿主机上请求一次模型列表接口，能通说明服务本身没问题，问题在网络或地址
- 进容器里用同样命令再试，通不了就锁定在容器到宿主机这条链路上
- 换地址写法逐个排除，先试内置域名，再试网关地址，最后看是不是 DNS 解析不到
- 看两边日志：报错说拒绝连接，多半是监听地址没改对；说超时，多半是防火墙或安全组挡了
还有一种容易漏的情况：宿主机上模型还在加载，容器里的应用已经发起请求，等不到响应就退出了。这类现象看起来像网络问题，其实是启动时序问题。给容器侧加超时和重试，观察日志里每次请求的耗时，能区分开来。
稳定可用的几个小习惯
一次调通不难，难的是换台机器、换个人接手还能通。把访问地址、模型名这类会变的东西抽成配置项，本地和测试环境共用同一份代码，只在环境变量上做区分。容器依赖宿主机服务时，超时和重试是标配，不是可选项。
- 地址和模型名走配置，不写死在代码里，换环境只改一处
- 给请求加合理的超时和重试，宿主机侧模型加载慢时不至于直接崩
- 把这份网络配置写进项目说明，下一个人不用重新踩一遍
- 环境变了就重跑一遍上面的排查顺序，别凭印象判断
- 涉及对外暴露的配置，先想清楚谁能访问，再决定开放范围
容器连不上宿主机，九成不是模型的问题，而是 localhost 的含义和监听地址这两件事没说清。下一步把几个常见平台的宿主机地址写法和监听配置差异，整理成一份随手能查的对照表；站内的工具目录和配置类指南里有对应的整理页面，照着核对比到处翻帖快。→
常见问题
容器里写 localhost 为什么连不上宿主机上的 Ollama？
容器里的 localhost 指向容器自己，不是宿主机。要么改用平台提供的宿主域名或网桥网关地址，要么让容器直接共用宿主机的网络栈。先把地址改对，再去看 Ollama 有没有对外监听。
改了监听地址还是连不上，最常见的原因是什么？
多半是没重启服务，或者防火墙没放行。先确认服务重启后监听状态变了，再从容器里试一次；如果表现为超时而不是拒绝连接，基本可以往防火墙和网络策略方向查。
把 Ollama 开放给容器访问，会不会有安全风险？
会。绑到所有网卡后同网段的机器都可能访问到，公网机器上尤其危险。稳妥做法是只对内网或指定网段开放，再加一层鉴权和访问控制；只是本机开发用，尽量别扩大监听范围。
