n8n Code 节点 Task request timed out 怎么排查？

如果 n8n 的 Code 节点执行到一半不是报你的 JavaScript 语法错，而是在等了大约 60 秒后直接出现：

Task request timed out
Your Code node task was not matched to a runner within the timeout period

第一判断不要放在 return、循环或输入数据上。这个错误首先表示 Code 节点提交的任务在 N8N_RUNNERS_TASK_REQUEST_TIMEOUT 窗口内没有被匹配的 Task Runner 接走。 XBSTACK 在官方 n8nio/n8n:2.37.1 + n8nio/runners:2.37.1 external mode 上做了隔离实验：移除 Runner 后，同一段只有一行 return 的最小 Code 稳定报出完整错误；Runner 注册后立即恢复；请求已经在等待时再启动 Runner，也能在截止前被接单。Self-hosted 应优先查 Runner 注册、Broker 连通性、auth token、版本和容量；Cloud 用户则先用最小 Code 排除业务逻辑，再带执行信息找 n8n Support。把 request timeout 调大只能延长等待，不会修复一个永远不会注册的 Runner。

先看清楚：这不是普通的 JavaScript 执行超时

n8n 当前的 Task Runner 架构有三个角色：

Code node / task requester
          ↓
      task broker
          ↓
 available task runner
          ↓
   execute JavaScript

官方文档说明，Task Runner 通过 WebSocket 连到 broker；Code 节点在这里是 task requester，先把任务交给 broker，再由一个可用的 runner 接单执行。如果在规定时间内一直没有匹配的 runner，requester 才会得到 Task request timed out。

n8n Code 节点从 requester 到 broker 再到 Task Runner 的调度链路，以及未匹配 Runner 时发生 request timeout 的位置

这和“Runner 已经接到任务，但你的 JavaScript 跑了太久”是两个不同阶段。

官方当前给出的两个环境变量尤其容易混淆：

变量	官方当前默认值	控制什么
`N8N_RUNNERS_TASK_REQUEST_TIMEOUT`	60 秒	任务请求最多等多久，等不到可用 Runner 就失败
`N8N_RUNNERS_TASK_TIMEOUT`	300 秒	Runner 已经接单后，任务最多执行多久

所以如果报错正文里明确写着：

was not matched to a runner within the timeout period

你应该先查“为什么没有 Runner 接单”，而不是先优化 JavaScript 的运行时间。

XBSTACK 实测：没有 Runner、Runner 正常、等待中恢复

为了把问题从 Cloud 环境、业务 workflow 和 JavaScript 逻辑里剥离出来，我在一台 Linux x86_64 NAS 上只跑了官方 Docker 镜像：

Docker 28.5.2；
n8nio/n8n:2.37.1；
n8nio/runners:2.37.1；
external runner mode；
默认 SQLite；
不调用外部 API；
不使用凭据；
最小 workflow 只有 Manual Trigger → Code。

Code 只有这一行：

return [{ json: { ok: true, source: 'xbstack-task-runner-repro' } }];

为了不让负向实验每次等满官方默认的 60 秒，我把 N8N_RUNNERS_TASK_REQUEST_TIMEOUT 临时缩短为 15 秒。这只是加快复现，不改变错误机制。

对照 1：external mode，但没有任何匹配 Runner

结果：约 15.04 秒后稳定失败。

n8n 日志进入：

n8n Task Broker ready on 0.0.0.0, port 5679
Task request timed out
Error: Task request timed out

Execution 里的 description 是：

Your Code node task was not matched to a runner within the timeout period
(waited 15 seconds).
This indicates that the task runner is currently down, or not ready,
or at capacity, so it cannot service your task.

而且 Minimal Code 的 executionTime 是约 15040 ms。这里的 15 秒不是这段 JavaScript 真跑了 15 秒，而是它等了 15 秒也没有被任何 JavaScript Runner 接走。

对照 2：匹配版本的 JS Runner 正常注册

