웹사이트가 프록시 트래픽을 감지하는 방법: 신호, 테스트 및 실용적인 방어

프록시 트래픽은 단일 신호로 감지되지 않습니다. 웹사이트는 프록시를 통해 요청이 들어왔다고 해서 이를 차단하는 경우는 드뭅니다. 대신, 네트워크 아이덴티티, 브라우저 행동, 요청 타이밍, 디바이스 신호, 세션 기록 및 위치 일관성을 비교합니다. 이러한 신호들이 일치하지 않을 때 마찰이 증가합니다: CAPTCHA가 나타나고, 페이지가 빈 데이터를 반환하며, 세션이 재설정되거나 요청이 속도 제한을 받습니다.

웹 스크래핑 프록시, 브라우저 자동화, SEO 모니터링, 가격 정보 수집 또는 지리적 타겟팅 연구를 사용하는 팀에게 프록시 감지를 이해하는 것은 필수적입니다. 이는 팀이 올바른 프록시 유형을 선택하고, 트래픽을 책임감 있게 형성하며, 데이터 품질을 검증하고, 추측에 의존하지 않고 피할 수 있는 차단을 줄이는 데 도움이 됩니다.

웹사이트는 IP 평판, ASN 분류, TLS 및 HTTP 지문, 브라우저 지문, DNS 및 WebRTC 신호, 지리적 일관성, 쿠키 행동 및 트래픽 패턴을 결합하여 프록시 트래픽을 감지합니다. 가장 강력한 시스템은 이러한 신호를 함께 점수화한 다음, 속도 제한, 중간 페이지, CAPTCHA, 소프트 블록 또는 전체 블록과 같은 마찰을 적용합니다.

프록시 감지가 의미하는 것

프록시 감지는 웹사이트가 트래픽이 일반 사용자, 비즈니스 시스템, 검색 크롤러, 봇, 스크래퍼, 자동화 도구 또는 프록시 네트워크에서 오는 것처럼 보이는지를 결정하는 과정입니다.

프록시 자체는 자동으로 의심스럽지 않습니다. 많은 합법적인 시스템이 라우팅, 보안, 테스트, 현지화, 연구, 모니터링 및 비즈니스 운영을 위해 프록시를 사용합니다.

문제는 신호 일관성입니다.

세션이 더 의심스러워 보일 때:

• IP 위치가 브라우저 시간대와 충돌할 때
• User-Agent가 Chrome이라고 주장하지만 TLS 행동이 Chrome과 일치하지 않을 때
• 요청마다 쿠키가 재설정될 때
• 수천 개의 페이지가 동일한 타이밍으로 가져올 때
• 동일한 브라우저 지문이 여러 IP에서 나타날 때
• WebRTC가 다른 네트워크 경로를 노출할 때
• IP가 호스팅 ASN에 속하지만 세션이 소비자 사용자처럼 행동할 때
• 현지화된 콘텐츠가 요청된 시장과 일치하지 않을 때

감지 시스템은 이러한 불일치와 패턴을 찾습니다.

웹사이트가 프록시 트래픽을 감지하는 이유

웹사이트는 여러 가지 이유로 프록시 감지를 사용합니다:

• 남용 및 사기 감소
• 계정 시스템 보호
• 서버 부하 관리
• 재고 남용 방지
• 무단 스크래핑 제한
• 스팸 및 자격 증명 공격 감소
• 가격 또는 마켓플레이스 데이터 보호
• 지역 라이센스 또는 접근 규칙 시행
• 분석 품질 보존
• 보안 정책 준수

데이터 팀에게 이는 프록시 전략이 책임감 있고, 측정 가능하며, 워크플로우와 일치해야 함을 의미합니다. 사이트가 공식 API, 파트너 피드 또는 사용 사례에 맞는 라이센스 데이터 경로를 제공하는 경우, 해당 경로를 먼저 고려해야 합니다.

웹사이트가 사용하는 핵심 신호

프록시 감지는 일반적으로 여러 레이어의 신호를 결합합니다.

가장 중요한 레이어는:

