一连串 429（Too Many Requests）错误，足以让一个本来跑得好好的工作流直接停摆。重试是解决办法的一部分，但时机很关键：重试得太快，很可能又撞上同一个限制。

搞清楚限流和速率限制的区别，能帮你更聪明地应对：既可以在调用 API 之前先控制好节奏，也可以在服务商明确让你等待时退避重试。

API 节流与速率限制：谁在执行，谁在适应

限流和节流都控制到达 API 的流量大小，但两者处理超额请求的方式并不相同。限流会给客户端在给定时间段内能发起的请求数设一个上限。一旦越过这个上限，服务方就可以拒绝后续请求，通常返回一个 429 Too Many Requests 响应。

节流则不同，当流量超过允许速率时，它会放慢或延迟请求。无论哪种方式，限制都由服务方掌控。而作为 API 使用方，你能掌控的是自己的工作流如何应对：尽量调整请求节奏以避免触限，真撞上限时就退避重试。

这张图说明了 API 限流与节流之间的区别：在前一种情况下，多出来的一个 API 请求会直接报错；而在后一种情况下，只是处理时间会变长。

什么是 API 节流？

API 节流通过放慢请求流量来调节请求，而不是让所有请求一次性全部放行。当需求过高时，请求可能会被延迟或排队，直到有可用容量为止。

这并不一定意味着，API 承压时你的工作流请求就会失败。但完成时间可能会变长。你的工作流仍然需要把这段延迟考虑进去，尤其是当后续步骤依赖该响应时。

限流与节流：实操上的区别

设想某个 API 允许每分钟 100 次请求，而你的工作流在这一分钟还没走完时就发出了第 101 次请求。如果是限流，这次请求可能会被拒绝并返回 429 错误，接下来什么时候重试就得由你的工作流自己决定。如果是节流，服务方可能会把第 101 次请求放进队列，稍后再处理。

这种差别改变的是你的工作流看到的结果（是报错还是延迟），但控制权在谁手里并没有变。流量策略由 API 提供方执行。你要做的是调整自己的请求方式，让工作流能继续往下走，又不至于反复把服务压垮。

继续滚动查看更多 ➔

限流节流
超过限制会怎样？请求可能被拒绝请求可能被延迟或排队
你的工作流会看到什么？一个错误（通常是错误 429）更慢的响应
由谁控制？API 提供方API 提供方
你的工作流该怎么做？退避并重试把增加的延迟考虑进去

限流是怎么运作的

限流听起来很简单——请求发得太多，API 就会让你停下。但到底多少算太多，取决于服务商怎么统计流量。有些 API 统计的是固定时间段内的请求数，另一些则允许短时突发，只要整体请求速率不越界就行。

对你们的工作流来说，底层算法很关键，因为它会改变你该以什么节奏发请求。稳定持续的调用节奏，对某个 API 可能很合适，换到另一个 API 上却会撞上限流。而一旦你真的越了线，通常就会碰到 Error 429——这是提醒你该放慢速度的第一个信号。

固定窗口与滑动窗口

固定窗口限流把时间切成一个个固定区间。比如某个 API 允许每分钟 100 次请求，到了下一分钟开始时计数器就清零。这样规则虽然好理解，但在两个窗口的交界处容易放过突发的流量尖峰。

滑动窗口通过在一段持续移动的时间区间内统计请求数，避开了那种硬性清零。它不问的是「从计时开始到现在你发了多少请求」，而是看「过去 60 秒内你发了多少请求」。等着时钟翻篇，未必能立刻恢复工作流的全部请求额度。

令牌桶与漏桶

令牌桶算法能给你留出一定的突发余量。可以把你的 API 配额想象成一个桶，令牌以稳定速率往桶里补充。每个请求消耗一个令牌，没用掉的令牌可以一直攒着，最多攒到桶的容量上限。只要攒下的令牌足够多，你的工作流就能一次性发出多个请求，而不会超出限额。

漏桶走的是相反的路子。请求先进入队列，再按受控的速率离开。突发流量会被抹平成更平稳的流量，而不是一次性把攒下的容量全部用掉。

别以为每个 API 都吃同一套请求模式。在决定批量或调用节奏能放多猛之前，先查一下服务商的限流文档。

429（请求过多）错误说明了什么

当 API 因为你超出了它的限流而拒绝请求时，HTTP 状态码 429（Too Many Requests）会告诉你发生了什么。响应里还可能带一个 Retry-After 头，指明客户端在再次发起请求之前应该等多久。

如果响应里带了 Retry-After，就按它来，别自己猜什么时候重试。如果没有，你的工作流就得有自己的策略来安排后续重试的间隔。这正是指数退避的用武之地：不再按固定间隔（或立刻）重试，而是逐步拉长每次尝试之间的等待时间。