把 n8nio/runners:2.37.1 sidecar 按官方 external mode 配置接到同一个 broker 后，日志先出现：

Registered runner "launcher-javascript"
Registered runner "JS Task Runner"

然后同一个 Code 正常返回：

{
  "ok": true,
  "source": "xbstack-task-runner-repro"
}

对照 3：先让 Code 等，再启动 Runner

第三组更能解释 N8N_RUNNERS_TASK_REQUEST_TIMEOUT 的含义。

我先启动 n8n 让 Code 任务进入等待，此时 Runner 还没运行；随后在 15 秒截止前启动匹配的 n8nio/runners:2.37.1。结果不需要人工重跑 workflow，JS Runner 注册后，已经挂在 broker 里等待的任务被接走，约 8.42 秒后成功结束。

n8n Code 节点 Task Runner 三组实测：无 Runner 超时、Runner 正常成功、等待中启动 Runner 后在截止前恢复

这组结果支持一个很实用的判断：

N8N_RUNNERS_TASK_REQUEST_TIMEOUT 是“我愿意等 Runner 多久”的窗口，不是“JavaScript 最多执行多久”的窗口。

完整实验文件、日志和版本矩阵放在 XBSTACK 的最小复现仓库中；文章发布后会与 GitHub 仓库互相链接。

最快排查：先用一个 10 秒钟就能看懂的最小 Code

如果你当前的 workflow 有几十个节点、多个 AI Agent、数据库和 API，不要在原 workflow 上直接猜。

新建：

Manual Trigger
  ↓
Code

Code 写：

return [{ json: { ok: true } }];

然后看结果。

情况 A：最小 Code 也报同一个 Runner timeout

这时业务逻辑、输入数据、API Key、模型调用都不是第一排查对象。把注意力转到：

Runner 是否真的启动；
Runner 是否成功注册到 broker；
JS Runner 是否可用，而不是只有 Python Runner；
broker 是否从 Runner 容器可达；
auth token 是否一致；
Runner 是否已达到并发上限；
当前执行到底落在哪个 worker，而那个 worker 是否有自己的 sidecar。

情况 B：最小 Code 正常，只有某个 workflow 失败

那就不要把所有问题都归因到 Runner 基础设施。继续看：

某个 Code 是否真的长时间执行；
是否有死循环、巨量数据、同步 CPU 密集逻辑；
是否用了 Runner 中不存在或未 allowlist 的模块；
是否只有 Schedule / Webhook / Manual 某一种触发路径失败。

后者尤其要和最新的 n8n #37065 区分：该 Issue 报告的是 external runner 健康、manual/webhook Code 成功，但 Schedule Trigger 触发的同一 JavaScript 没有被 dispatch。这是更窄的“触发路径/调度差异”，不应该和“没有可用 Runner”的通用 timeout 混为同一个根因。

n8n Code 节点 Task request timed out 的排查流程：先用最小 Code，再区分 Cloud、self-hosted、Runner 注册、Broker、Auth、容量与触发路径

Self-hosted：按这个顺序查，不要先改 timeout

1. 先确认你用的是 internal 还是 external mode

生产环境官方当前建议使用 external mode，让 n8nio/runners 作为独立 sidecar 运行。

最基本的 n8n 端配置包括：

environment:
  N8N_RUNNERS_MODE: external
  N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0
  N8N_RUNNERS_AUTH_TOKEN: your-shared-secret

Runner sidecar：

environment:
  N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
  N8N_RUNNERS_AUTH_TOKEN: your-shared-secret

其中一个很容易漏：broker 默认只监听 localhost；跨容器时官方要求让它接受外部连接，因此 N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 是重点检查项。

2. n8n 与 runners 镜像版本必须匹配

官方 external mode 文档明确要求 n8nio/runners 镜像版本与 n8nio/n8n 匹配。

例如：

n8nio/n8n:2.37.1
n8nio/runners:2.37.1

不要主实例升了、sidecar 还长期停在另一个 tag，然后先去改 workflow。