• 네트워크 및 IP 평판
• ASN 및 호스팅 분류
• TLS 및 HTTP 지문
• 브라우저 및 디바이스 지문
• DNS 및 WebRTC 행동
• 지리 및 로케일 일관성
• 쿠키 및 스토리지 행동
• 요청 타이밍 및 탐색 패턴
• 활성 도전 및 함정

각 신호는 단독으로는 불완전합니다. 함께 결합되어 위험 점수를 생성합니다.

네트워크 및 IP 평판 신호

첫 번째 레이어는 IP 자체입니다.

웹사이트는 다음을 평가할 수 있습니다:

• IP 평판
• 남용 이력
• ASN 유형
• 호스팅 제공업체 범위
• 알려진 프록시 네트워크
• 공개 프록시 데이터베이스
• 블랙리스트
• 인근 IP의 요청량
• 서브넷 행동
• 역 DNS 패턴
• 국가 또는 도시 메타데이터

데이터센터 프록시는 빠르고 비용 효율적이지만, 일부 웹사이트는 호스팅 또는 클라우드 ASN을 더 조심스럽게 다룹니다. 이는 데이터센터 프록시가 사용 불가능하다는 것을 의미하지 않습니다. 이들은 공개 페이지, API, 사이트맵, 모니터링 및 낮은 마찰의 워크플로우에 매우 잘 작동할 수 있습니다.

주거용 프록시는 소비자 ISP 네트워크를 통해 라우팅되며, 지리적으로 민감하거나 소비자 지향적인 작업 흐름에 더 적합합니다. 이들은 일부 IP 수준의 의심을 줄일 수 있지만, 나쁜 브라우저 지문, 공격적인 요청 타이밍 또는 불량 세션 설계를 해결하지는 못합니다.

더 넓은 라우팅 비교를 보려면 데이터 센터 vs 주거용 vs ISP 프록시 설명를 참조하십시오.

ASN 및 호스팅 검사

ASN은 자율 시스템 번호(Autonomous System Number)를 의미합니다. 이는 IP 주소 블록을 소유하거나 발표하는 네트워크를 식별합니다.

웹사이트는 ASN 데이터를 사용하여 트래픽을 다음과 같이 분류할 수 있습니다:

• 클라우드 제공업체
• 호스팅 제공업체
• 데이터 센터
• ISP
• 모바일 통신사
• 기업 네트워크
• 주거용 브로드밴드

세션이 정상 가정 사용자처럼 행동한다고 주장하지만 알려진 데이터 센터 ASN에서 오는 경우, 위험 점수가 증가할 수 있습니다. 이는 소비자 지향 사이트, 전자상거래 플랫폼, 여행 사이트, 소셜 플랫폼 및 계정 기반 서비스에서 특히 그렇습니다.

좋은 프록시 전략은 프록시 유형을 작업 부하에 맞추는 것입니다. 작동하는 곳에서는 더 저렴한 데이터 센터 경로를 사용하십시오. 세션 신뢰, 지리적 정확성 또는 소비자와 같은 네트워크 정체성이 중요한 경우에는 주거용 또는 ISP 경로를 사용하십시오.

TLS 및 HTTP 지문 인식

웹사이트는 페이지가 로드되기 전에 클라이언트가 연결하는 방식을 검사할 수 있습니다.

TLS 지문 인식은 다음과 같은 세부 사항을 살펴봅니다:

• TLS 버전
• 암호화 스위트
• 확장 순서
• 지원 그룹
• ALPN 동작
• HTTP/2 설정
• 연결 재사용 동작

일반 Chrome 브라우저, Python HTTP 클라이언트, 헤드리스 브라우저 및 구식 스크래핑 라이브러리는 모두 서로 다른 연결 지문을 생성할 수 있습니다.

사용자 에이전트가 "Chrome"이라고 말하지만 TLS 동작이 Chrome과 유사하지 않으면 세션이 합성으로 보일 수 있습니다.

이것이 단순히 브라우저 헤더를 복사하는 것만으로는 충분하지 않은 이유입니다. 전체 클라이언트 스택이 일관되어야 합니다.

