限流 429 api proxy

Error 429 Too Many Requests

連續 429 多半是上游帳號池限流、冷卻或額度耗盡。先讓服務商換號、換線路或換模型,再用最小請求排除本地並發、餘額和重試循環問題。

錯誤摘要

報錯:exceeded retry limit, last status: 429 Too Many Requests, request id: <request-id>。AI 中轉站裡連續 429 多半是上游帳號池限流、冷卻或額度耗盡,先讓服務商換號、換線路或換模型。

#error 429 #429 too many requests #openai api 429 #claude code 429 #codex 429 #exceeded retry limit 429

這個錯誤是什麼意思

Error 429 表示服務端理解了請求,但目前不願意繼續處理,因為請求頻率、並發、token 消耗或帳號額度觸發了限制。

在 AI 中轉站裡,重點看中轉站背後的上游帳號池,而不是反覆重試同一個 API Key。只要帳號池已經冷卻或耗盡,繼續重試只會把 429 放大。

常見原因

  1. 中轉站背後的上游帳號池觸發限流、進入冷卻,或可調度帳號已經沒有可用額度。
  2. 目前模型通道沒有可用計費、模型級限制被打滿,或該線路暫時沒有健康帳號。
  3. 中轉站對你的 API Key 做了限流,即使其他帳號池或上游官方 API 還有容量,也可能返回 429。
  4. Claude Code、Codex、Cursor 或其他工具可能會自動重試失敗請求,把一次失敗變成很多次請求。
  5. 高上下文 prompt、串流任務、批處理任務或 coding agent 循環可能比普通聊天更快消耗 token。

AI 中轉站報 429 怎麼排查

先用相同的 Base URL、API Key 和模型名發一個最小請求。如果最小請求也返回 429,問題更可能在額度、計費、provider 限制或中轉站限流。

如果最小請求正常,但 coding tool 失敗,重點檢查並發和重試循環。Coding agent 在讀文件、調用工具、恢復失敗步驟時,可能快速發出很多請求。

AI 中轉站報 429 怎麼解決

  1. 先等待再重試。如果回應裡有 Retry-After header,按它給出的時間等待,不要立刻重複發送同一個請求。
  2. 檢查服務商控制台裡的餘額、計費狀態、每日額度、請求限制和模型級限制。
  3. 確認目前中轉站方案或 API Key 支援的並發數上限,再降低並發、減少 max output tokens、縮短 prompt,避免多個 coding agent 會話共用同一個 API Key 同時跑。
  4. 如果目前 Claude Code、Codex 或 Cursor 會話連續出現 429,但最小請求本身正常,可以先停止目前任務,等待一段時間後新開一個對話或新會話重試。
  5. 如果 429 持續出現,聯絡中轉站售後客服,並附上報錯時間、模型名、Base URL、請求工具和完整錯誤資訊,讓客服確認是否是帳號池、額度或線路限流。

相關錯誤

Claude Code / Codex 503 No available accounts:中轉站帳號池不可用排查 先不要盲目換 Key。這個錯誤通常說明帳號池、供應商、分組或模型路由暫時不可用。先測最小請求、確認模型和分組,再判斷是等待恢復、降低上下文,還是換 provider。 Codex: Selected model is at capacity. 模型容量已滿排查 報錯:Selected model is at capacity. Please try a different model. 先把它當作模型級容量、Admission 或串流中斷問題處理。它可能出現在官方 ChatGPT 登錄態 Codex CLI,也可能來自中轉站帳號池或 Sub2API 上游 overloaded 透傳。 Codex 提示:你的對話中有多個可能的網路安全風險的標記 提示:你的對話中有多個可能的網路安全風險的標記。先把它當作 OpenAI/Codex 安全路由觸發,而不是直接判斷帳號或中轉站故障;再檢查是否使用了中轉 API、敏感關鍵詞、超長程式碼上下文或不透明模型路由。 Error 401 Unauthorized:AI API 中轉站認證排查 401 是認證失敗訊號。先檢查目前載入的是哪一個 Key、請求打到哪個 Base URL、header 格式是否正確,以及這個 Key 是否仍然在對應 provider 中有效。 Codex 提示:此聊天已被標記為可能存在網路安全風險 Codex 提示「此聊天已被標記為可能存在網路安全風險」時,先不要把它當作中轉站故障或封號。它更像是系統級網路安全風險標記;普通開發誤觸發時,優先新開會話、縮小上下文、重新表述任務。 Codex 報錯 stream disconnected before completion: Upstream request failed Codex 報 stream disconnected before completion: Upstream request failed 時,先不要只看普通 curl 或 hello 請求。這類錯誤更常出現在 Codex 的 Responses 串流、SSE / WebSocket 長連線、中轉站上游或客戶端版本變化上。

相關教程

相關主題

常見問題

常見問題

Error 429 一定是服務商掛了嗎?

不一定。它更常見是限流、額度、計費或重試循環問題。先看餘額、請求限制和 Retry-After,再判斷是不是服務商故障。

為什麼 Codex 或 Claude Code 更容易遇到 429?

Coding agent 會讀文件、規劃修改、調用工具、重試失敗請求。一次互動任務可能比普通聊天消耗更多請求數和 token。

遇到 429 要立刻換中轉站嗎?

不要先換中轉站,先讓目前中轉站換可用帳號、換線路或換模型。只有多個帳號池或線路都持續 429,且最小請求也失敗時,換 provider 才有意義。