n8n 对接自定义 API 时 Base URL 已配置在凭据中却仍返回 404 的排查思路

n8n 的 OpenAI 凭据里有 Base URL 这一栏，从 n8n@1.73.0 起就有，只是官方文档到今天也没写。 填上 OpenAI 节点、AI Agent、模型下拉全都能直接指向你自己的网关，不用退回 HTTP Request 节点手写请求体。

真正会咬人的不是这一栏找不找得到，是它填对了、凭据测试也是绿的，工作流照样 404。下面那一段是本文的重点，我在一个真实实例上把两种情况各跑了一遍。

本文所有运行结果来自 2026-09-01 在 Docker 里起的 n8n 2.36.9 实例，模型端点指向一个会记录请求路径的本地服务，因此每一次请求打在哪个 URL 上都是原始记录，不是推断。

n8n 到底能不能填自定义 Base URL？

能，而且这一栏已经存在快两年了。

一手证据有四条，从产品往回追到代码：

PR 的描述写得很直白，它做的是搬家不是新增：

Removes the Base URL parameters from the OpenAI nodes and uses the new Base URL parameters in the OpenAI credentials.

也就是说这个能力更早就存在于节点选项里，1.73.0 只是把它挪到了凭据里，并且做了版本兼容让老节点继续读节点上的那份。

我从跑着的实例里把凭据定义原样导出，字段清单是这样：

顺带一个连社区都很少提的：这套凭据还能加一对自定义请求头。需要给网关带 X-Title、路由标签或者自家鉴权头的，不用为此绕去 HTTP Request 节点。

为什么满世界都说 n8n 不能填？

因为文档确实没写，而且不是漏了一句，是整栏都没有。

我不想凭一两个页面下结论，所以把 n8n 的全文档索引拉下来搜过一遍：

凭据文档页列出的要求，到今天仍然只有两项：

An API Key

An Organization ID: Required if you belong to multiple organizations; otherwise, leave this blank.

有意思的是，n8n 并不是不会写这一栏。同一个文档仓库里，Ollama、Milvus、Chroma、NVIDIA 的凭据页都老老实实写了 Base URL，NVIDIA 那页甚至直接把它描述成「the OpenAI-spec compatible endpoint to call」，还提醒你路径要带 /v1。所以这不是产品理念问题，是这一页漏了。

漏在哪一步，PR 自己留了痕迹。#12175 的评审清单里，「PR title and summary are descriptive」打了勾，而下面这一项没打：

• Docs updated or follow-up ticket created.

这个没打勾的复选框，就是后面将近两年混乱的全部来源。

这篇文章的初稿就是栽在这里的。 我把上面这份检索当成了结论，写成「n8n 不支持自定义端点，得换 HTTP Request 节点」。检索本身没问题——1,339、2 次、0 次都复现得了——错的是从「文档没有」推出「产品没有」。判断一个功能不存在，光查文档不够，还得查 issue tracker、release notes 和社区，因为文档滞后于产品是常态——n8n 这次从 2024-12-17 合并那天算到今天是 623 天，快两年了，凭据文档一个字没动。

对你的实际影响是：遇到「n8n 不能接第三方端点」的说法，先去凭据弹窗里看一眼再信，包括本文发布之后可能又变过的部分。

凭据测试是绿的，工作流为什么还是 404？

因为这两件事打的根本不是同一个端点。

凭据测试在源码里就一行，它只发一次 GET {Base URL}/models：

原因是 OpenAI Chat Model 子节点里有个叫 Use Responses API 的开关，源码里写着 default: true，且只在 @version >= 1.3 时出现。换句话说，你新拖出来的节点，默认走的是 Responses 端点。

而文档在这一点上写反了。 节点文档写的是：

Toggle to Use Responses API if you want the model to generate output using the Responses API. Otherwise, the OpenAI Chat Model node will default to using the Chat Completions API.

按这句话，不动开关就该走 Chat Completions。实测不是。我用同一套凭据、同一个工作流跑了两遍，只改这一个开关，服务端收到的请求是：