고충이 큰 대상의 경우, 브라우저 기반 수집이 수동으로 구성된 헤더를 가진 경량 HTTP 클라이언트보다 더 일관되게 동작할 수 있습니다. 저충 대상의 경우, HTTP 클라이언트가 여전히 더 효율적이고 완전히 충분할 수 있습니다.

헤더 일관성

헤더는 또 다른 탐지 계층입니다.

웹사이트는 다음을 평가할 수 있습니다:

• 헤더 순서
• 누락된 브라우저 헤더
• 비정상적인 대문자 사용
• Accept-Language
• Accept-Encoding
• sec-ch-ua 값
• 사용자 에이전트 일관성
• 리퍼러 동작
• 쿠키 처리
• 압축 지원

일반적인 실수에는 다음이 포함됩니다:

• 일치하는 브라우저 헤더 없이 최신 Chrome 사용자 에이전트를 사용하는 것
• 프록시 지역과 충돌하는 Accept-Language 설정
• 비브라우저 순서로 헤더 전송
• 모든 세션에서 동일한 헤더 재사용
• 모바일이라고 주장하지만 데스크탑 뷰포트 동작 사용
• 반복적인 브라우징 단계에서 쿠키를 전송하지 않음

헤더는 클라이언트와 목표 시장에 맞아야 합니다. 프랑스에서 온 세션이 고의적인 이유가 없는 한 미국 전용 로케일을 우연히 포함해서는 안 됩니다.

브라우저 및 장치 지문 인식

브라우저 지문 인식은 브라우저 기반 작업 흐름에서 가장 중요한 계층 중 하나입니다.

웹사이트는 다음을 검사할 수 있습니다:

• 사용자 에이전트
• 화면 크기
• 장치 메모리
• 하드웨어 동시성
• 시간대
• 언어
• 설치된 글꼴
• 캔버스 동작
• WebGL 렌더러
• 오디오 API
• 미디어 장치
• 브라우저 플러그인
• 자동화 플래그
• 쿠키 및 로컬 스토리지
• WebRTC 동작

프록시는 네트워크 경로를 변경합니다. 그러나 브라우저 지문을 자동으로 변경하지는 않습니다.

예를 들어, 세션이 독일의 주거용 IP를 사용할 수 있지만 다음을 노출할 수 있습니다:

• 미국 시간대
• 영어 전용 언어 설정
• 리눅스와 유사한 글꼴
• 비정상적인 WebGL 출력
• 누락된 미디어 장치
• 자동화 플래그

그 조합은 일관성이 없어 보일 수 있습니다.

더 깊은 안내를 원하시면 웹 스크래핑을 위한 브라우저 지문 인식을 참조하십시오.

DNS, WebRTC 및 환경 누수

일부 프록시 설정은 브라우저나 런타임이 프록시 경로 외부의 네트워크 세부정보를 노출하기 때문에 실패합니다.

일반적인 누수 지점은 다음과 같습니다:

• DNS 해석기 위치
• WebRTC 네트워크 정보
• 로컬 IP 노출
• 브라우저 확장 프로그램
• 시스템 시간대
• 프록시 우회 규칙
• 일관되지 않은 지리적 위치 권한

HTTP 트래픽이 한 국가를 통해 나가지만 DNS 또는 WebRTC 신호가 다른 네트워크 경로를 제안하면 세션이 덜 일관되게 됩니다.

이는 브라우저 자동화 및 안티 감지 설정에 가장 중요합니다. 단순한 IP 확인만으로는 충분하지 않습니다. 팀은 DNS 동작, WebRTC 동작, 시간대, 언어 및 반환된 콘텐츠를 검증해야 합니다.

자세한 내용은 WebRTC 누수: 왜 안티 감지 설정을 깨는가를 참조하십시오.

지리 및 지역 불일치

지리적 불일치는 감지 문제이자 데이터 품질 문제입니다.

세션이 의심스러워 보일 수 있는 경우:

• IP 국가와 브라우저 시간대 간의 충돌
• 언어가 지역과 일치하지 않음
• 통화가 상점과 일치하지 않음
• 쿠키가 다른 국가를 제안함
• 세션 중 배송 지역이 변경됨
• 도시 수준의 콘텐츠가 프록시 경로와 일치하지 않음