指数退避

当 API 提示你放慢速度时，立刻重试同一个请求反而会让问题重现。指数退避通过每次失败后拉长等待时间来避开这个循环。比如，你的工作流不必每秒都重试，而是可以等一秒，再等两秒、四秒、八秒，以此类推。

设置最大延迟和重试上限，这样即使 API 出现临时问题，你的工作流也不会无限重试下去。如果 API 给出了 Retry-After 值，就按这个提示来，别只依赖自己定的重试节奏。

还有个麻烦。多个工作流一起失败，也会一起重试。给每次延迟加上抖动，也就是掺一点随机量，就能把这些重试尝试摊开，避免再撞出一次流量高峰。

先确认这个请求可以安全地重复执行。带副作用的请求可能会不小心把同一个动作执行两次，所以在自动重试之前，要先确认这个 API 是否支持幂等。

不加重试随机抖动的指数退避照样会形成尖峰，而额外加一段随机延迟就能把负载摊平。改编自：https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/**

💡

当你面对会调用工具的 AI 智能体系统时，加入随机抖动尤其重要。可以读一读我们这篇讲 LLM 工具调用错误处理的文章 https://blog.n8n.io/llm-tool-calling-error-handling/，里面说明了哪些情况下可以重试、哪些情况下更适合把错误上报升级。

n8n 中的限流与退避模式

不用从零开始自己搭限流处理。n8n（https://n8n.io/）是一个源码可得的 AI 原生自动化平台，给工程团队提供了几种方式，用 AI agent 或 agentic 工作流来处理限流。你可以在请求打到 API 限额之前先放慢速度，也可以在失败之后重试，或者把持续报错转到别处处理。

在 n8n 里，可以在好几个地方加请求延迟。Loop 节点会分批处理进来的条目。在循环内部，你还可以再加一个 HTTP Request 节点，用更小的批次并单独设置延迟。

不用从零搭重试逻辑，也能扛住 API 限流

批量请求、加等待节点，把持续出现的 429 错误转给错误处理工作流——全都在同一张画布上完成

免费注册

具体用哪种方式取决于 API。你可以把请求批量合并、拉开间隔，主动控制流量；也可以在单次调用之间加等待；或者在 API 返回 429 时配置重试。并发控制还能限制并行执行数，避免多个工作流合起来把同一个 API 打爆。先给请求限速，限流仍然挡路时，再用重试和错误处理兜底。

用批处理和等待节点控制请求节奏

对于限流可预期的 API，预防通常比事后补救更划算。HTTP Request 节点可以分批处理条目，并用 Items per Batch 和 Batch Interval 在批次之间暂停。这样你就能控制一次发出多少请求，以及 n8n 在发送下一批之前等待多久。

实际用法可以看这个批量发送 HTTP 请求的工作流：https://n8n.io/workflows/1243-avoid-rate-limiting-by-batching-http-requests/。如果需要更精细的控制，可以把 Loop Over Items（https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.splitinbatches）和 Wait 节点（https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait#limit-wait-time）搭配起来，围绕 API 的限流逐个控制请求节奏。

失败重试与退避

控制请求节奏能降低触发限流的概率，但无法杜绝每一次 429。遇到这类情况，可以用「失败重试」自动重试失败的节点，并配置「重试间隔」，避免立刻把同一个请求再发一遍。

遇到更复杂的情况，比如要拉长每次重试之间的间隔，你可以在工作流里搭一套更高级的重试逻辑。这样你就能自己掌控什么时候再试一次、什么时候彻底停止重试。

用错误工作流捕获持续 429 秒的问题

有些请求在你用完重试次数后仍然会失败。与其让这些失败淹没在执行历史里，不如把它们交给一个单独的错误工作流处理，用来记日志、发告警或做其他恢复操作。

在 n8n 里，你可以用 Error Trigger 节点 在另一个工作流失败时运行一个专门的工作流。这样一来，持续出现的 429 错误就能触发一条预先定义好的恢复路径，而不只是让执行就此结束。

💡

这里还有一份关于如何使用 API 限流的指南，帮你搭建更可靠的工作流。

用 n8n 掌控 API 限流

API 设定的限流你控制不了，但工作流撞上限流时怎么响应，这个你能控制。用 n8n，这套响应逻辑本身就变成了工作流的一部分，不用再自己写重试代码、还得一直维护。

用 n8n 掌控 API 限流

节奏控制、重试和错误路由都直接内建在工作流里，不用再自己写代码去维护。

免费试用 n8n Cloud