블로그로 돌아가기

프록시를 통한 파싱 시 API 속도 제한 우회 방법: IP 선택 및 회전 설정

API 차단 원인을 분석하고 프록시 사용 시 속도 제한 우회를 위한 구체적인 방법을 보여줍니다: IP 회전 설정부터 올바른 프록시 유형 선택까지.

📅2026년 2월 19일
```html

파서를 설정하고 프록시를 연결했지만 API가 여전히 429 "요청이 너무 많습니다" 오류를 반환하거나 접근을 차단하고 있습니까? 문제는 프록시 자체가 아니라 그 사용 전략이 잘못되었기 때문입니다. 요청 제한은 API의 보호 메커니즘으로, 특정 기간 동안 하나의 IP 주소에서 보낼 수 있는 요청 수를 제한합니다. 이 기사에서는 프록시를 사용할 때 차단이 발생하는 이유와 제한을 우회하기 위한 시스템을 올바르게 설정하는 방법을 살펴보겠습니다.

API 요청 제한이란 무엇이며 어떻게 작동하는가

요청 제한(요청 빈도 제한)은 API를 과부하 및 남용으로부터 보호하는 메커니즘입니다. 서비스는 특정 시간 동안 하나의 출처에서 수행할 수 있는 요청 수에 제한을 둡니다. 예를 들어, 인기 있는 API는 다음과 같은 제한을 사용합니다:

  • Twitter API: 표준 접근을 위한 15분 동안 300 요청
  • Instagram Graph API: 애플리케이션당 시간당 200 요청
  • Google Maps API: 요금제에 따라 다르며, 일반적으로 하루 100-1000 요청
  • Wildberries API: 비공식 제한 약 1분당 60 요청
  • Avito API: 광고 파싱을 위한 초당 10 요청

요청 출처를 식별하는 몇 가지 방법이 있으며, 이에 따라 요청 제한이 적용됩니다:

IP 주소: 가장 일반적인 방법입니다. API는 특정 IP에서의 요청 수를 시간 창에 따라 계산합니다.

API 키: 키를 통한 인증을 사용하는 경우, 제한은 IP와 관계없이 키에 연결됩니다.

User-Agent 및 핑거프린트: 일부 API는 브라우저 헤더를 분석하고 클라이언트의 디지털 지문을 생성합니다.

세션(쿠키): 제한은 쿠키를 통해 사용자 세션에 연결될 수 있습니다.

제한을 초과하면 API는 HTTP 상태 429 "요청이 너무 많습니다"와 함께 제한 재설정까지의 시간을 나타내는 Retry-After 헤더를 반환합니다. 일부 서비스는 "슬라이딩 윈도우"(rolling window)를 사용하여 제한을 점진적으로 업데이트하며, 다른 서비스는 특정 시간에 재설정되는 고정 윈도우를 사용합니다.

프록시가 요청 제한으로부터 자동으로 보호하지 않는 이유

많은 개발자들이 프록시를 연결하기만 하면 무제한 요청을 보낼 수 있다고 잘못 생각합니다. 실제로는 다음과 같은 문제가 발생합니다:

모든 요청에 동일한 프록시 사용

스크립트가 모든 요청에 동일한 IP 주소의 프록시를 사용하는 경우, API는 이를 일반 사용자로 인식하고 표준 제한을 적용합니다. 예를 들어, Wildberries를 통해 가격 파서를 설정했지만 하나의 레지던트 프록시를 사용합니다. 파서는 분당 100 요청을 수행하지만 제한은 60 요청입니다. 결과: IP가 10-30분 동안 차단됩니다.

느린 IP 회전

일부는 5-10개의 프록시 풀을 사용하고 순차적으로 전환합니다. 문제는 각 IP가 전체 회전이 이루어지기 전에 여전히 더 빨리 제한에 도달한다는 것입니다. 예를 들어, 10개의 프록시와 IP당 100 요청의 제한이 있다고 가정합시다. 시간당 1000 요청을 수행하면 각 프록시는 100 요청을 받게 되며, 이는 제한의 경계에 해당합니다. 불균형한 분배는 차단으로 이어질 수 있습니다.

다른 식별 요소 무시

IP 회전이 완벽하더라도 다음과 같은 경우 차단될 수 있습니다:

  • 모든 요청이 동일한 User-Agent로 전송됨 (예: python-requests/2.28.0)
  • 모든 요청에 동일한 API 키 사용
  • 요청이 완벽한 주기로 도착 (0.5초마다) — 이는 봇처럼 보입니다
  • 프록시의 IP 주소가 동일한 서브넷에 있음 (예: 모두 192.168.1.x 범위에 있음)

IP 주소의 평판

데이터 센터 프록시는 종종 블랙리스트에 올라갑니다. 왜냐하면 그들의 IP는 수백 명의 다른 사용자에 의해 파싱에 사용되기 때문입니다. API는 이러한 주소에 대해 더 엄격한 제한을 적용하거나 즉시 차단할 수 있습니다. 예를 들어, Instagram과 Facebook은 데이터 센터를 공격적으로 차단하며, 공식 제한을 초과하지 않더라도 차단할 수 있습니다.

제한 우회를 위한 IP 회전 전략

올바른 프록시 회전은 요청 제한을 우회하는 열쇠입니다. 작업에 따라 효과적인 전략을 살펴보겠습니다.

각 요청 후 회전

가장 공격적인 전략: 각 요청이 새로운 IP를 통해 전송됩니다. 매우 엄격한 제한(1-5 요청/IP)이 있는 작업이나 부하를 최대한 분산시켜야 할 때 적합합니다. 이를 위해 자동 회전 레지던트 프록시를 사용합니다. 이들은 수백만 개의 IP 풀을 제공하며, 각 요청은 자동으로 새로운 주소를 받습니다.

사용 예: 비공식 API를 통해 Instagram을 파싱할 때, IP당 1분에 5 요청의 제한이 있습니다. 각 요청 후 회전을 사용하면 300개의 서로 다른 IP를 통해 분당 300 요청을 할 수 있습니다.

장점: 요청 제한에 대한 최대 보호, 각 IP는 최소한으로 사용됩니다.

단점: 높은 비용(레지던트 프록시가 더 비쌉니다), IP 변경 시 지연이 발생할 수 있으며, 세션 유지가 더 어렵습니다.

시간에 따른 회전(스티키 세션)

IP 주소는 특정 시간(5-30분) 동안 사용되며, 이후 새로운 IP로 변경됩니다. 이 전략은 세션 유지를 요구하는 API에 적합하거나 하나의 "사용자"로부터 여러 관련 요청을 수행해야 할 때 유용합니다.

최적의 회전 시간 계산: API 제한이 시간당 100 요청이고, 하나의 IP를 통해 50 요청을 수행할 계획이라면, 30분 동안 스티키 세션을 사용하십시오. 이 시간 동안 25 요청을 수행하게 되며(균일한 부하를 가정할 때), 이는 제한의 두 배로 낮습니다.

제한 추적을 통한 풀 회전

고급 전략: 스크립트는 각 IP에서의 요청 수를 추적하고 제한에 가까워지면 자동으로 새로운 IP로 전환합니다. 예를 들어, 20개의 프록시 풀과 API 제한이 시간당 100 요청이 있다고 가정합니다. 스크립트는 각 IP에 대한 카운터를 추적하고 90 요청에 도달하면 다음 IP로 전환합니다.

이 전략은 로직 프로그래밍이 필요하지만 최대 효율성을 제공합니다: 각 프록시를 최대한 활용하면서 제한을 초과하지 않습니다.

지리적 회전

일부 API는 지역에 따라 다른 제한을 적용합니다. 예를 들어, 서비스는 미국에서의 요청을 유럽보다 더 엄격하게 제한할 수 있습니다. 이러한 경우 다양한 국가의 프록시를 사용하고 부하를 분산시켜야 합니다.

회전 전략 언제 사용해야 하는가 프록시 유형
각 요청 후 엄격한 제한 (1-10 요청/IP), 소셜 미디어 파싱 자동 회전 레지던트
시간에 따른 회전 (5-30분) 세션 필요, 중간 제한 (50-200 요청/시간) 스티키 레지던트 또는 모바일
제한 추적을 통한 풀 회전 대량 파싱, 알려진 API 제한 10개 이상의 IP 풀
지리적 지역 제한, 로컬 콘텐츠 파싱 다양한 국가의 레지던트

요청 간 지연 설정

완벽한 IP 회전이 있더라도 요청 간 지연을 올바르게 설정하는 것이 중요합니다. 너무 빠른 요청은 공격처럼 보일 수 있으며, 다양한 IP에서 발생하더라도 마찬가지입니다.

최소 지연 계산

공식: 지연 = (시간 창(초) / 요청 제한) × 안전 계수

예: API가 시간당 100 요청을 허용합니다(3600초). 최소 지연 = 3600 / 100 = 36초. 안전 계수 1.2를 추가합니다: 36 × 1.2 = 43초. 따라서 하나의 IP에서 요청 간 43초의 지연을 두어야 합니다.

10개의 프록시를 사용하여 회전하는 경우, 각 4.3초마다 요청을 수행할 수 있습니다(43 / 10), 어떤 IP에서도 제한을 초과하지 않습니다.

무작위 지연(jitter)

고정된 5초 지연 대신 3초에서 7초 사이의 무작위 간격을 사용하십시오. 이는 트래픽을 실제 사용자 행동처럼 보이게 합니다. 많은 봇 방지 시스템은 패턴을 분석합니다: 요청이 정확히 5.0초마다 도착하면 의심스러워 보입니다.

오류 발생 시 지연 증가

429 오류가 발생하면 즉시 요청을 계속 보내지 마십시오. 지연 증가를 사용하십시오: 첫 번째 시도는 1초 후, 두 번째는 2초 후, 세 번째는 4초 후, 네 번째는 8초 후 등으로 진행합니다. 이는 API가 클라이언트에게 기대하는 표준 관행입니다.

조언: API 응답에서 Retry-After 헤더를 확인하십시오. 이는 요청을 반복할 수 있는 정확한 시간을 나타냅니다. 이 값을 임의의 지연 대신 사용하십시오.

API 작업에 적합한 프록시 유형 선택하기

프록시 유형 선택은 요청 제한 우회의 성공에 중대한 영향을 미칩니다. 각 옵션의 장단점을 살펴보겠습니다.

레지던트 프록시

레지던트 프록시는 실제 사용자에게 할당된 IP 주소를 사용합니다. API에는 일반 가정용 인터넷처럼 보입니다.

API에 대한 장점:

  • 높은 신뢰도: API는 가정용 IP를 잘 차단하지 않습니다
  • 거대한 풀: 수백만 개의 IP를 회전할 수 있습니다
  • 지리적 다양성: 다양한 도시와 국가의 IP
  • 소셜 미디어 및 엄격한 API(Instagram, Facebook, TikTok)에 적합합니다

단점:

  • 높은 비용: 일반적으로 트래픽에 대해 지불합니다(1GB당 $5-15)
  • 변동 속도: 최종 사용자의 인터넷에 따라 다릅니다
  • 불안정성: IP가 언제든지 끊길 수 있습니다

사용 시기: Instagram, Facebook, TikTok 파싱, 마켓플레이스 API(Wildberries, Ozon) 작업, IP 평판이 중요한 모든 작업.

모바일 프록시

모바일 프록시는 모바일 통신사(IP 4G/5G)의 IP를 사용합니다. 하나의 IP는 종종 수천 명의 실제 사용자가 동시에 사용하므로 API는 이를 거의 차단하지 않습니다.

API에 대한 장점:

  • 최대 신뢰도: API는 모바일 통신사의 IP를 차단할 수 없습니다
  • 모바일 애플리케이션 및 API(Instagram, TikTok, Snapchat)에 이상적입니다
  • 재연결 시 자동 IP 변경(비행기 모드)
  • 하나의 IP가 더 많은 요청을 수행할 수 있습니다

단점:

  • 매우 높은 비용: 하나의 IP당 월 $50-150
  • 작은 풀: 수백 개의 모바일 IP를 얻기 어렵습니다
  • 변동 속도: 모바일 신호 품질에 따라 다릅니다

사용 시기: 모바일 API 작업, Instagram/TikTok 대량 파싱, 차단 방지 최대화가 필요한 경우.

데이터 센터 프록시

데이터 센터 프록시는 데이터 센터에 위치한 서버의 IP 주소입니다. 실제 사용자와 연결되어 있지 않습니다.

API에 대한 장점:

  • 낮은 비용: 하나의 IP당 월 $1-5
  • 높은 속도: 1-10 Gbps의 채널
  • 안정성: IP가 우연히 끊기지 않습니다
  • 큰 풀: 수백 개의 IP를 쉽게 얻을 수 있습니다

단점:

  • 낮은 신뢰도: 많은 API가 데이터 센터를 차단합니다
  • IP가 다른 사용자로 인해 블랙리스트에 자주 올라갑니다
  • 소셜 미디어 및 엄격한 서비스에 적합하지 않습니다

사용 시기: 엄격한 보호가 없는 공개 API 파싱(날씨, 환율, 뉴스), 자체 API 작업, 테스트 및 개발.

기준 레지던트 모바일 데이터 센터
API 신뢰도 높음 최대 낮음
풀 크기 수백만 개의 IP 수백 개의 IP 수천 개의 IP
속도 평균 (10-50 Mbps) 평균 (5-100 Mbps) 높음 (100+ Mbps)
비용 $5-15/GB $50-150/IP/월 $1-5/IP/월
소셜 미디어용 ✅ 훌륭함 ✅ 이상적임 ❌ 적합하지 않음
공개 API용 ✅ 좋음 ✅ 좋음 (비쌈) ✅ 훌륭함

실용적인 구현: Python 코드 예제

프록시를 사용하여 요청 제한을 우회하는 구체적인 구현 예제를 살펴보겠습니다. 모든 예제는 requests 라이브러리를 사용하는 Python 코드입니다.

프록시 풀에서 간단한 회전

목록에서 IP를 순환하는 기본 구현:

import requests
import time
from itertools import cycle

# 프록시 목록 (형식: protocol://user:pass@host:port)
PROXY_LIST = [
    'http://user1:pass1@proxy1.example.com:8080',
    'http://user2:pass2@proxy2.example.com:8080',
    'http://user3:pass3@proxy3.example.com:8080',
]

# 순환 이터레이터 생성
proxy_pool = cycle(PROXY_LIST)

def make_request(url):
    proxy = next(proxy_pool)  # 풀에서 다음 프록시 가져오기
    proxies = {
        'http': proxy,
        'https': proxy
    }
    
    try:
        response = requests.get(url, proxies=proxies, timeout=10)
        return response
    except requests.exceptions.RequestException as e:
        print(f"프록시 {proxy}에서 오류 발생: {e}")
        return None

# 사용 예
for i in range(10):
    response = make_request('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"요청 {i+1}: 성공")
    time.sleep(2)  # 요청 간 지연

제한 추적을 통한 회전

각 프록시의 요청 수를 계산하고 제한에 가까워지면 전환하는 더 발전된 버전:

import requests
import time
from collections import defaultdict

class ProxyRotator:
    def __init__(self, proxy_list, max_requests_per_ip=90, time_window=3600):
        self.proxy_list = proxy_list
        self.max_requests = max_requests_per_ip  # IP당 요청 제한
        self.time_window = time_window  # 시간 창(초)
        self.request_counts = defaultdict(list)  # 각 IP의 요청 기록
        self.current_index = 0
    
    def get_proxy(self):
        """요청 수가 가장 적은 프록시 반환"""
        current_time = time.time()
        
        # 시간 창을 초과한 오래된 기록 삭제
        for proxy in self.request_counts:
            self.request_counts[proxy] = [
                t for t in self.request_counts[proxy]
                if current_time - t < self.time_window
            ]
        
        # 요청 수가 가장 적은 프록시 찾기
        available_proxies = []
        for proxy in self.proxy_list:
            count = len(self.request_counts[proxy])
            if count < self.max_requests:
                available_proxies.append((proxy, count))
        
        if not available_proxies:
            # 모든 프록시가 제한에 도달한 경우 대기
            oldest_request = min(
                min(times) for times in self.request_counts.values() if times
            )
            wait_time = self.time_window - (current_time - oldest_request) + 1
            print(f"모든 프록시가 제한에 도달했습니다. {wait_time:.0f}초 대기 중...")
            time.sleep(wait_time)
            return self.get_proxy()
        
        # 요청 수가 가장 적은 프록시 선택
        proxy = min(available_proxies, key=lambda x: x[1])[0]
        self.request_counts[proxy].append(current_time)
        return proxy
    
    def make_request(self, url, **kwargs):
        proxy = self.get_proxy()
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(url, proxies=proxies, timeout=10, **kwargs)
            return response
        except requests.exceptions.RequestException as e:
            print(f"프록시 {proxy}에서 오류 발생: {e}")
            return None

# 사용 예
PROXY_LIST = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
]

rotator = ProxyRotator(PROXY_LIST, max_requests_per_ip=100, time_window=3600)

for i in range(500):  # 500 요청 수행
    response = rotator.make_request('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"요청 {i+1}: 성공")
    time.sleep(1)  # 최소 지연

429 오류 처리 및 지연 증가

"요청이 너무 많습니다" 응답을 올바르게 처리하는 방법, Retry-After 헤더를 고려하여:

import requests
import time

def make_request_with_retry(url, proxies, max_retries=5):
    """429 오류 발생 시 자동으로 재시도하는 요청 수행"""
    
    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=10)
            
            if response.status_code == 200:
                return response
            
            elif response.status_code == 429:
                # Retry-After 헤더 확인
                retry_after = response.headers.get('Retry-After')
                
                if retry_after:
                    wait_time = int(retry_after)
                    print(f"요청 제한. {wait_time}초 대기 중 (Retry-After에서)")
                else:
                    # 지연 증가: 2^attempt 초
                    wait_time = 2 ** attempt
                    print(f"요청 제한. 시도 {attempt+1}, {wait_time}초 대기 중")
                
                time.sleep(wait_time)
                continue
            
            else:
                print(f"HTTP 오류 {response.status_code}")
                return None
        
        except requests.exceptions.RequestException as e:
            print(f"연결 오류: {e}")
            if attempt < max_retries - 1:
                time.sleep(2 ** attempt)
                continue
            return None
    
    print(f"시도 횟수 초과 ({max_retries})")
    return None

# 사용 예
proxies = {
    'http': 'http://user:pass@proxy.example.com:8080',
    'https': 'http://user:pass@proxy.example.com:8080'
}

response = make_request_with_retry('https://api.example.com/data', proxies)
if response:
    print("데이터 수신됨:", response.json())

자동 회전 레지던트 프록시 사용

많은 레지던트 프록시 제공업체는 각 요청 시 IP를 자동으로 변경하는 단일 엔드포인트를 제공합니다. 설정 예:

import requests
import random
import time

# 자동 회전 레지던트 프록시
# 형식: protocol://username:password@gateway:port
ROTATING_PROXY = 'http://customer-USER:PASS@proxy.provider.com:12321'

def make_request_rotating(url):
    """회전 프록시를 통한 요청 (매번 새로운 IP)"""
    proxies = {
        'http': ROTATING_PROXY,
        'https': ROTATING_PROXY
    }
    
    # 더 큰 익명성을 위해 무작위 User-Agent 추가
    user_agents = [
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
        'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36',
        'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36',
    ]
    
    headers = {
        'User-Agent': random.choice(user_agents)
    }
    
    try:
        response = requests.get(url, proxies=proxies, headers=headers, timeout=15)
        return response
    except requests.exceptions.RequestException as e:
        print(f"오류 발생: {e}")
        return None

# 100개의 요청을 서로 다른 IP를 통해 수행
for i in range(100):
    response = make_request_rotating('https://api.example.com/data')
    if response and response.status_code == 200:
        print(f"요청 {i+1}: 성공, IP 변경됨")
    
    # 1-3초의 무작위 지연
    time.sleep(random.uniform(1, 3))

제한 모니터링 및 오류 처리

API와 효과적으로 작업하려면 제한을 지속적으로 모니터링하고 오류를 올바르게 처리해야 합니다. 주요 관행은 다음과 같습니다:

응답 헤더 분석

많은 API는 응답 헤더에 제한 정보를 반환합니다. 표준 헤더는 다음과 같습니다:

  • X-RateLimit-Limit — 시간 창에서의 최대 요청 수
  • X-RateLimit-Remaining — 남은 요청 수
  • X-RateLimit-Reset — 제한 재설정 시간 (Unix 타임스탬프)
  • Retry-After — 몇 초 후에 요청을 반복할 수 있는지

이러한 헤더를 읽는 예:

response = requests.get(url, proxies=proxies)

# 제한 헤더 확인
limit = response.headers.get('X-RateLimit-Limit')
remaining = response.headers.get('X-RateLimit-Remaining')
reset_time = response.headers.get('X-RateLimit-Reset')

if remaining:
    remaining = int(remaining)
    if remaining < 10:
        print(f"주의! 남은 요청 수: {remaining}")
        
if reset_time:
    import datetime
    reset_dt = datetime.datetime.fromtimestamp(int(reset_time))
    print(f"제한이 {reset_dt}에 재설정됩니다.")

로깅 및 통계

각 프록시에 대한 요청의 자세한 통계를 기록하십시오. 이는 문제 있는 IP를 식별하고 회전을 최적화하는 데 도움이 됩니다:

import json
from datetime import datetime

class RequestLogger:
    def __init__(self):
        self.stats = {}
    
    def log_request(self, proxy, status_code, response_time):
        if proxy not in self.stats:
            self.stats[proxy] = {
                'total': 0,
                'success': 0,
                'rate_limited': 0,
                'errors': 0,
                'avg_response_time': 0
            }
        
        self.stats[proxy]['total'] += 1
        
        if status_code == 200:
            self.stats[proxy]['success'] += 1
        elif status_code == 429:
            self.stats[proxy]['rate_limited'] += 1
        else:
            self.stats[proxy]['errors'] += 1
        
        # 평균 응답 시간 업데이트
        current_avg = self.stats[proxy]['avg_response_time']
        total = self.stats[proxy]['total']
        self.stats[proxy]['avg_response_time'] = (
            (current_avg * (total - 1) + response_time) / total
        )
    
    def print_stats(self):
        print("\n=== 프록시 통계 ===")
        for proxy, data in self.stats.items():
            success_rate = (data['success'] / data['total'] * 100) if data['total'] > 0 else 0
            print(f"\n프록시: {proxy}")
            print(f"  총 요청 수: {data['total']}")
            print(f"  성공: {data['success']} ({success_rate:.1f}%)")
            print(f"  요청 제한: {data['rate_limited']}")
            print(f"  오류 수: {data['errors']}")
            print(f"  평균 응답 시간: {data['avg_response_time']:.2f}s")

# 사용 예
logger = RequestLogger()

start_time = time.time()
response = requests.get(url, proxies=proxies)
response_time = time.time() - start_time

logger.log_request(proxy, response.status_code, response_time)
logger.print_stats()

전략 자동 전환

429 오류가 지속적으로 발생하는 경우, 자동으로 요청 속도를 늦추거나 프록시 풀을 늘리십시오:

class AdaptiveRateLimiter:
    def __init__(self, initial_delay=1.0):
        self.delay = initial_delay
        self.consecutive_429 = 0
    
    def on_success(self):
        """성공적인 요청 - 약간 속도를 높일 수 있습니다"""
        self.consecutive_429 = 0
        self.delay = max(0.5, self.delay * 0.95)  # 지연을 5% 줄입니다.
    
    def on_rate_limit(self):
        """429 오류 발생 - 속도를 늦춰야 합니다"""
        self.consecutive_429 += 1
        self.delay *= 1.5  # 지연을 1.5배 늘립니다.
        
        if self.consecutive_429 > 5:
            print("주의: 너무 많은 429 오류가 발생했습니다. 설정을 확인하십시오!")
    
    def wait(self):
        """다음 요청 전 대기"""
        time.sleep(self.delay)
        return self.delay

# 사용 예
limiter = AdaptiveRateLimiter(initial_delay=2.0)

for i in range(1000):
    response = make_request(url)
    
    if response.status_code == 200:
        limiter.on_success()
    elif response.status_code == 429:
        limiter.on_rate_limit()
    
    delay = limiter.wait()
    print(f"요청 {i+1}, 지연: {delay:.2f}s")

캡차 및 기타 차단 처리

일부 API는 제한을 초과하면 직접 차단하는 대신 캡차를 표시합니다. 징후는 다음과 같습니다:

  • 응답 본문에 "captcha" 또는 "recaptcha"가 포함된 상태 코드 403
  • 캡차 페이지로 리디렉션 (상태 302)
  • X-Captcha-Required: true와 같은 특별한 헤더

이러한 경우에는 다음을 수행해야 합니다:

  1. 즉시 해당 IP 사용 중지
  2. 풀에서 다른 프록시로 전환
  3. 요청 간 지연을 늘리기
  4. User-Agent 및 기타 헤더에 더 많은 다양성 추가

중요: 레지던트 프록시를 사용할 때 캡차에 자주 직면하는 경우, 문제는 IP 주소가 아니라 행동 패턴(동일한 헤더, 너무 빠른 요청)에 있을 가능성이 높습니다.

결론

프록시를 사용하여 API 요청 제한을 우회하는 것은 단순한 기술적 설정이 아니라, 올바른 프록시 유형 선택, IP 회전 설정, 지연 관리 및 제한 모니터링을 포함하는 종합적인 전략입니다. 이 기사에서의 주요 결론은 다음과 같습니다:

  • 프록시 자체가 요청 제한 문제를 해결하지 않습니다 — 올바른 회전 전략이 필요합니다
  • 소셜 미디어 및 엄격한 API에는 레지던트 또는 모바일 프록시를 사용하고, 공개 API에는 데이터 센터가 적합합니다
  • 요청 제한 및 원하는 파싱 속도에 따라 프록시 풀 크기를 계산하십시오
  • 항상 요청 제한 및 오류를 모니터링하고 적절하게 대응하십시오
```