Dify 使用 OpenAI-API-compatible Provider 接入 DeepAI API 中转站、LiteLLM、Ollama 代理或自建网关时，最常见的误判之一是：在自己电脑上 curl http://localhost:4000/v1/chat/completions 能通，但 Dify 里保存模型凭据时却报 Connection refused。这类问题通常不是模型不可用，也不是 API Key 错，而是 Dify 运行环境访问不到你填写的 Base URL。
问题背景：LiteLLM 本机可用，Dify 校验失败
在 langgenius/dify Issue #4460 中，用户使用 Dify Cloud 的 OpenAI-API-compatible Provider 添加本地 LiteLLM，Base URL 填写 http://localhost:4000。LiteLLM 用 curl 和 Python 测试都正常，但 Dify 凭据校验报错：请求 /chat/completions 时无法连接 localhost:4000，错误为 connection refused。
这个 Issue 已关闭，但它留下了一个很有价值的排查原则：Base URL 是从 Dify 后端发起请求的地址，不是从浏览器或你本机 shell 发起请求的地址。如果使用 Dify Cloud，localhost 指的是云端服务自身；如果使用 Docker 部署，localhost 指的是容器内部；如果使用 Kubernetes，localhost 指的是 Pod 内部。它们都不是你的笔记本电脑。
为什么 DeepAI API 中转站能绕开这类网络问题？
DeepAI API 中转站的核心价值之一，就是提供一个稳定、公开、标准化的 OpenAI-compatible 入口，例如 https://api.deepai.wang/v1。相比把 Dify 指向本地 localhost 代理，公开 HTTPS Base URL 更适合云端 Dify、多人工作区、生产工作流和知识库任务。Dify 后端只需要能访问这个公网地址，就能完成凭据校验、模型调用、Embedding、工作流节点执行和日志追踪。
Dify 官方模型供应商文档也说明，模型提供商是在 workspace 级别配置的，管理员进入 Settings → Model Providers 添加凭据，Dify 会在保存前进行验证。文档还提到 OpenAI 配置可使用自定义 Base URL 来连接代理或 Azure OpenAI。这意味着 Base URL 的可达性必须站在 Dify 服务端视角检查，而不是只看本机终端。
三种部署场景的正确 Base URL 写法
1. Dify Cloud
Dify Cloud 无法访问你电脑上的 localhost 或家庭局域网地址。要接入 DeepAI API 中转站，建议直接填写公网 HTTPS 地址：
Provider: OpenAI-API-compatible API Endpoint URL: https://api.deepai.wang/v1 API Key: 使用你的 DeepAI 中转站 Key Model Name: 中转站支持的模型名
2. Docker 自托管 Dify
如果 Dify 和 LiteLLM 都在 Docker Compose 里，推荐把 LiteLLM 放进同一个 Docker network，并用服务名访问，例如 http://litellm:4000/v1。如果 LiteLLM 跑在宿主机，Windows/macOS Docker 可以尝试 http://host.docker.internal:4000/v1；Linux 则通常需要显式配置 host gateway 或直接使用宿主机内网 IP。
3. 生产环境或多人工作区
生产环境不建议依赖临时内网地址。更稳的做法是把模型网关暴露成 HTTPS 域名，或者直接使用 DeepAI API 中转站作为统一入口。这样 Dify、n8n、Cherry Studio、Claude Code、Codex CLI 等客户端都能复用同一套 Base URL、Key 管理、模型映射和调用日志。
排查步骤：从 Dify 后端视角测试
- 确认 Dify 是 Cloud、Docker、Kubernetes 还是裸机部署，不同部署下
localhost含义完全不同。 - 进入 Dify 后端容器或服务器，直接执行
curl Base_URL/chat/completions或curl Base_URL/models，不要只在个人电脑上测。 - 检查 Base URL 是否带
/v1。很多 OpenAI-compatible 网关要求 Base URL 到/v1，否则 Dify 拼接路径后会变成错误地址。 - 如果使用 DeepAI API 中转站，优先用
https://api.deepai.wang/v1做连通性测试，再配置模型名和 Key。 - 如果 Dify 校验失败，记录完整错误：是 DNS 解析失败、connection refused、timeout、401、404 还是 400。不同状态码对应的方向不同。
常见错误与处理方式
- Connection refused：目标主机可解析，但端口没有服务监听，或容器访问到的是自己的 localhost。
- Timeout：网络被防火墙、安全组、Docker network 或云服务出口策略拦截。
- 401 Unauthorized：Base URL 可达，重点检查 API Key、Authorization Header 和中转站账号额度。
- 404 Not Found：通常是
/v1路径拼接错误，或中转站没有实现 Dify 调用的接口。 - 400 Bad Request：请求已到达上游，重点看模型名、参数兼容性、tools、response_format、Embedding 维度等字段。
DeepAI API 中转站的配置建议
为了让 Dify 工作流稳定运行，建议在 DeepAI API 中转站侧准备三类信息：可公开访问的 Base URL、明确的模型名列表、以及调用日志。Dify 的聊天应用、Workflow、Knowledge Base、Embedding 和工具节点可能会使用不同模型能力，站长最好把聊天模型、Embedding 模型、图片模型分别写清楚，避免“聊天能用，知识库不可用”的二次排查。
推荐填写： API Endpoint URL: https://api.deepai.wang/v1 Chat Model: 选择中转站支持的对话模型 Embedding Model: 选择中转站支持的 embedding 模型 日志检查：记录 Dify 工作区、模型名、状态码、上游错误
SEO 与产品文档建议
搜索“Dify OpenAI-API-compatible localhost connection refused”“Dify LiteLLM localhost 连接失败”“Dify API 中转站 Base URL”“Dify DeepAI API 中转站教程”的用户，通常已经完成了本地模型或代理部署，只卡在 Dify 的服务端可达性上。DeepAI API 中转站的教程页可以把 Cloud、Docker、Kubernetes、生产 HTTPS 四种场景分开写，用户会更快找到自己的路径。
参考资料
总结
Dify 接入 DeepAI API 中转站或 LiteLLM 这类 OpenAI-compatible Provider 时，localhost connection refused 的根因多半不是模型坏了，而是 Dify 后端访问不到你填写的地址。把排查视角从“我本机 curl 能不能通”切换成“Dify 服务端能不能通”，再使用 https://api.deepai.wang/v1 这类稳定公网 Base URL，就能快速绕开本地网络、Docker 容器和云端隔离带来的连接失败。
