场景导入：自动化最怕的不是逻辑错误，而是“网络波动”

作为 N8N大学 的首席主编，笔者见过太多同学满怀信心地搭建好自动化流程，却在深夜收到一堆报错邮件。最常见的罪魁祸首不是代码逻辑，而是那个令人头疼的 ETIMEDOUT。

想象一下：你的流程正在抓取竞争对手的电商价格，或者同步跨区域的数据库数据。突然，网络抖动了一下，请求超时了。如果没有重试机制，整个流程直接中断，后续的“计算利润”、“发送警报”节点全部瘫痪。这不仅是数据丢失，更是对业务连续性的打击。

今天，我们就来硬核拆解 n8n 中关于超时和重试的设置。这不是简单的参数调整，而是一套对抗不完美网络环境的防御策略。

核心实操：从基础设置到高级重试策略

在 n8n 中，超时和重试的设置分为两个层面：单节点的基础配置，以及通过“重试节点”实现的复杂逻辑。我们先从最常用的 HTTP Request 节点说起。

1. HTTP Request 节点的基础超时控制

当你使用 HTTP Request 节点调用外部 API 时，n8n 默认有超时机制，但默认值往往过于激进。在高延迟场景下（如跨国 API 调用），你需要手动调整。

操作步骤：

1. 打开你的 HTTP Request 节点配置面板。
2. 在“Options”选项卡中，找到 Timeout 参数。
3. 默认单位是毫秒（ms）。如果你的 API 响应较慢，建议从默认的 30000ms（30秒）适当调高。
4. 关键点： 这里的超时设置仅针对单次 HTTP 请求。如果请求发出后因为网络波动在 30 秒内未收到任何字节，连接就会被强制关闭。

但这还不够。如果网络波动发生在请求发出前，或者响应数据传输中途卡住，单节点的超时设置只能报错，无法自救。

2. 使用“错误触发器”捕捉超时异常

N8N 大学建议：不要让你的流程在报错时直接“静默死亡”。你需要一个监控机制。

在你的主流程末尾，添加一个 Error Trigger 节点。这个节点就像一个看门狗，专门监听主流程中任何节点抛出的异常。

当 HTTP Request 因超时报错时，Error Trigger 会捕获到具体的错误信息。你可以在这里配置通知（如发送钉钉/飞书消息），告诉自己：“嘿，XX 接口超时了，正在尝试重试逻辑。”

3. 进阶实战：构建自动重试逻辑（推荐）

仅仅报警是不够的，我们想要的是“自动重试”。在 n8n 原生节点中，虽然没有直接的“重试按钮”，但我们可以通过 IF 节点和 Wait 节点构建一个简单的重试循环。

步骤拆解：

1. 重试计数器： 在流程开始时，使用 Set 节点初始化一个变量，例如 retryCount 设为 0。
2. 执行请求： 运行你的 HTTP Request 节点。
3. 判断成功与否： 在请求节点后连接一个 IF 节点。判断条件是：HTTP Request 输出的数据 是否存在（或者判断状态码是否为 200）。
4. 失败处理（核心）： 如果判断为“否”（失败）：
   • 使用 Set 节点将 retryCount 加 1。
   • 连接一个 Wait 节点（或 Sleep 节点），设置等待时间（如指数退避：1秒、2秒、4秒）。
   • 将流程回连到 IF 节点之前，但要限制循环次数（例如：如果 retryCount < 3，则继续；否则走失败分支）。
5. 成功处理： 如果判断为“是”，则继续执行后续业务逻辑。

这种“手动搭建”的重试逻辑虽然略显繁琐，但在 n8n 社区版中是实现灵活重试最稳健的方式。

4. 利用 n8n 的“执行重试”功能（全局配置）

除了手动搭建逻辑，n8n 还提供了一个系统级的“兜底”机制。在 n8n 的配置文件（.env）或 Docker Compose 设置中，你可以配置执行重试。

找到环境变量 EXECUTIONS_PROCESS 确保为 main（默认）。对于失败的执行，n8n 有一个内置的重试逻辑，但这通常针对的是节点执行层面的崩溃，而非网络超时。因此，对于网络波动，我们更推荐上述的逻辑级重试。

避坑指南：关于重试的两个致命误区

误区一：无限重试导致 API 被封禁

很多同学在设置重试时，喜欢把次数设得很高，或者干脆无限循环。这是一个危险的操作。

场景： 如果你的目标 API 因为服务器过载而暂时不可用，你每秒重试一次，只会加剧对方服务器的负担。更糟糕的是，如果对方开启了防刷机制，你的 IP 很可能因为短时间内请求过多而被永久拉黑。

建议： 重试次数建议控制在 3-5 次。重试间隔必须使用“指数退避”（Exponential Backoff），即第一次等 1 秒，第二次等 2 秒，第三次等 4 秒，让服务器有喘息的时间。

误区二：幂等性（Idempotency）缺失

什么是幂等性？简单说，就是“重复做同一件事，结果应该是一样的”。

场景： 你的流程是“扣减库存”。网络波动导致请求超时，你以为失败了，触发重试，再次发送“扣减 1 个库存”的请求。实际上，第一次请求可能已经成功处理了，只是响应包丢失了。结果就是库存被扣了两次。

建议： 在重试逻辑中，务必带上唯一的请求 ID（Request ID）。如果后端服务支持幂等性接口，重试才是安全的。如果后端不支持，重试前最好先查询一下当前状态，避免脏数据。

FAQ 问答

1. n8n 的 HTTP Request 节点默认超时是多少？

默认情况下，n8n 的 HTTP Request 节点超时时间通常为 30000 毫秒（30秒）。如果超过这个时间服务端没有响应，节点会抛出 ECONNABORTED 或 ETIMEDOUT 错误。你可以通过节点的 Options 选项卡中的 Timeout 参数手动增加这个值。

2. 使用“Wait”节点做重试会消耗 n8n 的并发额度吗？

会的。当你使用 Wait 节点暂停工作流时，该执行实例会进入“等待”状态。虽然它不占用 CPU 资源，但会占用一个执行记录名额。如果你的 n8n 实例设置了最大并发执行数，等待中的工作流会占用这个配额，可能导致新的触发无法立即执行。对于高频重试场景，建议评估并发压力。

3. 除了 HTTP Request，其他节点（如 SSH、Postgres）也有重试设置吗？

是的。大多数需要建立连接的节点（如 SSH, Postgres, MySQL, Redis）都在 Options 选项卡中提供了 Connection Timeout 或 Query Timeout 设置。但和 HTTP 类似，它们通常只控制单次连接的超时，而非失败后的自动重连。复杂的重试逻辑依然建议使用前文提到的 IF 节点循环法。

总结与资源

网络波动是自动化领域的“不可抗力”，但通过 n8n 强大的节点编排能力，我们可以将这种不可抗力转化为可控的延时处理。

核心回顾：

• 基础层： 调整 HTTP Request 的 Timeout 参数，适应慢网络。
• 逻辑层： 使用 IF + Wait 节点构建指数退避重试循环。
• 安全层： 确保接口的幂等性，避免重复操作导致数据错误。

如果你想深入了解 n8n 的高级容错架构，欢迎访问 N8N大学 (n8ndx.com)，这里有更多关于全栈自动化实战的硬核内容。记住，好的自动化流程，不是从不失败，而是失败后能优雅地站起来。