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·프록시·앱 정책

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)