IP 평판과 사기 점수의 작동 방식 (IPQualityScore) 완벽 해부
데이터센터 IP로 웹사이트에 접속하면 로그인 페이지에서 즉시 차단되지만, 레지덴셜 프록시로 같은 요청을 보내면 정상적으로 통과한다면 — 그 차이는 IP 평판과 사기 점수 시스템이 만들어낸 결과입니다. IPQualityScore(IPQS)는 이 분야에서 가장 널리 사용되는 상용 API 중 하나이며, 웹사이트의 로그인, 결제, 가입 단계에서 실시간으로 IP를 평가합니다.
이 글에서는 IPQS의 0~100점 사기 점수 모델을 기술적으로 분해하고, 프록시 감지 신호가 어떻게 조합되는지, 그리고 왜 진짜 ISP가 할당한 레지덴셜 IP가 이 감지 체계를 통과하는지 설명합니다. 마지막에는 Python 코드로 ProxyHat 레지덴셜 출구 IP와 데이터센터 IP의 IPQS 점수를 직접 비교합니다.
기술적 배경: 왜 IP 평판 시스템이 존재하는가
현대 웹사이트는 계정 탈취(ATO), 결제 사기, 봇 어뷰즈, 대량 가입 공격에 지속적으로 노출되어 있습니다. 방화벽과 WAF만으로는 이를 막을 수 없습니다 — 공격자는 정상 사용자와 동일한 HTTP 요청을 보내기 때문입니다. 유일한 차이는 요청이 어디서 오는가입니다. 이것이 IP 평판 시스템이 존재하는 이유입니다.
IPQS를 비롯한 사기 점수 업체는 수십억 건의 과거 트래픽 데이터, 글로벌 honeypot 네트워크, 실시간 블랙리스트 피드를 결합하여 각 IP 주소에 0~100점의 점수를 부여합니다. 점수가 높을수록 사기 가능성이 큽니다. 이 점수는 단순히 "이 IP가 프록시인가?"를 넘어서, "이 IP에서 최근에 실제 사기 행위가 발생했는가?"를 종합적으로 평가합니다.
0~100 사기 점수의 구성 요소
IPQS의 사기 점수는 단일 신호로 결정되지 않습니다. 여러 데이터 소스가 가중 평균되어 최종 점수를 만듭니다. 핵심 구성 요소는 다음과 같습니다.
Honeypot과 트랩 네트워크
IPQS는 전 세계에 분산된 honeypot 엔드포인트를 운영합니다. 이들은 보이지 않는 웹 페이지, 가짜 로그인 폼, 노출된 API 엔드포인트 등으로 위장됩니다. 정상 사용자는 절대 접근하지 않지만, 자동화된 스캐너와 크롤러는 이를 발견하고 요청을 보냅니다. 이 honeypot에 접근한 IP는 자동으로 사기 점수가 상승합니다. 한 번 honeypot에 걸린 IP는 수일에서 수주간 블랙리스트에 등재됩니다.
ASN 및 IP 대역 분류
모든 IP 주소는 ASN(Autonomous System Number)에 속합니다. ASN 분류는 BGP 라우팅 데이터와 RIR(Regional Internet Registry) 할당 기록을 기반으로 합니다. IPQS는 ASN을 다음과 같이 분류합니다.
- ISP ASN: Comcast, AT&T, Deutsche Telekom 등 — 일반 가정용 인터넷 가입자에게 할당된 대역
- 호스팅/데이터센터 ASN: AWS(asn 16509), DigitalOcean(asn 14061), OVH, Hetzner 등 — 클라우드 서버 대역
- 모바일 ASN: Verizon Wireless, T-Mobile 등 — 셀룰러 네트워크 대역
데이터센터 ASN에서 오는 요청은 기본적으로 의심스럽게 취급됩니다. 일반 소비자가 AWS IP 대역에서 브라우징을 할 이유가 없기 때문입니다. 반면 ISP ASN은 기본 점수가 낮습니다.
블랙리스트 및 과거 어뷰즈 기록
IPQS는 Spamhaus, AbuseIPDB 등의 글로벌 블랙리스트와 자체 데이터를 교차 참조합니다. recent_abuse 플래그는 최근 30일 이내에 해당 IP에서 실제 사기 또는 어뷰즈 행위가 보고되었음을 의미합니다. 이 플래그가 true이면 사기 점수는 일반적으로 75점 이상으로 급등합니다.
머신러닝 모델
IPQS는 과거 사기 패턴을 학습한 ML 모델을 사용하여, 개별 신호의 단순 합 이상의 패턴을 감지합니다. 예를 들어, "데이터센터 ASN + 비정상 시간대 트래픽 + 다중 계정 가입 시도"의 조합은 개별 신호만으로는 중간 점수일 수 있지만, ML 모델은 이를 고위험 패턴으로 분류합니다.
실시간 포렌식 검사
IPQS API 호출 시 수행되는 실시간 검사는 다음을 포함합니다.
- 프록시/VPN/Tor 감지: 공개 프록시 리스트, Tor exit node 리스트, 상용 VPN 대역과의 매칭
- 확장 가능한 어뷰즈 패턴: 짧은 시간 내 다수 사이트에서 동일 IP의 비정상적 요청 빈도
- 포트 스캔 시그니처: 알려진 프록시 포트(8080, 3128, 1080 등)의 오픈 여부
프록시 감지 신호: IPQS가 무엇을 보는가
IPQS의 proxy detection API는 단일 불리언이 아닙니다. 여러 신호가 개별적으로 반환되며, 각 신호가 사기 점수에 가중치를 더합니다. 핵심 신호를 기술적으로 분석합니다.
ASN 타입 — 호스팅 vs ISP
가장 강력한 단일 신호입니다. IPQS는 IP의 ASN이 호스팅 제공자에 등록되어 있는지 확인합니다. AWS, Google Cloud, DigitalOcean의 IP는 연결 타입이 hosting으로 분류되며, 이는 곧 프록시 또는 봇 트래픽의 강력한 지표가 됩니다.
오픈 포트 및 rDNS
IPQS는 대상 IP의 역방향 DNS(rDNS)를 조회합니다. rDNS 레코드가 ec2-54-xxx-xxx-xxx.compute-1.amazonaws.com 형태이면 명백한 클라우드 IP입니다. 반면 cpe-72-xxx-xxx-xxx.nyc.res.rr.com 형태는 ISP 가입자 대역을 나타냅니다. 또한 알려진 프록시 포트가 오픈되어 있는지 비침습적으로 확인합니다.
지리적 위치 불일치
IPQS는 GeoIP 데이터와 자체 데이터를 교차 참조하여 IP의 지리적 위치를 추정합니다. 사용자가 브라우저의 Geolocation API로 San Francisco를 보고했지만, IP가 Frankfurt 데이터센터로 확인되면 — 불일치 점수가 부여됩니다. 이는 VPN 사용의 전형적인 패턴입니다.
연결 타입
IPQS API 응답의 connection_type 필드는 Residential, Corporate, Education, Mobile, Datacenter 중 하나를 반환합니다. Datacenter가 반환되면 사기 점수에 직접적인 페널티가 적용됩니다.
최근 어뷰즈 기록
recent_abuse 불리언은 최근 보고된 사기 활동의 존재 여부를 나타냅니다. 데이터센터 IP 대역은 여러 사용자가 공유하므로, 한 사용자의 어뷰즈가 전체 대역의 평판을 훼손하는 경우가 빈번합니다.
TLS 핑거프린팅 — JA3/JA4와 캔버스 핑거프린트
IP 평판 시스템 자체는 TLS 핑거프린트를 직접 수집하지 않지만, 최신 웹 방어 스택은 IPQS 점수와 TLS 핑거프린트를 결합합니다. TLS 1.3(RFC 8446)의 ClientHello 메시지에서 추출되는 JA3/JA4 핑거프린트는 클라이언트가 사용하는 TLS 라이브러리와 설정을 식별합니다.
예를 들어, Python requests 라이브러리의 기본 TLS 설정은 Chrome 브라우저의 TLS 핑거프린트와 확연히 다릅니다. cipher suite 순서, extension 목록, elliptic curve 설정이 모두 다르기 때문입니다. Cloudflare와 같은 CDN은 이를 실시간으로 비교하여 "IPQS 점수 85 + 비브라우저 TLS 핑거프린트 = 봇"으로 판정합니다.
캔버스 핑거프린팅은 JavaScript를 통해 브라우저의 Canvas 렌더링 결과를 해시화합니다. Headless Chrome은 일반 Chrome과 다른 GPU 렌더링 결과를 생성하므로, 캔버스 핑거프린트가 불일치합니다. 행동 분석(behavioral analytics)은 마우스 이동 패턴, 키보드 입력 타이밍, 스크롤 속도를 분석하여 자동화 여부를 판단합니다.
이러한 신호들은 IP 평판과 직접 관련이 없지만, 방어 시스템은 IPQS 점수와 결합하여 다층 방어를 구성합니다. 레지덴셜 프록시가 IP 레이어에서 통과하더라도, TLS 핑거프린트가 Python requests의 것이면 여전히 차단될 수 있습니다.
임계값과 통합 — 사기 점수 90점 이상 차단
IPQS는 점수 90점 이상을 "high risk"로 권장합니다. IPQS 공식 문서에 따르면, 90점 이상 IP는 즉시 차단하거나 추가 검증(2FA, CAPTCHA, 수동 검토)을 적용하는 것이 권장 사항입니다.
웹사이트는 이를 다음과 같이 통합합니다.
| 사용자 흐름 | 권장 임계값 | 조치 |
|---|---|---|
| 회원가입 | ≥ 80점 | CAPTCHA + 이메일 인증 필수 |
| 로그인 | ≥ 85점 | 2FA 챌린지 |
| 결제/체크아웃 | ≥ 75점 | 결제 지연 + 수동 검토 |
| API 접근 | ≥ 90점 | 즉시 차단 |
결제 단계에서 임계값이 가장 낮은 이유는 금전적 손실 위험이 가장 크기 때문입니다. 가입 단계에서는 계정 생성 자체를 막는 것이 목적이므로 임계값이 상대적으로 높습니다.
레지덴셜 프록시가 통과하는 이유
모든 프록시가 동일하게 감지되는 것은 아닙니다. 레지덴셜 프록시가 IPQS 감지를 통과하는 핵심 이유는 진짜 ISP가 실제 가정에 할당한 IP 주소를 사용하기 때문입니다.
데이터센터 프록시가 실패하는 이유를 먼저 보겠습니다.
- AWS IP(예: 54.x.x.x)는 ASN이 "Amazon AWS"로 등록 → connection_type =
Datacenter - rDNS가
ec2-54-x-x-x.compute-1.amazonaws.com→ 명백한 클라우드 - 동일 대역에서 대량 어뷰즈 이력 존재 → recent_abuse = true 가능성 높음
- 결과: 사기 점수 85~99점
반면, ProxyHat 레지덴셜 프록시의 출구 IP는 다음과 같이 평가됩니다.
- Comcast, AT&T 등의 ISP ASN에 속함 → connection_type =
Residential - rDNS가
cpe-72-x-x-x.nyc.res.rr.com형태 → 일반 가정용 인터넷 - 해당 IP 대역의 과거 어뷰즈 이력이 없음 → recent_abuse = false
- 지리적 위치가 실제 ISP 서비스 지역과 일치
- 결과: 사기 점수 0~15점
이것이 감지의 핵심 도전 과제입니다. IPQS가 볼 수 있는 모든 신호가 "이것은 일반 가정용 인터넷 연결"을 가리킵니다. IP 주소 자체는 진짜 가정에서 할당된 것이므로, IP 레이어에서는 프록시와 일반 사용자를 구분할 수 없습니다.
다만, 이는 IP 레이어에서의 이야기입니다. 앞서 설명한 TLS 핑거프린트, 캔버스 핑거프린트, 행동 분석은 IP와 독립적으로 작동합니다. 레지덴셜 프록시를 사용하더라도 requests 라이브러리의 기본 TLS 설정으로 요청을 보내면, IPQS 점수는 낮지만 Cloudflare의 JA3 매칭에서 차단될 수 있습니다. 완벽한 스텔스를 위해서는 레지덴셜 IP + 브라우저 스텔스(TLS 핑거프린트 매칭, 캔버스 핑거프린트 정규화)가 함께 필요합니다.
실전 예제: IPQS API로 ProxyHat 레지덴셜 IP 검증하기
다음 Python 코드는 ProxyHat 레지덴셜 프록시를 통해 IPQS proxy detection API를 호출하여, 출구 IP의 사기 점수를 확인하는 방법을 보여줍니다. 이 코드는 자신의 IP 품질을 검증하거나 인가된 자동화 시스템의 프록시 품질을 모니터링하는 목적으로 사용해야 합니다.
1단계: ProxyHat 레지덴셜 프록시로 출구 IP 확인
import requests
# ProxyHat 레지덴셜 프록시 (US 출구)
proxy_auth = "user-country-US:your_password"
proxy_url = f"http://{proxy_auth}@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}
# 출구 IP 확인
resp = requests.get(
"https://api.ipify.org?format=json",
proxies=proxies,
timeout=10
)
exit_ip = resp.json()["ip"]
print(f"ProxyHat residential exit IP: {exit_ip}")2단계: IPQS proxy detection API 호출
# IPQS API 키 (본인의 키로 교체)
IPQS_KEY = "your_ipqs_api_key"
# 출구 IP의 사기 점수 조회
ipqs_url = f"https://www.ipqualityscore.com/api/json/ip/{IPQS_KEY}/{exit_ip}"
params = {"strictness": 1, "allow_public_access_points": "true"}
result = requests.get(ipqs_url, params=params, timeout=10).json()
print(f"Fraud Score: {result['fraud_score']}")
print(f"Proxy: {result['proxy']}")
print(f"VPN: {result['vpn']}")
print(f"Tor: {result['tor']}")
print(f"Recent Abuse: {result['recent_abuse']}")
print(f"Bot Status: {result['bot_status']}")
print(f"ASN: {result['ASN']}")
print(f"ISP: {result['ISP']}")
print(f"Connection Type: {result['connection_type']}")
print(f"Country: {result['country_code']}")3단계: 데이터센터 IP와 비교
# 데이터센터 IP 직접 조회 (프록시 없이)
dc_result = requests.get(
f"https://www.ipqualityscore.com/api/json/ip/{IPQS_KEY}/8.8.8.8",
params={"strictness": 1},
timeout=10
).json()
print(f"\n--- Datacenter IP (8.8.8.8) ---")
print(f"Fraud Score: {dc_result['fraud_score']}")
print(f"Connection Type: {dc_result['connection_type']}")
print(f"ISP: {dc_result['ISP']}")예상 결과: ProxyHat 레지덴셜 출구 IP는 fraud_score가 0~15점, connection_type이 Residential로 반환됩니다. 반면 데이터센터 IP는 점수가 75점 이상, connection_type이 Datacenter로 반환됩니다. 물론 실제 점수는 IPQS 데이터베이스 업데이트 상태와 해당 IP의 최근 트래픽 패턴에 따라 달라집니다.
curl 예제
# ProxyHat 레지덴셜 프록시로 출구 IP 확인
curl -x "http://user-country-US:your_password@gate.proxyhat.com:8080" \
"https://api.ipify.org?format=json"
# IPQS API 호출 (IP를 실제 출구 IP로 교체)
curl "https://www.ipqualityscore.com/api/json/ip/YOUR_KEY/EXIT_IP?strictness=1"프록시 타입별 IPQS 통과율 비교
| 특성 | 데이터센터 프록시 | 레지덴셜 프록시 | 모바일 프록시 |
|---|---|---|---|
| ASN 타입 | 호스팅 (AWS, OVH 등) | ISP (Comcast, AT&T 등) | 모바일 통신사 |
| 예상 IPQS 점수 | 75~99점 | 0~15점 | 0~10점 |
| connection_type | Datacenter | Residential | Mobile |
| recent_abuse 위험 | 높음 (대역 공유) | 낮음 | 중간 |
| 지역 타겟팅 | 제한적 | 국가/도시 단위 | 국가 단위 |
| 평균 레이턴시 | 50~200ms | 100~500ms | 200~800ms |
| 적합 용도 | 대량 데이터 수집 | 정밀 스크래핑, 인증 | 소셜 미디어, 모바일 앱 |
윤리적 프레이밍 및 법적 고려사항
IP 평판 검증과 프록시 사용은 항상 합법적 목적 내에서 이루어져야 합니다. 적절한 사용 사례는 다음과 같습니다.
- 자사 IP 품질 검증: 자신이 운영하는 프록시 인프라의 출구 IP가 사기 점수 시스템에서 어떻게 평가되는지 확인
- 인가된 자동화: 대상 사이트의 ToS를 준수하고,
robots.txt를 존중하며, 적절한 rate limit을 유지하는 웹 스크래핑 - 보안 연구: 자사 시스템에 대한 인가된 침투 테스트, IPQS API 응답 패턴 분석
- QA 자동화: 지역별 사용자 경험을 시뮬레이션하기 위한 지리적 테스트
절대 해서는 안 되는 것: 결제 사기, 계정 탈취, 대량 가입 공격, CAPTCHA 우회를 통한 무차별 대입, 타인의 서비스 ToS 위반. 이러한 행위는 법적 책임을 초래합니다.
유럽 연합에서 활동하는 경우 GDPR을 고려해야 합니다. IP 주소는 GDPR 제4조에서 "개인정보"로 분류되며, IPQS API 호출 시 EU 사용자의 IP를 처리하는 것은 적법한 근거가 필요합니다. 미국에서는 CFAA(Computer Fraud and Abuse Act)가 무인가 시스템 접근을 제한하며, ToS 위반은 CFAA 위반으로 해석될 수 있습니다. 2021년 Van Buren v. United States 판결 이후 ToS 위반만으로 CFAA 위반이 자동으로 성립하지는 않지만, 무인가 데이터 접근은 여전히 위험합니다.
웹 스크래핑 사용 사례와 SERP 추적 페이지에서 합법적 자동화 시나리오를 확인하세요. ProxyHat 문서에서 프록시 설정 가이드를 참조할 수 있습니다.
ProxyHat 설정 가이드
ProxyHat 레지덴셜 프록시는 IPQS 감지를 통과하도록 설계되었습니다. 주요 설정 옵션은 다음과 같습니다.
국가 타겟팅
# US 레지덴셜 IP
http://user-country-US:pass@gate.proxyhat.com:8080
# 독일 레지덴셜 IP
http://user-country-DE:pass@gate.proxyhat.com:8080도시 타겟팅
# Berlin 레지덴셜 IP
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080스티키 세션 (IP 유지)
# 동일 IP 유지 (세션 ID 지정)
http://user-session-abc123:pass@gate.proxyhat.com:8080SOCKS5 사용
# SOCKS5 프로토콜
socks5://user-country-US:pass@gate.proxyhat.com:1080프라이싱 페이지에서 레지덴셜, 모바일, 데이터센터 프록시 요금제를 비교할 수 있습니다.
일반적인 실수와 엣지 케이스
1. 데이터센터 프록시로 충분하다고 가정
단순 HTML 스크래핑이나 공개 API 호출에는 데이터센터 프록시가 충분할 수 있습니다. 하지만 로그인이 필요한 사이트, 결제 흐름, 또는 IPQS가 통합된 사이트에서는 데이터센터 IP가 즉시 차단됩니다. 사용 사례에 맞는 프록시 타입을 선택해야 합니다.
2. IP 레이어만 신경쓰고 TLS/행동 신호 무시
레지덴셜 IP로 IPQS를 통과해도, TLS 핑거프린트가 requests 라이브러리의 것이면 Cloudflare나 DataDome에 차단됩니다. IP 레이어와 브라우저/클라이언트 레이어를 모두 관리해야 합니다. Playwright나 Puppeteer with stealth 플러그인을 사용하면 TLS 핑거프린트를 실제 브라우저와 일치시킬 수 있습니다.
3. 단일 IP 과도한 사용
레지덴셜 프록시라도 단일 IP에서 시간당 수백 건의 요청을 보내면, 행동 분석 시스템이 이를 비정상으로 감지합니다. IP 회전을 사용하고, 사이트별 rate limit을 준수하세요.
4. IPQS strictness 레벨 무시
IPQS API의 strictness 파라미터(0~3)는 감지 민감도를 조절합니다. strictness=0은 관대한 설정, strictness=3은 가장 엄격한 설정입니다. 대상 사이트가 어느 레벨을 사용하는지에 따라 같은 IP라도 점수가 달라질 수 있습니다.
핵심 요약
IPQS 사기 점수는 다층 신호 시스템입니다. ASN 타입, rDNS, 과거 어뷰즈, honeypot 히트, 실시간 포렌식 검사가 결합되어 0~100점을 만듭니다. 단일 신호가 아니라 전체 패턴을 봅니다.
데이터센터 IP는 구조적으로 실패합니다. 호스팅 ASN, 클라우드 rDNS, 높은 어뷰즈 이력이 결합되어 점수 75~99점이 됩니다. 이는 기술적 한계이지 설정 문제가 아닙니다.
레지덴셜 프록시는 IP 레이어에서 통과합니다. 진짜 ISP IP, 가정용 rDNS, 깨끗한 어뷰즈 이력이 결합되어 점수 0~15점이 됩니다. 하지만 TLS 핑거프린트와 행동 분석은 별도로 관리해야 합니다.
90점 임계값이 업계 표준입니다. 결제 단계에서는 75점, 가입에서는 80점이 일반적입니다. 자동화 시스템은 이 임계값 아래로 점수를 유지해야 합니다.
윤리와 법률은 선택이 아닙니다. 자사 IP 검증, 인가된 자동화, 보안 연구만이 정당한 사용입니다. 결제 사기와 타인 시스템 무인가 접근은 법적 책임을 초래합니다.
