스크래핑 시 CAPTCHA 피하는 방법 (신호를 줄이고, 해결하지 않기)
CAPTCHA를 해결하는 것은 느리고 비용이 들며, 증상을 치료하는 것입니다. 지속 가능한 해결책은 CAPTCHA를 호출하지 않는 것입니다: 이를 유발하는 신호를 정리하여 위험 점수를 낮추세요.
스크래퍼가 CAPTCHA에 걸리면 해결 서비스를 찾는 것이 본능입니다. 그러나 이는 잘못된 본능입니다. CAPTCHA는 뚫고 지나가는 벽이 아닙니다 - 이미 자동화된 것으로 판단한 위험 점수의 가시적인 출력입니다. 이를 해결하는 것은 느리고, 해결당 비용이 들며, 점수를 낮추지 않기 때문에 다음 요청에서도 다시 도전받게 됩니다. 스크래핑 시 CAPTCHA를 피하는 방법에 대한 지속 가능한 답은 이를 유발하지 않는 것입니다: 점수를 빨간색으로 밀어넣는 몇 가지 신호를 정리하세요.
왜 해결하는 것이 패배의 움직임인가
reCAPTCHA v2가 실제로 어떻게 작동하는지 생각해보세요. 사이트는 공개 사이트 키를 포함하고 있으며, 도전을 해결하면 서버가 나중에 확인하는 숨겨진 g-recaptcha-response 필드에 긴 토큰을 기록합니다. 그 토큰은 재사용 방지 조치로 설계된 단일 사용입니다 - 한 번 해결하고 재사용할 수 없습니다. 해결 서비스(인간 농장 또는 ML 해결사)는 도전당 새로운 토큰을 반환하므로 점수가 높게 유지될 때마다 비용을 지불하고 몇 초를 기다려야 합니다. 당신은 증상을 자동화했을 뿐, 원인을 제거하지 않았습니다.
또한 더 미묘한 함정이 있습니다: 페이지 소유자가 그 경로에 자동화된 트래픽을 원하지 않기 때문에 도전이 표시됩니다. 문서화된 API가 존재한다면 사용하세요. 그렇지 않다면, 위험 엔진이 결코 상승하지 않도록 보통 방문자처럼 보이는 것이 현실적인 목표입니다. 이는 전적으로 당신이 보내는 신호에 관한 것입니다.
신호 1: IP 품질이 가장 큰 레버입니다
가장 강력한 입력은 요청이 어디에서 오는가입니다. 데이터 센터 IP 범위는 카탈로그화되고 미리 점수가 매겨져 있습니다; 그 중 하나에서의 새로운 요청은 페이로드의 바이트를 보내기 전에 위험 척도의 중간부터 시작할 수 있습니다. 거주지 IP - 실제 가정 연결 - 은 훨씬 낮게 시작합니다. 이것이 고전적인 현장 조언이: 거주지 IP에서 실행하고, 도전이 나타나는 순간 새로운 출구로 회전하는 것입니다. 거주지 프록시 풀은 90M+ IP에 걸쳐 요청당 회전을 자동으로 수행하여 한 주소에서 전체 작업을 스크래핑하지 않도록 합니다.
어떤 풀도 신뢰하기 전에 측정하세요. 우리의 무료 IP 품질 점수 검사기는 안티봇 엔진이 출구에 할당할 사기/평판 점수를 보여줍니다 - 높은 사기 점수를 가진 데이터 센터 IP는 CAPTCHA가 발생할 준비가 된 것입니다. 대부분의 사이트에서 왜 평판이 지문보다 우수한지에 대한 전체 그림을 원한다면, 우리의 사기 점수가 중요한 이유에 대한 게시물이 더 깊이 들어갑니다.
import requests
# Detect a challenge in the response and rotate the exit instead of retrying
CHALLENGE_MARKERS = ("g-recaptcha", "hcaptcha", "/cdn-cgi/challenge", "captcha-delivery")
def looks_challenged(resp):
if resp.status_code in (403, 429, 503):
return True
body = resp.text[:20000].lower()
return any(m in body for m in CHALLENGE_MARKERS)
def fetch(url):
# rotating gateway hands out a new residential IP each request
proxy = "http://USER:PASS@rotating.quantumproxies.io:8000"
r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=20)
if looks_challenged(r):
return None # burn this exit, the gateway rotates on the next call
return r신호 2: 당신의 TLS 지문이 당신을 드러냅니다
깨끗한 IP에서도 TLS 핸드셰이크가 당신을 드러냅니다. Python 또는 Go의 기본 스택에서의 원시 요청은 Chrome과 전혀 다른 JA3/JA4 지문을 생성합니다 - 실제 브라우저는 스크립팅 라이브러리가 복제하지 않는 특정 암호 순서, 확장 및 ALPN 값을 광고합니다. 안티봇 엔진은 그 핸드셰이크를 해시하고 알려진 봇 서명과 일치시킵니다. 해결책은 진짜 브라우저 지문을 보내는 것입니다, TLS-모방 클라이언트를 통해서든 실제 브라우저 엔진을 실행하든. 우리는 JA3/JA4 지문이 작동하는 방식에서 그 메커니즘을 다룹니다.
신호 3: 헤더 일관성
헤더는 서로 일치해야 하며 지문과도 일치해야 합니다. Windows에서 Chrome 120이라고 주장하지만 일치하는 sec-ch-ua 클라이언트 힌트를 생략하거나, 잘못된 순서로 헤더를 보내거나, 모바일 User-Agent를 데스크톱 TLS 프로파일과 함께 사용하는 요청은 명백히 일관성이 없습니다. User-Agent만 설정하지 말고, 실제 브라우저가 보낼 전체 일관된 세트를 보내고, 당신이 모방하는 플랫폼과 일관되게 유지하세요.
# Coherent header set that matches a Chrome-on-Windows fingerprint
headers = {
"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,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"sec-ch-ua": '"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"',
"sec-ch-ua-platform": '"Windows"',
"Upgrade-Insecure-Requests": "1",
}
신호 4: 행동과 속도
IP당 요청 빈도는 주요 속도 신호입니다. 한 주소에서 분당 60개의 요청은 봇으로 읽히지만, 60개의 IP에 걸쳐 분산된 동일한 60개는 60명의 사람으로 읽힙니다. 속도를 늦추고, 요청 사이에 지터를 추가하고, 풀에 걸쳐 볼륨을 분산하세요. JavaScript가 많은 대상에서는 행동 점수가 마우스 움직임, 스크롤 및 체류 시간을 감시합니다 - 헤드리스 브라우저를 구동하는 경우 즉시 클릭을 발사하지 마세요. 회전은 IP 기반 차단을 줄이지만, 기관총 요청 패턴을 변명하지 않습니다. 전체 규율은 우리의 차단 방지 체크리스트에 있습니다.
신호 5: 세션 및 쿠키 연속성
다섯 번째, 더 조용한 신호가 있습니다: 연속성. 쿠키, 참조자 및 기록 없이 도착하는 요청은 어디서 나타났는지 알 수 없는 것처럼 보입니다 - 이는 순진한 봇이 정확히 하는 것입니다. 실제 사용자는 세션을 축적합니다: 페이지에 도착하고, 쿠키가 설정되며, 클릭을 통해 이를 계속 유지합니다. 세션 내에서 쿠키를 유지하고, 보호된 경로로 차갑게 깊이 링크하지 않고 그럴듯한 페이지를 통해 들어가며, 일관된 흐름의 길이 동안 하나의 정체성을 유지하세요. 로그인 중간에 IP를 회전하는 것은 반대 효과를 줍니다 - 연속성을 찢고 점수를 올립니다 - 이것이 바로 장바구니 및 로그인과 같은 상태 유지 단계에 스티키 세션이 존재하는 이유입니다.
도전을 피할 수 없는 경우
모든 방문자를 차단하는 경로가 있습니다 - 로그인 벽, 결제, 공격적으로 보호된 검색. 그곳에서는 아무리 신호 위생을 해도 도전을 제거할 수 없으며, 브라우저 지문 유지, TLS 모방 및 깨끗한 풀을 수작업으로 관리하는 것이 자체 프로젝트가 됩니다. 그 시점에서 전체 스택을 Scraper API에 맡기는 것이 좋습니다. 이 API는 실제 브라우저 지문을 가지고 있으며, 거주지 IP를 회전시키고, 필요에 따라 JavaScript를 렌더링합니다 - URL을 보내면 HTML 또는 JSON을 반환받고, 도전 처리도 포함됩니다. 이는 자체 해결사 농장보다 이동 부품이 적고 성공률이 높습니다.
자주 묻는 질문
웹 스크래핑 시 CAPTCHA를 어떻게 피하나요?
이를 유발하는 위험 점수를 낮추세요. 플래그된 데이터 센터 범위 대신 거주지 IP에서 스크래핑하고, 일관된 헤더와 함께 실제 브라우저 TLS 지문을 보내며, 요청 속도를 조절하고 여러 IP에 걸쳐 분산시키고, 세션 내에서 쿠키를 유지하세요. 도전이 나타나면, 소진된 IP를 재시도하는 대신 출구를 회전하세요.
CAPTCHA를 해결하는 것이 더 나은가요, 피하는 것이 더 나은가요?
피하는 것이 더 낫습니다. 해결은 도전당 비용과 시간이 들며, reCAPTCHA 토큰은 단일 사용이기 때문에 지속적으로 높은 위험 점수는 매 요청마다 다시 비용을 지불해야 함을 의미합니다. 예방은 원인을 한 번에 해결합니다. 신호가 아무리 깨끗해도 모든 방문자를 도전하는 드문 경로에 대해 해결을 예약하세요.
거주지 프록시가 CAPTCHA를 막나요?
그들은 가장 큰 단일 트리거 - 나쁜 IP 평판 - 을 제거하지만, 그들만으로는 완전한 해결책이 아닙니다. 거주지 IP가 Python 기본 TLS 지문 및 기관총 요청 속도와 결합되면 여전히 도전받게 됩니다. 깨끗한 IP를 브라우저 지문, 일관된 헤더 및 합리적인 속도와 결합하세요.
거주지 IP에서도 CAPTCHA를 받는 이유는 무엇인가요?
IP는 하나의 입력일 뿐이기 때문입니다. 당신의 TLS/JA3 지문, 헤더 일관성, 요청 속도 및 세션 쿠키 부족이 여전히 점수에 영향을 줍니다. 한 번 플래그된 거주지 출구는 최근 기록도 가질 수 있습니다. 무료 IP 품질 도구로 출구를 확인하고, 실제 브라우저 지문을 보내며, IP가 문제라고 가정하기 전에 요청 속도를 늦추세요.
CAPTCHA를 장애물로 취급하지 마세요. 그것은 나타나기 전에 당신이 보낸 모든 것의 판독입니다. IP, 지문, 헤더 및 속도를 정리하면 판독이 녹색으로 유지됩니다 - 해결사가 필요 없습니다.