嗨各位，
我正在構建高度依賴外部 API 的 n8n 工作流程，我想找到一種可靠的方式來處理速率限制，而不會拖累整個工作流程。
例如，API 可能會返回：{
“status”: 429,
“message”: “Too Many Requests”,
“retry_after”: 30
}
我的主要考慮是：避免不必要的重試
遵守 API 速率限制
防止一個速度緩慢的 API 阻止其他工作流程
在不丟失資料的情況下處理暫時故障
我正在考慮指數退避、請求佇列和限制並發。
對於在生產環境中運行 n8n 的人員：
你們通常如何處理 429 回應？
你們使用佇列還是只是以延遲重試？
你們如何決定最大重試次數？
你們是否找到了一個好方法來防止一個 API 成為整個 n8n 執行個體的瓶頸？
描述問題/錯誤/問題
錯誤訊息是什麼（如有）？
請分享你的工作流程
(在畫布上選擇節點，使用鍵盤快捷鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製和貼上工作流程。)
分享最後一個節點返回的輸出
關於你的 n8n 設定的資訊
- n8n 版本：
- 資料庫（預設：SQLite）：
- n8n EXECUTIONS_PROCESS 設定（預設：own, main）：
- 透過以下方式運行 n8n（Docker、npm、n8n cloud、桌面應用程式）：
- 作業系統：
嘿 @Greg_John，在等待回覆的同時，以下是一些可能對你有幫助的資源：
建議資源
自動匹配至您的問題。
文檔：
論壇：
@Niffzy、@Yo_its_prakash - 你們之前有協助解決過類似的問題，可以看一下嗎？
由 n8n 社群機器人自動建議。這是試驗計畫 - 請在此分享反饋。
Hi @Greg_John 一個良好的生產方法是將速率限制視為預期行為，而不是簡單地立即重試所有內容。
API 請求
↓
429 / 臨時錯誤？
↓ 是
等待 + 指數退避
↓
重試
↓
達到最大嘗試次數？
↓ 是
死信 / 錯誤工作流程
建議方法
在提供時尊重 API 的 Retry-After 值
對臨時故障使用指數退避
設定最大重試次數
限制對 API 的並發請求
將永久失敗的任務發送到錯誤/恢復工作流程
例如：重試 1 → 2 秒
重試 2 → 4 秒
重試 3 → 8 秒
重試 4 → 16 秒
確切的延遲應取決於 API 的限制。
關鍵是避免重試風暴。如果數百次執行同時收到 429 並立即全部重試，你可能會讓問題更糟。
對於高容量系統，結合併發限制 + 指數退避 + 恢復路徑通常可以提供更可靠的設置。
@Greg_John HTTPS 請求有重試次數和等待時間，你可以利用這個來幫助自己，但除非你有更高級的方案，否則無法真正加快速率限制。你可以設置讓它們進行批處理，在失敗時重試，+ 等待節點會有幫助！
設置錯誤工作流也可以幫助更輕鬆地監控！
以上很好的答案。以下幾點特別針對你對某個緩慢API阻礙其他工作流程的顧慮：
**使用子工作流程隔離各API的執行**
關鍵洞見：不要在主工作流程內處理速率限制。將每個外部API呼叫移到自己的子工作流程中（執行工作流程節點）。你的主流程保持快速；子工作流程處理自己的重試邏輯，並可獨立執行而不會阻礙其他平行執行。
**跨執行追蹤配額狀態**
內建HTTP重試只會處理暫時性故障。要在並行執行之間進行真正的速率限制管理，你需要在執行間保留狀態：
1. API呼叫前，從鍵值存放區讀取剩餘配額（Airtable列、透過HTTP的Redis或Google工作表）
2. 若配額接近用盡，寫入「冷卻至」時間戳並跳過
3. 成功呼叫後，遞減計數器
這可防止多個並行工作流程執行同時對相同API配額造成攻擊。
**斷路器模式**
在API子工作流程的早期新增斷路器檢查：
- 從你的鍵值存放區讀取「斷路器狀態」旗標
- 若為`開啟`（在N個連續429後觸發），立即傳回結構化錯誤而不觸及API
- 另一個排程工作流程在冷卻期過期後重設旗標
這就是阻止速率受限API造成所有依賴它的項目級聯故障的方式。
**死信佇列**
在重試達上限後，不只記錄錯誤——將失敗的有效負載寫入Airtable表格或webhook佇列。另一個復原工作流程按排程重試這些，或將其標記供Slack審核。
@Niffzy概述的指數退避 + 等待節點方式在重試層很堅實。斷路器 + 外部狀態層則是在多個工作流程共用相同API配額時讓它生產環境安全的因素。
-–
若這是針對故障有實際成本的系統（遺失訂單、遺漏觸發），這是我們在[occelatus.io/automate](Automation Services — Occelatus Labs)的成品建構中處理的架構類型。無論如何都很樂意在這裡回答問題。
上面關於退避和子工作流隔離的答案很好。三件在生產環境中會出問題但還沒被提到的事。
不要重試每個失敗。 只有 429 和 5xx 值得重試。400、401 或 403 每次嘗試都會以相同方式失敗，所以重試只會浪費你的重試預算，讓憑證問題看起來像是速率限制問題。在重試邏輯之前檢查狀態碼，而不是之後。這是「我的重試沒有幫助」最常見的原因。
在退避中添加抖動。 純粹的指數退避意味著在同一時刻被限流的每個並行項目都會在同一時刻重試，你會以同步的方式重新觸發限制。將每次延遲隨機化大約正負 30%。有十個並行項目時，這是在第二次嘗試恢復和花一分鐘崩潰之間的區別。
使重試的寫入具有冪等性。 這才是真正會虧錢的。如果 POST 超時或返回 502，你通常不知道伺服器是否處理了它。重試可能會創建兩次記錄。如果 API 支持冪等性鍵，請發送一個並在同一邏輯操作的重試中重複使用。如果不支持，在首次嘗試後的任何嘗試中檢查該記錄。重試讀取是免費的；重試寫入不是。
關於你的 retry_after: 30 例子還有一件事：當 API 發送該值時應尊重該值而不是你自己的退避曲線。還值得知道的是，429 背後有兩種不同的情況，它們需要不同的響應。每個端點的時間窗口限制意味著配額在固定重置時間之前已耗盡，唯一的解決方案是等待和控制你的請求速率。一般服務限流意味著你現在發送速度太快，所以退避加上降低並發會清除它。如果響應包含重置時間戳，你處於第一種情況；如果它只包含 Retry-After，你通常處於第二種情況。
