아마존 안티봇 우회 방법: 프록시 및 파싱을 위한 기법

```html

아마존은 세계에서 가장 보호된 마켓플레이스 중 하나입니다. 그의 안티봇 시스템은 가격, 재고 및 상품 위치에 대한 자동 데이터 수집 시도의 90%를 차단합니다. 판매자와 마케팅 담당자에게 이는 치명적인 문제입니다: 최신 경쟁 데이터 없이는 가격 전략을 조정하고 수익성을 유지할 수 없습니다.

이 가이드에서는 아마존의 보호 기술 메커니즘을 분석하고, 안티봇을 우회하는 검증된 방법을 보여주며, 차단 없이 몇 달 동안 안정적으로 작동하는 가격 모니터링 시스템을 설정합니다.

아마존이 파싱을 차단하는 이유: 보호 메커니즘

아마존은 파싱으로 인해 수백만 달러를 잃고 있습니다: 경쟁자들이 상품 데이터, 가격, 리뷰를 복사하고, 부정직한 판매자들이 위치를 조작하기 위해 자동화를 사용합니다. 따라서 회사는 여러 수준에서 동시에 작동하는 안티봇 시스템에 막대한 자금을 투자합니다.

아마존 보호의 주요 구성 요소:

AWS WAF (웹 애플리케이션 방화벽) — 들어오는 트래픽을 분석하고 네트워크 수준에서 의심스러운 IP 주소를 차단합니다. 요청 빈도, 지리, IP 평판을 추적합니다.
Cloudfront CDN — 봇 필터링 알고리즘을 가진 분산 콘텐츠 전송 네트워크입니다. 요청 헤더, 쿠키, TLS 브라우저 지문을 확인합니다.
봇 관리 시스템 — 사용자 행동 분석을 위해 머신 러닝을 사용합니다. 마우스 움직임, 스크롤 속도, 클릭 패턴을 추적합니다.
CAPTCHA 및 챌린지 페이지 — 의심스러운 활동 시 표시됩니다. 문제 해결이나 CAPTCHA 입력을 요구합니다.
요청 제한 — 하나의 IP에서 요청 수에 대한 엄격한 제한: 일반적으로 로그인하지 않은 사용자에게는 분당 10-20 요청입니다.

이러한 모든 시스템은 함께 작동하며 데이터를 교환합니다. 그 중 하나라도 봇을 의심하면 — IP는 24-48시간 동안 블랙리스트에 올라가며, 때로는 영구적으로 차단됩니다.

중요: 아마존은 지역 및 사용자 유형에 따라 서로 다른 가격을 표시합니다. 차단은 단순히 접근 불가능한 것이 아니라, 부정확한 데이터를 받는 것이며, 이는 경쟁 모니터링에 치명적입니다.

아마존이 봇을 식별하는 방법: 7가지 주요 신호

아마존의 안티봇 시스템은 각 요청의 수십 가지 매개변수를 분석합니다. 다음은 자동화를 인식하는 주요 신호입니다:

1. IP 주소의 평판

아마존은 데이터 센터, VPN 서비스, 공개 프록시의 IP 주소 데이터베이스를 유지합니다. 이러한 주소에서 오는 요청은 높은 주의를 받거나 즉시 차단됩니다. 시스템은 또한 활동 기록을 추적합니다: IP에서 상품 페이지에 대한 요청이 너무 많으면 의심스럽습니다.

확인되는 사항: 유명 데이터 센터(AWS, Google Cloud, DigitalOcean)에 속하는지, 공개 프록시 데이터베이스에 있는지, 지난 한 시간 동안의 요청 수, 지리(예상치 못한 국가에서의 요청).

2. User-Agent 및 HTTP 헤더

많은 파서가 표준 User-Agent 라이브러리를 사용합니다: python-requests/2.28.0 또는 이 헤더를 아예 전송하지 않습니다. 아마존은 이러한 요청을 즉시 인식합니다.

의심스러운 징후: Accept-Language, Accept-Encoding 헤더의 부재; User-Agent 및 다른 헤더의 불일치(예: Chrome User-Agent지만 Firefox의 헤더); 페이지 간 전환 시 Referer의 부재; 오래된 브라우저 버전.

3. TLS/SSL 지문

HTTPS 연결을 설정할 때 브라우저는 암호화 매개변수 집합(암호 스위트, 확장, TLS 버전)을 전송합니다. 이 집합은 각 브라우저마다 고유합니다. requests나 curl과 같은 라이브러리는 실제 브라우저와 다른 지문을 가지고 있으며, 아마존은 이를 인식합니다.

4. JavaScript 및 Canvas 지문

아마존은 브라우저에 대한 정보를 수집하는 JavaScript 코드를 로드합니다: 화면 해상도, 설치된 글꼴, 지원되는 WebGL 기능, Canvas 매개변수. 간단한 HTTP 클라이언트는 JavaScript를 실행하지 않으며 즉시 자신을 드러냅니다.

5. 쿠키 및 세션

아마존은 첫 방문 시 여러 개의 쿠키를 설정합니다: session-id, ubid-main, x-main 등. 이러한 쿠키가 없거나 잘못된 값은 봇의 징후입니다. 시스템은 또한 세션의 수명 시간을 추적합니다: 실제 사용자는 30초 안에 100개의 요청을 하지 않습니다.

6. 행동 패턴

실제 사람은 홈페이지를 열고, 상품을 검색하고, 카테고리를 탐색하고, 설명을 읽고, 뒤로 돌아갑니다. 봇은 즉시 특정 상품의 URL을 완벽한 순서로 요청하며 지연 없이 진행합니다.

의심스러운 패턴: 메인 페이지를 방문하지 않고 상품 페이지에만 요청; 완벽한 URL 순서(product1, product2, product3...); 정적 콘텐츠에 대한 요청 부재(이미지, CSS, JS); 요청 간 동일한 간격.

7. 요청 빈도

완벽한 브라우저 에뮬레이션이 있더라도 너무 높은 요청 빈도는 봇을 드러냅니다. 아마존은 IP에서 분당, 시간당, 일당 요청 수를 추적합니다. 한계 초과(일반적으로 비회원의 경우 분당 10-20 요청)는 차단으로 이어집니다.

안티봇 우회를 위한 프록시 선택: 레지던트 vs 데이터 센터

올바른 프록시 유형 선택은 아마존 보호 우회의 70%입니다. 세 가지 주요 유형과 마켓플레이스 파싱에 대한 적용 가능성을 분석합니다.

프록시 유형	아마존의 신뢰 수준	속도	용도
레지던트	매우 높음 (실제 가정 사용자 IP)	중간 (50-150ms)	주요 파싱, 대량 작업
모바일	최대 (모바일 운영자의 IP)	낮음 (200-500ms)	강력한 차단 우회, 계정
데이터 센터	낮음 (아마존이 이 IP를 알고 있음)	매우 높음 (10-30ms)	테스트, 일회성 작업

레지던트 프록시 — 최적의 선택

아마존의 안정적인 파싱을 위해 레지던트 프록시를 추천합니다 — 이들은 아마존이 대량으로 차단할 수 없는 실제 가정 사용자의 IP 주소를 사용합니다.

아마존을 위한 레지던트 프록시의 장점:

IP는 데이터 센터가 아닌 인터넷 서비스 제공업체(Comcast, AT&T, Verizon 등) 소속입니다.
차단 비율이 낮음: 올바른 회전 설정 시 2% 미만
지리적 선택 가능: 미국, 영국, 독일 등 현지 가격을 얻기 위한 국가 선택
스티키 세션 지원: 하나의 IP를 10-30분 동안 사용하여 실제 사용자를 에뮬레이션할 수 있습니다.

레지던트 프록시 선택 시 중요한 매개변수:

IP 풀 크기: 효과적인 회전을 위해 최소 100만 개의 주소 필요
지리: 아마존이 운영되는 국가 선택 (미국, 영국, 독일, 일본 등)
회전 유형: 10-30분의 수명으로 스티키 세션 지원
프로토콜: 다양한 도구와의 호환성을 위한 HTTP/HTTPS 및 SOCKS5

모바일 프록시를 사용할 때

모바일 프록시는 모바일 운영자의 IP(4G/5G)를 사용합니다. 아마존은 이러한 주소를 거의 차단하지 않으며, CGNAT 기술로 인해 하나의 IP 뒤에 수천 명의 실제 사용자가 있을 수 있습니다.

모바일 프록시를 선택해야 할 때:

아마존 판매자 계정(Seller Central) 작업 — IP의 안정성이 중요합니다.
레지던트 IP 차단 후 강력한 차단 우회
인증이 필요한 파싱 (예: Prime 구독자를 위한 가격)
소량 데이터 (하루에 1000개 상품까지) — 모바일 프록시는 더 비쌉니다.

모바일 프록시의 단점은 높은 비용과 모바일 네트워크의 특성으로 인한 낮은 속도입니다. 수천 개의 상품을 대량으로 파싱하는 데는 비효율적입니다.

데이터 센터는 적합하지 않은 이유

데이터 센터 프록시는 AWS, Google Cloud, DigitalOcean의 서버 IP를 사용합니다. 아마존은 이러한 주소를 즉시 인식합니다 — 이들은 데이터 센터의 ASN(자율 시스템) 데이터베이스에 포함되어 있습니다.

데이터 센터 사용 시 문제: 5-10 요청 후 차단; 지속적인 CAPTCHA; 오래된 가격이나 빈 페이지 표시; 몇 번의 시도 후 IP 영구 차단.

데이터 센터를 사용할 수 있는 유일한 경우는 레지던트 프록시로 시작하기 전에 소량의 상품(10-20개)에 대해 파서를 테스트하는 것입니다.

IP 주소 회전 전략: 빈도 및 지리

레지던트 프록시를 사용하더라도 잘못된 IP 회전은 차단으로 이어질 수 있습니다. 아마존은 각 주소의 행동을 추적하고 너무 많은 요청을 하거나 의심스러운 행동을 하는 주소를 차단합니다.

최적의 회전 빈도

회전에는 두 가지 접근 방식이 있습니다: 각 요청 후 회전(회전 프록시)과 고정 수명(스티키 세션). 아마존의 경우 두 번째 옵션이 더 효과적입니다.

추천 스티키 세션 전략:

IP 수명: 10-15분 — 실제 사용자 에뮬레이션과 차단 위험 사이의 최적의 균형
IP당 요청 수: 세션 수명 동안 15-20 요청 이하
요청 간 지연: 3-7초 (무작위, 고정되지 않음!)
행동 에뮬레이션: 첫 요청 — 홈페이지 또는 카테고리, 그 다음 — 상품 페이지

하나의 IP에 대한 시나리오 예: 아마존.com 열기 → 5초 대기 → 전자 제품 카테고리 열기 → 4초 대기 → 상품 1 열기 → 6초 대기 → 상품 2 열기 → ... → 15 요청 후 IP 변경.

높은 부하에 대한 조언:

시간당 수천 개의 상품을 파싱해야 하는 경우, 다양한 IP를 가진 50-100개의 동시 세션 풀을 사용하십시오. 각 세션은 지연을 두고 10-15개의 요청을 한 다음 IP를 변경합니다. 이는 차단 없이 시간당 500-1500개의 요청을 제공합니다.

지리적 분포

아마존은 사용자의 위치에 따라 서로 다른 가격, 품목 및 배송 조건을 표시합니다. 정확한 모니터링을 위해서는 목표 마켓플레이스와 동일한 국가의 프록시를 사용해야 합니다.

마켓플레이스와 프록시의 지리적 일치:

Amazon.com (미국): 미국의 프록시를 사용하고, 다양성을 위해 다양한 주에서 선택하는 것이 좋습니다.
Amazon.co.uk (영국): UK의 프록시
Amazon.de (독일): 독일의 프록시
Amazon.co.jp (일본): 일본의 프록시

중요: 특정 마켓플레이스를 파싱할 때 다른 국가의 프록시는 사용하지 마십시오. 예를 들어, 인도나 러시아의 IP로 Amazon.com에 요청하면 의심스러워 보이며 자주 CAPTCHA를 받습니다.

IP 재사용 피하기

IP가 차단되지 않더라도 2-3시간 이내에 재사용하지 마십시오. 아마존은 각 주소의 활동 기록을 기억합니다. 동일한 IP가 하루에 15분마다 나타나면 이는 자동화의 명백한 징후입니다.

회전 규칙: 안정적인 작업을 위한 최소 풀은 500-1000개의 고유 IP입니다. 이는 각 주소가 하루에 1-2회 이상 사용되지 않도록 충분한 다양성을 제공합니다.

실제 브라우저 에뮬레이션: 헤더 및 지문

레지던트 프록시와 올바른 회전이 있더라도 파서는 실제 브라우저를 에뮬레이션하지 않으면 차단됩니다. 아마존은 HTTP 요청 및 JavaScript 환경의 수십 가지 매개변수를 확인합니다.

올바른 HTTP 헤더

간단한 HTTP 클라이언트(requests, curl, wget)는 최소한의 헤더 집합을 전송하여 즉시 봇을 드러냅니다. 실제 브라우저의 헤더를 복사해야 합니다.

아마존을 위한 필수 헤더:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0

중요한 점:

User-Agent: 최신 버전의 Chrome 또는 Firefox를 사용하십시오 (2-3개월마다 확인). 오래된 브라우저 버전은 의심스럽습니다.
Accept-Language: 프록시의 지리와 일치해야 합니다 (미국의 경우 en-US, 영국의 경우 en-GB, 독일의 경우 de-DE)
Sec-Fetch-* 헤더: 최신 브라우저에서 나타나며, 이들의 부재는 오래된 클라이언트의 징후입니다.
Referer: 페이지 간 전환 시 반드시 이전 페이지의 Referer를 전송해야 합니다.

TLS 지문 및 우회

아마존은 TLS 연결의 매개변수를 분석합니다: 프로토콜 버전, 암호 집합, 확장. 표준 라이브러리(파이썬 requests의 OpenSSL)는 브라우저와 다른 지문을 가지고 있습니다.

해결책: 브라우저의 TLS를 에뮬레이트하는 도구를 사용하십시오:

curl-impersonate: Chrome 및 Firefox의 TLS 지문을 복사하는 curl 버전
tls-client (Python): 브라우저 지문을 지원하는 라이브러리
Playwright/Puppeteer: 헤드리스 모드의 실제 브라우저 — 완벽한 에뮬레이션이지만 느립니다.

JavaScript 및 쿠키

아마존은 페이지 로드 시 JavaScript 코드를 실행하여 쿠키를 설정하고 브라우저에 대한 정보를 수집합니다. 이 코드를 실행하지 않으면 전체 데이터를 얻지 못하고 빠르게 차단됩니다.

필수 작업:

JavaScript를 지원하는 도구 사용: Selenium, Playwright, Puppeteer
하나의 세션 내에서 모든 쿠키를 요청 간에 저장
데이터 추출 전에 페이지가 완전히 로드될 때까지 기다리기 (DOMContentLoaded 이벤트)
사용자 행동 에뮬레이션: 스크롤, 무작위 지연

아마존은 중요한 쿠키를 설정합니다: session-id, ubid-main, x-main. 이들이 없으면 CAPTCHA나 빈 페이지를 받게 됩니다.

요청 한계 및 요청 간 지연

완벽한 브라우저 에뮬레이션이 있더라도 너무 많은 요청을 하면 차단됩니다. 아마존은 하나의 IP에서 요청 빈도를 엄격하게 제한합니다.

아마존의 문서화된 한계

공식적인 한계 데이터는 없지만, 커뮤니티 테스트를 기반으로 한 대략적인 값이 알려져 있습니다:

사용자 유형	요청 한계/분	요청 한계/시간
비회원 사용자	10-15	200-300
로그인한 구매자	20-30	500-800
아마존 API (공식)	제한 없음	요금제에 따라 다름

한계를 초과하면 CAPTCHA, 일시적 차단(1-24시간) 또는 시스템적 위반 시 IP의 영구 차단으로 이어집니다.

요청 간 최적의 지연

고정 간격(예: 정확히 5초)은 봇을 드러냅니다. 실제 사람은 다양한 길이의 지연을 두며: 상품 설명을 읽고, 가격을 비교하고, 주의가 분산됩니다.

추천 지연 전략:

기본 지연: 3-7초 (범위 내 무작위 값)
세션의 첫 요청: 5-10초 (홈페이지 로딩 에뮬레이션)
오류 또는 CAPTCHA 후: 재시도 전 30-60초 대기
IP 변경 간: "재연결"을 위해 2-3초 대기

무작위 지연 구현 예: sleep(random.uniform(3, 7)) — 각 지연이 고유하게 됩니다.

시간에 따른 부하 분산

자정에 수천 개의 상품을 동시에 파싱하지 마십시오. 아마존은 활동의 급증을 추적합니다. 작업을 몇 시간 또는 하루에 걸쳐 분산하십시오.

예: 5000개의 상품을 파싱해야 합니다. 500개 상품씩 10개의 패키지로 나누고, 각 패키지를 1-2시간 간격으로 실행합니다. 이는 다양한 사용자의 유기적인 활동처럼 보입니다.

아마존 파싱을 위한 준비된 도구

처음부터 파서를 작성하는 것은 어렵고 시간이 많이 걸립니다. 이미 안티봇 우회, 프록시 회전 및 브라우저 에뮬레이션을 구현한 준비된 솔루션이 있습니다.

1. Bright Data Web Scraper IDE

아마존을 위한 준비된 템플릿이 있는 클라우드 도구입니다. 프로그래밍이 필요 없으며, 시각적 인터페이스를 통해 데이터 선택기를 설정합니다. 내장된 프록시 및 CAPTCHA 우회 기능이 있습니다.

장점: 즉시 작동, IP 자동 회전, JavaScript 지원. 단점: 비쌈 ($500 이상/월), 외부 서비스에 의존.

2. Octoparse

시각적 파서 생성기가 있는 Windows용 데스크톱 애플리케이션입니다. 24/7 작업을 위한 클라우드 버전이 있습니다. 프록시 통합을 지원합니다.

Octoparse에서 프록시 설정: 설정 → 프록시 설정 → IP:PORT:USER:PASS 형식으로 프록시 목록 추가 → 회전 활성화.

장점: 코드 필요 없음, 편리한 인터페이스, 무료 플랜 있음. 단점: 무료 버전에서 페이지 수 제한, CAPTCHA 문제.

3. ScrapingBee API

자동으로 보호를 우회하는 파싱을 위한 API 서비스입니다. URL을 전송하면 HTML을 받습니다. 내장된 프록시 회전 및 JavaScript 실행 기능이 있습니다.

사용 예:

curl "https://app.scrapingbee.com/api/v1/?api_key=YOUR_KEY&url=https://www.amazon.com/dp/B08N5WRWNW&render_js=true&premium_proxy=true&country_code=us"

장점: 간단한 통합, 자체 프록시 필요 없음. 단점: 유료 (월 $49부터), 요청 수에 대한 제한.

4. Playwright + 자체 프록시 (개발자를 위한)

프로그래밍을 할 수 있다면, Playwright(또는 Puppeteer)와 레지던트 프록시를 사용하는 것이 최선의 선택입니다. 프로세스에 대한 완전한 제어와 최소 비용을 제공합니다.

Playwright에서 프록시 설정 예 (Python):

from playwright.sync_api import sync_playwright
import random
import time

proxy_list = [
    {"server": "http://proxy1.example.com:8080", "username": "user", "password": "pass"},
    {"server": "http://proxy2.example.com:8080", "username": "user", "password": "pass"},
]

with sync_playwright() as p:
    proxy = random.choice(proxy_list)
    browser = p.chromium.launch(proxy=proxy, headless=True)
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
        locale="en-US",
        timezone_id="America/New_York"
    )
    page = context.new_page()
    
    # 첫 요청 - 홈페이지
    page.goto("https://www.amazon.com")
    time.sleep(random.uniform(3, 5))
    
    # 상품 요청
    page.goto("https://www.amazon.com/dp/B08N5WRWNW")
    page.wait_for_load_state("networkidle")
    
    # 데이터 추출
    title = page.locator("#productTitle").inner_text()
    price = page.locator(".a-price-whole").first.inner_text()
    
    print(f"Title: {title}, Price: ${price}")
    
    browser.close()

장점: 완전한 제어, 클라우드 서비스보다 저렴, 확장 가능. 단점: 프로그래밍 기술 필요, CAPTCHA를 직접 처리해야 함.

도구 선택에 대한 권장 사항

당신의 상황	추천 도구
프로그래밍을 할 수 없고, 하루에 100-500개의 상품이 필요함	Octoparse + 레지던트 프록시
아이디어를 빠르게 테스트해야 하고, 예산이 있음	ScrapingBee API
프로그래밍을 할 수 있고, 수천 개의 상품이 필요함	Playwright/Puppeteer + 레지던트 프록시
예산이 크고 최대의 신뢰성이 필요함	Bright Data Web Scraper

차단 시 대처 방법: 진단 및 해결책

모든 규칙을 준수하더라도 때때로 차단이 발생할 수 있습니다. 원인을 이해하고 문제를 신속하게 해결하는 것이 중요합니다.

차단 유형 및 징후

1. CAPTCHA (상태 코드 503 또는 /errors/validateCaptcha로 리디렉션):

원인: IP에서 의심스러운 활동이 발생했지만 완전한 차단은 아님
해결책: IP 변경, 요청 간 지연 증가, 사용자 행동 에뮬레이션 추가
자동화: CAPTCHA 해결 서비스 사용 (2Captcha, Anti-Captcha) — 하지만 이는 파싱 속도를 늦춥니다.

2. IP 차단 (코드 403 또는 빈 페이지):

원인: IP가 한계를 초과하거나 데이터 센터를 사용하여 블랙리스트에 올라감
해결책: 즉시 IP 변경, 프록시 유형 확인 (레지던트 대신 데이터 센터 사용 가능성)
지속 시간: 일반적으로 24-48시간, 때로는 영구적

3. "아마존 데이터에 대한 자동 접근에 대해 논의하려면 api-services-support@amazon.com에 문의하십시오":

원인: 아마존이 자동화를 명확하게 식별하고 공식 API 사용을 제안함
해결책: 브라우저 에뮬레이션 개선, TLS 지문 확인, 요청 빈도를 2배 줄임

문제 진단 체크리스트

차단이 발생하면 순서대로 확인하십시오:

프록시 유형: 레지던트를 사용하고 있는지 확인하고 데이터 센터가 아닌지 확인하십시오. whoer.net에서 확인할 수 있습니다.
지리: IP는 마켓플레이스와 동일한 국가에서 나와야 합니다 (USA는 .com, UK는 .co.uk)
User-Agent: 최신 Chrome/Firefox 버전 (3-4개월 이내)
쿠키: 세션 내 요청 간에 저장되는지 확인
JavaScript: 실행되는지 확인 (Playwright/Puppeteer를 사용하는 경우 반드시 실행되어야 함)
요청 빈도: 하나의 IP에서 분당 10-15개 이하
지연: 무작위, 고정되지 않음
IP 회전: 각 주소는 2-3시간에 1회 이하로 사용해야 함

대량 차단 시 긴급 조치

대부분의 요청이 차단되는 경우 (30% 이상):

2-3시간 동안 파싱 중지 — 아마존이 귀하의 활동을 "잊게 하십시오."
프록시 공급자 변경 — IP 풀에 이미 문제가 있을 수 있습니다.
부하를 3-5배 줄이십시오 — 시간당 100개의 요청 대신 20-30개 요청하십시오.
모바일 프록시로 전환 — 거의 차단되지 않지만 더 비쌉니다.
사람 행동을 더 많이 에뮬레이션하십시오: 무작위 카테고리 전환, 직접 URL이 아닌 검색창을 통한 상품 검색

주의: IP가 영구적으로 차단된 경우(차단이 72시간 이상 지속되는 경우), 다시 사용하려고 하지 마십시오. 아마존은 영구 차단을 해제하는 경우가 드뭅니다. 새로운 프록시 풀로 전환하십시오.

결론

아마존의 안티봇 우회는 올바른 프록시, 정확한 브라우저 에뮬레이션 및 합리적인 요청 한계를 결합해야 하는 복합적인 작업입니다. 성공적인 파싱을 위한 핵심 사항: 마켓플레이스와 동일한 국가의 레지던트 프록시 사용; 10-15분마다 IP 회전, 세션당 15-20 요청 한계; 올바른 헤더 및 JavaScript 실행을 포함한 현대 브라우저의 완전한 에뮬레이션; 요청 간 3-7초의 무작위 지연.

이러한 규칙을 준수하면 성공적인 요청 비율이 95-98%에 도달하고 차단은 드물어집니다. 가장 중요한 것은 서두르지 않고 실제 사용자의 행동을 에뮬레이션하는 것이며, 몇 분 안에 수천 개의 상품을 파싱하려고 하지 않는 것입니다.

아마존과의 안정적인 작업을 위해 레지던트 프록시를 사용하는 것을 권장합니다.

```

아마존 안티봇 우회 방법과 경쟁사 실제 가격 확인하기: 완벽 가이드