Rate Limit Header 解析器

限流响应头解析

同时兼容新的 RateLimit-* 头和常见的 X-RateLimit-* 头，帮助你判断剩余额度、重置时间和重试窗口。

标准 RateLimit-*

1 个标准 limit 窗口reset: 18s
Window #1limit: 100window: 1m 0s
100;w=60

旧版 X-RateLimit-*

Limit
5000
Remaining
4991
Used
9
Reset (epoch)
2025/04/14 16:00:00
Retry-After
1m 0s
Resource
-

JSON 预览

{
  "headers": {
    "x-ratelimit-limit": [
      "5000"
    ],
    "x-ratelimit-remaining": [
      "4991"
    ],
    "x-ratelimit-used": [
      "9"
    ],
    "x-ratelimit-reset": [
      "1744617600"
    ],
    "retry-after": [
      "60"
    ],
    "ratelimit-limit": [
      "100;w=60"
    ],
    "ratelimit-remaining": [
      "25"
    ],
    "ratelimit-reset": [
      "18"
    ]
  },
  "standard": {
    "limit": [
      {
        "raw": "100;w=60",
        "amount": 100,
        "windowSeconds": 60,
        "parameters": {
          "w": "60"
        }
      }
    ],
    "remaining": [
      {
        "raw": "25",
        "amount": 25,
        "windowSeconds": null,
        "parameters": {}
      }
    ],
    "reset": "18",
    "policy": ""
  },
  "legacy": {
    "limit": "5000",
    "remaining": "4991",
    "used": "9",
    "reset": "1744617600",
    "resource": "",
    "retryAfter": "60",
    "retryAfterSeconds": 60
  }
}

在线看限流头，429 到底卡在哪一眼就知道。

相关推荐

Link Header 解析器

Hreflang Generator

HSTS Analyzer

HTTP Cookie解析器

Meta Tag 生成器

Cron 表达式工作台

适用场景

  • 接口频繁返回 429 时，先拆开限流响应头判断是额度用完还是节流窗口未结束
  • 调用第三方 API 时查看剩余请求次数和重置时间规划调用频率
  • 设计接口重试策略时参考限流窗口大小和 Retry-After 延迟时间
  • 同步限流规则给团队成员说明配额和频控逻辑避免重复触发限流

使用方法

  1. 粘贴 RateLimit 或 X-RateLimit 响应头内容到输入区
  2. 工具自动解析限流窗口、剩余次数、重置时间和 Retry-After 字段
  3. 查看标准格式的窗口列表和传统格式的配额键值对
  4. 根据解析结果调整调用频率或设计退避重试策略

功能特点

  • 双格式解析：同时支持标准 RateLimit-Limit/Remaining/Reset 和传统 X-RateLimit-* 系列头
  • 限流窗口可视化：每个窗口的 amount、windowSeconds 独立展示，配额信息不再挤成一团
  • 重置时间可读化：Epoch 秒数自动转日期时间，秒数自动转可读时长（如 60s → 1 分钟）
  • 完整 JSON 预览：解析结果支持 JSON 预览，适合脚本处理和接口文档记录

常见问题

为什么接口会返回 429 Too Many Requests？

429 通常说明请求频率超过了服务端限制。把 RateLimit 或 X-RateLimit 信息拆开后，就能看清剩余额度和恢复时间。

Retry-After 和重置时间有什么区别？

Retry-After 更偏向告知多久后再试，重置时间则更接近限流窗口恢复节点。结合查看能更准确安排重试策略。

适合排查第三方 API 的调用配额问题吗？

非常适合。无论是开放平台、支付接口还是云服务 API，很多都会通过响应头返回配额信息。

可以帮助做接口重试策略设计吗？

可以。理解剩余次数、限流窗口和恢复时间后，更容易制定退避、排队和重试策略。