这是什么
一个免费的限流响应头解读工具。它能看懂 Retry After、X RateLimit 系列、IETF RateLimit 字段，以及 GitHub、OpenAI、Anthropic、Shopify 和 Discord 的格式。
用大白话解释 429
你的 API 返回了 429。来看看它真正的意思。
粘贴响应头。Rate Limit Story 会读出限额、剩余次数、重置时间和需要等待多久，然后写成一个四格故事，再附上一段可以直接发给撞墙客户的回复。
- 客户端
正在发送第 501 批，共 600 批…
- API
请求太多了！令牌桶已经空了。
- Rate Limit Story
等 20 秒，再加一点随机延迟重试。
适合谁用
API 提供方、开发者支持、合作伙伴经理，以及刚收到客户一张没头没尾的 429 截图的任何人。
解决什么问题
限流响应头晦涩难懂，Unix 时间和秒数混在一起，每家厂商还各不相同。大家只能靠猜，重试太快，结果被封得更久。
讲讲这次响应的故事
所有内容都在当前标签页中解析。你粘贴的内容不会被上传或保存。
加载样例
可以粘贴原始响应头、curl -i 的输出，或由响应头组成的 JSON 对象。状态行可有可无。还没有故事
粘贴一次失败调用的响应头，或者加载一个样例。
响应头不会离开这个页面。不过分享截图前，最好还是删掉认证和 Cookie 相关的响应头。
能看懂的响应头
同一次粘贴里可以混合不同风格的响应头。名称不区分大小写。
Retry After
Retry-After: 20秒数或 HTTP 日期。只要出现，就优先于其他所有重置提示。
X RateLimit 系列
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1792661820GitHub、Twitter 风格的 API 以及很多其他服务都在用。重置值可能是 Unix 秒、毫秒或从现在起的秒数，工具会告诉你它按哪种解读。
IETF RateLimit
RateLimit-Policy: "default";q=100;w=60
RateLimit: "default";r=7;t=42标准字段，包含配额、窗口、剩余次数和距重置的时间。
OpenAI 与 Anthropic
x-ratelimit-remaining-tokens: 0
x-ratelimit-reset-tokens: 18.4s请求和令牌分开计数，时长写成 6m0s 这样的格式。用光的那个桶会被标记为卡住你的桶。
Shopify 与 Discord
X-Shopify-Shop-Api-Call-Limit: 38/40
X-RateLimit-Reset-After: 2.75已用和总量计数、按秒重置、额度桶、作用范围以及全局限流。
使用方法
复制响应头
来自浏览器的网络面板、curl -i、日志，或者客户发来的截图。只有响应头那几行有用。
粘贴并生成故事
每个额度桶单独解读，已经用光或最接近用光的那个就是故事的主角。
看懂四格漫画
发生了什么、你的处境、何时重置、该怎么做，时间同时用 UTC 和你的本地时区显示。
发送回复
把现成的回复复制到工单里，或者复制完整故事留作自己的记录。
注意事项
- 它只解释你粘贴的响应头，不会调用 API，也看不到 API 没有公开的限额。
- 重置值有歧义时，大于十亿的数字按 Unix 时间处理，较小的按秒处理。
- 安全节奏需要同时知道限额和窗口时长。很多 API 只发送限额。
- 本地时间使用这台设备的时钟。
常见问题
为什么 GitHub 返回 403 而不是 429？
GitHub 对部分超限调用返回 403。只要剩余次数为零，故事仍会把它当作被限流。
Retry After 和重置时间，以哪个为准？
以 Retry After 为准。它是服务器明确告诉你要等多久，而重置时间描述的是整个窗口。
随机延迟是什么，为什么要加？
一小段随机的额外等待。没有它，所有被拦下的客户端会在同一秒重试，再次触发限流。
粘贴真实的响应头安全吗？
页面不会向任何地方发送数据。不过分享之前，还是请删掉 Authorization 和 Cookie 相关的响应头。