AnyRouter 429 怎么办？先分网页、API 与上游限流
简答：先判断你遇到的是浏览器打开页面时的 429，还是 API 请求返回的 429：网页 429 先检查浏览器、Cookie、出口 IP 和 CDN/WAF 风控；API 429 先保存 Retry-After、error.code、响应体和请求头；如果响应明确来自上游模型，再按供应商容量或 BYOK 处理。本文截至 2026-11-01 整理一套从现场分流到最小请求、退避重试和免费模型排查的步骤。
定义：AnyRouter 429 是 HTTP 429 Too Many Requests，表示某个访问层或模型供应商要求客户端降低请求频率；它不自动等于 API Key 失效。
30 秒速查：先确认是哪一类 429
本站是独立的 AI API 接入与排障指南，不是相关服务的官方站点。先不要连续刷新页面或无间隔重试 API；把浏览器现象与 API 响应分开记录。
| 现场 | 识别线索 | 先做什么 |
|---|---|---|
| 浏览器打开页面 429 | 地址栏页面直接显示 429，通常还没有 API 响应体 | 暂停刷新；检查是否仅当前浏览器或出口 IP 受影响，清理站点 Cookie 后重新打开，并确认网络出口、代理或企业网关没有频繁请求。 |
| API 网关 429 | 程序收到 HTTP 429，并能看到 JSON 的 error.code、message 或 metadata | 记录 Retry-After、X-RateLimit-* 和完整错误体，降低并发后按退避重试。 |
| 上游模型 429 | 响应消息明确写出供应商、免费容量或上游 429 | 等待上游恢复、换当前可用模型，或按文档配置自己的供应商 Key；不要把它当成 API Key 必然失效。 |
HTTP 429 的通用含义是单位时间内请求过多，响应可能带有 Retry-After，用于提示客户端何时再次请求。可查看 MDN 对 HTTP 429 的说明。如果你访问的是 anyrouter.cfd 页面，不要直接假定该页面域名就是 API Base URL；当前公开 API 文档列出的 Base URL 是 https://anyrouter.dev/api/v1，实际接入仍应以你当前使用的文档和响应为准，详见 API Overview。
网页访问 429：不要用 API 重试代码处理浏览器拦截
如果 429 出现在浏览器页面、控制台或站点首页，而不是你的模型请求响应中，先按“访问层”排查。页面 429 可能与短时间刷新、多个标签页或程序共享同一出口 IP、Cookie/Session 状态异常、企业网关以及 CDN/WAF 风控有关；仅凭页面状态码无法判断具体原因。
- 确认范围：用同一浏览器的新无痕窗口测试一次，再用另一个网络或设备对比。不要在短时间内反复刷新。
- 确认会话：检查 Cookie 是否被禁用、登录状态是否过期，必要时清理该站点 Cookie 后重新登录。
- 确认请求来源：暂停自动刷新、浏览器插件、脚本和多个并发标签页；如果是企业网络，询问是否存在统一出口或安全网关。
- 确认是否只有页面受影响：浏览器页面能打开不代表 API 一定可用，页面 429 也不应直接套用 API Key、模型和请求体排查。
- 记录再求助：保存发生时间、页面地址、浏览器开发者工具中的状态码和请求 ID；不要公开 Cookie、Session 或 API Key。
若换浏览器、暂停刷新并等待后仍只有页面访问受限，应通过当前服务提供的支持入口核查，而不是继续提高刷新频率。本文不把网页 429 推断为平台整体不可用。
API 429：先看 error.code、Retry-After 和请求头
当前错误文档说明，API 错误采用包含 error.message、error.code 和可选 error.metadata 的结构；429 属于可以退避重试的状态码。具体字段是否出现在每个接口、每次响应中，应以实际响应为准，详见 Errors 文档。
| 看到的字段或现象 | 更可能的方向 | 动作 |
|---|---|---|
rate_limit_exceeded | 账号、API Key 或当前模型请求速率超过限制 | 优先等待 Retry-After，降低并发和 Agent 循环次数。 |
ip_rate_limit_exceeded | 出口 IP 或匿名请求触发限制 | 确认请求是否正确携带认证，排查同一出口下的多个进程、插件和任务。 |
| 响应明确指出上游 429 | 模型供应商或共享免费容量繁忙 | 等待、换模型，或按当前 BYOK 文档配置自己的供应商 Key。 |
| 只有 HTTP 429，没有更多字段 | 信息不足，不能直接判断限流层 | 保存完整响应头和响应体，先发一个最小请求，不要猜测固定阈值。 |
限流页面介绍了按 IP、API Key、账号或请求类型实施限制的可能性，也列出了 X-RateLimit-Tier 等响应头。阈值、套餐和模型目录可能变化，不能把某个数字当作永久规则；排查时以当前响应和文档为准，参见 Rate Limits 文档。
最小 curl 验证：下面示例只适用于已确认使用该 API 文档的接入场景。不要把 anyrouter.cfd 页面地址与 API 地址自动拼接；Base URL、路径和模型 ID 应来自当前接入文档。
export ANYROUTER_API_KEY='替换为推理 API Key'
export MODEL_ID='替换为当前可用模型'
curl -i 'https://anyrouter.dev/api/v1/chat/completions' -H "Authorization: Bearer $ANYROUTER_API_KEY" -H 'Content-Type: application/json' -d "{\"model\":\"$MODEL_ID\",\"messages\":[{\"role\":\"user\",\"content\":\"Reply with OK\"}]}"
如果接口文档要求的是其他域名、路径或兼容协议，应替换完整地址，不要重复拼接 /v1。认证 Key 类型也要按当前 API 文档核对；公开文档将推理 Key 与管理用途 Key 分开说明，详见 API Overview 的认证部分。
按顺序排查：凭据→地址→模型→最小请求→状态码
- 确认凭据：检查环境变量是否为空、是否包含首尾空格、是否在请求头中使用了
Bearer，并确认它是用于推理的 Key。不要把完整 Key 写入仓库、截图或公开日志。 - 确认地址：核对当前文档中的 Base URL 和 endpoint。OpenAI 兼容客户端可能自行追加
/v1，因此要避免把/api/v1或/v1重复拼接。 - 确认模型：使用当前模型目录中的完整模型 ID。历史文章、旧配置或猜测的模型名可能导致 404，而不是 429。
- 发最小请求：只保留一个短文本、一次调用和非流式响应，先排除长上下文、工具调用、流式输出和 Agent 循环。
- 按状态码分流：429 才进入退避逻辑；401 先查认证，403 查权限或套餐，404 查路径和模型，400/422 查请求体，5xx 再按服务端或上游错误处理。错误文档明确将多数 4xx 标为不应直接重试。
PowerShell：$env:ANYROUTER_API_KEY='替换为推理 API Key'
$env:MODEL_ID='替换为当前可用模型'
$body=@{model=$env:MODEL_ID;messages=@(@{role='user';content='Reply with OK'})}|ConvertTo-Json -Depth 5
curl.exe -i 'https://anyrouter.dev/api/v1/chat/completions' -H "Authorization: Bearer $env:ANYROUTER_API_KEY" -H 'Content-Type: application/json' --data-raw $body
Windows CMD：set ANYROUTER_API_KEY=替换为推理 API Key
set MODEL_ID=替换为当前可用模型
curl.exe -i https://anyrouter.dev/api/v1/chat/completions -H "Authorization: Bearer %ANYROUTER_API_KEY%" -H "Content-Type: application/json" --data-raw "{\"model\":\"%MODEL_ID%\",\"messages\":[{\"role\":\"user\",\"content\":\"Reply with OK\"}]}"
Python 重试示例：兼容秒数和 HTTP-date
优先使用响应中的 Retry-After。它可能是整数秒，也可能是 HTTP 日期；下面代码两种格式都尝试解析，并设置最大等待时间，避免错误响应让任务无限睡眠。示例只重试 429，最多 5 次；实际项目还应设置并发上限、总超时和任务取消。
import os
import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
import requests
URL = 'https://anyrouter.dev/api/v1/chat/completions'
API_KEY = os.environ['ANYROUTER_API_KEY']
MODEL_ID = os.environ['MODEL_ID']
HEADERS = {'Authorization': f'Bearer {API_KEY}', 'Content-Type': 'application/json'}
PAYLOAD = {'model': MODEL_ID, 'messages': [{'role': 'user', 'content': 'Reply with OK'}]}
def retry_after_seconds(value, cap=60):
if not value:
return None
try:
return max(0, min(float(value), cap))
except ValueError:
try:
target = parsedate_to_datetime(value)
if target.tzinfo is None:
target = target.replace(tzinfo=timezone.utc)
seconds = (target - datetime.now(timezone.utc)).total_seconds()
return max(0, min(seconds, cap))
except (TypeError, ValueError, OverflowError):
return None
for attempt in range(5):
response = requests.post(URL, headers=HEADERS, json=PAYLOAD, timeout=60)
if response.status_code != 429:
response.raise_for_status()
print(response.json())
break
wait = retry_after_seconds(response.headers.get('Retry-After'))
if wait is None:
wait = min(30, 2 ** attempt) + random.random()
time.sleep(wait)
else:
raise RuntimeError('429 after maximum retries')
这段代码需要先安装 requests，并在运行前设置 ANYROUTER_API_KEY 与 MODEL_ID。如果服务返回的是供应商 429，机械重试可能只会延长等待，应结合错误消息、Provider 字段或日志中实际提供的路由信息判断；如果这些字段没有返回，就写成“未提供”，不要自行推断。
免费模型持续 429：等待、降并发、换模型还是 BYOK
免费模型 429 至少要区分“自己的请求速率过高”和“上游共享容量不足”。当前公开指南将这两类原因分开：前者适合等待 Retry-After、降低循环速率或调整计划；后者可能需要等待容量恢复、换模型，或添加自己的供应商 Key，具体见 免费模型限流与 BYOK 指南。
- 先暂停突发请求：把并发降到 1，停止批处理，给 Agent 设置最大工具轮数和失败后的等待时间。
- 再看模型类型：如果是
:free或文档所述免费模型，不能只凭一次 429 断定 Key 失效。 - 如果是共享容量不足：等待一段时间或从当前模型目录选择其他可用模型。模型和供应商状态会变化，使用前重新核对目录。
- 如果需要自己的供应商额度：按照当前 BYOK 页面添加并保存供应商 Key，先确认供应商账户、Key 权限和费用规则。BYOK 不是永久可用或无限制的保证。
- 验证结果：再次发送短请求；如果响应或日志提供 Provider、费用或请求 ID，再记录这些字段。若没有提供，不要补写不存在的字段。
任何 Key 都不要放进前端公开代码、浏览器脚本或公开仓库。误上传后应立即撤销并重新生成。
仍然 429 时的最终清单
- 网页还是 API：浏览器页面 429 与 API JSON 429 分开记录。
- 是否重复请求：检查多个进程、IDE 插件、定时任务和 Agent 是否共用同一 Key 或出口 IP。
- 是否读取等待时间：优先解析
Retry-After，没有时才使用带随机抖动的指数退避。 - 是否超过最大重试：设置最大次数、最大等待和总超时，不要无限重试。
- 是否为上游：只有响应明确提供供应商或上游信息时，才按上游限流处理；否则标记为未核实。
- 是否保存证据：记录时间、URL、模型 ID、状态码、错误体、响应头和请求 ID，并脱敏 Key、Cookie 与 Session。
- 是否误用地址：不要因为页面域名是
anyrouter.cfd，就直接把它当成 API Base URL；重新核对当前接入文档。
如果最小请求在等待、降并发并确认模型后仍持续返回 429，建议通过当前服务的支持渠道提交脱敏后的时间、模型、错误码和响应头。本文不据此判断服务状态、价格或长期可用性。
商业推荐
如果你正在寻找便于统一管理 API Base URL、Key 与限流排查的接入方案，可了解犀速 AI 的相关接入方式，具体能力与当前规则以其官网说明为准。
常见问题
打开 AnyRouter 页面显示 429，能直接运行 API 重试代码吗？
不能直接判断。页面 429 属于浏览器、会话、出口 IP 或 CDN/WAF 访问层现象，应先暂停刷新并检查 Cookie、Session、插件和网络出口；只有 API 请求返回 JSON 429 时，才进入 Retry-After 和退避排查。
anyrouter.cfd 页面地址和 API Base URL 是同一个吗？
不能默认认为相同。当前公开 API 文档列出的 Base URL 是 https://anyrouter.dev/api/v1；页面域名、API 域名和兼容客户端追加的路径应分别按当前接入文档核对。
AnyRouter 429 是 API Key 失效吗？
通常不能这样判断。429 表示某个访问层或模型供应商要求降速；认证错误更应检查 401，但最终应以实际 error.code、响应体和请求头为准。
Retry-After 返回日期格式时怎么办？
不要只用 float 解析。Retry-After 可能是秒数或 HTTP 日期，客户端应兼容两种格式，并设置最大等待时间；本文 Python 示例已包含这两种解析方式。
免费模型一直返回 429，换一个 API Key 一定有用吗？
不一定。如果是自身请求速率过高，应等待并降低并发；如果是共享免费容量不足，换模型、等待或按当前 BYOK 文档添加自己的供应商 Key 更有针对性。
为什么 429 不能像 401、403、404 一样一直重试？
429 通常可以带退避重试，但 401、403、404 多数对应认证、权限或路径问题，重复发送不会修复配置。先按状态码分流，再决定是否重试。
相关阅读
- 继续核对 Codex 的 Base URL、Key 与 Responses API
- 如果同时出现 403 或余额提示，查看权限与账户排查步骤
- 使用 Cursor 时，先用最小 curl 请求验证 OpenAI 兼容 API
- 配置 Cursor 的第三方 API 时，查看 Base URL、Key 与模型设置
参考资料
- Errors：API 错误格式、状态码与重试行为（docs.anyrouter.dev）
- Rate Limits：IP、API Key 与账号限流说明（docs.anyrouter.dev）
- API Overview：Base URL、端点与认证 Key 类型（docs.anyrouter.dev）
- 免费模型限流与 BYOK 处理指南（docs.anyrouter.dev）
- MDN：HTTP 429 Too Many Requests