Dify 接 DeepAI 报错怎么查？401、404、429、timeout 对照表

有些 Dify 报错看起来很吓人，其实不用一上来就重装 Dify，也不用马上怀疑 DeepAI 接口坏了。

真正高效的排查方式是：先看报错属于哪一类。

• 401 多半是鉴权问题；
• 404 多半是地址或模型路径问题；
• 429 多半是限速、并发或额度问题；
• timeout 多半是网络、节点耗时或工作流太重；
• model not found 多半是模型 ID 或权限问题；
• Internal Server Error 不一定是模型问题，也可能是 Dify 插件或自托管环境问题。

这篇不是完整配置教程，而是一张排错手册。你可以先按报错关键词跳到对应部分查。

本文默认 DeepAI API 地址为：

https://api.deepai.wang/v1

如果你还没确认 DeepAI API 本身能不能通，先用 curl 测一次：

从 curl 到 Python：如何确认 DeepAI OpenAI 兼容接口真的能用

先看这张总表

下面逐个拆。

401：先别动模型，先查 Key

Dify 里出现 401、Authentication failed、Incorrect credentials、Credentials validation failed，第一优先级不是模型名，而是鉴权。

你要先确认三件事：

• Dify 里填的是 DeepAI 控制台创建的 Key；
• Base URL 是 https://api.deepai.wang/v1；
• Key 没有多复制空格、换行或中文符号。

常见错误是把别的平台 Key 填到 DeepAI 地址里。

比如：

Base URL: https://api.deepai.wang/v1
API Key: 另一个平台的 sk-xxxx

这看起来像是“有 Key”，但服务端不认识它。

如果你怀疑 Key 有问题，别在 Dify 里猜，直接用 curl 测：

curl https://api.deepai.wang/v1/models \
  -H "Authorization: Bearer YOUR_DEEPAI_API_KEY"

curl 也 401，说明 Key 或权限本身有问题。

curl 正常，Dify 401，再回头查 Dify 里是否填错了凭据、是否用了旧凭据、是否当前模型绑定了另一个 Key。

404：优先查 Base URL，不要急着换模型

Dify 接 OpenAI Compatible API 时，404 很多时候不是“模型不存在”，而是路径写错。

常见错误写法：

https://api.deepai.wang/v1/chat/completions

这个是完整接口路径，不一定适合填进 Dify 的 Base URL / API Endpoint URL。

更常见的填写方式是：

https://api.deepai.wang/v1

如果你把完整 endpoint 填进去，Dify 可能会继续拼接路径，最后变成类似：

https://api.deepai.wang/v1/chat/completions/chat/completions

或者：

https://api.deepai.wang/v1/v1/chat/completions

这类路径当然会出问题。

看到 404，先问自己：

• 我填的是 Base URL，还是完整接口路径？
• 有没有重复 /v1？
• 有没有把 /chat/completions 填进不该填的位置？
• Dify 这个字段到底叫 Endpoint URL 还是 Base URL？

如果你还分不清这些字段，可以先看这篇基础说明：

OpenAI Compatible API 是什么？Base URL、API Key、Model ID 与 DeepAI 接入教程

429：别连续点重试，先看是谁在烧请求

429 一般和频率、并发、额度、限流有关。

在 Dify 里，429 比普通聊天客户端更容易出现，因为一次应用运行可能不止调用一次模型。

比如一个 RAG 工作流可能会有：

• 意图识别一次；
• Embedding 检索一次；
• Rerank 一次；
• LLM 生成一次；
• 失败后自动重试一次；
• 多个用户同时访问。

你以为点了一次“运行”，实际上后面可能打了好几个请求。

429 出现后，最不应该做的是疯狂点重试。这样只会让限速更严重。

应该先查：

• DeepAI 控制台有没有请求日志；
• 429 来自哪个模型；
• 是聊天模型、Embedding，还是 Rerank；
• Dify 里是不是多个应用共用同一个 DeepAI Key；
• 有没有 Cherry Studio、Cline、Open WebUI 也在用同一个 Key；
• Workflow 是否有循环、重试或过多 LLM 节点。

更稳的做法：

• 给 Dify 单独创建 DeepAI Key；
• 开发、测试、生产分开 Key；
• 先把 Workflow 简化到一个 LLM 节点；
• 降低并发测试；
• 确认是哪一个节点触发高频请求。

Dify 的请求消耗通常不是“一个问题一句回答”这么简单。429 要从调用链上查。

model not found：不要凭感觉写模型名

model not found 很直接：Dify 请求的模型，DeepAI 当前不可用，或者你的 Key 没权限。

最常见原因是模型名写成了简称。

错误例子：

gpt4
claude
sonnet
deepseek

模型 ID 不是品牌名，也不是你自己起的备注名。它必须和 DeepAI 控制台里的可用模型 ID 对上。

排查顺序：

1. 到 DeepAI 控制台复制模型 ID； 2. 确认 Dify 里模型类型选对了； 3. 确认这个模型绑定的是当前 DeepAI Key； 4. 用 curl 单独测这个模型； 5. 再回 Dify 测。

curl 示例：

