1. 问题初现：当Dify遇上Ollama，为何总是“连接被拒”？

最近在折腾Dify，想让它调用我自己在本地电脑上跑的Ollama大模型。这个组合听起来很美：Dify负责提供强大的AI应用编排和可视化能力，Ollama则在本地默默提供模型推理服务，既保护了隐私，又能灵活使用各种开源模型。想法很丰满，但现实往往先给你一记重拳。我按照常规思路，在Dify的模型供应商配置里，填上了Ollama服务的地址，比如 http://192.168.1.100:11434，然后满怀信心地点了保存。结果，屏幕上赫然弹出一个刺眼的错误：

An error occurred during credentials validation: HTTPConnectionPool(host='', port=): Max retries exceeded with url: /api/chat (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7550bc7cb350>: Failed to establish a new connection: [Errno 111] Connection refused'))

这个报错信息，相信很多尝试在Docker容器里跑Dify，并连接宿主机或其他网络服务的朋友都见过。它直白地告诉你：“兄弟，我连不上你给的那个地址。” 但问题来了，我明明在浏览器里输入 http://192.168.1.100:11434 能正常看到Ollama的API文档页面，说明服务是好的，网络也是通的。为什么偏偏在Dify容器内部就“连接被拒”了呢？这背后，其实是一场关于网络边界和访问权限的“暗战”。今天，我就把自己踩过的坑和最终的解决方案，掰开揉碎了讲给你听，让你不仅能解决这个问题，更能理解背后的原理，以后遇到类似的容器网络问题都能从容应对。

简单来说，这个场景的核心矛盾在于：Dify运行在一个Docker容器构成的隔离网络环境里，而Ollama服务可能运行在宿主机的本地网络、另一个容器，甚至另一台物理机器上。Dify容器内的Python程序（使用urllib3库）试图向外发起HTTP连接，但目标地址对容器而言可能不可达，或者目标服务本身拒绝了这个连接请求。我们接下来的所有操作，都将围绕“如何让这两个身处不同网络域的服务顺利握手”而展开。

2. 庖丁解牛：深入理解“Connection Refused”背后的网络迷局

看到“Connection refused”（连接被拒绝）这个错误，我们首先要建立一个清晰的排查思路。这不仅仅是“网络不通”四个字能概括的，它可能发生在网络通信链条的多个环节。我们可以把一次HTTP请求想象成一次快递送货：Dify容器是发货方，Ollama服务是收货方。

首先，检查“收货方”是否在家（服务是否运行）。 这是最基本的一步。在运行Ollama的机器上，执行 ollama serve 命令来启动服务，或者用 systemctl status ollama 查看服务状态。更直接的方法是使用 curl 命令测试：curl http://localhost:11434/api/tags。如果能在Ollama本机成功获取到模型列表，那至少证明Ollama服务进程本身是健康的，正在监听端口。

其次，理解“发货地址”的视角差异（容器网络命名空间）。 这是最容易让人困惑的地方。当你在Dify容器内部尝试连接 192.168.1.100:11434 时，这个IP地址是从容器网络的视角去解析的。Docker容器默认使用自己的网络命名空间，它可能并不直接识别宿主机的物理IP。对于容器来说，宿主机有一个特殊的别名：host.docker.internal（在macOS和Windows的Docker Desktop中自动支持）。在Linux环境下，更常见的做法是使用宿主机的网桥IP（如 172.17.0.1）或者直接将容器网络模式设置为 host。所以，你需要在Dify容器内部，用 ping 或 curl 测试你配置的地址是否真的可达。进入Dify容器执行命令是诊断的关键：docker exec -it your-dify-container-name /bin/bash，然后在容器内尝试 curl http://你配置的Ollama地址:11434/api/tags。

最后，确认“收货方”是否愿意接收这个快递（服务监听配置）。 这是本次问题的核心症结，也是原始文章里重点提到的。Ollama服务默认的监听行为非常“内向”。它默认绑定在 127.0.0.1 这个回环地址上。这意味着，只有运行Ollama的机器本机上的程序才能访问它。来自其他任何IP地址的请求，包括同一台宿主机上但不同Docker容器的请求，都会被无情地拒绝，从而产生“Connection refused”错误。这就好比你的Ollama服务只开通了“内部员工通道”，外部访客（Dify容器）自然被保安拦在了门外。因此，我们必须修改Ollama的配置，让它监听在更广泛的网络接口上，比如 0.0.0.0，表示监听所有可用的网络接口，接受来自任何地址的连接。

3. 实战破解：三招搞定Ollama服务配置

理解了问题根源，解决方案就清晰了。我们需要让Ollama服务“打开大门”，接受来自Dify容器的连接。这里提供三种不同层次的配置方法，你可以根据你的部署方式选择。

3.1 方法一：临时启动，指定监听地址（最快验证）

如果你只是想快速测试，或者以临时方式运行Ollama，可以在启动命令中直接指定监听的主机和端口。这不需要修改任何配置文件，关闭进程后设置即失效。

打开终端，使用以下命令启动Ollama：

OLLAMA_HOST=0.0.0.0:11434 OLLAMA_ORIGINS=* ollama serve

让我解释一下这两个环境变量：

• OLLAMA_HOST=0.0.0.0:11434：这是关键。0.0.0.0 是一个特殊的IP地址，表示“所有IPv4地址”。设置这个，Ollama就会监听机器上所有网络接口（网卡）的11434端口。这样，无论是本机回环地址127.0.0.1，还是你的内网IP192.168.1.100，甚至是Docker容器的虚拟IP，发来的请求都能被Ollama接收到。
• OLLAMA_ORIGINS=*：这个是为了处理跨域资源共享（CORS）问题。当Dify的前端页面（通常运行在浏览器里）直接尝试调用Ollama的API时，浏览器会执行CORS检查。设置为星号*表示允许任何来源的网页发起请求，简化配置。在生产环境中，出于安全考虑，建议设置为具体的Dify前端地址。

启动后，你可以在另一台机器或同一个宿主机的Dify容器里，用 curl http://<宿主机IP>:11434/api/tags 测试，应该能成功获取响应。

3.2 方法二：修改系统服务文件（推荐用于长期部署）

如果你是通过系统级服务（比如使用 systemd）来管理Ollama的（例如通过官方安装脚本安装），那么修改服务配置文件是最一劳永逸的方法。这也是原始文章中给出的解决方案。

1. 编辑Ollama的systemd服务文件：

   sudo vim /etc/systemd/system/ollama.service
   

   或者使用你喜欢的其他编辑器，如 nano。

2. 找到 [Service] 部分，在里面添加或修改 Environment 行。通常这个文件里已经有一些配置，我们重点关注以下两行：

   [Service]
   # ... 其他现有配置 ...
   Environment="OLLAMA_HOST=0.0.0.0:11434"
   Environment="OLLAMA_ORIGINS=*"
   

   重要安全提示：将服务暴露在 0.0.0.0 并允许所有跨域请求（*）存在安全风险，意味着你内网中任何设备都能访问你的模型服务。仅在可信的网络环境（如家庭内网、安全的开发环境）中这样操作。如果处于公网或不可信网络，务必配置防火墙规则，或使用更精细的CORS设置（如 OLLAMA_ORIGINS=http://你的dify前端域名:端口）。

3. 保存文件后，需要重新加载systemd配置并重启Ollama服务：

   sudo systemctl daemon-reload
   sudo systemctl restart ollama
   

4. 检查服务状态和监听端口：

   sudo systemctl status ollama
   sudo netstat -tlnp | grep 11434
   

   执行 netstat 命令后，你应该能看到类似下面的输出，其中 0.0.0.0:11434 就表示服务正在所有接口上监听：

   tcp6       0      0 :::11434                :::*                    LISTEN      12345/ollama
   

3.3 方法三：通过环境变量配置文件

有些安装方式或启动脚本会读取特定的环境变量配置文件。你可以创建一个配置文件，例如在Ollama的安装目录或用户目录下创建 .env 文件，或者直接在你的启动脚本（如 docker-compose.yml）中定义。

例如，在Docker Compose中部署Ollama时，可以这样配置：

version: '3.8'
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_ORIGINS=*
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

volumes:
  ollama_data:

这种方式同样清晰地将配置固化下来，适合容器化部署的场景。

4. 打通任督二脉：Dify容器网络的进阶配置

解决了Ollama的“收听”问题，我们还需要确保Dify容器能够“喊话”到正确的位置。有时候，即使Ollama监听在 0.0.0.0，Dify容器仍然可能因为网络路由问题无法连接。这就需要我们对Docker容器的网络模式有更深入的了解。

4.1 理解Docker的网络驱动

Docker提供了几种不同的网络驱动，它们决定了容器如何与外界通信：

• bridge（网桥）：默认模式。Docker会创建一个虚拟网桥（通常叫 docker0），并为每个容器分配一个虚拟网卡和IP。容器之间可以通过IP通信，容器访问外网通过NAT。宿主机访问容器用容器IP，容器访问宿主机用宿主机的网桥IP（通常是172.17.0.1）。
• host（主机）：容器直接使用宿主机的网络命名空间，共享宿主机的IP和端口。此时容器内访问 localhost 就是宿主机本身。在这种模式下，如果Ollama运行在宿主机，Dify容器配置 http://localhost:11434 就能直接访问。
• none：禁用网络。

对于我们的场景，如果Ollama运行在宿主机，Dify运行在bridge模式容器里，那么Dify容器内需要配置的Ollama地址应该是宿主机的IP，或者Docker网桥的IP。

4.2 配置Dify连接地址的几种姿势

1. 使用宿主机特殊域名（推荐，最方便）：在Docker Desktop for Mac/Windows 和 新版本的Docker for Linux 中，支持在容器内通过 host.docker.internal 这个主机名解析到宿主机的内部IP。这样，在Dify的模型配置中，你就可以直接填写 http://host.docker.internal:11434。这是最直观、跨平台兼容性较好的方式。

2. 使用宿主机物理IP：在Dify容器中配置你宿主机的内网IP，如 http://192.168.1.100:11434。但要注意，如果宿主机IP是DHCP动态获取的，重启后可能会变，导致配置失效。

3. 使用Docker网桥网关IP：在宿主机上执行 ip addr show docker0，可以查看到网桥的IP，通常是 172.17.0.1。在Dify容器中配置 http://172.17.0.1:11434。这个地址相对稳定。

4. 将Dify容器网络模式改为host：在启动Dify容器时，加入 --network host 参数。这样Dify容器就直接使用宿主机网络，配置 http://localhost:11434 即可。但缺点是端口冲突风险高，且失去了容器网络的隔离性。

5. 使用自定义Docker网络：创建一个自定义的Docker网络，将Ollama容器和Dify容器都加入这个网络。这样它们可以通过容器名称直接通信，完全屏蔽底层IP。这是多容器应用的最佳实践。

   # 创建自定义网络
   docker network create my-ai-network
   
   # 启动Ollama容器并加入网络
   docker run -d --name ollama --network my-ai-network -p 11434:11434 -e OLLAMA_HOST=0.0.0.0:11434 ollama/ollama
   
   # 启动Dify容器并加入同一网络
   docker run -d --name dify --network my-ai-network -p 3000:3000 ...
   

   之后，在Dify配置中，就可以直接使用容器名作为主机名：http://ollama:11434。这种方式通信效率高，且配置最稳定。

4.3 在Dify容器内部进行诊断

当配置完成后，强烈建议进入Dify容器内部进行一次完整的连通性测试，这能帮你确认所有环节都已打通。

# 1. 进入Dify容器
docker exec -it dify-app /bin/bash

# 2. 尝试ping宿主机或Ollama容器（如果网络支持）
ping host.docker.internal
# 或
ping 172.17.0.1

# 3. 使用curl直接测试Ollama API
curl -v http://host.docker.internal:11434/api/tags
# 或者你配置的地址
curl -v http://ollama:11434/api/tags

如果 curl 命令能成功返回模型列表的JSON数据，那么恭喜你，网络通道已经畅通无阻。如果仍然失败，结合 -v 参数输出的详细过程，可以清晰地看到是在DNS解析、TCP连接还是HTTP协议层面出了问题。

5. 避坑指南与安全加固：让集成更稳定可靠

解决了基本连接问题，我们还需要考虑长期运行的稳定性和安全性。这里有几个我踩过坑后总结的经验。

防火墙与安全组：这是最容易被忽略的“隐形墙”。请确保运行Ollama的宿主机防火墙（如ufw、firewalld或Windows Defender防火墙）开放了11434端口的入站连接。对于云服务器，还需要检查安全组规则是否允许该端口的流量。

Dify中的模型配置细节：在Dify工作台的“模型供应商”配置Ollama时，除了基础地址，模型名称的填写也有讲究。Ollama的模型名称就是通过 ollama pull 拉取时的名字，比如 llama3.2:1b、qwen2.5:7b。在Dify的配置页面，通常只需要在“模型名称”字段填写这个名称即可，Dify会在请求时自动拼接到API路径上。确保这个模型名称与Ollama服务中已加载的模型完全一致，大小写敏感。

性能与超时设置：本地模型推理可能比较耗时。如果遇到超时错误，可能需要调整Dify调用模型时的超时参数。这通常在Dify的应用编排或Agent的推理设置中，可以找到“超时时间”的配置项，适当调大（例如设置为120秒或更长）。

安全警告再强调：将 OLLAMA_HOST 设置为 0.0.0.0 和 OLLAMA_ORIGINS 设置为 * 是为了快速解决问题，但在生产环境或暴露在公网的环境下是极其危险的。这相当于把你的大模型API毫无保护地暴露给了网络上的所有人。攻击者可以随意调用你的模型，消耗你的计算资源，甚至可能通过特制输入进行攻击。安全的做法是：

1. 使用反向代理：通过Nginx或Caddy等反向代理将Ollama服务保护起来，在代理层配置IP白名单、认证（如API Key）和速率限制。
2. 配置精确的CORS：将 OLLAMA_ORIGINS 设置为你的Dify前端实际部署的精确地址，例如 http://dify.your-domain.com:3000。
3. 利用网络隔离：如果Ollama和Dify都部署在容器内，使用自定义的Docker网络，并配合防火墙规则，只允许特定的容器IP访问11434端口。
4. 考虑使用VPN或私有网络：在团队协作时，确保这些服务只运行在内部的、受保护的网络环境中。

6. 举一反三：从Ollama到其他本地服务的通用思路

通过解决Dify连接Ollama的问题，我们实际上掌握了一套通用的“Docker容器访问宿主机或其他网络服务”的排查和解决方法。这个思路可以迁移到无数类似的场景中。

例如，你想让Dify连接本地部署的另一个AI服务，比如LocalAI、Text Generation WebUI，或者一个自研的模型API服务；又或者，你想让容器里的应用访问宿主机的数据库（MySQL、Redis）。问题的本质都是一样的：服务是否监听在正确的接口上？客户端是否使用了正确的地址进行连接？中间是否有防火墙阻拦？

通用的排查路径可以归纳为：

1. 服务端检查：确认目标服务进程是否运行，并检查其监听地址（netstat -tlnp | grep 端口号）。确保监听地址不是 127.0.0.1，而是 0.0.0.0 或特定的网络接口IP。
2. 客户端测试：从客户端所在环境（容器内）使用最基础的工具（telnet、nc、curl）测试到目标IP和端口的TCP连接是否通畅。telnet <目标IP> <端口号> 如果能建立连接，说明网络通路是好的。
3. 网络路径分析：理清客户端到服务端的网络路径。是容器到宿主机？容器到容器？还是跨物理机？针对不同路径，选用正确的寻址方式（host.docker.internal、网桥IP、容器名、物理IP）。
4. 环境配置：在服务端配置文件中，寻找类似 HOST、BIND_ADDRESS、LISTEN 这样的参数，将其设置为允许外部连接的值。
5. 安全加固：在解决问题后，立即根据实际网络环境，用防火墙、反向代理、认证等方式替换掉临时开放的全通配置。

回过头看最开始那个令人头疼的 HTTPConnectionPool 报错，它其实是一个友好的信号，精确地指出了问题发生在网络连接层面。比起一些模糊的内部错误，这种报错更能指引我们找到方向。搞定一次这样的问题，你对微服务、容器化部署中的网络通信理解就会加深一层。下次再遇到“Connection refused”，你就能气定神闲地打开终端，沿着服务监听、网络命名空间、防火墙这条线索一步步查下去，而不是对着浏览器发呆。技术上的很多坑，填平一次，就成了你脚下的路。