你是否在使用 n8n 處理大量數據時，遇到過這個最常見也最令人沮喪的紅色錯誤訊息：「ERROR: Request failed with status code 429」？你的工作流可能在前 50 筆資料時都運作得完美無缺，但就在第 51 筆時，突然崩潰，並告訴你「Too Many Requests」。
這個「429 錯誤」是你在串接外部 API 或進行大規模爬蟲時，必然會遇到的一堵高牆。它不是你的 n8n 流程有 Bug，也不是對方伺服器當機，而是你觸發了 API 服務的「速率限制 (Rate Limiting)」機制。
簡單來說，你的 n8n 流程因為執行速度「太快了」，在短時間內向對方伺服器發送了過多的請求，而被暫時封鎖了。
這篇文章將是你的 n8n Rate Limit 終極指南。我們將帶你深入理解為什麼 API 需要速率限制，並手把手教你如何使用 n8n 內建的 Split In Batches 與 Wait 節點組合，建立一套優雅且萬無一失的流量控制模式，讓你從此告別 429 錯誤，打造出能夠穩定處理海量數據的專業級自動化工作流。
為什麼我會遇到 429 Too Many Requests？認識 API 的「流量管制」
要解決問題，必先理解問題的根源。你可以把 API 伺服器想像成一家熱門酒吧的調酒師。
- 伺服器資源是有限的： 調酒師一次能調製的酒、服務的客人數量都是有限的。同樣地，一台 API 伺服器在單位時間內能處理的請求數量也是有上限的。
- n8n 的自動迴圈是天生的急性子： 當你的 n8n 工作流需要處理 500 筆資料時，它預設的自動迴圈機制會像 500 個口渴的客人，在同一秒內全部衝到吧台前，對著調酒師大喊：「給我一杯酒！」
- 速率限制 (Rate Limit) 就是管制措施： 面對這種突發的巨量請求，調酒師（API 伺服器）為了確保服務品質、防止自己被累垮（伺服器過載），並公平地服務所有客人，他會設立一個規則：「本店每分鐘只接受 60 位客人的點單。」
- 429 錯誤就是「請排隊」的訊號： 當第 61 位客人在同一分鐘內衝過來時，調酒師就會把他擋下，告訴他：「請求過於頻繁，請稍後再來！」這，就是
429 Too Many Requests錯誤的本質。
速率限制是所有公開 API 的標準做法，它不是為了刁難你，而是為了確保服務的公平性與穩定性。而一個專業的自動化開發者，就是要學會如何讓我們的 n8n 工作流，成為一位有禮貌、懂得排隊的「紳士顧客」。
n8n 的 Rate Limit 解決方案：Split In Batches + Wait 節點組合拳
要在 n8n 中優雅地處理速率限制，我們需要一套組合拳，結合兩個核心節點的功能。這個模式，是你處理任何大量迴圈請求時都應該採用的標準架構。
步驟一：用 Split In Batches 節點進行「分流排隊」
這個節點是我們的「排隊管理員」。它能將一大群（例如 500 個）準備衝向吧台的客人（Items），先分成數個可控的小隊伍（Batches）。
- 核心設定：
Batch Size(批次大小)。 - 作用： 如果 API 限制是「每分鐘 60 次請求」，一個非常保險的做法，就是將
Batch Size設定為60或一個更小的數字，例如50。
步驟二：用 Wait 節點實現「間隔休息」
這個節點是我們的「節拍器」。它會在處理完一個批次的請求後，強制整個工作流「休息」一段時間，等時間到了，再放下一批次的請求過去。
- 核心設定：
Time和Unit。 - 作用： 如果 API 限制是「每分鐘 60 次請求」，那麼我們就在處理完一個批次後，使用
Wait節點，設定等待 60 秒 (1 分鐘)。
透過「Split In Batches (分批) + Wait (等待)」的組合，我們就能將原本瞬間爆發的請求，完美地整形 (Shape) 成一個平穩、規律、且完全符合 API 規定的請求流量。
實戰演練：批次更新 CRM 聯絡人，完美遵守每分鐘 100 次的請求限制
- 目標： 我們有 1000 筆需要更新到 HubSpot CRM 的聯絡人資料。HubSpot 的 API 速率限制是「每分鐘 100 次請求」。
- 流程設計：
Read Data->Split In Batches->Wait->HubSpot (Update Contact)
Read Data節點:- 假設這個節點（可能是
Google Sheets或PostgreSQL）讀取了 1000 筆聯絡人資料，並輸出了 1000 個 Items。
- 假設這個節點（可能是
Split In Batches節點:- 將上一步的輸出連接到此節點。
- Batch Size: 設為
100。 - 解說： 這會將 1000 筆資料，切分成
1000 / 100 = 10個批次。n8n 會先將第一個批次（包含 100 個 Items）送往下一個節點。
Wait節點:- Mode:
Relative Time - Time:
60 - Unit:
Seconds - 解說： 這個節點會接收到第一個批次的 100 筆資料，但它本身不做處理，只是讓流程暫停 60 秒。
- Mode:
HubSpot節點:- Operation:
Contact > Update - 解說： 當 60 秒等待結束後，第一個批次的 100 筆資料會送達此節點。n8n 的自動迴圈機制會在這裡生效，節點會執行 100 次，完成這 100 筆資料的更新。
- 當這 100 筆都更新完畢後，整個迴圈的「第一次」執行才算結束。流程會回到
Split In Batches節點，放出第二個批次的 100 筆資料，然後再次進入Wait節點等待 60 秒… 如此循環，直到 10 個批次全部處理完畢。
- Operation:
這個流程的總執行時間大約是 10 分鐘，但它完美地確保了我們每分鐘發出的請求數量，都不會超過 100 次的限制。
更強固的作法：搭配「錯誤處理」自動重試 429 錯誤
「分批等待」是一種「事前預防 (Proactive)」的策略。但有時，因為網路延遲或其他因素，即使我們做了流量管制，還是可能偶爾會遇到 429 錯誤。這時，我們可以用 n8n 的錯誤處理機制，來做「事後補救 (Reactive)」。
在你的 HTTP Request 或 App 節點（如 HubSpot）的 Settings 分頁中，啟用 Retry on Fail：
- On Error:
Retry on Fail - Retries:
1或2次。 - Retry Interval:
60秒。
你可以將這個設定與我們的「分批等待」模式結合使用。這樣一來，即使在某個批次中，因為瞬間的網路抖動，導致第 99 次請求觸發了 429 錯誤，n8n 也會自動等待 60 秒後，為你重試那一次失敗的請求，讓你的工作流更加強固。
讀懂遊戲規則：如何查找與解讀 API 文件的速率限制？
要成為一個負責任的自動化開發者，最好的習慣是「先讀說明書」。在你開始大量呼叫任何一個 API 之前，都應該先去它的官方開發者文件中，找到關於「Rate Limiting」或「API Throttling」的章節。
文件通常會告訴你：
- 限制的維度： 是「每秒」、「每分鐘」還是「每天」？
- 限制的數量： 具體的請求次數是多少？
- 限制的層級： 是針對單一 API Key、單一使用者，還是整個公司的帳號？
- 超限的後果： 是暫時封鎖幾分鐘，還是需要聯繫客服才能解鎖？
理解並尊重這些規則，不僅能讓你的工作流穩定運行，也是維持與 API 供應商良好關係的基礎。
結語
429 Too Many Requests 錯誤，不是 n8n 的敵人，而是 API 世界給我們的一個友善提醒。它提醒我們，自動化的力量需要被溫柔地駕馭。
透過掌握 Split In Batches + Wait 這套優雅的組合拳，你就能夠將 n8n 的極速執行力，轉化為一種可控、平穩、且符合規則的請求節奏。這不僅僅是一個技術技巧，更是一種專業的、負責任的自動化思維。從今天起，就為你所有處理大量數據的迴圈流程，都加上這道「流量管制」的安全閥吧！
更多精選文章請參考
n8n 與 Zapier 比較：該選哪個？2025年最完整功能、費用、優缺點分析
開源自動化工具推薦：從工作流程到測試，找到最適合你的免費方案
n8n 發送 Email 超詳細教學：從 SMTP 設定到 Gmail 節點串接，一篇搞定！
n8n Notion 串接終極指南：2025 年打造自動化工作流程，效率翻倍！
