n8n 正在从传统自动化平台变成 AI 工作流编排平台。很多用户会把 OpenAI Node、AI Agent、HTTP Request、数据库和消息通知串成一条自动化链路，再通过 DeepAI API 中转站 统一调用不同模型。问题是：在 n8n 里，“凭据测试通过”并不一定代表节点运行时一定能成功。
GitHub Issue 背景：测试成功，运行时 404
n8n GitHub 仓库中有一个已关闭且标记为 completed 的 Issue：用户在 Docker 自托管 n8n 中配置 OpenAI Node v2，使用自定义 Base URL 接入 OpenAI-compatible 服务。凭据测试显示成功，但实际执行 “Message a model” 节点时返回 The resource you are requesting could not be found 和 404 page not found。
更有意思的是，同样的凭据在 AI Agent → OpenAI Chat Model 中可用，回退到旧版本 OpenAI Node 也可用。这说明问题不一定出在 API Key，也不一定是模型不可用，而可能是 OpenAI Node v2 的运行时请求路径、节点实现或兼容层行为与凭据测试阶段不同。
DeepAI API 中转站的 n8n 推荐配置
在 n8n 里接入 DeepAI API 中转站时，如果节点要求填写 OpenAI-compatible Base URL，推荐使用：
https://api.deepai.wang/v1
API Key 填写 DeepAI 后台生成的密钥，不要额外手动加 Bearer。模型 ID 则要填写 DeepAI 当前实际支持的模型名。不要把完整的 /chat/completions 路径写到 Base URL 里，因为 n8n 节点会根据操作类型自行拼接请求路径。
为什么凭据测试成功仍然会 404
凭据测试通常只验证“这个 Key 和这个基础地址是否能连上”，但节点运行时会多做几件事：选择具体资源、选择操作、拼接接口路径、发送模型 ID、附带消息体参数。只要其中一个环节和上游 OpenAI-compatible 服务不一致，就可能出现运行时 404。
- 测试接口和运行接口不同：凭据测试可能访问模型列表，运行时访问聊天或 Responses 路径。
- 节点版本行为不同：OpenAI Node v1、v2、AI Agent 内部调用链可能不是同一套代码。
- 模型 ID 不存在：凭据能通过，但具体模型在中转站或上游没有启用。
- 路径被重复或改写：Base URL 末尾、代理、Docker 网络或网关规则都可能影响最终请求。
推荐排查顺序
- 先在 n8n 凭据里确认 Base URL 是
https://api.deepai.wang/v1，不是完整聊天接口。 - 选择一个确认可用的模型 ID，用最短提示词测试 OpenAI Node。
- 如果 OpenAI Node v2 运行时报 404，改用 AI Agent → OpenAI Chat Model 做同样测试，判断是不是节点版本差异。
- 自托管 Docker 场景下进入容器内部，用 curl 测试 DeepAI API 中转站地址是否可达。
- 查看 n8n 执行日志和 DeepAI API 中转站后台日志，确认请求是否到达、路径是什么、模型 ID 是什么。
Docker 自托管时重点看日志
Issue 中用户提供了 n8n Docker 日志，可以看到节点执行时在 request helper 里返回 404，并且错误来自 “Message a model” 节点。自托管用户遇到类似问题时，不要只看前端弹窗，应该同步看容器日志：
docker logs -f n8n # 或 docker compose logs -f n8n
日志里最有价值的信息包括：节点名称、HTTP 状态码、请求方法、报错栈、模型 ID、执行 ID。如果 DeepAI API 中转站后台没有出现对应请求，说明请求可能还没到达中转站；如果后台有请求但上游返回 404，则继续检查模型 ID 和路径规则。
临时绕过方案：先用 AI Agent 节点
在该 Issue 的讨论里，有用户提到同样凭据在 AI Agent → OpenAI Chat Model 中可以工作。对于生产工作流来说，这给了一个务实的绕过思路：如果 OpenAI Node v2 对自定义 Base URL 的某个运行路径不稳定，可以先用 AI Agent 或旧版本节点完成调用，再等待 n8n 升级修复。
这并不是最终方案，但在自动化任务不能停的情况下很有用。尤其是邮件总结、表格处理、客服分流、内容生成等工作流，只要能稳定拿到模型回复，节点选择可以先服务于可靠性。
404、401、429 要分开处理
n8n 接入 API 中转站时，最怕把所有错误都归因于“Key 不对”。实际排查应按错误码分流：
- 404：优先看 Base URL、路径拼接、模型 ID、节点版本。
- 401：优先看 API Key 是否有效、是否多填 Bearer、是否复制了空格。
- 429：优先看额度、并发、重试策略和工作流循环。
- 5xx：结合 DeepAI API 中转站日志判断是上游模型、网络还是网关瞬时错误。
DeepAI API 中转站对 n8n 的价值
n8n 的优势是把多个系统串起来，DeepAI API 中转站的价值则是把多个模型入口统一起来。两者结合后，可以把不同工作流都指向同一个 OpenAI-compatible Base URL，并在后台统一看调用日志、成本、失败率和模型使用情况。对团队来说，这比在每个 n8n 工作流里分散维护多个供应商 Key 更容易治理。
建议给 n8n 单独生成一组 DeepAI API Key，并按用途拆分：测试环境一个 Key，生产环境一个 Key，高并发工作流一个 Key。这样出现 404、429 或成本异常时，后台日志更容易定位到具体工作流。
参考资料
- n8n GitHub 仓库
- n8n Issue #21651：OpenAI Node v2 自定义 Base URL 运行时 404
- DeepAI API 中转站教程导航
- OpenAI Compatible API 教程合集
总结
n8n 接入 DeepAI API 中转站时，凭据测试通过只是第一步。真正要确认的是运行时节点是否用正确路径、正确模型 ID 和正确参数发起请求。遇到 OpenAI Node v2 运行 404，先检查 Base URL 是否只到 /v1，再对比 AI Agent 节点、Docker 日志和 DeepAI 后台调用记录。按这个顺序排查，能更快判断问题到底在 n8n 节点、API 中转站配置，还是上游模型兼容性。