而凭据测试在两种情况下都是绿的——它打的是 /v1/models，那个端点一直都在。

最难受的是报错本身会误导人。执行记录里那条错误除了 404，还挂着一个 LangChain 的排障链接，归类是 MODEL_NOT_FOUND：

Troubleshooting URL: https://docs.langchain.com/oss/javascript/langchain/errors/MODEL_NOT_FOUND/

模型没找到——于是你会去改模型名、去核对模型是否上架、去怀疑网关目录。而问题跟模型无关，是那个端点整个不存在。 这也是为什么这个坑值得单独写一节：它的表征把人引向了完全错误的方向。

处理办法很简单，先关掉 Use Responses API 让工作流跑通，再回头判断你的模型支不支持 Responses。

有多少模型支持 chat/completions 却不支持 responses？

拿我们自己的目录做个量： 部分聚合网关（如 OpenRouter 或 ）对外暴露的是标准 /chat/completions 端点，而非 OpenAI 新版 /responses 端点，这意味着在 n8n 中选择 OpenAI 节点时，若后端不实现该路由，请求将直接返回 404。

支持聊天端点的 111 条里，有 39 条不吃 Responses。 这个比例放在别的网关上只会更高，Responses 是相对新的端点，实现进度参差。

所以这个开关的正确用法是：先去模型页看端点那一栏，确认支持再打开；只是想跑通，就让它关着。Responses 能换来的是一次请求里跑多轮内置工具、以及用 conversation_id 做持久会话，代价是端点兼容面窄得多。

还有一条同类的：文档写明内置工具（Web Search、File Search、Code Interpreter）只在 OpenAI Chat Model 配 AI Agent 节点时可用，配 Basic LLM Chain 就没有。把 Agent 换成 Chain 图省事，会静默丢掉一批能力。

那个绿勾到底验证了什么？

验证了你的 Base URL 能连通，不一定验证了你的 key 是对的。

n8n 的测试确实会看状态码——我拿一个瞎编的 key 去测 api.openai.com，返回的是 Error: Unauthorized，拦住了。但它拦不拦得住，取决于你的网关保不保护模型列表：

这一条对我们自己不利，但你该在接入前知道： ` 是公开端点，不带任何鉴权头也返回 200 和完整模型目录。好处是模型下拉在配 key 之前就能用；代价是 n8n 那个绿勾在我们这里完全不能用来验证 API Key。你把 key 打错一个字符，凭据页照样绿，然后在第一次真实调用时才报 401。

所以那个绿勾的正确读法是：它说明地址填对了，不说明这条路能跑通。 真要确认，跑一次工作流。

同一个 Base URL，n8n 有几个地方在读？

三个地方，各读各的——这是理解前面所有现象的底层原因。 在 n8n 中，Base URL 可能同时存在于凭据配置、节点参数以及环境变量三处，当使用兼容 OpenAI 协议的第三方端点（如 OpenRouter 或 ）时，需逐一核查各层级的读取优先级，否则实际请求可能仍指向默认的 api.openai.com。

中间那条最反直觉，它对你填的 URL 形状是有假设的：默认值 https://api.openai.com/v1 结尾有一个版本段，切分逻辑正是按这个形状写的。

社区里流传「Base URL 结尾不要带斜杠」，我在 2.36.9 上专门测了：没能复现。 带斜杠时凭据测试仍然打到 /v1/models 并运行时仍然打到 /v1/chat/completions 并成功，没有出现双斜杠。这条建议在当前版本上更像是历史遗留，不是必须遵守的规则——但它的由来是真的，那套字符串切分确实对 URL 形状敏感。稳妥的做法是照着默认值的形状填：协议 + 域名 + 一个版本段，比如 `

子节点里的表达式为什么只认第一条？

这条跟端点无关，但它是 n8n 里最花钱的一个坑，而且文档专门写了一节。

普通节点会对每一条输入分别求值：五个 name 进去，{ { $json.name }} 依次解析成五个不同的值。但子节点不是这样，OpenAI Chat Model 自己的 Common Issues 页原文是：

