1. Docker 跑起 n8n 之后模型通道怎么接才不别扭n8n 是一个开源的工作流自动化工具你可以把它理解成「自己部署的 Zapier」用节点拖拽的方式把 HTTP 请求、数据库、消息队列、大模型串成一条流水线。它适合谁适合不想把业务数据交给第三方 SaaS、又需要定时任务和 AI 能力结合的自托管玩家。用 Docker 部署 n8n 本身不难一条docker compose up -d就能跑起来真正让人卡住的是后面这一步工作流里要调用大模型Key 往哪放、Base URL 怎么填、容器里能不能通。我见过太多人把 Key 硬编码在 HTTP Request 节点的 Header 里结果工作流一导出分享Key 就跟着泄露了也有人把地址填成localhost在宿主机 curl 能通进了容器就报连接拒绝。这篇就聚焦 Docker 部署 n8n 之后接入 TaoToken 统一 Key/API 通道的配置环节给你一份可复制的settings.json骨架、环境变量注入方式以及一次能亲眼看到结果的连通性验证。先说清楚 TaoToken 在这里扮演什么角色。它是一个统一的模型 API 通道官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你拿到一个 Key就能通过同一套 Base URL 调用不同厂商的模型不用为每个模型单独维护一套鉴权和地址。对 n8n 这种要在多个节点里反复调模型的场景统一通道能省掉大量重复配置。整篇的路线是这样先确认你的 n8n 容器状态正常然后拿到 TaoToken 的 Key接着用环境变量把 Key 和 Base URL 注入容器再写一份settings.json骨架作为节点默认配置的参考最后发一次真实请求验证链路。全程命令都可以直接复制遇到报错我在第 5 节列了对照表。需要提醒一点n8n 的模型调用最终都是走 HTTP所以「连通性」这件事拆开就是三层——容器能不能出网、DNS 能不能解析、TLS 握手和鉴权能不能过。后面排障也是按这三层来定位不要一上来就怀疑 Key 错了。2. 接入前的准备TaoToken Key 与 n8n 容器状态确认在动配置文件之前先把两件事确认掉否则后面报错你分不清是环境问题还是配置问题。第一件事是 n8n 容器确实在跑。进入你放docker-compose.yml的目录执行docker compose ps正常输出里 n8n 和 postgres 两个服务的 STATE 都应该是Up。如果 n8n 显示Restarting先看日志docker compose logs -f n8n常见的是数据库连不上导致反复重启这种要先解决 postgres 的健康问题跟模型接入无关。确认 Web 界面能打开默认http://你的IP:5678登录进去能看到工作流列表这一步过了再往下。第二件事是拿到 TaoToken 的 Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 API Key。创建时给它起个能认出来的名字比如n8n-selfhost方便以后按用途吊销。Key 一般只在创建时完整显示一次复制下来先存到安全的地方别直接贴进聊天窗口。拿到 Key 之后建议先在宿主机上做一次最小验证确认这个 Key 和网络本身没问题再去折腾容器。用 curl 发一个最简请求curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer 你的Key \ | head -c 500如果返回一段包含模型列表的 JSON说明 Key 有效、宿主机出网正常。如果这里就失败那问题不在 n8n先解决宿主机到 API 的网络。这一步的价值在于把变量隔离出来——宿主机通了容器不通那一定是容器网络或环境变量的问题。关于模型 ID你可以在 https://taotoken.net/doc 查到当前支持的模型标识也可以直接调上面的/v1/models看返回。记下你要用的那个 Model ID后面配置里要填。不同模型的 ID 拼写不一样别凭记忆写复制为准。还有一个容易忽略的点n8n 容器默认以node用户运行工作目录是/home/node/.n8n。你挂载的./n8n_data对应容器内这个路径。如果你打算把配置文件放进容器要确保文件权限对node用户可读否则会出现「文件存在但读不到」的怪现象。用docker compose exec n8n ls -la /home/node/.n8n可以确认。3. 可复制配置环境变量注入与 settings.json 骨架这一节是核心给你两种注入方式选一种即可。推荐环境变量方式因为 Key 不进代码库、不进工作流导出文件最干净。3.1 用环境变量注入 Key 和 Base URL修改你的docker-compose.yml在 n8n 服务的environment段追加三项services: n8n: image: n8nio/n8n:latest ports: - 5678:5678 environment: - N8N_HOST你的服务器域名或IP - N8N_PORT5678 - N8N_PROTOCOLhttp - WEBHOOK_URLhttp://你的服务器域名或IP:5678/ - GENERIC_TIMEZONEAsia/Shanghai - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDn8n - N8N_BASIC_AUTH_ACTIVEtrue - N8N_BASIC_AUTH_USERadmin - N8N_BASIC_AUTH_PASSWORD你设置的密码 - TAOTOKEN_API_KEY你的TaoTokenKey - TAOTOKEN_BASE_URLhttps://taotoken.net/api - TAOTOKEN_MODEL_ID你的模型ID volumes: - ./n8n_data:/home/node/.n8n depends_on: - postgres restart: always注意TAOTOKEN_BASE_URL填的是https://taotoken.net/api不要自己加/v1具体路径在节点里拼。改完执行docker compose up -dn8n 会重建容器并读取新环境变量。用下面命令确认变量真的进去了docker compose exec n8n printenv | grep TAOTOKEN应该能看到三行输出。如果看不到说明 compose 文件没保存或没重建回到上一步。3.2 settings.json 骨架n8n 本身没有官方的settings.json来存模型凭证凭证是存在数据库里的。但很多团队习惯用一份 JSON 骨架来统一节点默认参数避免每个人手填。下面这份骨架你可以放在项目目录里作为配置参考字段名和你在 HTTP Request 节点里填的保持一致{ taotoken: { baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelId: 你的模型ID, defaultHeaders: { Content-Type: application/json, Authorization: Bearer ${TAOTOKEN_API_KEY} }, chatCompletionsPath: /v1/chat/completions, modelsPath: /v1/models, timeoutMs: 60000, retry: { maxAttempts: 3, backoffMs: 1000 } } }这份骨架的用法是在 n8n 的 HTTP Request 节点里URL 填{{ $env.TAOTOKEN_BASE_URL }}{{ $json.taotoken.chatCompletionsPath }}这种形式Header 里的 Authorization 用Bearer {{ $env.TAOTOKEN_API_KEY }}。这样 Key 永远从环境变量取节点配置里不出现明文。如果你更习惯用 n8n 的凭证系统可以在 Credentials 里建一个Header Auth类型Name 填AuthorizationValue 填Bearer 你的Key然后在节点里引用这个凭证。两种方式都行环境变量的好处是换 Key 只改一处。关于超时和重试timeoutMs给 60000 是留足大模型生成的时间别用默认的短超时否则长回答会被截断报错。重试三次、退避 1 秒能扛住偶发的网络抖动。3.3 容器网络的一个关键点如果你的 n8n 容器和别的服务在同一个自定义网络里容器内访问外网走的是 Docker 的默认网关一般没问题。但如果你之前给容器配过network_mode: host或者自定义了 DNS要确认容器能解析taotoken.net。验证方法docker compose exec n8n nslookup taotoken.net能返回 IP 就说明 DNS 正常。返回不了检查宿主机的/etc/resolv.conf和 Docker 的 daemon 配置。4. 验证请求从容器内发一次真实调用配置写完了不算数得看到真实返回。这一节给你一个在容器内直接跑的验证命令绕开 n8n 界面先把链路打通。进入 n8n 容器docker compose exec n8n sh容器里基于 Alpine可能没有 curl先装一个如果已有就跳过apk add --no-cache curl然后发一次 chat completions 请求curl -sS $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL_ID, messages: [ {role: user, content: 只回复两个字通了} ], max_tokens: 16 }如果一切正常你会看到类似这样的返回{ id: chatcmpl-xxxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: 通了 }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 2, total_tokens: 14 } }看到choices[0].message.content里有内容说明容器出网、DNS、TLS、鉴权、模型路由全部打通。这一步过了n8n 工作流里调用就是水到渠成的事。接着回到 n8n 界面新建一个工作流拖一个 HTTP Request 节点配置如下MethodPOSTURL{{ $env.TAOTOKEN_BASE_URL }}/v1/chat/completionsAuthenticationNone鉴权走 HeaderHeadersAuthorization: Bearer {{ $env.TAOTOKEN_API_KEY }}Content-Type: application/jsonBody Content TypeJSONBody填和上面 curl 一样的 JSONmodel 用{{ $env.TAOTOKEN_MODEL_ID }}点 Execute Node右侧输出面板出现和 curl 一样的 JSON就说明工作流层面也通了。这时候你可以把这个节点存成模板后面所有需要调模型的地方直接复用。如果你用的是 n8n 的 AI 节点比如 AI Agent 或 Basic LLM Chain在节点里选 OpenAI 兼容模式Base URL 填https://taotoken.net/api/v1API Key 填你的 KeyModel 填模型 ID。注意这里的 Base URL 带了/v1因为 AI 节点内部会自己拼/chat/completions别重复。5. 常见报错对照401、连接失败、choices 读取异常链路跑通之前报错是常态。这一节按真实遇到的错误信息给你对照排查每条都给出定位动作。401 Unauthorized / invalid api key这是最常见的一类。先确认 Key 有没有多余空格——从网页复制时经常带上换行或空格。在容器里执行echo $TAOTOKEN_API_KEY | wc -c字符数应该和 Key 实际长度一致多出来就是有空白。其次确认 Header 格式是Bearer加 Key中间一个空格Bearer首字母大写。如果 Key 是在别的环境创建的确认它没被吊销。还有一种情况是 Key 有效但没权限访问你指定的模型换一个模型 ID 试试。local proxy failed / connection refused / dial tcp timeout这类是网络层。先在容器里nslookup taotoken.net确认 DNS再curl -v https://taotoken.net/api/v1/models看卡在哪一步。如果 DNS 解析失败检查 Docker 的 DNS 配置如果 TCP 连不上检查宿主机防火墙出站规则如果 TLS 握手失败检查系统时间是否准确时间偏差过大会导致证书校验失败。注意不要在容器里配任何来路不明的网络转发工具直接用宿主机的正常出网即可。reading choices / Cannot read properties of undefined这个报错通常出现在 n8n 的 AI 节点里意思是它期望返回里有choices字段但没拿到。原因一般是 Base URL 填错比如填成了https://taotoken.net/api而 AI 节点又自己拼了一次路径导致请求打到了不存在的端点返回的是错误 JSON。解决方法是把 AI 节点的 Base URL 改成https://taotoken.net/api/v1或者用 HTTP Request 节点自己控制完整路径。另外确认返回体没有被中间层改写。OAuth / token exchange failed如果你在 n8n 里配的是某个需要 OAuth 的模型节点而不是 OpenAI 兼容模式可能会走到 OAuth 流程。TaoToken 走的是 API Key 鉴权不需要 OAuth。遇到这个报错说明节点类型选错了换成 HTTP Request 或 OpenAI 兼容的 LLM 节点用 Key 鉴权。模型返回空内容 / finish_reason 是 length这不是报错但结果不对。检查max_tokens是不是设得太小16 个 token 只够回几个字。生产环境按需调大比如 1024 或 2048。另外确认 messages 格式正确role 和 content 都不能少。容器重启后配置丢失如果你把 Key 写在容器内的文件里而不是环境变量容器重建后文件就没了。这就是为什么推荐环境变量方式——配置在docker-compose.yml里重建容器自动带上。如果你确实需要文件方式确保它挂载在./n8n_data这种持久化卷里。排查的通用思路是先分层再定位。网络层用 nslookup 和 curl -v鉴权层看 401 和 Header业务层看返回 JSON 结构。不要一上来就改代码先把请求本身跑通。6. 把通道固定下来长期跑工作流的几个习惯链路验证通过只是开始真正让自托管 n8n 稳定跑下去靠的是一些不起眼的习惯。第一Key 只放环境变量不进工作流导出文件。n8n 的工作流可以导出成 JSON 分享如果 Key 写在节点里导出即泄露。用{{ $env.TAOTOKEN_API_KEY }}引用导出文件里只有变量名安全得多。团队协作时每个人在自己的.env或 compose 文件里填自己的 Key工作流本身可以共用。第二给模型调用节点统一加超时和重试。大模型偶发慢响应是常态节点默认超时往往偏短。在 HTTP Request 节点的 Options 里把 Timeout 设成 60000 毫秒开启 Retry On Fail重试 3 次。这样一次网络抖动不会让整个工作流失败。第三把常用的模型调用封装成子工作流。比如「调用模型生成文本」做成一个子工作流输入是 prompt输出是文本主工作流通过 Execute Workflow 节点调用。这样换模型、改 Base URL 只改一处所有调用方自动生效。第四定期检查 Key 的使用情况。在 https://taotoken.net/console 可以看到调用记录和用量发现异常调用及时吊销重建。给不同的工作流用不同的 Key出问题能快速定位是哪个流程。第五容器日志别关。docker compose logs -f n8n在排查问题时是唯一的信息来源。建议把日志级别设成 info出问题时临时调到 debug。日志里能看到每个节点的请求和响应比在界面上猜快得多。如果你后面要跑更复杂的 Agent 工作流或者需要长期稳定的编码类任务可以了解一下 Coding Plan它在调用配额和并发上有更适合持续任务的安排。入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。日常调试模型返回用模型对话页面更直观https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 遇到路径或参数不确定时以文档为准。最后说一个我踩过的坑有次工作流在测试环境跑得好好的上到另一台机器就 401。查了半天发现是那台机器的 compose 文件里环境变量名拼错了一个字母TAOTOKEN_API_KEY写成了TAOTOKEN_APIKEY容器里取到空值请求自然被拒。所以每次换环境先用printenv | grep TAOTOKEN确认变量名和值都对能省掉大量无谓排查。配置这件事慢就是快。
Docker 安装 n8n 后配 TaoToken：settings.json 骨架与连通性验证
1. Docker 跑起 n8n 之后模型通道怎么接才不别扭n8n 是一个开源的工作流自动化工具你可以把它理解成「自己部署的 Zapier」用节点拖拽的方式把 HTTP 请求、数据库、消息队列、大模型串成一条流水线。它适合谁适合不想把业务数据交给第三方 SaaS、又需要定时任务和 AI 能力结合的自托管玩家。用 Docker 部署 n8n 本身不难一条docker compose up -d就能跑起来真正让人卡住的是后面这一步工作流里要调用大模型Key 往哪放、Base URL 怎么填、容器里能不能通。我见过太多人把 Key 硬编码在 HTTP Request 节点的 Header 里结果工作流一导出分享Key 就跟着泄露了也有人把地址填成localhost在宿主机 curl 能通进了容器就报连接拒绝。这篇就聚焦 Docker 部署 n8n 之后接入 TaoToken 统一 Key/API 通道的配置环节给你一份可复制的settings.json骨架、环境变量注入方式以及一次能亲眼看到结果的连通性验证。先说清楚 TaoToken 在这里扮演什么角色。它是一个统一的模型 API 通道官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你拿到一个 Key就能通过同一套 Base URL 调用不同厂商的模型不用为每个模型单独维护一套鉴权和地址。对 n8n 这种要在多个节点里反复调模型的场景统一通道能省掉大量重复配置。整篇的路线是这样先确认你的 n8n 容器状态正常然后拿到 TaoToken 的 Key接着用环境变量把 Key 和 Base URL 注入容器再写一份settings.json骨架作为节点默认配置的参考最后发一次真实请求验证链路。全程命令都可以直接复制遇到报错我在第 5 节列了对照表。需要提醒一点n8n 的模型调用最终都是走 HTTP所以「连通性」这件事拆开就是三层——容器能不能出网、DNS 能不能解析、TLS 握手和鉴权能不能过。后面排障也是按这三层来定位不要一上来就怀疑 Key 错了。2. 接入前的准备TaoToken Key 与 n8n 容器状态确认在动配置文件之前先把两件事确认掉否则后面报错你分不清是环境问题还是配置问题。第一件事是 n8n 容器确实在跑。进入你放docker-compose.yml的目录执行docker compose ps正常输出里 n8n 和 postgres 两个服务的 STATE 都应该是Up。如果 n8n 显示Restarting先看日志docker compose logs -f n8n常见的是数据库连不上导致反复重启这种要先解决 postgres 的健康问题跟模型接入无关。确认 Web 界面能打开默认http://你的IP:5678登录进去能看到工作流列表这一步过了再往下。第二件事是拿到 TaoToken 的 Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 API Key。创建时给它起个能认出来的名字比如n8n-selfhost方便以后按用途吊销。Key 一般只在创建时完整显示一次复制下来先存到安全的地方别直接贴进聊天窗口。拿到 Key 之后建议先在宿主机上做一次最小验证确认这个 Key 和网络本身没问题再去折腾容器。用 curl 发一个最简请求curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer 你的Key \ | head -c 500如果返回一段包含模型列表的 JSON说明 Key 有效、宿主机出网正常。如果这里就失败那问题不在 n8n先解决宿主机到 API 的网络。这一步的价值在于把变量隔离出来——宿主机通了容器不通那一定是容器网络或环境变量的问题。关于模型 ID你可以在 https://taotoken.net/doc 查到当前支持的模型标识也可以直接调上面的/v1/models看返回。记下你要用的那个 Model ID后面配置里要填。不同模型的 ID 拼写不一样别凭记忆写复制为准。还有一个容易忽略的点n8n 容器默认以node用户运行工作目录是/home/node/.n8n。你挂载的./n8n_data对应容器内这个路径。如果你打算把配置文件放进容器要确保文件权限对node用户可读否则会出现「文件存在但读不到」的怪现象。用docker compose exec n8n ls -la /home/node/.n8n可以确认。3. 可复制配置环境变量注入与 settings.json 骨架这一节是核心给你两种注入方式选一种即可。推荐环境变量方式因为 Key 不进代码库、不进工作流导出文件最干净。3.1 用环境变量注入 Key 和 Base URL修改你的docker-compose.yml在 n8n 服务的environment段追加三项services: n8n: image: n8nio/n8n:latest ports: - 5678:5678 environment: - N8N_HOST你的服务器域名或IP - N8N_PORT5678 - N8N_PROTOCOLhttp - WEBHOOK_URLhttp://你的服务器域名或IP:5678/ - GENERIC_TIMEZONEAsia/Shanghai - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_PORT5432 - DB_POSTGRESDB_DATABASEn8n - DB_POSTGRESDB_USERn8n - DB_POSTGRESDB_PASSWORDn8n - N8N_BASIC_AUTH_ACTIVEtrue - N8N_BASIC_AUTH_USERadmin - N8N_BASIC_AUTH_PASSWORD你设置的密码 - TAOTOKEN_API_KEY你的TaoTokenKey - TAOTOKEN_BASE_URLhttps://taotoken.net/api - TAOTOKEN_MODEL_ID你的模型ID volumes: - ./n8n_data:/home/node/.n8n depends_on: - postgres restart: always注意TAOTOKEN_BASE_URL填的是https://taotoken.net/api不要自己加/v1具体路径在节点里拼。改完执行docker compose up -dn8n 会重建容器并读取新环境变量。用下面命令确认变量真的进去了docker compose exec n8n printenv | grep TAOTOKEN应该能看到三行输出。如果看不到说明 compose 文件没保存或没重建回到上一步。3.2 settings.json 骨架n8n 本身没有官方的settings.json来存模型凭证凭证是存在数据库里的。但很多团队习惯用一份 JSON 骨架来统一节点默认参数避免每个人手填。下面这份骨架你可以放在项目目录里作为配置参考字段名和你在 HTTP Request 节点里填的保持一致{ taotoken: { baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelId: 你的模型ID, defaultHeaders: { Content-Type: application/json, Authorization: Bearer ${TAOTOKEN_API_KEY} }, chatCompletionsPath: /v1/chat/completions, modelsPath: /v1/models, timeoutMs: 60000, retry: { maxAttempts: 3, backoffMs: 1000 } } }这份骨架的用法是在 n8n 的 HTTP Request 节点里URL 填{{ $env.TAOTOKEN_BASE_URL }}{{ $json.taotoken.chatCompletionsPath }}这种形式Header 里的 Authorization 用Bearer {{ $env.TAOTOKEN_API_KEY }}。这样 Key 永远从环境变量取节点配置里不出现明文。如果你更习惯用 n8n 的凭证系统可以在 Credentials 里建一个Header Auth类型Name 填AuthorizationValue 填Bearer 你的Key然后在节点里引用这个凭证。两种方式都行环境变量的好处是换 Key 只改一处。关于超时和重试timeoutMs给 60000 是留足大模型生成的时间别用默认的短超时否则长回答会被截断报错。重试三次、退避 1 秒能扛住偶发的网络抖动。3.3 容器网络的一个关键点如果你的 n8n 容器和别的服务在同一个自定义网络里容器内访问外网走的是 Docker 的默认网关一般没问题。但如果你之前给容器配过network_mode: host或者自定义了 DNS要确认容器能解析taotoken.net。验证方法docker compose exec n8n nslookup taotoken.net能返回 IP 就说明 DNS 正常。返回不了检查宿主机的/etc/resolv.conf和 Docker 的 daemon 配置。4. 验证请求从容器内发一次真实调用配置写完了不算数得看到真实返回。这一节给你一个在容器内直接跑的验证命令绕开 n8n 界面先把链路打通。进入 n8n 容器docker compose exec n8n sh容器里基于 Alpine可能没有 curl先装一个如果已有就跳过apk add --no-cache curl然后发一次 chat completions 请求curl -sS $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL_ID, messages: [ {role: user, content: 只回复两个字通了} ], max_tokens: 16 }如果一切正常你会看到类似这样的返回{ id: chatcmpl-xxxx, object: chat.completion, choices: [ { index: 0, message: { role: assistant, content: 通了 }, finish_reason: stop } ], usage: { prompt_tokens: 12, completion_tokens: 2, total_tokens: 14 } }看到choices[0].message.content里有内容说明容器出网、DNS、TLS、鉴权、模型路由全部打通。这一步过了n8n 工作流里调用就是水到渠成的事。接着回到 n8n 界面新建一个工作流拖一个 HTTP Request 节点配置如下MethodPOSTURL{{ $env.TAOTOKEN_BASE_URL }}/v1/chat/completionsAuthenticationNone鉴权走 HeaderHeadersAuthorization: Bearer {{ $env.TAOTOKEN_API_KEY }}Content-Type: application/jsonBody Content TypeJSONBody填和上面 curl 一样的 JSONmodel 用{{ $env.TAOTOKEN_MODEL_ID }}点 Execute Node右侧输出面板出现和 curl 一样的 JSON就说明工作流层面也通了。这时候你可以把这个节点存成模板后面所有需要调模型的地方直接复用。如果你用的是 n8n 的 AI 节点比如 AI Agent 或 Basic LLM Chain在节点里选 OpenAI 兼容模式Base URL 填https://taotoken.net/api/v1API Key 填你的 KeyModel 填模型 ID。注意这里的 Base URL 带了/v1因为 AI 节点内部会自己拼/chat/completions别重复。5. 常见报错对照401、连接失败、choices 读取异常链路跑通之前报错是常态。这一节按真实遇到的错误信息给你对照排查每条都给出定位动作。401 Unauthorized / invalid api key这是最常见的一类。先确认 Key 有没有多余空格——从网页复制时经常带上换行或空格。在容器里执行echo $TAOTOKEN_API_KEY | wc -c字符数应该和 Key 实际长度一致多出来就是有空白。其次确认 Header 格式是Bearer加 Key中间一个空格Bearer首字母大写。如果 Key 是在别的环境创建的确认它没被吊销。还有一种情况是 Key 有效但没权限访问你指定的模型换一个模型 ID 试试。local proxy failed / connection refused / dial tcp timeout这类是网络层。先在容器里nslookup taotoken.net确认 DNS再curl -v https://taotoken.net/api/v1/models看卡在哪一步。如果 DNS 解析失败检查 Docker 的 DNS 配置如果 TCP 连不上检查宿主机防火墙出站规则如果 TLS 握手失败检查系统时间是否准确时间偏差过大会导致证书校验失败。注意不要在容器里配任何来路不明的网络转发工具直接用宿主机的正常出网即可。reading choices / Cannot read properties of undefined这个报错通常出现在 n8n 的 AI 节点里意思是它期望返回里有choices字段但没拿到。原因一般是 Base URL 填错比如填成了https://taotoken.net/api而 AI 节点又自己拼了一次路径导致请求打到了不存在的端点返回的是错误 JSON。解决方法是把 AI 节点的 Base URL 改成https://taotoken.net/api/v1或者用 HTTP Request 节点自己控制完整路径。另外确认返回体没有被中间层改写。OAuth / token exchange failed如果你在 n8n 里配的是某个需要 OAuth 的模型节点而不是 OpenAI 兼容模式可能会走到 OAuth 流程。TaoToken 走的是 API Key 鉴权不需要 OAuth。遇到这个报错说明节点类型选错了换成 HTTP Request 或 OpenAI 兼容的 LLM 节点用 Key 鉴权。模型返回空内容 / finish_reason 是 length这不是报错但结果不对。检查max_tokens是不是设得太小16 个 token 只够回几个字。生产环境按需调大比如 1024 或 2048。另外确认 messages 格式正确role 和 content 都不能少。容器重启后配置丢失如果你把 Key 写在容器内的文件里而不是环境变量容器重建后文件就没了。这就是为什么推荐环境变量方式——配置在docker-compose.yml里重建容器自动带上。如果你确实需要文件方式确保它挂载在./n8n_data这种持久化卷里。排查的通用思路是先分层再定位。网络层用 nslookup 和 curl -v鉴权层看 401 和 Header业务层看返回 JSON 结构。不要一上来就改代码先把请求本身跑通。6. 把通道固定下来长期跑工作流的几个习惯链路验证通过只是开始真正让自托管 n8n 稳定跑下去靠的是一些不起眼的习惯。第一Key 只放环境变量不进工作流导出文件。n8n 的工作流可以导出成 JSON 分享如果 Key 写在节点里导出即泄露。用{{ $env.TAOTOKEN_API_KEY }}引用导出文件里只有变量名安全得多。团队协作时每个人在自己的.env或 compose 文件里填自己的 Key工作流本身可以共用。第二给模型调用节点统一加超时和重试。大模型偶发慢响应是常态节点默认超时往往偏短。在 HTTP Request 节点的 Options 里把 Timeout 设成 60000 毫秒开启 Retry On Fail重试 3 次。这样一次网络抖动不会让整个工作流失败。第三把常用的模型调用封装成子工作流。比如「调用模型生成文本」做成一个子工作流输入是 prompt输出是文本主工作流通过 Execute Workflow 节点调用。这样换模型、改 Base URL 只改一处所有调用方自动生效。第四定期检查 Key 的使用情况。在 https://taotoken.net/console 可以看到调用记录和用量发现异常调用及时吊销重建。给不同的工作流用不同的 Key出问题能快速定位是哪个流程。第五容器日志别关。docker compose logs -f n8n在排查问题时是唯一的信息来源。建议把日志级别设成 info出问题时临时调到 debug。日志里能看到每个节点的请求和响应比在界面上猜快得多。如果你后面要跑更复杂的 Agent 工作流或者需要长期稳定的编码类任务可以了解一下 Coding Plan它在调用配额和并发上有更适合持续任务的安排。入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。日常调试模型返回用模型对话页面更直观https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 遇到路径或参数不确定时以文档为准。最后说一个我踩过的坑有次工作流在测试环境跑得好好的上到另一台机器就 401。查了半天发现是那台机器的 compose 文件里环境变量名拼错了一个字母TAOTOKEN_API_KEY写成了TAOTOKEN_APIKEY容器里取到空值请求自然被拒。所以每次换环境先用printenv | grep TAOTOKEN确认变量名和值都对能省掉大量无谓排查。配置这件事慢就是快。