SEO, 가격 책정, 여행 및 광고 검증을 위해 지리적 불일치는 데이터의 정확성을 떨어뜨릴 수 있습니다. 잘못된 위치에서 수집된 결과는 여전히 유효한 페이지일 수 있지만, 의도된 시장에는 유효하지 않습니다.

IP 레이블뿐만 아니라 반환된 콘텐츠로 지리적 정확성을 검증하십시오.

확인할 사항:

• 통화
• 언어
• 로컬 팩 결과
• 상점 선택기
• 배송 지역
• 페이지 URL
• 지역 배너
• 지역화된 스니펫
• 국가별 가용성

행동 신호

웹사이트는 트래픽의 행동을 평가하기도 합니다.

봇과 유사한 패턴은 다음과 같습니다:

• 완벽하게 타이밍이 맞는 요청
• 하나의 IP 또는 서브넷에서 높은 동시성
• 스크롤이나 상호작용 없음
• 많은 깊은 제품 페이지에 직접 접근
• 자산 로딩 없음
• 체류 시간 없음
• 동일한 탐색 경로
• 실패 후 과도한 재시도
• 동일한 템플릿에 대한 반복 접근
• 대규모에서의 단일 페이지 세션

정상 사용자는 일관성이 없습니다. 그들은 잠시 멈추고, 스크롤하고, 자산을 로드하고, 페이지 유형 간에 이동하며, 세션마다 다르게 행동합니다.

이것이 팀이 무모하게 인간 행동을 가장해야 한다는 의미는 아닙니다. 트래픽은 책임감 있게 형성되어야 합니다: 낮은 동시성, 큐 기반 일정, 백오프, 재시도 한도 및 작업 부하 분할.

능동적 도전과 함정

일부 웹사이트는 트래픽을 분류하기 위해 능동적인 메커니즘을 사용합니다.

여기에는 다음이 포함될 수 있습니다:

• CAPTCHA 프롬프트
• JavaScript 챌린지
• 작업 증명 과제
• 허니팟 링크
• 숨겨진 양식 필드
• 지연 렌더링
• 봇 감지 SDK
• 중간 페이지
• 소프트 블록 템플릿

소프트 블록은 특히 중요합니다. 페이지가 HTTP 200을 반환할 수 있지만, 콘텐츠가 불완전하거나, 오래되었거나, 일반적이거나, 필요한 데이터가 누락될 수 있습니다.

소프트 블록의 예는 다음과 같습니다:

• 빈 제품 가격
• 누락된 유기적 결과
• 일반 검색 페이지
• 반복된 동일한 콘텐츠
• HTML에 숨겨진 CAPTCHA
• 불완전한 재고
• 잘못된 지역 콘텐츠
• 자리 표시자 데이터

시스템은 상태 코드뿐만 아니라 콘텐츠를 검증해야 합니다.

다양한 프록시 유형이 플래그가 지정되는 방법

데이터 센터 프록시

데이터 센터 프록시는 대상이 호스팅 ASN 또는 클라우드 IP 범위를 강하게 불신할 때 플래그가 지정될 수 있습니다. 그들은 여전히 낮은 마찰의 공개 페이지와 대량 작업에서 잘 수행할 수 있습니다.

주거용 프록시

주거용 프록시는 일부 네트워크 수준의 의심을 줄이지만 여전히 브라우저 지문, 세션 행동 또는 지리적 불일치를 통해 감지될 수 있습니다.

ISP 프록시

ISP 프록시는 표준 데이터 센터 IP보다 안정적인 세션과 더 강한 평판을 제공할 수 있습니다. 연속성이 중요한 경우 유용합니다.

모바일 프록시

모바일 프록시는 모바일 우선 워크플로우에 잘 작동할 수 있지만 비용이 많이 들고 예측할 수 없을 수 있습니다. 일반적인 웹 스크래핑에는 항상 필요하지 않습니다.

