HTTP 429 Too Many Requests 해결: Retry-After·재시도 백오프·Nginx 제한 확인

그림: 429를 받으면 제한 위치와 재시도 시각을 확인하세요.

API나 로그인 요청에서 429 Too Many Requests가 나오면 일정 시간 동안 허용량보다 많은 요청을 보낸 것입니다. 즉시 무한 재시도하면 서비스를 더 압박합니다. 어느 계층이 제한했고 Retry-After가 있는지 먼저 확인하세요.

1. 429를 반환한 계층을 찾는다

브라우저 개발자 도구 또는 curl -i로 응답 헤더, 요청 ID, 시간을 기록하세요. API 제공자, CDN·WAF, Nginx, 앱 각각에서 429를 반환할 수 있습니다. 같은 IP의 모든 사용자가 실패하는지, 한 API 키만 실패하는지 비교하면 제한 기준을 좁힐 수 있습니다.

curl -i https://example.com/api/resource
sudo tail -n 100 /var/log/nginx/error.log

2. Retry-After를 우선 따른다

429 응답에는 Retry-After가 포함될 수 있습니다. 값은 기다릴 초 또는 HTTP 날짜입니다. 클라이언트는 그 이후 재시도하고, 헤더가 없다면 짧은 지수 백오프와 무작위 지연을 적용하세요. 최대 재시도 횟수와 전체 제한 시간이 없으면 요청 폭주가 생깁니다.

관찰	클라이언트 대응	운영자 점검
Retry-After 있음	지시 시각 이후 재시도	헤더와 정책 일치 여부
헤더 없음	백오프·무작위 지연	제한 기준 문서화
특정 계정만 429	동시 요청 줄이기	API 키 한도
모든 사용자 429	폭주 요청 중단	WAF·프록시·앱 정책

헤더를 읽어 대기 시간과 남은 예산을 따로 판단하기

HTTP 사양의 Retry-After는 HTTP 날짜 또는 음수가 아닌 정수 초를 허용합니다. 날짜는 수신 시각과의 차이로 대기 시간을 계산합니다. 다음은 수신 시각을 Mon, 12 Oct 2026 03:00:00 GMT, 남은 전체 재시도 예산을 30초로 고정한 로컬 계산 결과입니다. 예시 날짜는 IMF-fixdate 형식이며 모든 HTTP-date 형식을 처리하는 파서 구현은 아닙니다.

헤더 입력	계산한 대기	판단
2	2초	대기 후 예산 재확인
Mon, 12 Oct 2026 03:00:05 GMT	5초	대기 후 예산 재확인
Mon, 12 Oct 2026 02:59:55 GMT	0초	재시도 횟수·정책은 여전히 적용
없음 / soon / -1 / 1.5	유효 지연 없음	제공자 정책·제한된 백오프
120	120초	남은 30초보다 길어 중단

서버가 120초를 지시했는데 예산이 30초라고 대기 시간을 30초로 잘라 요청하면 지시보다 일찍 재시도하게 됩니다. 이 경우 현재 작업을 중단하고 지연·실패 상태를 반환하거나 별도 예약 작업으로 넘기는 정책을 정하세요. 과거 날짜의 계산값이 0이어도 무한 즉시 재시도는 허용하지 않습니다. 헤더 누락·잘못된 값에는 최대 횟수·전체 시간 제한이 있는 백오프를 적용하고 쓰기 요청은 중복 방지 조건도 확인해야 합니다.

2026년 10월 12일 Node.js 24.6.0, macOS arm64에서 위 고정 입력 8건의 계산과 예산 분기를 확인했습니다. 외부 API 요청, 실제 대기·재전송, Nginx 429 재현, 운영 장애 복구를 수행한 시험은 아닙니다.

3. 쓰기 요청 재시도는 조심한다

GET과 주문 생성 POST는 다릅니다. 쓰기 요청을 재시도하려면 API의 멱등성 키 지원을 확인하세요. 이미 서버에서 성공했지만 응답만 유실됐을 가능성이 있습니다. 상태 조회 방법 없이 쓰기 요청을 반복하면 중복 데이터가 생길 수 있습니다.

4. 실제 제한 정책을 찾아 수정한다

Nginx의 요청 제한 모듈을 쓴다면 zone·요청 속도·burst·거절 상태 코드를 확인하세요. 기본 거절 응답이 항상 429라고 가정하면 안 됩니다. API 제공자가 429를 반환했다면 Nginx 설정 변경은 해결책이 아닙니다. WAF 이벤트와 정상 고객 요청을 대조해 오탐을 조사하세요.

5. 운영 점검표

1. 응답 헤더와 요청 ID를 기록합니다.
2. 주체별 동시 요청과 빈도를 측정합니다.
3. 429를 반환한 계층을 특정합니다.
4. 백오프와 최대 재시도를 설정합니다.
5. 쓰기 요청의 중복 방지 정책을 시험합니다.
6. 정상 사용자 지연과 429 비율을 관찰합니다.

프록시에서 504도 난다면 Nginx 504 점검 가이드를 참고하세요. 429와 504는 원인이 다릅니다.

6. 자주 묻는 질문

Q. 몇 초 뒤 재시도하나요?
Retry-After를 우선 따르고 없으면 제공자 정책과 백오프를 사용하세요.

Q. 서버 장애인가요?
정상 제한일 수도, 클라이언트 호출 폭주나 오탐일 수도 있습니다.

Q. 프록시 한도를 늘리면 되나요?
먼저 프록시가 429를 반환했는지 확인하세요.

공식 자료: MDN 429 · MDN Retry-After · Nginx 요청 제한 (확인일: 2026-09-25)