标题修复记录：Linux docker 部署 Dify，无法调用宿主机当地服务

在 Linux 上用 Docker Compose 把 Dify 跑起来之后，想接宿主机上已经跑着的 Xinference 推理服务，结果地址填成 http://127.0.0.1:9997 就被拒绝连接。这是私有化部署大模型时非常高频的一个坑，根因听起来简单，但很多人换了好几种写法还是不通。这篇把报错拆开、把几种可选方案各自适用场景讲清楚。

一、报错原文里最关键的一行

在 Dify 里配置本机 Xinference 的模型，会看到这段信息：请求地址指向 9997 端口的 /v1/models/bge-m3，最终落到 [Errno 111] Connection refused。这个错误码的含义是目标端口上没有服务在监听，不是超时、也不是鉴权失败，这两者的处理方式完全不同，先分清这一点。

二、根因：容器里的 127.0.0.1 不是宿主机

Dify 跑在容器里，容器有自己独立的网络命名空间。容器里的回环地址指向的是容器自身，所以你填的那个 127.0.0.1，请求根本没出容器，自然到不了宿主机上跑的 Xinference。宿主机的 9997 端口对容器来说属于另一个网络世界。

把这句话记牢，这类问题的判断就少走一半弯路：先分清是地址写错，还是服务根本没监听。

三、四种可选方案

几种做法都能通，区别在于后续维护成本：

• 用宿主机在 Docker 网桥中的地址：Linux 上默认网桥网关通常是 172.17.0.1，把地址改成它就能命中宿主机。优点是改动最小，缺点是这个地址会随 Docker 网络配置变化，不是长期稳定方案。
• 用 host 网络模式：让相关容器以共享宿主机网络栈的方式运行，此时回环地址直接生效。代价是端口冲突风险变高，多容器编排时更麻烦。
• 放进同一个 Compose 文件用服务名互访：两个服务在同一自定义网络里，直接填服务名加端口。这是最干净的做法，也是长期维护最推荐的。
• 用宿主机内网 IP：写成宿主机的局域网地址，防火墙放行对应端口即可，适合跨机器部署。

四、还有一个容易漏的点：监听地址

就算 Dify 侧的地址改对了，Xinference 启动时如果只监听回环地址，容器发来的请求依然进不去。需要让它监听所有地址才能接受来自容器网络的访问。这一步经常被人忽略，然后回头继续改 Dify 的配置，白白绕一圈。

五、改完之后怎么验证

不要只看 Dify 页面有没有报错，先用一条命令确认容器里能不能到这个地址：进容器执行针对目标端口的连接测试，通了再去页面点一次模型列表刷新。能拉到模型清单才算真的通了，页面上的红字提示只是表象。

六、这个坑在哪些场景会复现

只要是容器访问宿主机上的本地服务，都会遇到同一类问题，除了 Dify 对接 Xinference，常见还有：容器内访问宿主机上的 Ollama、vLLM、向量库，以及访问宿主机跑的 Redis、MySQL 做数据持久化验证。判断逻辑完全通用：容器里的回环地址永远指向容器自己。

七、小结

处理顺序建议固定成三步：先看错误码分清是没监听还是地址错；改 Dify 侧的访问地址；确认宿主机服务监听在所有地址。多数情况下两边要一起改。如果长期维护，优先选 Compose 服务名互访，次选网桥地址并配合监控，host 网络模式只在单机单机验证时使用。

qidao123.com企服评测-应用市场 编辑提示