최고의 접근 방식은 일반적으로 하이브리드입니다. 쉬운 페이지는 비용 효율적인 프록시를 통해 라우팅하고 민감한 작업을 위해 더 강력한 경로를 예약합니다.

회전 세션 대 고정 세션

프록시 회전 전략은 감지 위험에 영향을 미칩니다.

회전 프록시는 다음에 유용합니다:

• 무상태 공개 스크래핑
• 광범위한 URL 수집
• 독립적인 SERP 확인
• 시장 조사
• 대량 공개 페이지

고정 또는 정적 세션은 다음에 더 좋습니다:

• 로그인
• 장바구니
• 체크아웃 흐름
• 계정 대시보드
• 페이지 매김
• 지역 SEO 배치
• 지역별 워크플로우
• 브라우저 자동화

더 많은 맥락은 회전 프록시 대 정적 프록시를 참조하세요.

과도한 회전은 과소 회전만큼이나 문제가 될 수 있습니다. IP가 너무 자주 변경되면 쿠키와 브라우저 정체성이 동일하게 유지되면서 세션이 일관성이 없어 보일 수 있습니다.

측정할 내용

프록시 감지는 측정할 때 관리하기가 더 쉬워집니다.

추적:

CPSR은 성공적인 요청당 비용을 의미합니다.

간단히 말해: CPSR은 프록시 지출, 컴퓨팅, 재시도, 브라우저 렌더링 및 실패 후 각 유효한 결과의 비용을 알려줍니다.

마찰을 줄이는 실용적인 방어책

목표는 통제를 우회하는 것이 아닙니다. 목표는 불필요한 마찰을 줄이는 일관되고 책임 있는 워크플로를 구축하는 것입니다.

다음과 같은 방법을 사용하세요:

• 작업에 맞는 프록시 유형 선택.
• 시간대, 언어 및 지역 정렬.
• 다단계 흐름에 대해 스티키 세션 사용.
• 상태 비저장 수집을 위해 회전 사용.
• 세션당 브라우저 지문 일관성 유지.
• 과도한 동시성 피하기.
• 재시도 한도 및 백오프 추가.
• 소프트 블록 검증.
• 디버깅을 위한 실패 샘플 저장.
• 지리적 정확성 모니터링.
• 사이트 약관 및 내부 정책 준수.
• 가능한 경우 API 또는 라이센스가 있는 피드를 선호.

구현 도움을 원하시면 SquidProxies의 프록시 튜토리얼을 검토하세요.

실제 시나리오: 전자상거래 모니터링

가격 팀이 여러 국가의 소매업체 제품 페이지를 모니터링합니다.

원래 설정은 매 요청마다 IP를 회전시키고 일반 헤더를 사용하며 HTTP 200을 성공으로 간주합니다. 보고서에는 누락된 가격과 일관되지 않은 통화가 표시됩니다.

개선된 설정은 지역별 제품 페이지에 주거용 프록시를 사용하고, 저위험 카테고리 페이지에 데이터 센터 프록시를 사용하며, 상점 확인에 스티키 세션을 사용하고, 가격, 통화, 가용성 및 지역에 대한 검증 규칙을 적용합니다.

팀은 소프트 블록을 줄이고 데이터 품질을 개선하면서 모든 요청을 가장 비싼 경로로 이동하지 않습니다.

실제 시나리오: 로컬 SEO 추적

SEO 팀이 여러 도시에서 순위를 추적합니다.

원래 워크플로는 하나의 일반 프록시 경로와 일관되지 않은 언어 설정을 사용합니다. 일부 SERP는 잘못된 도시에서 발생합니다.

개선된 워크플로는 도시별 주거용 프록시를 사용하고, 언어 및 검색 매개변수를 정렬하며, 반환된 결과에서 로컬 팩 주소를 검증합니다.

이로 인해 지리적 정확성이 향상되고 순위 보고서의 신뢰성이 높아집니다.

피해야 할 일반적인 실수

프록시를 유일한 탐지 계층으로 취급하기

프록시는 네트워크 아이덴티티에 영향을 미치지만, 브라우저 행동, TLS, 헤더, 세션 및 타이밍도 중요합니다.

