n8n 调接口遇到限流，怎样设置退避和重试上限

n8n 调接口遇到限流，先确认限制作用于哪个账户、哪个接口和哪个时间窗口，再决定等待多久。把重试次数调大只能增加尝试，不能增加服务方配额。适合的方案应同时控制发送速度、重试次数和任务截止时间；已经可能成功的写操作还要先查结果。下文是合成调度演练，不代表任何生产接口的实测配额。

先把限流与其他错误分开

查看响应状态、服务方错误码和响应头，记录发生时间与使用的凭据别名。HTTP 状态为 429 常表示请求过多，但每日额度耗尽、瞬时并发超限和单用户限额的处理可能不同。401、403 不应靠重复请求解决；输入格式错误应修正参数；连接断开则可能进入结果未知分支。不要把所有异常汇总为一个“重试直到成功”的循环。

n8n 官方限流处理文档介绍了 Retry On Fail，以及 Loop Over Items 配合 Wait 的方法。它们是调度工具，不知道你的订单是否已创建，也不会替你选择业务可接受的最长等待。设置项名称与可用参数依安装版本核对，先在隔离环境验证节点收到错误后究竟是终止、重试还是把错误交给后续分支。

为每个任务留出明确预算

给任务分配请求总上限、最多重试次数、最长累计等待和绝对截止时间。假设演示任务只读三条库存，最多尝试四次，累计等待不得超过一分钟；这些只是业务讨论的假设，不是推荐所有接口都采用的固定阈值。还要确认是否已有网关、SDK 或上游队列在重试，否则每层四次可能形成远超预期的请求放大。

退避可以采用逐次增加等待并加入随机扰动的设计，例如演示基础等待两秒，后续四秒、八秒，但真正等待应优先结合服务方返回的恢复提示和接口文档。设置最大单次等待，防止异常值让任务挂起很久；如果服务方要求等待到下一天，就不要在一分钟任务里持续占着执行，应转为延期或人工处理。对响应提示的解析失败要记为可见错误，不能静默当作零秒。

用记录表验证实际节奏

下载限流与重试演练记录。合成样例的第一次返回 429，第二次仍被限制，第三次成功；另一任务返回权限错误后立即停止。表中列出计划等待、实际开始时间、剩余尝试数和最终处置。实施时先使用可控的模拟接口，按顺序返回这些响应，再观察请求账本中的间隔，不只看工作流画布是否变绿。

在批量场景中，先把同一配额的任务集中排队，再按批次释放。若三个工作流共用一个凭据，分别在各自循环里等待仍可能合计超额，需要共享速率协调。不同租户通常应隔离预算，避免一个大客户耗尽所有人的窗口。暂停新增任务之后，已经排队的任务也要计入容量，不能只限制新到达流量而放任积压瞬间涌出。

写操作的重试必须多一道判断

查询库存与创建采购单不能用同一规则。创建请求超时后，应带原请求号查询状态；若目标系统支持幂等机制，必须按照它的接口契约复用同一键。不能每重试一次就生成一个新业务号。请求人权限、确认人的批准和被批准参数摘要都要随任务保留，等待期间对象内容有变化时，应重新确认，而不是沿用已经过期的批准。

任何自动重试都应能停下来。达到截止时间、连续出现配额耗尽、响应格式不符、授权被撤销时，进入有责任人的处理队列。通知中写任务号、接口别名、尝试次数和下一步建议，删去令牌与完整业务正文。用户界面要显示“已延期”或“待核对”，不能在未成功时显示“已处理”，也不能每次重试都给业务人员发一条相同告警。

验收时核对四个数

核对发送请求总数、成功业务数、累计等待和遗留任务数。预期成功也不能掩盖超额发送；请求数量符合预算但截止时间后还在调用，同样应判不通过。增加一个并发任务、一条无法解析的恢复提示和一个权限撤销场景，检查停止条件是否有效。最终把实际配额责任人写入交付清单，服务方改变限制时能够调整调度策略。

还应区分任务优先级。实时客服查询与夜间批量同步共用配额时，可以给实时任务保留窗口，让批量任务可暂停；具体比例由业务负责人确定，不给未经测量的通用数值。队列恢复后要逐步释放积压，观察失败与等待是否再次升高，不能把停机期间的所有任务一次倾倒给服务方。验收表增加任务创建时间、最后可接受完成时间与过期处置，过期数据应丢弃、重取还是交人工，要按业务含义决定。重试日志保留原因与下一次计划时间，便于值班人员判断正在合理等待，还是已经形成没有出口的循环。停止后保留任务原因，重新放行需要可追踪的业务决定。

相关基础见n8n 专题与Agent 节点的能力边界，重复回调问题可看事件幂等设计。需要对接有调用额度的 CRM、ERP 或内容接口，可通过咨询入口提交脱敏错误响应、峰值任务量和可接受等待时间，一起确定可验收的重试预算。