In sub-nodes, the expression always resolves to the first item.

而 OpenAI Chat Model 正是子节点。所以你在循环里给它传动态提示词时，实际发出去的是同一个提示词跑五遍——结果全是重复的，账单一次不少。这类错误不会报错，只会让你在月底看着用量发呆。

这也是定时工作流的通病：聊天应用是人点一次跑一次，写臃肿了用的人当场就嫌慢；定时触发没有这个反馈回路，跑错了也按点跑。所以两件事比选哪个模型更值得先做——先算单次触发的 token 量再乘触发频率，以及把节点选项里的 Maximum Number of Tokens 和 Timeout 填上别留空。Max Retries 同理，重试是要付钱的，失败调用在多数供应商那里照样计费，这一项的口径我们在AI 视频 API 一秒多少钱里单独算过。

什么时候还是该用 HTTP Request 节点？

当你要的东西超出了 OpenAI 协议本身的时候。

凭据里能填 Base URL 之后，HTTP Request 从主路降级成兜底，但它没有失去价值。《Custom API actions for existing nodes》那页写着，内置节点没覆盖的操作「You can work around this by making a custom API call using the HTTP Request node」，并且可以在 Authentication 里选 Predefined Credential Type 复用已建好的凭据，不用另做一套认证。

三条路现在是这样分工的：

Gateway credits 那条值得单说一句，顺带也是本文主题的又一个例子：同一件事，两个文档页写得不一样。OpenAI Chat Model 节点页说的是在 n8n Cloud 上可以「use the OpenAI Chat Model node with Gateway credits instead of your own OpenAI API key」，选上 Use Gateway credits 就能「run the node without an OpenAI account」；凭据页则写成「skip setting up OpenAI credentials by selecting Use Gateway credits in the credential field of nodes that support it」。这跟 ComfyUI 的合作节点是同一种设计——平台替你垫付调用，代价是账单落在平台的积分体系里，不落在你自己的模型账户上。方便程度和可控程度永远是一组反向的东西。

同一件事在别的工具上的配法：Dify 有现成的 OpenAI-API-compatible 供应商可选，步骤在Dify 接入 API 完全指南；Coze 侧写在Coze（扣子）怎么配置第三方 API；自建网关和商业网关怎么选在企业级 LLM Gateway 选型。

这套配置该怎么落地？

• 凭据里填 Base URL，形状照着默认值来：` Add Custom Header。

• 别信那个绿勾。它只证明地址通，在模型列表公开的网关上连 key 对不对都不验。

• 新建节点先把 Use Responses API 关掉。它默认开着，而运行时打的 /responses 是兼容面最窄的端点；等工作流跑通了，再对着模型页决定要不要打开。

• 看到 MODEL_NOT_FOUND 先查端点，别先查模型名。这个归类会把你带偏。

• 循环里给子节点传动态提示词之前，先读一遍那条「只认第一条」。它不报错，只多花钱。

反过来说清楚：如果你的工作流只调 OpenAI 官方、也不打算换模型，本文这套对你没有价值，默认配置就是最舒服的一条路，别为了统一而统一。

n8n 文档页支持在 URL 后加 .md 取 Markdown 原文，上面每一条文档引文都可以这样自行复核。运行结果来自 2026-09-01 的 n8n 2.36.9，版本行为会变，落地前以你自己实例上跑出来的那一次为准。

参考信息来源

• n8n PR #12175：Move OpenAI Base URL option to credentials

• n8n issue #14431：官方回复「This is already possible」

• n8n 源码：OpenAiApi.credentials.ts

• n8n 源码：LmChatOpenAi.node.ts

• n8n：OpenAI credentials 文档

• n8n：OpenAI Chat Model 节点参数

• n8n：OpenAI Chat Model Common Issues（子节点表达式那条）

• n8n：NVIDIA 凭据文档，同一仓库里写了 Base URL 的那页

• n8n：Custom API actions for existing nodes

• 模型与端点清单 llms-full.txt

参考来源

• ofox 文档：模型目录 — https://docs.ofox.io/zh/develop/models