소프트 블록 무시하기

성공적인 상태 코드는 유효한 데이터를 보장하지 않습니다.

너무 자주 회전하기

너무 많은 회전은 세션 신뢰를 깨뜨릴 수 있습니다.

모든 곳에서 하나의 프록시 유형 사용하기

다른 페이지는 다른 라우팅 전략이 필요합니다.

로케일과 IP 불일치

시간대, 언어, 통화 및 프록시 위치는 일치해야 합니다.

실패한 요청을 과도하게 재시도하기

깊은 재시도는 비용을 증가시키고 차단 패턴을 악화시킬 수 있습니다.

자주 묻는 질문

웹사이트는 프록시 트래픽을 어떻게 감지하나요?

웹사이트는 IP 평판, ASN 분류, TLS 지문, 브라우저 지문, DNS 및 WebRTC 행동, 지리적 일관성, 쿠키 및 트래픽 패턴을 결합하여 프록시 트래픽을 감지합니다.

주거용 프록시는 감지될 수 있나요?

예. 주거용 프록시는 일부 IP 수준의 의심을 줄일 수 있지만, 웹사이트는 여전히 일관되지 않은 브라우저 지문, 공격적인 행동, 지리적 불일치 또는 세션 이상을 감지할 수 있습니다.

데이터 센터 프록시는 스크래핑에 나쁜가요?

아니요. 데이터 센터 프록시는 공개 페이지, 저마찰 대상, API, 사이트맵 및 대량 워크플로에 잘 작동할 수 있습니다. 그들은 호스팅 ASN을 강하게 불신하는 대상에는 덜 적합합니다.

소프트 블록이란 무엇인가요?

소프트 블록은 페이지가 로드되지만 사용 불가능하거나 불완전한 콘텐츠를 반환할 때 발생합니다. 예를 들어 누락된 가격, 일반 템플릿, CAPTCHA 페이지 또는 잘못된 지역 결과가 있습니다.

프록시 차단을 줄이려면 어떻게 해야 하나요?

올바른 프록시 유형을 사용하고, 동시성을 낮추고, 브라우저 및 지리 신호를 정렬하고, 세션을 검증하고, 백오프를 사용하고, 재시도를 제한하고, 소프트 블록을 조기에 감지하세요.

브라우저 지문이 중요한가요?

예, 특히 브라우저 자동화의 경우. 좋은 프록시 경로도 브라우저 신호가 일관되지 않거나 명백히 자동화된 경우 실패할 수 있습니다.

요청마다 IP를 회전해야 하나요?

각 요청이 독립적인 상태 비저장 워크플로에 대해서만 그렇습니다. 로그인, 장바구니, 페이지 매김, 로컬 확인 또는 브라우저 세션의 경우 스티키 세션을 사용하세요.

무엇을 모니터링해야 하나요?

성공률, 차단률, 소프트 차단률, 재시도 깊이, CPSR, 세션 생존율, 지리 정확도, 대기 시간, 파서 오류율, CAPTCHA 비율을 추적합니다.

최종 생각

웹사이트는 불일치를 찾아 프로시 트래픽을 감지합니다. IP, ASN, TLS 동작, 헤더, 브라우저 지문, DNS 경로, WebRTC 동작, 로케일, 쿠키 및 요청 타이밍이 모두 함께 의미가 있어야 합니다.

가장 강력한 프록시 시스템은 하나의 프록시 유형이나 하나의 트릭에 기반하지 않습니다. 그들은 일관성, 측정 및 책임 있는 라우팅을 중심으로 구축됩니다.

속도와 비용이 중요한 경우 데이터 센터 프록시를 사용하세요. 지리적 정확도와 소비자와 같은 네트워크 정체성이 중요한 경우 주거용 프록시를 사용하세요. 워크플로우의 연속성이 필요한 경우 스티키 세션을 사용하세요. 성공을 계산하기 전에 반환된 콘텐츠를 검증하세요.

작은 파일럿으로 시작하고, 올바른 메트릭을 측정하며, 예측 가능한 비용으로 유효한 데이터를 생성하는 경로만 확장하세요.