救命！我的 n8n 跑着跑着就挂了？
作为 N8N大学 的首席主编，笔者见过太多同学深夜抓狂的场景：明明昨天还好好的自动化流程，今天早上起来一看，全红了。原因五花八门：第三方 API 抽风、网络抖动、数据库锁死……
最让人崩溃的是，你根本不知道它是什么时候挂的，只能等客户投诉了才发现。如果你还在靠人工盯着 n8n 的运行记录，那这篇文章就是为你准备的。今天，我们不聊虚的，只讲实战技巧：如何利用 n8n 强大的 Error Handling（错误处理）机制，让流程具备“不死金身”，自动重试，并在失败时第一时间通知你。
为什么你的 n8n 节点会“猝死”？
在动手配置之前，得先明白“敌人”是谁。n8n 的节点报错通常分为两类：
- 瞬时性错误：比如网络超时、API 限流（429错误）、数据库连接短暂中断。这种错误，重试一下往往就好了。
- 永久性错误：比如参数传错了、API Key 无效、数据库字段缺失。这种错误，重试一万次也是徒劳，必须人工介入。
n8n 的 Error Handling 策略，就是针对这两类错误设计的“智能分诊台”。
核心实操：配置自动重试与报警
进入正题。假设我们有一个 HTTP Request 节点去调用一个不稳定的天气 API，经常报 502 Bad Gateway。我们要怎么做？
步骤一：开启节点的“复活甲”——自动重试
n8n 默认情况下，节点失败了就是失败了，不会自动重试。我们需要手动开启这个功能。
- 双击打开那个容易出错的 HTTP Request 节点。
- 点击右上角的 Settings（设置）标签页（或者在某些版本中是“重试”选项）。
- 找到 Retry On（重试条件）。这里非常关键，不要全选，要根据错误类型选。
- 避坑指南：如果是 API 调用，建议勾选
5xx（服务器错误）和429（限流）。千万别勾选4xx（客户端错误），因为如果你参数填错了（比如缺必填字段），重试是没用的，只会浪费额度。
步骤二：设置“复活”规则——重试策略
光开启重试还不够，得告诉 n8n 怎么个重试法。
- 等待时间（Wait Time）：建议设置指数退避（Exponential Backoff）。比如第一次等 1 秒，第二次等 2 秒，第三次等 4 秒。这能有效避免给 API 服务器造成雪崩。
- 最大重试次数：根据业务敏感度设定。如果是实时数据，设 3 次；如果是后台补录，可以设 5-10 次。
配置好这些后，当网络波动导致的 502 错误发生时，n8n 会自动在后台默默重试，直到成功或达到上限，而你完全不需要干预。
步骤三：终极防线——失败后的通知机制
如果重试了 N 次还是失败，说明问题严重了，必须通知人工。这里我们需要利用 n8n 的 On Error（错误时）分支。
在 n8n 的工作流画布中，你可以看到每个节点右侧都有一个红色的 “On Error” 输出点。注意： 这个功能在较新版本的 n8n 中才作为标准功能提供（旧版可能需要通过 If 节点配合系统变量模拟）。
- 从容易报错的 HTTP Request 节点右侧，拖出一条连线。
- 在搜索框中选择 IF 节点（或者直接连接到通知节点，如果你的 n8n 版本支持直接连接 Error 输出）。
- 配置判断逻辑：如果
execution.lastNode.status是failed。 - 连接通知节点：推荐使用 Telegram、钉钉 或 邮件（Email） 节点。
- 关键参数：在消息体中，务必拼接上
{{ $json.error }}或{{ $lastNodeError }}（具体变量视版本而定），这样你收到的报警才包含具体的报错原因。
笔者的实战经验：在通知内容里加上“工作流 ID”和“出错节点名称”，能让你在后台快速定位问题，而不是盲人摸象。
步骤四：进阶玩法——使用 Error Trigger 节点
如果你有一个全局的监控需求，不想在每个节点都配一遍，可以使用 Error Trigger 节点。
这是一个特殊的触发器节点。当工作流中任何节点报错且未被捕获时，它会触发。你可以把它当作一个“全局错误监听器”。
- 新建一个工作流，拖入 Error Trigger。
- 接着添加 Slack 或 Send Email 节点。
- 在邮件内容中引用
{{ $json }}，它会把完整的错误堆栈发给你。
避坑指南：这些细节决定成败
在配置 Error Handling 时，新手容易栽在以下两个坑里：
1. 死循环陷阱
如果你在“重试”逻辑里设置了无限重试，或者在“On Error”分支里又触发了原工作流，可能导致死循环，瞬间耗尽你的 API 额度或导致服务器卡死。切记：重试要有上限，通知要简洁。
2. 变量作用域混淆
在错误通知节点中，很多人直接写 {{ error }}，结果取不到值。正确的做法是查看当前版本的 n8n 文档，通常需要通过 {{ $node["节点名"].json }} 或者系统变量来获取错误详情。
FAQ 常见问题解答
Q1: Error Handling 配置好后，为什么还是收不到通知？
A: 检查两点：一是你的通知节点（如 SMTP 或 Telegram）本身是否配置正确；二是确认报错的节点是否真的触发了“失败”状态。有些节点虽然报错，但被中间件处理了，可能不会触发全局的 Error Trigger。
Q2: 自动重试会扣费吗？
A: 如果是调用付费 API（如 OpenAI），每一次重试都会消耗 Token 或 API 调用次数。因此，对于昂贵的 API，建议重试次数设置保守一些（如 2-3 次），或者在重试前增加一个判断节点。
Q3: n8n 社区版和云版本的 Error Handling 有区别吗？
A: 核心功能（如节点内的 Retry 设置）基本一致。但云版本（n8n Cloud）可能在 UI 上更直观，且自带一些基础的健康检查。社区版需要自己配置通知渠道。
总结与资源
自动化最怕的就是“黑盒”运行。通过 n8n 的 Error Handling，我们实际上是给自动化流程装上了“保险丝”和“报警器”。不要等到客户投诉才去查日志，主动防御才是硬核玩家的操作。
如果你在配置过程中遇到具体的报错代码，欢迎在 N8N大学 的社区留言，或者参考 n8n 官方文档的 Error Handling 章节。
记住：最好的自动化，是即使出错了，你也能从容应对。