3. 看的是“Registered runner”，不是“容器 Up”

docker ps 显示 sidecar Up 只能证明容器进程存在，不能证明 JavaScript Runner 已经成功接入 broker。

真正有价值的是 n8n / runner 日志里是否出现类似：

Registered runner "launcher-javascript"
Registered runner "JS Task Runner"

如果日志只看到 Python offer，而当前任务类型是 JavaScript，n8n 会明确记录没有匹配类型的 offer。本文健康对照启动过程中就短暂出现过：

No matching task offer ... (type "javascript"). Available offer types: [python]

等 JS Runner 注册后，任务才继续执行。

4. 核对 auth token 和 broker URI

n8n 容器与 runners 容器必须使用同一个：

N8N_RUNNERS_AUTH_TOKEN

Runner 端还必须能解析并访问：

N8N_RUNNERS_TASK_BROKER_URI

在 Docker Compose 中通常应使用服务名，例如：

http://n8n:5679

不要习惯性写 localhost:5679——在独立 sidecar 里，localhost 指的是 Runner 自己，不是另一个 n8n 容器。

5. Queue Mode 下，每个真正执行任务的 worker 都要有 sidecar

官方文档强调，Queue Mode 下每个 worker 都需要自己的 Task Runner sidecar。

如果某次 Manual 执行正常、生产执行却超时，先问清楚：

这两个执行是不是落在同一个 n8n 实例/worker？

另外，如果 OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=false，main 实例自己会跑 manual execution，那么 main 也需要对应 sidecar。

6. 再看容量，而不是一看到 timeout 就重启

官方当前 N8N_RUNNERS_MAX_CONCURRENCY 默认是 5。如果所有 Runner 都正在执行长任务，新请求会在 broker 里等待；等待超过 N8N_RUNNERS_TASK_REQUEST_TIMEOUT 后也会得到相同高层错误。

所以同一个报错可能来自：

Runner 没启动；
Runner 启动了但没注册；
auth/网络导致 broker 不可达；
没有匹配的 JS/Python Runner 类型；
Runner 已经满载；
某个 worker 没配 sidecar；
Runner 自己启动失败或不断重启。

错误字符串能告诉你“任务没有及时被 Runner 接走”，但不能单独告诉你为什么没有被接走。

为什么不建议第一步就把 60 秒改成 300 秒

n8n 的错误提示本身会告诉你可以调整：

N8N_RUNNERS_TASK_REQUEST_TIMEOUT

这不是错，但使用场景要分清。

如果你确认 Runner 最终会正常注册，只是冷启动慢，或者当前有短时高峰，增加等待窗口可能有用。

但如果真实问题是：

Runner container down
AUTH_TOKEN mismatch
broker URI wrong
broker only listens on localhost
JS runner crashes during startup
worker has no sidecar

那么：

60s → 300s

只是把“1 分钟后失败”变成“5 分钟后失败”。

更糟糕的是，它会让用户误以为 workflow 一直在执行，实际上 Code 还没有被 Runner 接单。

Cloud 用户怎么处理：不要照搬 self-hosted 的 Docker 命令

2026-08-25 到 26 日，n8n GitHub 出现了多条 Cloud Code Node 同类报告：

#37069：2.37.1 Cloud，空白 workflow + 最小 Code 也无法匹配 Runner；
#37062：2.37.1 Cloud，同样是约 66 秒后失败，并有其他用户补充同类现象；
#37043：JavaScript Code node timeout，评论里也有 Cloud 2.37.1 用户确认；
#36989：Cloud 2.35.4 也出现相同高层错误。

但不要因此把文章标题写成“2.37.1 已确认回归”。

n8n 在 8 月 25 日的 GitHub release 上，stable 指向 2.36.7，beta 指向 2.37.1。#37064 提出了 2.37.x / Node 26 runner image 的回归假设，但 maintainer 随后关闭该 Issue，并明确表示自己的 Cloud 与 self-hosted 实例没有看到同样问题，因此目前没有官方证据支持“所有 2.37.1 都会坏”。

