n8n Error Handling节点：我用它解决了3个最让人头疼的错误-N8N大学

让自动化流程从“玻璃心”变成“钢铁侠”

在 N8N大学里，我见过太多同学的自动化流程跑得好好的，突然某天就“死”了。没有通知，没有预警，你甚至不知道它是什么时候停摆的。

这就是低代码自动化中最让人头疼的痛点：**错误处理**。很多人以为 n8n 只是把任务串联起来，却忽略了现实世界的网络波动、API 限流和数据格式的千奇百怪。

作为一个在低代码领域摸爬滚打 8 年的老司机，笔者必须告诉你：一个没有错误处理的 n8n 工作流，就像一辆没有刹车的汽车。今天，我就用 Error Handling 节点（错误处理分支），带你解决 3 个最让人崩溃的实战场景。

这是最常见的问题。比如你调用一个天气 API，或者给客户发邮件的 API。对方服务器偶尔会返回 502 Bad Gateway 或者 429 Too Many Requests。

在没有错误处理时，n8n 会直接把整条流程挂起，变成红色。你得手动去点“重试”，或者等它自己慢慢恢复。但如果是半夜 3 点呢？

解决方案：利用 Error Flow 智能重试

在 n8n 的 HTTP Request 节点设置中，有一个高级选项叫 On Error。不要选默认的“Stop”，我们要利用它。

设置重试逻辑： 在 HTTP Request 节点的 Settings 里，找到 Error Handling。你可以设置当遇到特定错误代码时，自动重试。
自定义重试策略： 笔者建议使用 Wait 节点配合 If 节点来手动构建重试逻辑。如果 HTTP Request 返回错误，在 If 节点判断 $json.code 是否为 502。
循环重试： 如果是，将流程导向一个 Wait 节点（等待 5 秒），然后重新回到 HTTP Request。为了避免无限循环，记得加一个计数器。

这样，你的流程就具备了“韧性”，能抗住短时间的网络抖动。

笔者曾经维护过一个抓取电商评论的流程。某天，网站改版了，json 里的某个字段名变了。结果，n8n 的 Set 节点找不到字段，直接报错，整个工作流停摆。

这种错误最隐蔽，也最致命。因为你不知道数据哪里出了问题，只能去日志里大海捞针。

解决方案：加“安全网”节点

在 n8n 中，我们不依赖“数据永远不变”这种童话，而是通过架构来兜底。

使用 Function 节点检查数据： 在处理数据的核心节点（如 Set 或 Function）之前，插入一个 Function 节点。用 JavaScript 代码检查关键字段是否存在。
错误分流： 如果字段不存在，通过 throw new Error() 抛出异常。此时，利用 n8n 的 Error Trigger 节点捕获这个错误。
记录失败数据： 在 Error Trigger 后，连接一个 Google Sheets 或 Notion 节点，将错误的原始数据和报错信息记录下来，而不是让流程直接“爆炸”。

这样，即使数据格式变了，流程依然能跑，只是把错误数据丢进了“垃圾桶”待处理，保证了主流程的畅通。

当你设置 n8n 的 Split in Batches 节点处理大量数据时，经常会遇到 API 响应超时的问题。默认情况下，n8n 会等待直到超时，然后报错。

如果你有 1000 个任务，中间一个超时，整个批次可能都要重跑，效率极低。

解决方案：设置超时与熔断机制

这里我们需要对 HTTP Request 节点进行精细化配置。

调整超时时间： 在 HTTP Request 节点的 Settings 中，找到 Timeout。不要用默认值，根据 API 实际响应速度设置一个合理的值（例如 30000ms）。
激活错误处理分支： 在节点的 On Error 下拉菜单中，选择 Error Flow。这意味着一旦超时，流程不会卡死，而是会走另一条线（红色线路）。
构建降级策略： 连接红色线路到一个 Switch 节点。如果是超时错误，可以发送一条钉钉/飞书报警，或者将任务标记为“稍后重试”，而不是直接失败。

这就是“熔断”的雏形。当压力过大时，自动降级，保护你的 n8n 服务器和 API 配额。

在 N8N大学的社群里，很多人在使用 Error Handling 时容易踩这两个坑：

1. 混淆了“节点报错”和“流程报错”

n8n 的 Error Trigger 节点只能捕获“执行失败”的错误。如果你在 IF 节点里手动把数据导向了错误分支，Error Trigger 是不会触发的。所以在设计逻辑时，要清楚你是要处理“系统级异常”还是“业务级判断”。

2. 忽略了错误日志的上下文

当错误发生时，仅仅记录“出错了”是没用的。在你的报警节点里，一定要带上 {{ $json }} 或者关键的上下文信息（比如订单 ID）。否则，你根本没法排查问题。

是的。n8n 的核心功能是开源的，Error Trigger 和节点内的 Error Handling 设置在社区版（self-hosted）和企业版中都是可用的。

不能。错误处理是 n8n 内部机制的一部分。如果你的 n8n 服务器完全宕机，你需要外部监控（如 UptimeRobot）来报警。这也是为什么我们建议将 n8n 部署在 Docker 中并设置自动重启。

在 Error Trigger 节点后，你可以连接一个 If 节点，通过检查 $json.message 或 HTTP 状态码来区分。例如，如果是 401 说明授权失败，如果是 500 说明服务器内部错误。

在 n8n 的世界里，成功的自动化不是“不出错”，而是“出错时处理得当”。通过合理配置 HTTP Request 的超时、利用 Error Flow 分流、以及建立 Error Trigger 监控，你可以将脆弱的脚本变成健壮的系统。

如果你在实操中遇到具体的报错代码，欢迎在 N8N大学社区发帖，笔者会亲自为你解惑。