curl https://api.deepai.wang/v1/chat/completions \
  -H "Authorization: Bearer YOUR_DEEPAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "messages": [
      {"role": "user", "content": "测试模型是否存在"}
    ]
  }'

如果 curl 报 model not found，那就不是 Dify 的问题。

timeout / 504：先拆工作流，不要先怪接口

timeout、504、请求超时、中途断开，通常有三类原因：

一类是网络问题

比如自托管 Dify 容器访问外部 API 不稳定，或者代理影响了容器内部通信。

这种情况要查：

• Dify 容器能否访问 https://api.deepai.wang/v1；
• 服务器 DNS 是否正常；
• 代理是否只对宿主机生效，容器里不生效；
• 是否有防火墙或出口限制。

一类是模型响应慢

长上下文、复杂提示词、大输出都会让响应时间变长。

先用短 prompt 测：

请回复 ok

短 prompt 正常，长 prompt 超时，说明问题可能在上下文长度或输出长度。

一类是 Dify 工作流太重

如果一个 Workflow 里有多个 LLM 节点、知识库检索、Rerank、HTTP 工具、条件分支，任何一个慢都会拖慢整体。

处理方式不是马上换 Key，而是先拆：

• 只保留一个 LLM 节点测试；
• 关闭 Rerank 测试；
• 减少知识库召回片段；
• 降低最大输出长度；
• 分开测试每个节点。

如果最小 LLM 节点稳定，完整工作流超时，问题就在工作流设计，不在 DeepAI Key。

Internal Server Error：可能是 Dify 自己的插件或部署问题

Internal Server Error 很容易误导人。

它不一定是 DeepAI 返回的错误。有时候是 Dify 自己在模型供应商插件、plugin daemon、Docker 网络或凭据校验阶段出错。

网上有不少自托管 Dify 的案例，OpenAI API compatible 插件添加模型时报 Internal server error，日志里可能出现：

no available node, plugin not found

这种情况和 API Key 未必有关系。

你要查的是：

• Dify 插件是否安装成功；
• plugin daemon 是否正常运行；
• Docker 容器之间网络是否正常；
• 自托管环境是否能访问插件市场；
• 离线安装插件时依赖是否完整；
• Dify 版本和插件版本是否兼容。

如果你用的是 Dify 云端版，插件层问题通常少一些。

如果你是 Docker 自托管版，遇到 Internal Server Error，别只盯着 DeepAI 控制台。先看 Dify 的 api、worker、plugin daemon 日志。

知识库没结果：不一定是聊天模型的问题

Dify 里还有一种“软错误”：没有明显报错，但知识库问答就是不准，或者完全答不出文档内容。

这时很多人会换聊天模型。

但知识库问题常常不在聊天模型，而在 Embedding 和检索。

你要看：

• 文档有没有成功索引；
• Embedding 模型有没有配置；
• 知识库使用的是不是正确的 Embedding；
• 查询时有没有召回片段；
• 召回片段是否相关；
• Rerank 是否需要开启；
• Prompt 有没有要求模型基于资料回答。

如果 Embedding 阶段没做好，后面聊天模型再强，也是在缺资料的情况下回答。

什么时候去 DeepAI 控制台，什么时候看 Dify 日志

很多排错卡住，是因为不知道该看哪边。

可以按这个规则分：

如果 DeepAI 控制台完全没有请求记录，说明请求可能没到 DeepAI。

那就回头查 Dify 的 Base URL、网络、插件、容器和代理。

如果 DeepAI 控制台有请求记录，就根据返回状态码继续排查。

最小排错路径

如果你现在已经报错，又不想看太多解释，就按这个顺序走：

1. 用 curl 测 DeepAI Key
2. 用 curl 测具体模型 ID
3. 确认 Dify Base URL 是 https://api.deepai.wang/v1
4. 确认 Dify 模型名称和 DeepAI 控制台一致
5. 建一个只有一个 LLM 节点的最小应用
6. 再逐个加知识库、Embedding、Rerank、Workflow 节点
7. 出现 429 就查 DeepAI 日志和 Dify 节点调用次数
8. 出现 Internal Server Error 就查 Dify plugin daemon / Docker 日志

排错最忌讳的是一次改五个地方。

一次只改一个变量，才能知道到底是哪一步修好了。

相关教程

如果你是第一次配置 Dify + DeepAI，看这篇更适合：

Dify 配置 DeepAI API 中转站教程：OpenAI Compatible 模型从添加到测试

如果你已经接入了，但工作流不稳定，看这篇：

Dify 接入 DeepAI 后工作流跑不稳？别只检查 API Key

如果你想先确认 DeepAI API 本身是否可用，看这篇：

从 curl 到 Python：如何确认 DeepAI OpenAI 兼容接口真的能用

最后提醒

Dify 报错不要全都归因于“Key 错了”。

401 可能是 Key。

404 可能是 URL。

429 可能是工作流打太多请求。

timeout 可能是节点太重。

Internal Server Error 可能是插件或 Docker 环境。

知识库没结果，可能是 Embedding 和检索。

先按错误类型分流，再查 DeepAI 控制台和 Dify 日志。这样排错会比在模型供应商页面反复保存快得多。