Cloud 用户最有效的动作不是找 docker ps：

新建 Manual Trigger → Code 最小 workflow；
Code 只返回 {ok:true}；
记录 n8n 版本；
记录错误里 waited 60/66 seconds；
保存 Execution / Debug Info；
如果最小 Code 也失败，直接向 n8n Support 提供这些证据。

因为 Cloud 的 Runner sidecar、broker 和实例调度属于平台内部，你没有权限像 self-hosted 那样直接检查或重启容器。

这和 ARM64 GLIBC_PRIVATE 是不是同一个 Task Runner 问题？

不是。

站内已有的 n8n 2.33.7 distroless ARM64 GLIBC_PRIVATE 实测解决的是另一个独立故障：Python Runner 在 ARM64 上进程启动即 exit 127，日志有明确的 libc symbol lookup error。

这篇文章解决的是：

Code task submitted
↓
waiting for matching runner
↓
not accepted before deadline
↓
Task request timed out

前者是已知 Runner 进程/ABI 启动失败，后者是 broker/requester 看到的“没有及时获得可用 Runner”。ABI 崩溃可以导致“最终没有 Runner 可用”，但不能把所有 not matched to a runner 都反推成 GLIBC 问题。

如果你正在搭建整个 self-hosted 拓扑，先看 Self-hosted n8n：Docker Compose、Postgres、VPS 与 NAS 生产基线；如果 Runner 已接单后节点本身失败、需要 Retry/Error Workflow，再看 n8n 错误处理：Error Workflow、重试、超时与失败重跑。

一张排查清单

遇到：

Task request timed out
Your Code node task was not matched to a runner within the timeout period

按这个顺序：

用 Manual Trigger → Code 最小化；
确认是否所有 Code 都失败；
self-hosted：确认 external/internal mode；
检查 Runner 日志是否真的注册 JS/Python Runner；
核对 n8n/runners 版本是否一致；
核对 N8N_RUNNERS_AUTH_TOKEN；
核对 N8N_RUNNERS_TASK_BROKER_URI 与 BROKER_LISTEN_ADDRESS；
Queue Mode 检查执行所落 worker 是否有 sidecar；
检查 MAX_CONCURRENCY 和长任务占用；
最后才考虑是否需要扩大 TASK_REQUEST_TIMEOUT；
Cloud 最小 Code 仍失败：带证据找 Support，不要继续改 JavaScript。

官方修复状态：目前没有一个通用版本号可以写成“升级就好”

截至 2026-08-26，这个错误字符串代表的是一个症状边界，不是单一 Bug ID。

近期 Cloud 报告值得持续观察，但目前证据不支持：

所有 2.37.1 = 同一个 Runner regression

也不支持：

把 timeout 调大 = 已修复

更可靠的生产策略是保留一个最小 Code canary，并把 Runner 注册日志、broker 可达性和容量纳入部署后验证。这样下一次再看到同样错误时，可以迅速区分：平台实例问题、Runner 基础设施问题，还是某个特定 workflow/trigger 的问题。

参考与实验资产

官方资料：

近期上游讨论：

完整的最小 workflow、无 Runner 日志、正常 Runner 对照、等待中恢复对照与版本矩阵已经公开在 XBSTACK n8n Code Node Task Runner timeout 最小复现仓库。站内源文件同时保留在 experiments/n8n-code-node-task-runner-timeout-repro/，便于后续版本回归继续复跑。

专题入口 / AI Workflow Hub

继续按 n8n 生产排障链路读

自托管、Queue Mode、Webhook、错误处理和案例文统一沉淀到 Workflow 专题页：部署文做主力页，案例文做长尾页，对比文承接工具选择流量。

进入 Workflow 专题 → 查看 Webhook 排障订阅

小白 / Xiaobai

n8n Code 节点报 Task request timed out 怎么解决？Task Runner 未匹配排查实测