프록시 오류 참조 · HTTP 상태 코드

스크래핑 중 429 Too Many Requests: 의미와 해결책

Q: 429 후 얼마나 기다려야 하나요?

Retry-After 헤더에 있는 대기 초 단위나 날짜까지 기다리세요. 헤더가 없으면 1~2초에서 시작해 429마다 지터를 포함한 지수적 백오프로 늘리며 최대 1분 정도로 제한하세요. 429를 일으킨 속도가 아닌 낮은 속도로 다시 시작하세요.

HTTP 상태 코드 (4xx, 클라이언트 오류): 각 도구에서 정확한 메시지, 가능한 원인들의 순서, 그리고 효과적인 해결 방법.

마지막 업데이트: 2026년 10월 13일 · 4 분 읽기

빠른 답변

프록시에서 429 Too Many Requests는 무엇을 의미하나요?

429 Too Many Requests는 사이트가 속도 제한을 하고 있음을 의미합니다: 특정 시간 창에 허용하는 요청 수를 초과했습니다. 해결책은 요청을 줄이는 것이지 숨기는 것이 아닙니다. CrawlRelay 주거용 프록시를 사용할 때는 Retry-After 헤더를 준수하고, 호스트당 동시 접속 수를 제한하며, 무작위 지터와 함께 지수적 백오프로 조절하세요. IP를 돌려 사이트가 공개한 제한을 넘는 것은 대부분 이용 약관 위반입니다.

429 Too Many Requests 한눈에 보기

오류	429 Too Many Requests
유형	HTTP 상태 코드 (4xx, 클라이언트 오류)
전송 주체	대상 웹사이트 또는 API 게이트웨이
정의 위치	RFC 6585, section 4 (Retry-After: RFC 9110, section 10.2.3)
다시 시도할까요?	예, Retry-After 지연 후 또는 지수적 백오프로 가능
먼저 확인하세요	Retry-After 헤더와 호스트별 초당 요청 수를 확인하세요.

429 Too Many Requests가 무엇을 의미하나요?

RFC 6585에서 429는 속도 제한용으로 도입되었습니다. 서버는 Retry-After 헤더를 추가해 몇 초 후 또는 HTTP 날짜 형식으로 다시 시도할 시점을 알려줍니다. API는 종종 X-RateLimit-Remaining 같은 자체 헤더도 추가합니다.

429는 사이트가 스크래퍼에 줄 수 있는 가장 공손한 응답입니다. 내용은 있지만 현재 속도에는 제공하지 않겠다는 뜻입니다. 429를 무시하면 사이트가 403, 캡차 또는 영구 차단으로 대응하는 경우가 많습니다.

Python, curl, Node.js, 브라우저에서 a 429는 어떻게 나타나나요?

같은 실패가 도구마다 다르게 출력됩니다. 로그에서 검색할 메시지들:

Python requests / httpx: status_code == 429, 종종 Retry-After: 30 포함
Scrapy: 429가 기본 RETRY_HTTP_CODES에 포함되어 RetryMiddleware가 처리
curl: HTTP/2 429와 이어서 응답 헤더 retry-after:
API: {"error": "rate_limited"}와 같은 JSON 바디

a 429의 원인은 무엇인가요?

가장 가능성 높은 첫 번째 원인:

호스트별 동시 접속 과다. 하나 도메인에 50개 병렬 작업은 공격처럼 보입니다.
요청 간 지연 없음 또는 고정 지연이 여러 작업을 동시에 몰리게 함.
백오프 없는 재시도. 첫 429 후 재시도 폭풍은 부담 가중.
공유 제한. 일부 사이트는 IP가 아닌 계정, API 키, 세션 쿠키별 요청을 계산.
부하가 큰 엔드포인트. 검색 및 필터 URL은 정적 페이지보다 제한 엄격.

a 429를 단계별로 진단하는 방법은?

첫 429 시 Retry-After 값과 속도 제한 헤더 기록
총 요청이 아닌 호스트별 실제 요청 속도를 측정
제한이 IP, 쿠키 또는 API 키 기준인지 확인: 하나씩 변경해 테스트
사이트 API 또는 robots.txt 문서 확인; Crawl-delay 줄에 요청 속도 안내

