logo
GeekFormat

Rate Limit 헤더 파서

비율 제한 헤더 파서

새로운 RateLimit-* 헤더와 일반적인 X-RateLimit-* 헤더 모두와 호환되어 나머지 할당량, 재설정 시간 및 재시도 창을 결정하는 데 도움이 됩니다.

표준 RateLimit-*

1개 표준 제한 창재설정: 18s
Window #1limit: 100창: 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
  }
}

온라인 Rate Limit 헤더 파싱, API 속도 제한 상태를 한눈에 확인하세요.

관련 추천

사용 사례

  • API 호출 시 429 Too Many Requests 오류 발생 시 Rate Limit 헤더를 분석하여 원인 파악
  • Retry-After 헤더를 파싱하여 재시도 가능 시간 계산
  • API 클라이언트 개발 시 속도 제한 상태를 모니터링하여 요청 전략 최적화
  • 서버 측 Rate Limit 구성 검증 및 디버깅

주요 기능

  • Rate Limit 헤더 구조화 파싱: 남은 요청, 제한, 재설정 시간을 명확하게 표시
  • API 디버깅에 유용: 429 오류 원인 분석과 속도 제한 상태 확인
  • Retry-After 분석: 재시도 가능 시간을 계산하여 자동 재시도 전략 수립
  • 결과를 바로 복사: JSON 형식 결과를 문서나 스크립트에 직접 활용

이용 방법

  1. HTTP Rate Limit 응답 헤더 문자열을 입력하세요(X-RateLimit-*, Retry-After 등)
  2. 도구가 자동으로 헤더를 파싱하여 남은 요청, 제한, 재설정 시간을 표시
  3. Retry-After 시간과 재시도 권장 시간을 확인하세요
  4. JSON 형식 결과를 복사하여 API 디버깅이나 문서에 활용

자주 묻는 질문

Rate Limit 헤더는 무엇인가요?

Rate Limit 헤더는 API의 현재 속도 제한 상태를 나타내며 남은 요청 수, 최대 제한, 재설정 시간 등을 포함합니다.

429 오류가 발생했을 때 어떻게 해야 하나요?

Rate Limit 헤더를 확인하여 남은 요청 수와 재설정 시간을 파악하고 Retry-After 헤더가 있다면 해당 시간 후에 재시도하세요.

Retry-After 헤더는 어떻게 해석하나요?

Retry-After는 초 단위 숫자 또는 HTTP 날짜 형식으로 재시도 가능 시간을 나타냅니다.

API 개발과 디버깅에 적합한가요?

네. API 클라이언트 개발, 속도 제한 모니터링, 429 오류 디버깅에 모두 적합합니다.