다른 어떤 문의보다도 자주 듣는 이야기가 있습니다. “레지덴셜 프록시가 차단당한 게 분명해요, 계속 막혀요.” 확인해보면 IP는 깨끗하고 평판이 좋은 레지덴셜 주소입니다. 문제는 프록시가 아닙니다. 요청이 전송되는 방식입니다.
레지덴셜 IP가 사주는 것은 딱 한 가지, 깨끗한 네트워크 신원입니다. 깨끗한 요청을 사주지는 않습니다. 안티봇 시스템은 수십 가지 신호를 살펴보며, IP는 그중 첫 번째에 불과합니다. 헤더, 타이밍, 핑거프린트, 세션 행동 등 트래픽의 나머지 모든 요소가 “자동화”를 말하고 있다면, 완벽한 레지덴셜 IP로도 구원받을 수 없습니다. 대부분의 레지덴셜 프록시 탐지는 IP의 실패가 아니라 설정 단계에서 자초한 결과입니다.
이 글은 좋은 레지덴셜 프록시가 그럼에도 탐지당하게 만드는 실수들과, 각각을 고치는 방법을 다루는 실무자용 가이드입니다.
1. 세션 도중 IP를 로테이션하는 것
가장 흔한 실수이자 가장 자멸적인 실수입니다. 한 IP로 로그인한 뒤, 다음 요청, 즉 로그인 뒤의 페이지를 가져오는 요청이 다른 IP로 나갑니다. 사이트 입장에서는 인증된 세션이 갑자기 새로운 주소로 순간이동한 것입니다. 이는 즉각적인 플래그로 이어지며, 어떤 IP 품질로도 이를 해결할 수 없습니다.
해결책: 로테이션 모드를 작업에 맞추십시오. 여러 단계로 이루어진 흐름(로그인, 탐색, 결제)에는 스티키 세션이 필요합니다. 즉, 전체 시퀀스 동안 하나의 IP를 유지하는 것입니다. 요청별 로테이션은 상태가 없는 독립적인 요청에 적합합니다. 이 둘을 뒤섞어서, 유지해야 할 때 로테이션하는 것이 “레지덴셜 프록시가 탐지당했다”는 문제의 단일 최대 원인입니다. (언제 무엇을 써야 하는지는 스티키 대 로테이팅을 참고하세요.)
2. 하나의 IP를 너무 세게 두드리는 것
정반대의 실수입니다. 스티키 IP 하나를 고정하고 짧은 시간 안에 수천 건의 요청을 그 IP를 통해 발사합니다. 실제 레지덴셜 사용자는 1분에 5,000개의 페이지를 로드하지 않습니다. 요청 양이 인간을 초월하면 아무리 깨끗한 IP라도 자동화된 것처럼 보입니다.
해결책: 부하를 풀 전체에 분산시키십시오. 스티키 세션은 흐름이 실제로 하나의 신원을 필요로 하는 동안만 사용하고, 그 후에는 로테이션하십시오. IP당 요청 속도를 인간적인 범위 안에 유지하십시오. 대규모 풀의 핵심은 어느 하나의 IP도 의심스러운 부하를 지지 않는다는 점이며, 이를 무너뜨리면 풀 자체를 무너뜨리는 것입니다.
3. IP와 모순되는 지역 신호
독일 레지덴셜 IP를 경유하지만, 요청은 Accept-Language: en-US를 보내고, 브라우저 시간대는 America/New_York이며, 로케일 설정은 미국입니다. IP는 독일이라고 말하지만 나머지 모든 것은 미국이라고 말합니다. 이러한 모순은 교과서적인 탐지 신호이며, 전적으로 당신이 통제할 수 있는 부분입니다.
해결책: 모든 지역 신호가 IP와 일치하도록 만드십시오. 특정 국가를 타겟팅할 때는 Accept-Language, 시간대, 로케일, 통화/지역 설정을 모두 맞추십시오. 특정 위치의 레지덴셜 IP는 요청의 나머지 부분도 그 위치에 속할 때에만 설득력이 있습니다.
4. 자동화를 외치는 핑거프린트
IP는 레지덴셜이지만, 요청은 순서가 잘못된 세 개의 헤더와 실제 브라우저와 일치하지 않는 TLS 핸드셰이크를 가진 python-requests/2.x로 전송됩니다. 안티봇 시스템은 User-Agent, 헤더 세트와 순서, TLS/JA3 핑거프린트를 읽으며, 이들 사이의 불일치(“Chrome” User-Agent가 Python TLS 핑거프린트 위에 있는 경우)는 확실한 단서입니다. IP는 레지덴셜이지만, 클라이언트는 명백히 스크립트입니다.
해결책: 일관되고 브라우저와 부합하는 핑거프린트를 전송하십시오. 현실적인 User-Agent를 사용하고, 실제 브라우저가 보내는 전체 헤더 세트를 올바른 순서로 보내고, 자처하는 브라우저와 TLS 핑거프린트가 일치하는 클라이언트를 사용하십시오. 프록시 핑거프린트에서 이 계층을 심도 있게 다루는데, 탐지를 피하는 데 있어 가장 저평가된 부분입니다.
5. DNS 유출 (socks5 대 socks5h)
미묘한 문제입니다. socks5:// 대신 socks5h://를 사용하지 않으면, 요청이 프록시를 통과하기 전에 당신의 기기가 대상 호스트명을 로컬에서 먼저 해석합니다. 이 DNS 조회는 당신의 실제 네트워크에서 일어나며, 이는 실제 위치를 노출시킬 수 있고, 일부 설정에서는 DNS 해석과 연결이 서로 다른 곳에서 발생한다는 사실 때문에 프록시가 사용되고 있음을 드러낼 수 있습니다.
해결책: DNS를 프록시에서 해석하십시오. socks5h://(그 h)를 사용하거나, HTTP 프록시의 경우 클라이언트가 미리 해석하지 않도록 하십시오. 이렇게 하면 조회를 포함한 전체 요청이 레지덴셜 종료 지점에서 발생하게 됩니다. (자세한 내용은 자동화를 위한 SOCKS5 참고.)
6. 비인간적인 요청 패턴
완벽한 IP와 핑거프린트를 갖추고도, 행동이 당신을 드러냅니다. 정확하고 기계적으로 규칙적인 간격으로 발사되는 요청들. 동작 사이의 생각하는 시간이 전혀 없음. 하나의 세션에서 완벽하게 병렬로 동일한 엔드포인트를 두드리는 열 명의 “사용자”. 쿠키도 없고, 자산 로드도 없고, JavaScript도 없이, 사람이 브라우저로는 결코 단독으로 만들어내지 않을 순수한 HTML 요청들뿐입니다.
해결책: 사람처럼 행동하십시오. 무작위 지연을 추가하고, 타이밍을 다양하게 하고, 완벽하게 균등한 간격으로 요청을 발사하지 말고, 하나의 신원 아래에서 불가능한 동시성을 실행하지 마십시오. 행동 기반 탐지는 IP와 핑거프린트 검사를 통과한 후 스크레이퍼를 잡아내는 방법으로 점점 더 많이 사용되고 있습니다.
7. 하나의 신원을 여러 IP에 걸쳐 사용하는 것
실수 #1의 거울상입니다. 한 IP에서 세션 쿠키를 수집한 다음, 부하를 분산시키기 위해 그 동일한 쿠키를 수십 개의 다른 IP에서 재사용합니다. 사이트 입장에서는 로그인된 하나의 계정이 서로 다른 도시의 스무 개 주소에서 동시에 접속하고 있는 것입니다. 실제 사용자라면 그렇게 하지 않습니다.
해결책: 신원과 IP를 함께 묶어두십시오. 하나의 세션, 그 세션의 수명 동안 하나의 스티키 IP. IP를 로테이션한다면 새로운 세션을 시작하고, 이전 신원의 쿠키, 로컬 스토리지, 토큰을 새로운 주소로 끌고 가지 마십시오.
8. 소프트 차단을 무시하고 무작정 재시도하는 것
CAPTCHA나 429를 만나면, 스크레이퍼가 동일한 요청을 즉시, 동일한 IP에서, 동일한 속도로 재시도합니다. 재시도할 때마다 자동화라는 사실이 사이트에 확인되고 플래그가 격화되며, 종종 “CAPTCHA 표시”에서 “이 IP 차단”으로 이어집니다.
해결책: 소프트 차단을 노이즈가 아니라 신호로 취급하십시오. 물러서고, IP를 로테이션하고, 속도를 늦추고, 챌린지를 유발한 패턴을 재고하십시오. 무작정 재시도는 회복 가능한 소프트 차단을 하드 차단으로 만듭니다. (일반적인 대처법은 차단을 피하는 방법에서 다룹니다.)
9. 지역 설정을 과도하게 제한해서 풀을 붕괴시키는 것
정밀한 것이 더 낫다는 생각으로 국가 + 주 + 도시 + ASN을 타겟팅합니다. 그러면 매칭되는 풀이 아주 작아지고, 게이트웨이는 같은 소수의 IP를 반복해서 당신에게 넘겨줍니다. 거대하고 다양한 레지덴셜 풀을 다섯 개 주소의 로테이션으로 만들어버린 셈이고, 각각이 당신의 전체 부하를 지면서 빠르게 소진됩니다.
해결책: 작업이 필요로 하는 만큼만 타겟팅하십시오. 사이트가 국가를 신경 쓴다면 국가만 타겟팅하고, 도시 + ASN까지는 하지 마십시오. 과도한 제한은 풀 다양성을 축소시키고 발자국을 집중시키는데, 이는 레지덴셜 프록시의 목적과 정반대입니다. (좁은 지역 타겟팅이 정말로 필요할 때만 IP 로테이션을 활용하십시오.)
10. 브라우저 자동화 유출
Puppeteer, Playwright, Selenium 등으로 실제 브라우저를 레지덴셜 프록시를 통해 구동할 때, 브라우저 자체가 당신을 배신할 수 있습니다. WebRTC는 프록시 뒤에 있는 실제 IP를 노출시킬 수 있습니다. 헤드리스 모드의 흔적, 누락되거나 자동화 특유의 속성, 기본 자동화 플래그 모두 종료 IP가 아무리 깨끗해도 봇임을 알립니다.
해결책: 브라우저를 강화하십시오. 실제 IP가 유출되지 않도록 WebRTC를 비활성화하거나 라우팅하고, 헤드리스 흔적을 제거하고, 자동화 프레임워크가 일반 브라우저처럼 보이도록 설정하십시오. 명백히 자동화된 브라우저 앞의 레지덴셜 IP는 낭비된 레지덴셜 IP입니다.
이 모든 것 뒤에 있는 패턴
위의 모든 실수는 같은 근본 원인을 가지고 있습니다. 레지덴셜 IP를 위장의 전부로 취급하고, 그것이 한 층에 불과하다는 사실을 무시하는 것입니다. 탐지는 전체적입니다. 안티봇 시스템은 IP, 핑거프린트, 지역 신호, 세션 행동, 타이밍으로부터 그림을 그리고, 모순을 플래그합니다. Python 핑거프린트, 미국 헤더, 기계적 타이밍, 공유 쿠키를 가진 레지덴셜 IP는 레지덴셜 사용자가 아니라 레지덴셜 IP를 걸친 스크립트이며, 현대 탐지 시스템은 이를 정확히 꿰뚫어봅니다.
IP를 제대로 갖추고(깨끗하고, 레지덴셜이고, 잘 관리된) 그런 다음 다른 모든 신호가 그것과 일치하도록 만드십시오. 그것이 이 기술의 전부입니다.
FAQ
IP가 깨끗한데 왜 내 레지덴셜 프록시가 탐지되나요? IP는 신호 중 하나에 불과하기 때문입니다. 핑거프린트(User-Agent, 헤더, TLS), 지역 설정, 세션 행동, 또는 요청 타이밍이 레지덴셜 IP와 모순되면 안티봇 시스템은 그 모순을 플래그합니다. 대부분의 레지덴셜 프록시 탐지는 IP 문제가 아니라 설정 문제입니다.
가장 흔한 레지덴셜 프록시 실수는 무엇인가요? 세션 도중 IP를 로테이션하는 것, 즉 로그인과 그 뒤의 요청 사이에서 주소를 바꾸는 것이며, 이로 인해 인증된 세션이 IP 사이를 점프하는 것처럼 보입니다. 여러 단계로 이루어진 흐름에는 스티키 세션을 사용하십시오.
레지덴셜 프록시가 내 핑거프린트를 숨겨주나요? 아니요. 레지덴셜 프록시는 IP만 바꿀 뿐, 다른 것은 바꾸지 않습니다. User-Agent, 헤더 순서, TLS/JA3 핑거프린트, 브라우저 속성은 변하지 않으며 별도로 일관되게 만들어야 합니다. IP와 핑거프린트는 독립된 계층입니다.
지역 불일치가 레지덴셜 프록시를 차단당하게 할 수 있나요?
네. 한 국가의 IP인데 Accept-Language, 시간대, 로케일이 다른 국가의 것이라면 이는 전형적인 탐지 신호입니다. 모든 지역 신호를 IP의 위치와 맞추십시오.
지역 타겟팅을 과도하게 하면 왜 나쁜가요? 국가 + 주 + 도시 + ASN으로 제한하면 매칭되는 풀이 축소되어, 같은 소수의 IP를 재사용하게 되고 발자국이 집중되어 그 IP들을 빠르게 소진시킵니다. 작업이 요구하는 만큼만 정밀하게 타겟팅하십시오.
CAPTCHA 이후 즉시 재시도해야 하나요? 아니요. 동일한 IP로 즉시 재시도하면 자동화가 확인되어 소프트 차단이 하드 차단으로 격화됩니다. 물러서고, 로테이션하고, 속도를 늦추고, 챌린지를 유발한 패턴을 재고하십시오.
결론
인간처럼 보이려면 레지덴셜 IP가 필요하지만, 그것만으로는 결코 충분하지 않습니다. 실무자들을 가장 좌절시키는 탐지, “좋은 프록시를 갖고 있는데도 여전히 차단당한다”는 거의 항상 자초한 것입니다. 로테이션 실수, 핑거프린트 불일치, 지역 모순, 또는 비인간적인 타이밍입니다. 이것들을 고치면, 깨끗한 IP가 마침내 제 역할을 할 수 있게 됩니다.
IP 자체가 문제라고 의심된다면, 그것도 배제해볼 가치가 있으며, IP 평판에서 풀을 평가하는 방법을 다룹니다. 하지만 훨씬 더 자주, 해결책은 연결의 당신 쪽에 있습니다. 우선 IP 계층이 견고하도록 양질의 레지덴셜 네트워크로 시작한 다음, 요청 안의 다른 모든 신호가 그것과 일치하도록 만드십시오. 프록시는 당신이 부여한 위장만큼만 그것을 운반할 수 있습니다.