curl로 실패한 URL 테스트하기(HTTP 포트, 상세 모드)

# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL

a 429를 어떻게 고치나요?

Retry-After 준수. 최소한 서버가 요구하는 시간만큼 대기
호스트별 동시 접속 제한. 전역 뿐 아니라 Scrapy의 CONCURRENT_REQUESTS_PER_DOMAIN, AUTOTHROTTLE_ENABLED 활용
지터 포함 지수적 백오프: 1초, 2초, 4초에 무작위 추가, 최대값 설정
요청 감소. 응답 캐시, If-Modified-Since 또는 If-None-Match 전송, 변경 없는 페이지 건너뛰기
공식 API 사용. 제공 시 한계를 문서로 안내하는 경우가 많음

Python: Retry-After, 지수 백오프 및 지터로 재시도하기

import random
import time

import requests

PROXY = "http://USERNAME:[email protected]:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))

a 429 이후에 다시 시도해야 하나요?

예, 429는 나중에 재시도하도록 설계되었습니다. 서버가 Retry-After 지연을 보내면 기다리고, 없으면 지터가 있는 지수적 백오프로 진행하세요. 호스트별 연속 429 횟수를 세고, 429 증가 시 해당 호스트의 동시 접속 수를 줄이세요. 아래 Python 함수는 기본적인 부분을 수행합니다.

429 Too Many Requests가 CrawlRelay에 어떻게 적용되나요?

CrawlRelay를 통해 받은 429는 대상 사이트의 헤더 및 본문을 그대로 포함합니다: 제한은 사이트 측이고, 호스트별 속도 조절은 귀하 몫입니다. 사이트가 세션별 요청을 계산한다면 스티키 세션을 사용해 속도 측정이 가능하게 하세요. 시작에 참고할 수 있는 동시성 가이드]도 확인하세요.

게이트웨이: gw.crawlrelay.com, 포트 7777 (CONNECT를 통한 HTTP, HTTPS) 및 포트 7778 (SOCKS5). 사용자 이름 형식: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. 관련: 403 Forbidden · 503 Service Unavailable · 동시성 가이드.

429 Too Many Requests: 개발자들이 묻는 질문들

429 오류를 피하려고 IP를 돌려야 하나요?

아니요. 429는 사이트가 요청 속도를 줄이라는 뜻입니다. IP별 제한 밑에 있으려 같은 요청 속도를 여러 IP에 분산하는 것은 우회이며 대부분 이용 약관에 위배됩니다. IP 회전은 부하 분산과 위치 목적에 유용하며, 공개된 제한을 넘는 데 쓰이지 않습니다. 속도를 낮추고 캐시 활용을 늘리세요.

429 후 얼마나 기다려야 하나요?

Retry-After 헤더에 있는 대기 초 단위나 날짜까지 기다리세요. 헤더가 없으면 1~2초에서 시작해 429마다 지터를 포함한 지수적 백오프로 늘리며 최대 1분 정도로 제한하세요. 429를 일으킨 속도가 아닌 낮은 속도로 다시 시작하세요.

분당 몇 건 요청하는데 왜 429가 나나요?

제한이 IP별이 아니라 계정, 쿠키, API 키별일 수 있고, 엔드포인트가 검색 페이지처럼 부하가 큰 경우도 있습니다. 일부 사이트는 봇으로 분류한 클라이언트에 낮은 제한을 설정하기도 합니다. 응답 헤더, 사이트 API 문서 확인 후 추가 권한이 필요하면 요청하세요.

이 참조에서 다른 프록시 오류들

HTTP 상태 코드

브라우저 및 클라이언트 오류

연결 및 TLS 오류

실패 사례를 다루는 문서가 있는 레지덴셜 프록시들

US$0.50/GB의 레지덴셜 프록시 CrawlRelay개, 트래픽이 절대 만료되지 않음.

가격 확인 빠른 시작