n8n 遇到 429、500 和超时该不该重试？70 次真实 HTTP 对照

三次请求恢复了什么

有限重试在本实验中恢复了 30/30 个瞬时故障。持续 429、持续 500 和持续超时共 30 个观测，没有一个因为多发两次请求而成功。

代价也写在结果里。无重试分支发出 70 个请求，三次尝试分支发出 190 个，是前者的 2.714 倍。持续超时的节点耗时中位数从 362 ms 增至 1,162 ms。

这组数字只适用于公开协议：服务在前两次请求失败、第三次恢复，或一直失败。它证明有限重试能处理短暂故障，也证明重试不能修复持续故障。

请求确实到达了 HTTP 服务

前一项基线在 Code 节点里抛出 429 和超时标记，只能验证分类器。这次不同。测试机启动一个本地 HTTP 服务，n8n 容器通过 host.docker.internal 访问它。服务在收到请求时记录运行编号、策略、尝试次数、计划状态码和延迟，再按协议返回响应。

HTTP Request 节点的响应头超时设为 300 ms。超时场景让服务等待 800 ms，因此客户端会先中止。429 与 500 场景返回真实状态码；429 响应还带有 Retry-After: 0.1。我们没有据此声称 n8n 会遵守 Retry-After，因为本实验只配置了固定 100 ms 等待。

两个策略来自同一个准备节点：

两个 HTTP 节点都使用 continueOnFail。这样无重试分支失败时，不会阻止另一分支留下证据。

七种场景各跑十次

每种场景重复十次，共 70 次工作流执行。每次同时产生两个策略观测，所以 runs.csv 有 140 行数据；requests.csv 有 260 条服务端请求记录。

所有 140 个观测都符合预先写入清单的结果和请求次数，协议偏差为 0。控制组的 retry_3 分支有一次 444 ms 长尾，因此 P95 也是 444 ms；样本只有十个，不能用这个点估计生产延迟分布。

429、500 和超时不能共用一句规则

429 表示请求速度超过了服务当前允许的范围。立即连发两次，可能让限流窗口更拥挤。生产流程至少要读取服务条款，确认是否应该按 Retry-After 或配额重置时间等待。

500 表示服务端没有完成请求，但请求是否已经产生副作用并不总是明确。创建订单、付款、发消息这类动作如果没有幂等键，自动重试可能生成重复结果。GET 查询通常风险较低，写操作必须先设计去重。

超时更棘手。客户端不知道服务器是尚未处理、正在处理，还是已经处理完但响应没有返回。本实验的延迟服务最终会尝试返回 200，可 n8n 已经在 300 ms 时中止。重试前若不检查业务状态，同一个写操作可能被执行两次。

所以“哪些状态可以重试”只解决了一半问题。另一半是“重复请求会不会破坏业务”。

请求量为什么必须进入成本表

在本协议里，重试分支只比无重试多恢复 30 个瞬时故障，却多发了 120 个请求。持续故障贡献了其中 60 个额外请求，但没有带来一次恢复。

若第三方服务按调用量计费，或共享团队级配额，这些请求会进入账单和限额。故障发生时流量本来就在上升，所有工作流同时固定间隔重试，还可能形成新的峰值。

生产设置应同时记录：

1. 原始请求数与重试请求数；
2. 按状态码和节点划分的恢复次数；
3. 重试后仍失败的次数；
4. 从第一次请求到最终结果的总耗时；
5. 因重试产生的重复业务记录。

只看“最终成功率”会隐藏第五项。

我会采用的上线规则

读取类请求可以把 429、选定的 5xx 和网络超时列为候选重试错误，但必须有最大次数。写入类请求先验证供应商是否支持幂等键；没有幂等协议时，默认不自动重放。

固定 100 ms 只适合这项快速实验。生产流程需要按供应商限制选择等待，增加抖动，避免多个执行在同一毫秒重新请求。达到上限后，错误应进入独立记录或人工队列，并保留执行 ID、节点、错误类别和最后一次响应。

401、403、无效参数一类错误通常不会因为再试两次自行消失。把它们与 429 混在一个重试开关里，会延迟告警并消耗配额。

一次中止没有被算进结果

正式运行前，收集器完成两个控制组后，在读取夹具状态时遇到一次 ECONNRESET。n8n 的两次工作流结果正常，但状态证据不完整，所以那批运行被停止，没有并入 CSV。

状态查询随后增加最多十次、每次间隔 50 ms 的有限重试。正式实验从第一个控制组重新开始，起止时间为 2026-07-23T08:59:39.368Z 至 2026-07-23T09:05:01.534Z。这个修正影响的是收集器，不是 HTTP Request 节点的重试设置。

复核和下一项实验

workflow.json 可以直接导入 n8n 2.30.5。runs.csv 保存每个策略观测的结果、请求数、节点耗时、CLI 耗时和输出哈希；requests.csv 保存服务端看到的 260 次请求；samples.json 给出每种场景第一轮的规范化样本。

下一项实验不会把本次固定等待换个数字再跑一遍。它要比较固定等待、指数退避加抖动，并给写操作加入幂等键，观察恢复、请求峰值和重复副作用是否一起改善。