上周末想用 Dify 搭一个内部知识库问答机器人，结果光是配 OpenAI 的 API 就折腾了大半天。官方文档写得太简略，实际跑起来各种报错——403、超时、模型找不到，一个比一个离谱。后来把坑全趟平了，顺手整理成这篇，给同样在折腾的人省点时间。
先说结论
| 配置方式 | 适合谁 | 难度 | 稳定性 |
|---|---|---|---|
| 官方 OpenAI 直连 | 有海外服务器 | ⭐⭐ | 取决于网络 |
| 聚合 API（兼容 OpenAI 协议） | 国内环境、想切换多模型 | ⭐ | 稳 |
| Azure OpenAI | 企业用户、合规要求 | ⭐⭐⭐ | 很稳但贵 |
国内服务器部署 Dify，大概率会卡在网络问题上。我最后的方案是用兼容 OpenAI 协议的聚合接口，改一下 Base URL 就通了，下面一步步说。
为什么要折腾这个
Dify 本身挺好用的，拖拖拽拽能搭 Workflow，做 RAG 知识库问答也方便。但核心能力依赖底层模型，得先把模型接进去才能玩。
我的场景是：公司内网服务器（国内），接 GPT-5 做文档问答，偶尔切 Claude Opus 4.6 做代码审查。听起来不复杂对吧？实操起来坑比想象的多。
方案一：直连 OpenAI 官方 API
最直接的方式，前提是你的 Dify 部署环境能访问 api.openai.com。
步骤
- 登录 Dify 后台，点左下角头像 → 设置 → 模型供应商
- 找到 OpenAI，点击「设置」
- 填入你的 API Key（
sk-开头那个） - Base URL 留空（默认就是官方地址）
- 点「保存」
保存后 Dify 会自动拉取你的 Key 能访问的模型列表。正常的话，模型下拉框里能看到 gpt-4o、gpt-4o-mini 这些。
我遇到的问题
在国内环境直连 OpenAI 几乎没成功过。具体报错：
Error: Connection to api.openai.com timed out after 30s
还有一种更隐蔽的情况——连接倒是通了，但响应巨慢，一个简单的 chat completion 要 8-15 秒，做知识库问答根本没法用。
有海外服务器或稳定网络的话，方案一完全够用。国内机器建议直接看方案二。
方案二：用聚合 API 接入（推荐国内用户）
思路很简单：找一个兼容 OpenAI API 协议的中转/聚合服务，把 Base URL 换掉。Dify 本身支持自定义 Base URL，对这种方式支持得很好。
我现在用的是 ofox.ai，一个 AI 模型聚合平台，一个 API Key 可以调用 GPT-5、Claude Opus 4.6、Gemini 3、GLM-5、DeepSeek V3 等 50+ 模型，国内直连，支持支付宝付款。选它的原因也简单——兼容 OpenAI 协议，Dify 这边配置改动最小。
步骤
- 去 ofox.ai 注册账号，拿到 API Key
- 打开 Dify 后台 → 设置 → 模型供应商
- 两种配法，看你的需求：
配法 A：在 OpenAI 供应商里改 Base URL
找到 OpenAI，点设置：
- API Key：填 ofox.ai 给你的 Key
- API Base：填
https://api.ofox.ai/v1 - 保存
简单粗暴，Dify 会把它当成 OpenAI 的模型来用。
配法 B：用 OpenAI-API-compatible 供应商（更灵活）
Dify 在模型供应商列表里有个 OpenAI-API-compatible 选项，专门为这种场景设计的：
- 模型名称：手动填，比如
gpt-4o、claude-sonnet-4-20250514、glm-5 - API Key：ofox 的 Key
- API Endpoint URL：
https://api.ofox.ai/v1 - 模型类型：选 Chat
- Context Window：根据模型填，GPT-5 填 128000，Claude Opus 4.6 填 200000
推荐配法 B，一个供应商能配多个模型，模型名称自己填，想接什么就接什么。
实际效果
配完之后做了个简单测试，在 Dify 里建了一个 Chatbot 应用，挂上公司的产品文档做知识库：
# 用来验证 API 是否通的测试脚本
# 这个跑通了，Dify 里的配置基本没问题
from openai import OpenAI
client = OpenAI(
api_key="your-ofox-key",
base_url="https://api.ofox.ai/v1"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "你是一个技术文档助手"},
{"role": "user", "content": "解释一下 RAG 的工作原理"}
],
stream=True
)
for chunk in response:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="")
首 Token 延迟大概 300-500ms，流式输出流畅。知识库检索 + 生成的完整响应在 2-4 秒，能接受。
方案三：Azure OpenAI
企业用户、合规要求严的场景可以考虑。
Dify 内置了 Azure OpenAI 供应商，配置需要填：
- API Key：Azure 控制台拿
- API Base：类似
https://your-resource.openai.azure.com - API Version：
2024-12-01-preview（用最新的） - Deployment Name：你在 Azure 里创建的部署名
Azure 的配置是三种方案里最麻烦的——要先在控制台创建资源、部署模型、配 endpoint，光这个流程就能劝退一波人。每个模型还得单独部署，不像聚合接口一个 Key 全搞定。价格也不便宜。胜在合规、SLA 有保障。
踩坑记录
坑 1：模型名称写错导致 404
用 OpenAI-API-compatible 配置时，模型名称是手动填的。我一开始填了 gpt-4-turbo，一直报 404。后来才发现聚合接口那边的模型 ID 是 gpt-4o，名字得对上。
去你用的 API 服务文档里查一下支持的模型列表和准确的模型 ID。
坑 2：Streaming 不生效
配好之后发现 Dify 的对话界面是等全部生成完才一次性显示，没有流式效果。检查了一圈发现是配置时没勾选「支持 Stream」。
在模型供应商的高级配置里，确认 Stream 选项是开启的。
坑 3：Embedding 模型忘了配
知识库建好了，上传文档的时候报错：
Embedding model not configured
RAG 需要两个模型——Chat 模型生成回答，Embedding 模型做文档向量化。我只配了 Chat，忘了 Embedding。
回到模型供应商，再加一个 Embedding 类型的模型。用 OpenAI-API-compatible 配置的话，模型名填 text-embedding-3-small 或 text-embedding-3-large，模型类型选 Text Embedding。
坑 4：Context Window 设小了导致截断
我把 Context Window 随手填成了 4096，结果知识库检索的上下文加上用户问题一超过这个数就报错。GPT-5 明明支持 128k，是我自己在配置里限制了。
按照模型的实际能力填，别省。
坑 5：Docker 部署的 DNS 问题
这个折磨我最久。Dify 用 Docker Compose 部署，容器内 DNS 解析有时候会抽风，同一个配置有时候能用有时候超时。
在 docker-compose.yml 里给 api 和 worker 服务加上 DNS 配置：
services:
api:
dns:
- 8.8.8.8
- 114.114.114.114
# ... 其他配置
worker:
dns:
- 8.8.8.8
- 114.114.114.114
docker compose up -d 重启，DNS 问题基本就没再出现了。
补充：一次接入多个模型
Dify 支持同时配置多个模型供应商，同一个应用的 Workflow 里，不同节点可以用不同模型。
我现在的配置：
- 知识库问答用 GPT-5（理解力强、稳定）
- 代码相关任务用 Claude Opus 4.6（代码生成确实强）
- 简单分类/提取用 GLM-5（够用，便宜）
全部走同一个聚合接口，一个 Key，在 Dify 里配三个不同的模型名就行。
小结
配置本身不难，核心就三步：选供应商 → 填 Key 和 URL → 配模型参数。大部分人卡住都是卡在网络和模型名称这种细节上。
国内部署 Dify 的话，别跟直连死磕，直接用兼容 OpenAI 协议的聚合接口，改个 Base URL 就能跑。省下来的时间去折腾 Workflow 和 Prompt 才是正事。
有问题评论区聊，看到会回。
