在成功部署 vLLM 和 Open WebUI 为两个独立的 Docker 容器后，你是否遇到了这样的困扰：浏览器可以正常访问 http://localhost:7860 的管理界面，但在尝试加载对话时却反复提示“连接后端失败”，或是在日志中发现令人头疼的 ConnectionRefusedError？这并非个例，而是 Docker 多容器部署场景中的一个典型挑战。
问题的核心非常明确：Open WebUI 容器无法定位到预期的 vLLM 服务。其根本原因在于，默认配置 OPENWEBUI_BASE_URL=http://localhost:8000 在容器化环境中指向的是 Open WebUI 自身，而非运行在隔壁容器中的 vLLM 服务。本文将系统性地解析并解决这一“容器间通信故障”，帮助您快速恢复服务。
一、修正 OPENWEBUI_BASE_URL 为 Docker 内部服务名
要实现 Open WebUI 容器与 vLLM 容器的通信，必须摒弃 localhost 这一本地回环地址。在 Docker 的架构中，容器间需通过服务名（Service Name）进行相互寻址，且前提是它们必须加入同一个 Docker 网络。
首先，请检查您的 docker-compose.yml 文件，确保 vLLM 服务已定义了一个清晰的服务名称，例如 vllm-server。
接着，定位到 Open WebUI 服务的环境变量配置区域，将 OPENWEBUI_BASE_URL 的值从 http://localhost:8000 修改为 http://vllm-server:8000。请注意，此处的 vllm-server 必须与 vLLM 服务的定义名称完全一致。
最后，请务必确认两个服务都声明使用了相同的网络（例如默认的 default 网络，或您自定义的 bridge 网络），并且均未设置 network_mode: host 模式。
二、验证 vLLM 容器是否监听 0.0.0.0 而非 127.0.0.1
仅修改地址是不够的。如果 vLLM 服务仅绑定在 127.0.0.1（本地回环接口）上，它将只接受来自其自身容器内部的请求，来自其他容器的连接尝试会被直接拒绝。因此，必须配置 vLLM 监听所有网络接口。
请检查 vLLM 的启动命令，确保其中包含了关键参数 --host 0.0.0.0（或其等效的配置项）。
若您使用 docker-compose.yml 进行管理，通常需要在 vLLM 服务的 command 字段末尾添加此参数。
修改并重启 vLLM 容器后，建议进行快速验证：首先进入 vLLM 容器内部，执行 curl -v http://localhost:8000/health，预期应返回 200 状态码。随后，从 Open WebUI 容器内部执行 curl -v http://vllm-server:8000/health，同样应返回 200。若此步骤失败，则表明网络配置或服务名解析仍存在问题。
三、显式暴露 vLLM API 端口并禁用宿主机端口映射干扰
此处存在一个常见误区。虽然容器间的通信不依赖于宿主机的端口映射，但如果您在 docker-compose.yml 中为 vLLM 配置了 ports: ["8000:8000"]，将容器端口映射到宿主机，有时可能引发意料之外的防火墙策略或 SELinux 限制，从而间接阻断容器间的直接通信。
一个更为稳妥的实践是，在 vLLM 服务的配置中，直接删除或注释掉 ports 配置项。容器间的访问应完全交由 Docker 网络层处理。
您可以保留 expose: ["8000"] 这一声明（其主要作用是文档化，说明该服务使用 8000 端口，实际通信不依赖于此）。
此外，请检查 Open WebUI 服务是否配置了依赖于 vLLM 的健康检查（例如使用 depends_on 配合 condition: service_healthy），以避免因 vLLM 启动较慢而导致 Open WebUI 启动失败或提前退出。
四、使用 curl 从 Open WebUI 容器内直连 vLLM 地址进行诊断
若问题依然存在，最直接的诊断方法是绕过所有应用层逻辑，直接测试底层网络连通性。
打开终端，执行 docker exec -it 命令进入 Open WebUI 容器内部。
随后，在容器内运行命令：curl -v http://vllm-server:8000/health。
观察输出：若返回 HTTP/1.1 200 OK，则恭喜您，网络和服务均畅通无阻，问题可能出在 Open WebUI 的应用层配置上。若报错 Failed to connect、Connection refused 或超时，则明确指向以下三种可能：服务名 DNS 解析失败、vLLM 服务未在运行，或 vLLM 未正确监听 0.0.0.0。
五、强制指定 Docker 自定义网络并验证 DNS 解析
如果上述所有步骤均已检查无误但问题依旧，可能是 Docker 默认的 bridge 网络存在残留配置或命名冲突。此时，创建一个专用的 Docker 网络是最为彻底的解决方案。
首先，创建一个新的网络：docker network create llama-net。
然后，在 docker-compose.yml 文件的最顶层（与 services 同级）声明此网络，并在 vLLM 与 Open WebUI 两个服务的配置中，均指定加入该网络。
最后，再次进入 Open WebUI 容器，执行 nslookup vllm-server。您应该能看到它成功解析到一个 Docker 内部的 IP 地址（例如 172.20.0.x），而非返回 127.0.0.11 或解析失败。这证明了容器内的 DNS 解析工作正常。
总而言之，解决此类问题的核心在于理解 Docker 容器网络的通信规则：使用服务名替代 localhost，确保服务监听所有网络接口，并保证相关容器处于同一网络。遵循这一思路进行逐步排查，问题通常都能迎刃而解。