exceeded retry limit, last status: 429 - Codex
Quick fix
限制客户端并发与重试频率,并通过 SQL 修复 cc-switch 热切换导致自动故障转移失效的 Bug,以应对供应商 429 限流。
Symptom
Section titled “Symptom”exceeded retry limit, last status: 429 Too Many Requests当使用 cc-switch 代理请求智谱 GLM 或 MiniMax 等供应商时,若遇到网络抖动或供应商限流(如高峰期倍率扣减触发 429),客户端会进入高频重试循环(client-side retry storm)。如果重试策略缺乏指数退避,连续的 429 响应会加剧重试风暴,导致 token 额度瞬间耗尽并报错。
此外,cc-switch 存在一个 Bug:在托盘菜单手动热切换 provider 时,会将数据库中的 auto_failover_enabled 重置为 0。这导致自动故障转移功能失效,当主用节点返回 429 时,系统不会自动切换到备用节点,而是持续报错且不切换。
在 cc-switch 前置代理(如 Nginx)中设置单分钟最大请求数(如 max_requests = 10)和单次对话 max_tokens,物理拦截重试风暴,防止额度快速耗尽。
完全退出 cc-switch,使用 SQL 工具打开数据库,执行更新语句将 auto_failover_enabled 强制设为 1,确保遇到 429 时能自动切换备用节点。
-- cc-switch.dbUPDATE proxy_config SET auto_failover_enabled=1 WHERE app_type='claude';在官方修复此 Bug 前,修改配置后请通过冷启动(完全退出并重启 cc-switch)生效,绝对避免使用托盘菜单手动切换 provider,以免开关再次被静默重置为 0。
确认使用的 API Key 正确,且智谱 GLM 使用的是 Coding Plan 专属链接(新版本已修复预设)。尽量将高并发任务安排在非高峰时段(避开 14:00-18:00 UTC+8)以降低限流概率。
Affected Versions
Section titled “Affected Versions”Source Issues
Section titled “Source Issues”本页汇总自 3 个真实 issue
- 为什么我的 token 额度几分钟就花光了?
- 这是 client-side retry storm 导致的。当供应商返回 429 或超时时,客户端如果没有正确的指数退避策略,会以极高频率(如 100+次/秒)疯狂重试,导致额度快速消耗。
- 日志显示 enabled=true,为什么遇到 429 还是不自动切换?
- 日志中的 enabled=true 仅来自前端 UI 的 toggle 路径。如果你曾通过托盘菜单手动切换过 provider,数据库中的 auto_failover_enabled 会被静默重置为 0,导致实际运行态失效。
- 智谱 GLM 总是报 429 是配置错了吗?
- 不一定是配置错误。智谱 GLM 在 14:00-18:00 (UTC+8) 高峰期会按 3 倍速率扣减配额,极易触发限流。此外,请确保你使用的是 Coding Plan 的专属链接,并检查 API Key 对应的账号是否正确。
这是一个非官方社区 wiki,与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。