웹사이트나 API를 사용하다 갑자기 429 Too Many Requests가 나타나면 서버가 고장 난 것처럼 보일 수 있습니다. 재시도 버튼을 여러 번 누르거나 자동화 작업을 바로 다시 실행하고 싶어지기도 합니다.
하지만 429는 서버가 완전히 멈췄다는 뜻보다 정해진 시간 안에 허용된 요청 횟수를 넘었다는 의미에 가깝습니다. 문제는 Cloudflare, Nginx, 애플리케이션, 외부 API 가운데 어느 계층이 제한했는지 상태 코드만으로는 알 수 없다는 점입니다.
결론부터 말씀드리면 무조건 기다리거나 서버를 재시작하기 전에 실제 요청을 재현하고 응답 헤더에서 누가 429를 반환했는지 찾는 것이 먼저입니다.
429 Too Many Requests는 왜 발생할까요?
HTTP 429는 클라이언트가 일정 시간 동안 너무 많은 요청을 보냈을 때 반환하는 4xx 상태 코드입니다. 제한 기준은 서비스마다 다릅니다. IP 주소, 로그인 사용자, API token, 특정 URL이나 리소스를 기준으로 적용할 수 있습니다.
예를 들어 분당 100회까지 허용된 API를 자동화 프로그램이 짧은 시간에 150번 호출하면 429가 발생할 수 있습니다. 여러 사용자가 하나의 NAT IP를 공유한다면 개인별 호출량은 적어도 IP 기준 제한에 걸릴 수 있습니다.
여기서 중요한 점은 429라는 숫자만으로 발생 위치를 알 수 없다는 것입니다. 이제 응답 헤더부터 확인해보겠습니다.
| 발생 위치 | 흔한 원인 |
|---|---|
| 외부 API | 호출 횟수·token quota 초과 |
| Cloudflare | Rate Limiting Rule·API 제한 |
| 애플리케이션 | 사용자·IP별 요청 제한 |
| Nginx | limit_req 설정 |
| 자동화·크롤러 | 너무 짧은 간격의 반복 요청 |
| 로그인·폼 | 봇 방지용 요청 제한 |
Response Headers부터 확인하면 원인을 빠르게 좁힐 수 있습니다
브라우저에서는 개발자 도구의 Network 탭에서 실패한 요청을 선택해 Response Headers를 확인할 수 있습니다. 터미널에서는 다음처럼 응답 헤더와 본문을 함께 봅니다.
curl -i https://example.com/api연결 과정까지 자세히 보려면 다음 명령을 사용합니다.
curl -v https://example.com/apicurl -I는 HEAD 요청을 보내므로 실제 GET·POST 요청과 다른 제한 규칙이 적용될 수 있습니다. 운영 중 실패한 요청을 재현하려면 같은 HTTP 메서드와 인증 헤더, 요청 경로를 사용해야 합니다. 민감한 token이나 cookie가 터미널 기록과 공유 화면에 노출되지 않도록 주의하세요.
다음처럼 응답했다면 서버는 60초 뒤 다시 요청하라는 뜻입니다.
HTTP/1.1 429 Too Many Requests
Retry-After: 60Retry-After를 무시하고 즉시 반복하면 다시 제한되거나 서비스 정책에 따라 차단 시간이 늘어날 수 있습니다.
| 헤더 | 확인할 내용 |
|---|---|
Retry-After | 몇 초 뒤 또는 어느 시각 이후 다시 요청해야 하는지 |
Ratelimit | 남은 요청량과 reset 시간 |
Ratelimit-Policy | 전체 quota와 제한 시간 |
Server | 응답을 만든 서버 단서 |
cf-ray | Cloudflare를 거친 응답인지 확인할 단서 |
Cloudflare 429와 Nginx 429는 확인 방법이 다릅니다
Cloudflare를 사용한다면 먼저 Cloudflare API 제한인지 사이트 트래픽용 Rate Limiting Rule인지 구분해야 합니다. 둘은 같은 제품 계층이 아닙니다.
Cloudflare 공식 문서가 안내하는 현재 Client API 전역 제한은 사용자 또는 계정 token당 5분에 1,200회, IP당 초당 200회입니다. 사용자 기준 전역 제한을 넘으면 이후 5분 동안 API 호출이 차단되고 429가 반환될 수 있습니다. 일부 API는 별도의 제한을 사용합니다.
Cloudflare REST API에서는 다음 헤더를 확인할 수 있습니다.
Ratelimit
Ratelimit-Policy
retry-after반면 Nginx limit_req에는 꼭 알아야 할 차이가 있습니다. 요청을 거부할 때 기본 응답 코드는 429가 아니라 503입니다.
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
}
}이 구성에서 제한을 초과한 요청의 기본 거부 코드는 503입니다. 429를 반환하려면 별도 지시어가 필요합니다.
limit_req_status 429;따라서 브라우저에서 429가 보인다는 이유만으로 Nginx가 원인이라고 단정할 수 없습니다. access log와 error log를 함께 확인하세요.
tail -f /var/log/nginx/access.logtail -f /var/log/nginx/error.log설정을 바꾼다면 파일을 백업하고 먼저 nginx -t로 문법을 검사한 뒤 안전한 방식으로 reload해야 합니다.
자동 재시도는 Retry-After와 Backoff를 함께 사용하세요
API나 AI 자동화에서 흔한 실수는 429가 발생하자마자 같은 요청을 반복하는 것입니다. 서버가 속도를 줄여달라고 응답했는데 오히려 요청을 더 보내는 셈입니다.
먼저 Retry-After가 있다면 그 값을 우선 적용합니다. 값이 없다면 exponential backoff 방식으로 간격을 늘릴 수 있습니다.
1차 실패 → 1초 대기
2차 실패 → 2초 대기
3차 실패 → 4초 대기
4차 실패 → 8초 대기여러 클라이언트가 동시에 같은 순간에 재시도하지 않도록 작은 무작위 지연인 jitter도 더합니다. 최대 재시도 횟수와 전체 대기 시간도 정해 무한 반복을 막아야 합니다.
재시도만 다듬어도 해결되지 않는다면 호출 횟수 자체를 줄여야 합니다. 여러 요청을 하나로 묶을 수 있는지, 캐시할 수 있는 데이터를 반복해서 요청하는지, 동시에 실행되는 worker 수가 너무 많은지 확인하세요.
Googlebot에 429를 오래 반환하면 SEO에도 영향을 줄 수 있습니다
429는 API에서만 신경 써야 하는 오류가 아닙니다. Google은 429를 다른 4xx와 다르게 서버 과부하 신호로 취급하며, 5xx 오류와 마찬가지로 크롤링 속도를 일시적으로 낮춥니다. 정상적인 2xx 응답이 돌아오면 크롤링 속도는 점차 회복됩니다.
서버가 Googlebot 요청 때문에 과부하되는 긴급 상황이라면 Google은 429 또는 503을 임시로 반환하는 방법을 안내합니다. 하지만 오래 유지하면 안 됩니다. 공식 문서에 따르면 이 상태를 2일 넘게 지속하면 URL이 색인에서 제외될 수 있습니다.
특히 robots.txt 요청에 429나 5xx가 반환되는지도 확인해야 합니다. 크롤링이 갑자기 줄었다면 Search Console Crawl Stats와 Host status, 서버 로그를 함께 살펴보세요.
429 오류가 나오면 이 순서대로 확인하세요
429가 발생했다고 서버 설정부터 바꾸면 원인을 찾기 어려워집니다. 다음 순서로 발생 계층을 좁히는 편이 빠릅니다.
1. 브라우저 Network 또는 운영 요청과 같은 조건의 curl로 상태를 재현합니다. 2. Retry-After가 있는지 확인합니다. 3. Ratelimit, Ratelimit-Policy 헤더를 확인합니다. 4. Server, cf-ray 등으로 응답 계층을 좁힙니다. 5. Cloudflare Rate Limiting Analytics를 확인합니다. 6. 서버 access·error log를 확인합니다. 7. Nginx limit_req와 limit_req_status 설정을 확인합니다. 8. 애플리케이션과 외부 API quota를 확인합니다. 9. 자동 재시도에 Retry-After, exponential backoff, jitter를 적용합니다.
결국 429는 오류 자체보다 어느 계층에서 반환했는지 찾는 것이 중요합니다. Cloudflare 제한은 Nginx 설정으로 해결할 수 없고, 외부 API quota 초과는 서버 재시작으로 해결할 수 없습니다.
자주 묻는 질문
429 Too Many Requests는 서버 오류인가요?
HTTP 분류상 4xx 클라이언트 오류입니다. 다만 Googlebot은 429를 서버 과부하 신호로 보고 5xx와 비슷하게 크롤링 속도를 낮출 수 있습니다.
잠시 기다리면 429가 자동으로 해결되나요?
일시적인 제한이라면 해결될 수 있습니다. Retry-After가 있다면 해당 시간 이후 다시 요청하세요. 반복된다면 호출 횟수와 제한 정책을 확인해야 합니다.
Nginx rate limit에 걸리면 429가 나오나요?
기본값은 아닙니다. Nginx limit_req가 요청을 거부할 때 기본 상태 코드는 503입니다. 429를 반환하려면 limit_req_status 429;를 별도로 설정해야 합니다.
Cloudflare에서 429가 발생했는지는 어떻게 알 수 있나요?
응답 헤더와 Cloudflare Analytics를 함께 확인하세요. Cloudflare REST API 요청이라면 Ratelimit, Ratelimit-Policy, retry-after 헤더가 원인 파악에 도움이 됩니다.
429 오류가 SEO 순위에 바로 영향을 주나요?
한두 번의 일시적 응답만으로 바로 문제가 생긴다고 단정할 수는 없습니다. 하지만 Googlebot에 429가 지속되면 크롤링이 느려지고, 이 상태가 며칠 이어지면 URL이 색인에서 제외될 수 있습니다.
확인할 점
Cloudflare API 전역 제한과 사이트 트래픽에 적용하는 Rate Limiting Rule은 서로 다른 기능입니다. 또한 curl 테스트는 운영 요청과 같은 HTTP 메서드, 인증 헤더와 요청 경로를 사용해야 실제 제한을 재현할 수 있습니다. Nginx 설정 변경 전에는 구성 파일을 백업하고 nginx -t로 문법을 검사하세요.
자주 묻는 질문
429 Too Many Requests는 서버 오류인가요?
HTTP 분류상 4xx 클라이언트 오류입니다. 다만 Googlebot은 429를 서버 과부하 신호로 보고 5xx와 비슷하게 크롤링 속도를 낮출 수 있습니다.
잠시 기다리면 429가 자동으로 해결되나요?
일시적인 제한이라면 해결될 수 있습니다. Retry-After가 있으면 해당 시간이 지난 뒤 다시 요청하고, 반복된다면 호출 구조와 rate limit 설정을 확인하세요.
Nginx rate limit에 걸리면 429가 나오나요?
기본값은 아닙니다. Nginx limit_req가 요청을 거부할 때 기본 상태 코드는 503이며, 429를 반환하려면 limit_req_status 429;를 별도로 설정해야 합니다.
Cloudflare에서 429가 발생했는지는 어떻게 알 수 있나요?
응답 헤더와 Cloudflare Analytics를 함께 확인하세요. Cloudflare REST API 요청이라면 Ratelimit, Ratelimit-Policy, retry-after 헤더가 원인과 재시도 시점을 판단하는 데 도움이 됩니다.
429 오류가 SEO 순위에 바로 영향을 주나요?
한두 번의 일시적 응답만으로 바로 문제가 생긴다고 단정할 수는 없습니다. 하지만 Googlebot에 429가 지속되면 크롤링이 느려지고, 며칠 이상 계속되면 URL이 색인에서 제외될 수 있습니다.