당신은 403을 받았습니다 — 일반적으로 사람들이 가장 먼저 하는 것은 프록시를 변경하는 것입니다. 때때로 도움이 되지만, 더 자주 그렇지 않습니다. 왜냐하면 "안티봇"은 단일 기술이 아니라 최소한 여섯 가지 다른 시스템으로 구성되어 있으며, 각 시스템은 서로 다른 탐지 메커니즘, 엄격함 및 트래픽 요구 사항을 가지고 있기 때문입니다. Imperva에서 보호받는 것이 Kasada에 대해서는 무용지물입니다. 2026년에 누가 누군지, 30초 만에 공급업체를 식별하는 방법, 각 시스템에 맞게 프록시 스택을 어떻게 변경해야 하는지에 대해 알아보겠습니다.
왜 "그냥 프록시를 변경하는 것"이 더 이상 작동하지 않는가
전통적인 논리는 간단했습니다: IP가 차단되면 다른 것을 사용합니다. 이는 탐지가 주소의 평판에 기반할 때까지 작동했습니다. 오늘날 IP는 다섯 개의 층 중 하나일 뿐이며, 서로 다른 공급업체에 따라 그 중요성이 다릅니다.
모든 공급업체가 사용하거나 사용하는 신호의 일반적인 세트는 다음과 같습니다:
- TLS 핑거프린트 (JA3/JA4) — 핸드셰이크에서 암호화 세트 및 확장의 순서;
- HTTP 헤더의 순서 및 대소문자 — Python 클라이언트는 Chrome과 다릅니다;
- IP의 평판 — ASN, 데이터 센터 소속, 주소의 역사;
- 브라우저 핑거프린트 — 캔버스, WebGL, 하드웨어 센서;
- 행동 생체 인식 — 마우스 경로, 스크롤 속도, 입력 패턴.
모든 주제 연구자들이 반복하는 핵심 결론: 신호의 일관성이 중요합니다. Chrome의 User-Agent와 Python의 TLS 핑거프린트의 조합은 IP가 얼마나 깨끗하든지 간에 모든 공급업체에서 당신을 봇으로 표시합니다. 거주 주소는 구멍이 뚫린 브라우저 레이어를 "덮지" 않으며, 그 반대도 마찬가지입니다.
1단계: 흔적을 통해 공급업체 식별하기
무언가를 변경하기 전에 응답 헤더와 쿠키를 확인하십시오. 각 시스템은 인식 가능한 서명을 남깁니다 — 이는 당신이 무엇을 다루고 있는지 이해하는 가장 빠른 방법입니다.
- Cloudflare — 헤더 CF-RAY, 쿠키 cf_clearance 및 __cf_bm, challenge.js가 로드됩니다; 새로운 빌드에서는 cf-mitigated 헤더가 나타납니다.
- DataDome — 쿠키 datadome 및 _dd_s, 스크립트 tags.js.
- Akamai — 쿠키 _abck, 참조 헤더 akamai-grn.
- PerimeterX (HUMAN Security) — 쿠키 _px3, _pxvid, _pxhd, 스크립트 px.js 또는 d.js.
- Kasada — 헤더 패밀리 x-kpsdk-* (ct — 챌린지 토큰, dv — 장치 검증, cd — 챌린지 데이터, v — 버전), 쿠키 KP_UIDz, 스크립트 ips.js 또는 p.js.
- Imperva (Incapsula) — 쿠키 incap_ses_*, visid_incap_*, reese84.
- AWS WAF — 쿠키 aws-waf-token, 엔드포인트 호출 /challenge.js.
- F5 / Shape Security — TS 접두사가 있는 쿠키 (예: TS01a2b3c4).
별도의 마커는 거부의 성격입니다. Kasada는 본문이 없는 "맨몸" 429로 응답합니다: x-kpsdk-* 헤더와 함께 403 또는 429를 보는 경우, 질문은 종료됩니다. DataDome은 종종 CAPTCHA 페이지와 함께 403을 반환합니다. Cloudflare는 대화형 챌린지 또는 Turnstile을 사용합니다.
시스템의 실제 메커니즘 차이
서명은 "누구"를 말하지만, 전술은 "어떻게"에 의해 결정됩니다. 아키텍처적으로 공급업체는 크게 다릅니다.
Cloudflare — 네트워크 엣지의 글로벌 모델
CDN 엣지 수준에서 작동합니다: 요청이 애플리케이션에 도달하기 전에 결정이 이루어집니다. 모델은 글로벌하며, 전체 네트워크의 트래픽으로 학습되었습니다 — 인터넷의 약 5분의 1에 해당하는 사이트. 당신에게 유리한 점: 행동이 예측 가능하며, 한 사이트에서의 경험이 다른 사이트로 전이됩니다. 단점: 네트워크는 수천 개의 리소스에서 당신의 서브넷을 동시에 볼 수 있으며, 평판이 빠르게 축적됩니다.
DataDome — 각 사이트에 대한 개인 모델
주요 차이점: 플랫폼은 특정 사이트의 트래픽으로 학습된 약 85,000개의 클라이언트 ML 모델을 보유하고 있으며, 하루에 5조 개의 신호를 처리하며 응답 시간은 2밀리초 미만입니다. 실제적인 결과는 간단하고 불쾌합니다: 각 보호된 사이트는 별개의 과제입니다. Etsy에 대한 작업 조합은 동일한 공급업체 아래의 다른 리소스로 전이되지 않습니다. 2025년에는 의도 분석이 추가되어 방문 목적이 평가되며, 단순히 자동화 사실만이 아닙니다.
Akamai — TLS 및 텔레메트리에 중점을 둡니다
핸드셰이크 신호를 확인하고 행동 텔레메트리를 자신의 측에서 쿠키 _abck를 통해 검증합니다. 2026년의 독립적인 측정에 따르면 Akamai와 Imperva는 기본 자동화 클라이언트를 Cloudflare 및 DataDome보다 덜 자주 챌린지합니다 — 하지만 이는 "약하다"는 의미가 아닙니다: 공격적으로 설정된 곳에서는 우회하려면 올바른 TLS 레이어가 필요하며, IP 변경이 아닙니다.
PerimeterX / HUMAN — 네트워크 평판
클라이언트의 평판은 공급업체의 전체 네트워크에 퍼집니다. 한 사이트에서 발각되면 다른 사이트에 이미 태그가 붙어 있습니다. 전형적인 플랫폼: 전자상거래 및 부동산.
Kasada — 환경에 대한 능동적 심문
대중 시스템 중 가장 엄격합니다. 단순히 핑거프린트를 수집하는 것이 아니라 환경을 능동적으로 심문합니다: 클라이언트 코드를 Function.prototype.toString()을 통해 검사하고, 자체 스크립트의 디오브퓨스케이션을 적용합니다. 종합적인 평가에 따르면 복잡성에서 극단적인 점수를 받으며, 탐지의 정교함과 자가 우회의 어려움 모두에서 높은 점수를 받습니다. 티켓팅 및 부동산에 배치됩니다.
Imperva (Incapsula) — 기본 WAF 논리
IP 및 WAF 규칙에서 출발하며; 행동 레이어는 더 높은 설정에서 연결됩니다. 전형적인 플랫폼 — 기업 웹사이트 및 구인 게시판.
누가 더 엄격한가: 감정보다 숫자
독립적인 벤치마크 Scrapeway가 있습니다: 여덟 개 서비스가 열한 개 목표를 상대로, 목표당 1,000개 이상의 요청, 월 두 번의 보고서. 목표는 공급업체에 고정되어 있습니다 — Indeed는 Cloudflare 아래, Etsy는 DataDome 아래, Walmart와 Zillow는 PerimeterX 아래, Realtor는 Kasada 아래입니다.
2026년 측정 결과는 다음과 같습니다:
- 높은 엄격함 — Cloudflare, DataDome, PerimeterX, Kasada: 압도적인 다수의 기본, 비구성된 자동화 클라이언트가 챌린지를 받습니다.
- 중간 — Akamai 및 Imperva: 기본 클라이언트를 챌린지하는 빈도가 눈에 띄게 낮습니다.
- Cloudflare 목표에 대해서는 비구성된 클라이언트의 극소수가 안정적으로 페이지 콘텐츠를 받을 수 있었습니다.
비교를 위해: 전문 우회 서비스의 성공률은 공급업체에 따라 94–100% 범위에서 유지됩니다 — 즉, 해결 가능한 문제지만 기본 클라이언트나 단순한 IP 변경으로는 안 됩니다.
각각에 맞게 프록시 스택을 변경하는 방법
이제 실천입니다. 아래는 우회의 레시피가 아니라 탐지 유형에 따른 인프라 선택의 논리입니다.
- Imperva 및 AWS WAF. IP의 중요성이 높고, 행동 레이어가 자주 꺼져 있습니다. 여기서는 데이터 센터 프록시가 여전히 유효합니다 — 깨끗한 서브넷과 합리적인 비율을 조건으로 합니다. 여기서 시작하세요, 트래픽 측면에서 가장 저렴합니다.
- Akamai. 프록시는 TLS 레이어보다 덜 효과적입니다. 먼저 핸드셰이크와 헤더의 순서를 정리한 다음 IP 클래스를 높이십시오. 잘못된 JA4 핑거프린트에서 프록시를 변경해도 아무런 효과가 없습니다.
- Cloudflare. 글로벌 평판은 서브넷이 빠르게 소진된다는 것을 의미합니다. 넓은 풀과 합리적인 회전을 가진 거주 프록시가 필요합니다: "각 요청마다 새로운 IP"가 아니라 논리적 작업 시간 동안 세션을 유지해야 하며, 그렇지 않으면 cf_clearance가 무너집니다.
- DataDome. 모델은 특정 사이트의 트래픽으로 학습되었으므로 그 사이트에서의 행동의 일관성이 가장 중요합니다. 거주 IP는 긍정적인 트러스트 스코어를 제공합니다, 왜냐하면 실제 사람들이 거주 연결로 이동하기 때문입니다 — 그러나 스스로는 브라우저 핑거프린트를 관리하지 않으면 아무것도 보장하지 않습니다. 한 사이트에 대한 설정을 다른 사이트에 무작위로 적용하지 마십시오. 이 공급업체에 대한 구체적인 세부 사항은 DataDome 우회를 위한 프록시 분석에서 확인하십시오.
- PerimeterX / HUMAN. 네트워크 평판이므로 격리가 양보다 중요합니다: 서로 다른 프로젝트는 서로 다른 풀을 가져야 하며, 한 플랫폼의 태그가 다른 플랫폼으로 이어지지 않도록 해야 합니다.
- Kasada. 데이터 센터 주소는 입구에서 차단됩니다. 최소한의 작업은 거주 프록시이며, 더 나은 것은 모바일 프록시입니다: 하나의 모바일 IP를 통해 CGNAT를 통해 수백 명의 실제 가입자가 연결되어 있으며, 시스템은 그러한 주소를 차단하는 데 더 많은 비용이 듭니다. 또한 User-Agent는 최신 브라우저 버전과 일치해야 하며 — 구식 문자열은 즉시 연결을 드러냅니다.
주요 실수: 이질적인 스택
우리가 시작한 것을 반복하겠습니다, 왜냐하면 이것이 대부분의 "설명할 수 없는" 차단의 원인이기 때문입니다. 모든 여섯 시스템은 층 간의 비동기성을 포착합니다. 독일에서의 거주 IP + 시스템 표준 시간대 UTC + curl의 TLS 핑거프린트 + User-Agent의 최신 Chrome — 이는 "거의 통과했다"가 아니라 완전한 봇 프로필입니다. 프록시는 다섯 개 층 중 하나만 책임지며; 나머지 네 개는 당신의 클라이언트에 존재합니다.
따라서 실용적인 작업 순서는 다음과 같습니다: 먼저 서명으로 공급업체를 식별한 다음, 어떤 층이 가장 약한지 평가하고 그것을 수정하십시오 — 가장 쉽게 변경할 수 있는 것이 아니라. 스택을 정리한 후에도 목표가 여전히 접근할 수 없다면, 질문은 "스스로 구축할 것인가, 아니면 준비된 것을 위해 비용을 지불할 것인가"로 넘어갑니다 — 이 분기는 프록시 대 스크래핑 API 및 웹 언블로커 자료에서 다루었습니다.
간단히 말해
단일 "안티봇"은 존재하지 않으며, 보편적인 우회도 없습니다 — 어떤 기술도 여덟 개 시스템 모두에 대해 동시에 작동하지 않습니다. 쿠키와 헤더로 공급업체를 식별하십시오 (30초 소요), 그 메커니즘을 이해하십시오 — Imperva의 IP 중요성, Akamai의 TLS, Cloudflare의 글로벌 평판, DataDome의 사이트별 개인 모델, PerimeterX의 네트워크 태그, Kasada의 환경에 대한 능동적 심문 — 그리고 이에 맞는 프록시 유형을 선택하십시오, 무작위로가 아니라. 데이터 센터는 IP를 형식적으로 보는 곳; 거주지는 트러스트를 고려하는 곳; 모바일은 네트워크가 모든 서버를 엄격하게 차단하는 곳입니다. 그리고 모든 층의 일관성을 주의하십시오: 바로 이 점에서 대부분의 프로젝트가 잘못 설정된 것처럼 보입니다.
```