숫자면 기다릴 초, HTTP 날짜면 그 시각 이후를 뜻합니다
Retry-After는 음수가 아닌 정수 초 또는 HTTP 날짜로 표현할 수 있습니다. 숫자를 밀리초나 Unix 시각으로 읽지 않습니다.429에서는 다음 요청까지 대기,503에서는 예상 이용 불가 기간 등의 단서가 되므로 함께 받은 상태도 봅니다. 헤더가 있다는 사실은 그 뒤 요청 성공의 보장이 아닙니다. 근거: MDN Retry-After, 2026-11-04.
근거: MDN Retry-After · 2026-11-04 확인
120이라는 가상 값은2분 대기 안내입니다
Retry-After: 120을 응답 직후 읽었다면120초를 기준으로 기다립니다. 날짜 형식이면 그 날짜의 시각을 읽어야 하며 사용자 로컬 시각과의 변환을 임의로 생략하지 않습니다. 이 수치는 형식 설명을 위한 가상 값이지 어떤 사이트의 제한 시간을 실측한 것이 아닙니다. 실제 환경에서는 도구가 시간값을 어떻게 파싱하는지와 시스템 시각이 맞는지도 확인할 항목입니다.
근거: MDN Retry-After · 2026-11-04 확인
재시도 전에 요청의 중복 효과를 분리합니다
읽기 조회인지 주문·발송 같은 제출인지 먼저 확인합니다. 대기 안내를 지켰다고 제출을 다시 보내도 된다는 뜻은 아닙니다. 이전 요청이 처리되었는지 작업ID나 조회 경로로 확인하고 API의 재시도·중복 방지 계약을 따릅니다. 대기 중에도 같은 계정을 쓰는 다른 작업이 계속 호출한다면 제한이 유지될 수 있어 호출 주체를 함께 봅니다.
근거: MDN Retry-After · 2026-11-04 확인
안내가 없거나 잘못되었으면 수치를 만들어 채우지 않습니다
헤더가 없다고 즉시 무한 반복하지 말고 공식 문서의 제한과 대기 정책을 확인합니다. 파싱할 수 없는 값은 받은 그대로 비밀 없이 기록해 담당자에게 문의합니다. 어느 대기 규칙도 확인되지 않았다면 고위험 제출의 자동 재시도를 멈추고 결과 확인을 우선합니다. 계정이나 주소를 바꿔 제한을 회피하는 방법으로 문제를 해결하지 않습니다.
성공은 기다린 시간보다 다음 결과로 확인합니다
허가된 범위의 요청이 정상 상태와 예상 본문을 반환하는지 봅니다. 계속429·503이면 상태·헤더·실제 시도 시각·요청ID를 남기고 제한 범위나 장애 공지를 확인합니다. 헤더를 존중한 사실과 서비스 정상화 확인을 별도 결과로 보고합니다. 이 글은 실제 타이머를 돌리거나 재시도 성공을 측정한 사례가 아닙니다.
원문으로 이어 읽기
확인일: 2026-11-04. 정의와 적용 범위, 발행일과 판본을 함께 살펴봅니다. 원문이 존재한다는 사실만으로 개별 주장의 정확성과 재사용 권리가 자동 보장되지는 않습니다.