사기 방지위험 점수 이유: detection_methods를 필드별로 읽는 방법
필드별 위험 점수 이유: 점수 산정 코드가 반환하는 모든 detection_methods 값과 가중치, 그리고 검증된 크롤러가 64점을 35점으로 낮춘 실제 조회 사례를 설명합니다.
고객이 결제에서 차단되어 이유를 묻는 문의를 보냅니다. "공급자가 92라고 했습니다"는 대화를 나쁘게 끝냅니다. "고객님의 연결은 열린 OpenVPN 포트가 있는 등재된 VPN 서버에서 왔습니다"는 근거를 대고, 마음을 바꾸고, 조정할 수 있는 답입니다. 이것이 설명 가능한 위험 점수가 주는 것입니다. 숫자만이 아니라 이유 코드입니다.
이 페이지는 그런 답을 위한 사전입니다. 숫자 자체의 의미와 구간의 위치는 IP 위험 점수가 무엇이며 어떻게 읽는지에서 시작하십시오. 아래에서는 계산 과정을 보여 드리고, 실제 응답 하나를 이유별로 추적하고, 점수를 깎는 다섯 가지 이유를 다룬 뒤, 점수 산정 코드가 반환할 수 있는 모든 detection_methods 값을 가중치와 작동 조건과 함께 나열합니다.
위험 점수 이유는 더해집니다: 점수 곱하기 신뢰도, 그다음 제한
GeoIPHub의 점수 산정에서 모든 이유는 점수에 신뢰도를 곱한 값을 기여하며, 점수는 그 합을 반올림하여 0에서 100으로 제한한 값입니다. 그 위에 숨겨진 모델은 없습니다. 다음은 API의 점수 산정 단계(scoring.service.ts)를 계산식으로만 줄인 것입니다.
// Each fired reason: { points, confidence } from scoring.json
let sum = fired.reduce((s, r) => s + r.points * r.confidence, 0);
if (isCgnat && !ownThreatEvidence) sum = Math.min(sum, 50); // CGNAT cap
if (isRelay) sum = Math.min(sum, 60); // relay cap
const fraud_score = Math.max(0, Math.min(100, Math.round(sum)));
const confidence = fired.length === 0 ? 0.1
: Math.min(0.99, Math.abs(sum) / fired.length / 50 + fired.length * 0.05);
사람들이 자주 걸려 넘어지는 세부 사항이 두 가지 있습니다. 첫째, 응답의 confidence는 사기일 확률이 아닙니다. 이유의 개수와 평균 크기에 따라 커지므로, 적당한 이유 네 개가 큰 이유 하나보다 더 큰 신뢰도를 가질 수 있습니다. 이유가 없는 조회는 0.1을 반환합니다. 둘째, detection_methods의 순서는 코드가 확인하는 순서이지 크기순이 아닙니다. 첫 번째 항목을 주된 이유로 취급하지 마십시오.
다른 공급자들은 이유를 다르게 노출합니다. MaxMind의 minFraud 응답에는 risk_score_reasons가 있습니다. 위험 점수에 대한 승수이며 각각 ANONYMOUS_IP 같은 코드를 갖고, MaxMind는 이것이 "보통 중간에서 높은 위험의 트랜잭션에 대해서만 반환된다"고 밝힙니다. Socure의 Sigma Identity Fraud는 0.001에서 0.999 사이의 점수에 "사기 위험 점수에 영향을 준 요인을 이해하는 데 도움이 되는 상세 정보를 제공하는" 이유 코드를 짝지어 줍니다. GeoIPHub의 이유는 가산 방식의 점수이며, 점수를 움직인 모든 이유가 점수와 관계없이 나열됩니다.
이 계산이 실제 데이터에서도 성립하는지 확인했습니다. 다음 키 없는 조회 일곱 건은 2026-10-29 04:43:09에서 04:43:54 UTC 사이에 약 7초 간격으로 실행되었으며, 모든 점수와 신뢰도가 이유로부터 정확히 재현됩니다.
| IP (정체) | detection_methods | 합계 | 점수, 조치 | confidence |
|---|---|---|---|---|
| 185.220.101.1 (Tor 출구) | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | 108.05 | 100, block | 0.74 |
| 185.213.155.73 (Mullvad, 자체 목록에 있음) | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 101.5 | 100, block | 0.71 |
| 5.39.1.230 (AhrefsBot) | datacenter_blocklisted, no_ptr_datacenter, verified_crawler, known_spammer | 35.0 | 35, review | 0.375 |
| 45.33.32.156 (scanme.nmap.org, Linode) | datacenter_ip | 10.0 | 10, allow | 0.25 |
| 104.28.46.99 (iCloud Private Relay) | relay_ip | 8.5 | 9, allow | 0.22 |
| 107.178.192.1 (Google 사용자 트리거 페처) | datacenter_ip, rdns_hosting, verified_crawler | -12.5 | 0, allow | 0.23 |
| 66.249.66.1 (Googlebot) | datacenter_ip, verified_crawler | -18.5 | 0, allow | 0.285 |
실제 응답 하나 추적하기: 35점 review의 AhrefsBot
AhrefsBot의 5.39.1.230이 35, review를 받은 것은 이유 세 가지가 63.5점을 더했고 검증된 크롤러 일치가 28.5점을 덜어냈기 때문입니다. 이유가 양방향으로 작용하므로 가장 좋은 학습 사례입니다. 다음은 04:43:09 UTC 조회(meta.last_classified_at 2026-10-29T04:43:09.547Z)의 응답을 간추린 것이며, 값은 수정하지 않았습니다.
curl https://api.geoiphub.com/v1/lookup/5.39.1.230 \
-H "x-api-key: YOUR_API_KEY"
{
"ip": "5.39.1.230",
"asn": { "asn": 16276, "org": "OVH - OVH SAS", "asn_type": "hosting" },
"detection": { "is_vpn": false, "is_proxy": false, "is_hosting": true },
"threat": {
"is_spammer": true,
"dnsbl_sources": ["zen.spamhaus.org"],
"crawler": {
"verified": true,
"name": "AhrefsBot",
"operator": "Ahrefs",
"verification_method": "ip_range_list"
}
},
"dns": { "ptr_record": "none" },
"scoring": {
"fraud_score": 35,
"confidence": 0.375,
"recommended_action": "review",
"detection_methods": ["datacenter_blocklisted", "no_ptr_datacenter", "verified_crawler", "known_spammer"]
}
}
각 이유는 계산식 한 줄에 대응합니다.
| 이유 | 여기서 작동한 까닭 | 점수 × 신뢰도 | 가산 |
|---|---|---|---|
| datacenter_blocklisted | 스팸 목록에도 올라 있는 OVH 호스팅 주소 | 30 × 0.75 | +22.5 |
| no_ptr_datacenter | 저장된 기록에 역방향 DNS가 없는 호스팅 주소 | 10 × 0.50 | +5.0 |
| verified_crawler | Ahrefs가 공개한 크롤러 IP 대역 안 | -30 × 0.95 | -28.5 |
| known_spammer | zen.spamhaus.org에 등재 | 40 × 0.90 | +36.0 |
| 합계 | 35.0, review |
크롤러 일치를 빼면 합계는 63.5이고 반올림하면 64로 step up입니다. 검증된 대역 파일은 신고된 실제 크롤러를 챌린지에서 기록되는 review로 옮겼습니다. allow로 옮기지는 않았는데, 혐의를 벗겨 주는 이유는 허용 목록이 아니라 가중치이기 때문입니다. 같은 주소의 Spamhaus 등재는 여전히 반영됩니다.
이 응답이 틀린 부분
네 가지 이유 중 하나는 우리 쪽의 결함입니다. no_ptr_datacenter는 이 주소에 역방향 DNS가 없다는 뜻이지만, 04:44 UTC에 dig -x 5.39.1.230은 proxy-fr005-cip7.ahrefs.net을 반환했습니다. 이 이유는 저장된 PTR 레코드를 읽는데 그 레코드가 없습니다.
결함을 고쳐도 이 점수는 내려가지 않으며, 코드가 그 이유를 보여 줍니다. 우리의 PTR 분류기는 "proxy"가 들어 있는 호스트명을 프록시 패턴으로 읽습니다. 따라서 레코드가 저장되면 no_ptr_datacenter(+5)는 rdns_proxy(+14)로 대체되어 점수는 최소 44로 올라갑니다. 여전히 review이지만, 익명화 도구가 아니라 Ahrefs가 크롤러 출구용으로 고른 호스트명 때문입니다. 두 가지 모두 기록해 두었습니다. no_ptr_datacenter와 rdns_* 이유는 약한 증거로 읽으십시오. 가중치가 이미 그렇게 말하고 있습니다.
혐의를 벗겨 주는 이유: 다섯 개가 점수를 깎을 수 있으며 0에서 멈춥니다
혐의를 벗겨 주는 이유는 음수 점수를 가지므로 합계를 낮추지만 점수는 0 아래로 내려가지 않습니다. GeoIPHub의 점수 설정에는 여섯 개가 있으며 현재 다섯 개가 작동할 수 있습니다.
| 이유 | 점수 × 신뢰도 | 차감 | 작동 조건 |
|---|---|---|---|
| verified_crawler | -30 × 0.95 | 28.5 | 주소가 공식 크롤러 IP 대역 파일 19개 중 하나 안에 있음(Googlebot, Bingbot, GPTBot, ClaudeBot, AhrefsBot 등) |
| residential_isp | -20 × 0.85 | 17 | VPN, 프록시, Tor 증거가 없는 가정용 광대역 회선 |
| rdns_residential | -20 × 0.80 | 16 | 역방향 DNS가 가정용 회선처럼 보임(dsl, pool, dynamic, cable, customer) |
| mobile_carrier | -15 × 0.80 | 12 | 익명화 증거가 없는 모바일 네트워크(통신사 데이터, 모바일 호스트명 또는 우리의 CGNAT 플래그) |
| rdns_mobile | -10 × 0.70 | 7 | 역방향 DNS가 모바일 네트워크처럼 보임 |
| rdns_cgnat | -15 × 0.70 | 10.5 | 현재는 작동하지 않음: 호스트명 분류기에 CGNAT 패턴이 없음 |
검증된 크롤러 할인은 Googlebot 조회에서 확인할 수 있습니다. datacenter_ip가 10을 더하고 verified_crawler가 28.5를 덜어내어 API는 0을 반환했습니다. 남은 마이너스 18.5는 버려집니다. 이후의 다른 이유에 대한 크레딧으로 쌓이지 않으며, 이것이 올바른 동작입니다. 검증된 대역이 봇넷 등재를 가릴 수 있어서는 안 됩니다. verified_crawler 뒤에 있는 19개 대역 파일은 날짜 및 허용 목록 생성기와 함께 검증된 크롤러 IP 목록에 나열되어 있고, Google의 파일은 IP로 Googlebot 검증하기에서 자세히 다룹니다.
주거용 할인은 실제 주소로 보여 드릴 수 없습니다. 가정 연결의 조회를 공개하면 한 가구가 특정될 수 있기 때문입니다. 그래서 코드 경로를 글로 설명합니다. 주거용 이유는 역방향 DNS에 달려 있습니다. 우리 코드는 PTR 호스트명이 dsl, pool, dynamic 같은 가정용 패턴과 일치할 때만 회선을 주거용이라고 부릅니다. 그렇게 되면 회선이 모바일이나 CGNAT로도 플래그되지 않는 한 residential_isp(-17)와 rdns_residential(-16)이 함께 작동하여 마이너스 33이 됩니다. 모바일 또는 CGNAT 회선은 residential_isp 대신 mobile_carrier(-12)를 받으므로 그 쌍은 마이너스 28입니다. ISP가 역방향 DNS를 공개하지 않거나 우리가 인식하지 못하는 패턴으로 호스트 이름을 짓는 가정용 회선은 어느 할인도 받지 못합니다. 불리한 요소가 없으면 그냥 0점입니다. 같은 점수이므로 그 결함은 다른 이유가 작동할 때만 문제가 됩니다.
할인은 뒤집히기도 합니다. 주거용 회선에 프록시, Tor 또는 VPN 프로토콜 증거(IPsec 태그만으로는 해당하지 않음)가 있으면 residential_isp는 residential_with_threat(+21.25)로 대체됩니다. 모바일 회선도 mobile_with_threat(+16)로 같은 일이 일어납니다. 가정처럼 보인다는 이유의 할인은 그 가정이 트래픽을 중계하기 시작하는 순간 철회됩니다.
할인 옆에는 두 가지 상한이 있습니다. 릴레이 주소는 60으로 제한되므로 iCloud Private Relay 출구는 block에 도달할 수 없습니다. Private Relay와 WARP 트래픽을 탐지하는 방법과 이를 통과시켜야 하는 이유는 별도 글에서 설명합니다. CGNAT 단계가 플래그한 주소는 VPN, 프록시, Tor, VPN 프로토콜, 봇넷 또는 악용에 대한 자체 증거가 없는 한 50으로 제한됩니다.
모든 detection_methods 값, 필드별
GeoIPHub의 점수 산정 코드는 41개의 이유를 명명할 수 있고 현재 응답에 나타날 수 있는 것은 36개입니다. 아래 표는 36개 전부를 점수, 신뢰도, 기여도와 함께 각 이유가 답하는 질문별로 묶어 나열합니다.
이 주소는 익명화 도구입니까? 이 이유들은 Tor Project의 출구 목록, 공급자가 공개한 서버 목록, 자체 프로토콜 프로브, 타사 프록시 목록에서 옵니다. 프로브는 SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE(v1과 v2), PPTP, L2TP를 다룹니다. WireGuard 프로브는 없습니다.
| detection_methods 값 | 점수 × 신뢰도 | 가산 | 의미 |
|---|---|---|---|
| tor_exit | 45 × 0.99 | 44.55 | Tor Project의 공식 출구 목록에 있음, 6시간마다 다시 읽음 |
| known_vpn_server | 40 × 0.90 | 36 | is_vpn이 true: 공급자의 서버 목록에 있거나, VPN 서버를 운영하는 것으로 아는 네트워크 안에 있거나, 우리의 VPN 프로토콜 프로브에 응답함 |
| multi_source_vpn | 30 × 0.85 | 25.5 | WHOIS 또는 RDAP 레코드에도 VPN 키워드가 있는 VPN으로, 두 출처가 일치함 |
| openvpn_open | 35 × 0.90 | 31.5 | 우리의 프로브가 해당 주소에서 OpenVPN 응답을 받음 |
| ipsec_open | 30 × 0.80 | 24 | 우리의 프로브가 IKE 응답을 받았거나, 공급자의 서버 목록이 해당 서버를 IKEv2로 표시함(NordVPN, Surfshark, Windscribe 목록이 그렇게 함) |
| pptp_open | 30 × 0.92 | 27.6 | 우리의 프로브가 PPTP 응답을 받음 |
| l2tp_open | 30 × 0.85 | 25.5 | 우리의 프로브가 L2TP 응답을 받음 |
| wireguard_open | 35 × 0.70 | 24.5 | VPN 공급자가 공개한 서버 목록이 이 서버를 WireGuard로 표시함. 핸드셰이크가 아님 |
| socks5_open | 35 × 0.95 | 33.25 | SOCKS5 또는 SOCKS4 프록시가 우리의 프로브에 응답함 |
| http_proxy_open | 35 × 0.95 | 33.25 | HTTP CONNECT 또는 HTTP forward 프록시가 우리의 프로브에 응답함 |
| blocklist_proxy | 25 × 0.70 | 17.5 | 자체 SOCKS 또는 HTTP 리스너 없이 프록시로 플래그됨. 예를 들어 열린 프록시가 우리의 테스트 트래픽을 넘겨주는 것을 관찰한 출구 주소 |
| proxy_observed_third_party | 25 × 0.70 | 17.5 | 지난 하루 동안 트래픽을 프록시한 것으로 관찰된 주소의 타사 목록에 있음 |
| residential_proxy | 40 × 0.90 | 36 | 우리 데이터가 주거용 또는 모바일이라고 하는 회선에서 우리가 직접 플래그한 프록시. 대략적인 추론이며 주거용 프록시 탐지가 아님 |
| relay_ip | 10 × 0.85 | 8.5 | iCloud Private Relay 같은 프라이버시 릴레이 출구. 점수 상한도 60으로 제한함 |
이 주소는 문제를 일으킨 적이 있습니까? 이 이유들은 DNSBL 영역 세 개와 우리의 악용 및 봇넷 피드에서 옵니다.
| detection_methods 값 | 점수 × 신뢰도 | 가산 | 의미 |
|---|---|---|---|
| known_spammer | 40 × 0.90 | 36 | zen.spamhaus.org, b.barracudacentral.org 또는 bl.spamcop.net에 등재 |
| abusive_listed | 30 × 0.80 | 24 | 우리의 악용 피드에 등재되었거나, 세 DNSBL 영역 중 둘 이상에 등재 |
| botnet_c2 | 50 × 0.95 | 47.5 | 봇넷 피드가 명령 제어(C2) 서버로 등재함 |
| botnet_infected | 35 × 0.80 | 28 | 봇넷 피드가 감염된 기기 등 다른 역할로 등재함 |
서버 인프라입니까? 호스팅이란 엄선된 호스팅 ASN 853개 중 하나, 우리가 불러오는 클라우드 공급자 10곳의 대역, 또는 애니캐스트 대역을 뜻합니다. datacenter_* 이유 셋 중 하나만, 강한 것부터 작동할 수 있습니다.
| detection_methods 값 | 점수 × 신뢰도 | 가산 | 의미 |
|---|---|---|---|
| datacenter_with_vpn_proxy | 40 × 0.90 | 36 | 위의 VPN 또는 프록시 프로토콜 증거(목록의 WireGuard 태그 포함)가 있는 호스팅 주소 |
| datacenter_blocklisted | 30 × 0.75 | 22.5 | 악용, 스팸 또는 봇넷 목록에도 올라 있는 호스팅 주소 |
| datacenter_ip | 20 × 0.50 | 10 | 불리한 다른 요소가 없는 호스팅 주소 |
| no_ptr_datacenter | 10 × 0.50 | 5 | 빈틈이 있는 저장 기록에 역방향 DNS가 없는 호스팅 주소 |
| whois_vpn_keywords | 20 × 0.70 | 14 | WHOIS 또는 RDAP 레코드에 VPN 키워드가 있지만 주소가 VPN으로 플래그되지 않음 |
| whois_hosting | 15 × 0.55 | 8.25 | WHOIS 또는 RDAP 레코드에 호스팅 키워드가 있지만 주소가 우리의 호스팅 목록에 없음 |
역방향 DNS는 무엇이라고 말합니까? 이 이유들은 저장된 PTR 호스트명을 단순한 패턴으로 읽기 때문에 각각 가볍습니다.
| detection_methods 값 | 점수 × 신뢰도 | 가산 | 의미 |
|---|---|---|---|
| rdns_tor | 30 × 0.80 | 24 | 호스트명이 Tor 출구처럼 보임 |
| rdns_vpn | 20 × 0.75 | 15 | 호스트명에 "vpn" 또는 VPN 브랜드명이 들어 있음 |
| rdns_proxy | 20 × 0.70 | 14 | 호스트명에 "proxy", "squid" 또는 "socks"가 들어 있음 |
| rdns_hosting | 10 × 0.60 | 6 | 호스트명이 서버나 클라우드 호스트처럼 보임 |
| fcrdns_mismatch | 5 × 0.40 | 2 | 호스트명이 해당 주소로 다시 해석되지 않음 |
| rdns_residential | -20 × 0.80 | -16 | 호스트명이 가정용 회선처럼 보임 |
| rdns_mobile | -10 × 0.70 | -7 | 호스트명이 모바일 네트워크처럼 보임 |
어떤 종류의 회선이며 알려진 크롤러입니까? 네트워크 유형 이유는 항상 한 쌍 중 하나입니다. 익명화 증거가 없으면 할인, 있으면 가산입니다.
| detection_methods 값 | 점수 × 신뢰도 | 가산 | 의미 |
|---|---|---|---|
| residential_isp | -20 × 0.85 | -17 | 역방향 DNS에서 추론한 주거용 회선, 익명화 증거 없음 |
| residential_with_threat | 25 × 0.85 | 21.25 | 프록시, Tor 또는 VPN 프로토콜 증거(IPsec 태그만으로는 해당하지 않음)가 있는 주거용 회선 |
| mobile_carrier | -15 × 0.80 | -12 | 익명화 증거가 없는 모바일 회선 |
| mobile_with_threat | 20 × 0.80 | 16 | 익명화 증거가 있는 모바일 회선 |
| verified_crawler | -30 × 0.95 | -28.5 | 공식 크롤러 IP 대역 파일 안에 있음, 매일 다시 가져옴 |
코드는 알지만 반환하지 않는 다섯 가지 이유
GeoIPHub의 점수 산정 코드에는 이름이 존재하지만 현재 응답에 나타날 수 없는 이유가 다섯 개 있으므로, 이것을 기다리는 규칙을 만들지 마십시오.
spoofed_crawler(+42.75). 우리 파이프라인에서 이것을 설정하는 곳이 없으며, 조회는 IP만 볼 뿐 User-Agent는 보지 못합니다. 주장하는 봇 이름과threat.crawler의 비교는 여러분의 코드에서 이루어집니다.honeypot_hit(+33.25). 허니팟 카운트는 항상 0인 자리표시자입니다.known_vpn_asn(+22.5). 우리 코드는 주소가 이미 VPN일 때만 네트워크를 VPN으로 표시하므로known_vpn_server가 항상 이깁니다.rdns_cgnat(-10.5). 호스트명 분류기에 CGNAT 패턴이 없습니다.shadowsocks_suspected(+10). Shadowsocks 프로브가 없고, 우리가 불러오는 어떤 공급자 목록도 Shadowsocks를 표시하지 않습니다.
설정 파일에는 조회 경로가 읽지 않는 가중치가 11개 더 있으며, 그 이름들도 응답에 도달하지 않습니다. 휴면 상태의 이유를 기다리다 알게 되도록 두기보다 미리 나열해 두겠습니다.
규칙은 원시 숫자가 아니라 이유로 작성하십시오
이 이름들을 익혀야 하는 실용적인 이유는 이유에 기반한 규칙이 우리 데이터의 결함을 견디지만 합계에 기반한 규칙은 그렇지 못하기 때문입니다. 로그인, 가입, 결제의 차단 임계값이 구간을 정하고, 그 안에서는 몇 가지 이유 수준 규칙이 대부분의 일을 합니다.
- tor_exit, socks5_open, http_proxy_open, botnet_c2는 단독으로 강한 신호로 취급하십시오. 각각 33 이상을 더하며 목록이나 우리의 자체 프로브에서 옵니다.
- no_ptr_datacenter, fcrdns_mismatch 또는 어떤 rdns_* 이유도 단독으로 조치하지 마십시오. 2에서 24점을 지니며, 없거나 오래되었을 수 있는 저장된 호스트명을 읽습니다.
- verified_crawler는 threat.crawler.verified, 그리고 User-Agent가 주장하는 봇과 일치하는 operator와 함께 읽으십시오. threat.crawler.name은 절대 사용하지 마십시오. 2026년 10월 29일의 AhrefsBot처럼 스팸 목록에 올라 있는 검증된 크롤러는 결제가 아니라 크롤 허용 목록에 속합니다.
- wireguard_open은 프로브 결과가 아니라 목록 증거로 취급하십시오. 공급자가 공개한 목록이 해당 서버가 WireGuard를 실행한다고 말한다는 뜻입니다.
- 모든 결정과 함께 detection_methods 배열 전체를 기록하십시오. 지원 담당자나 지불 거절 검토자가 요구할 감사 추적입니다.
실제 필드만 사용한 코드로는 다음과 같습니다.
const { recommended_action, detection_methods: why } = data.scoring;
const strong = ["tor_exit", "socks5_open", "http_proxy_open", "botnet_c2"];
if (why.some((m) => strong.includes(m))) return block(why);
// isCrawlPath is your own route check, not an API field.
// claimMatchesOperator compares the bot your User-Agent names with
// threat.crawler.operator; /blog/verified-crawler-ip-list has a working version.
if (why.includes("verified_crawler") && isCrawlPath(req) &&
claimMatchesOperator(req, data.threat.crawler)) return allow(why);
if (recommended_action === "block") return block(why);
if (recommended_action === "step_up") return challenge(why);
return allow(why);
이유는 증거가 어디서 오는지도 알려 주며, 고객이 이의를 제기할 때 이것이 중요합니다. vpn_confidence 95의 known_vpn_server는 공급자 자체 목록을 뜻합니다. IP 뒤의 VPN 공급자를 명명하는 방법과 각 신뢰도 값의 의미는 별도 글에서 설명합니다. 프로브 쪽은 VPN 및 프록시 탐지의 작동 방식에서 가장 무거운 익명화 이유가 어디서 오는지 다루며, IP 데이터 필드 전체 목록은 응답의 나머지를 문서화합니다.
점수 하나를 직접 더해 보십시오
아무 주소나 GeoIPHub의 무료 IP 위험 점수 검사기에 붙여 넣고, 이유를 복사한 뒤 위의 표로 숫자를 다시 계산해 보십시오. 여러분의 합계와 우리의 점수가 다르다면 둘 중 하나에 버그가 있는 것이며, 어느 쪽인지 알려 주시면 감사하겠습니다.
더 알아보기
자주 묻는 질문
scoring.detection_methods에는 무엇이 들어 있나요?
점수를 바꾼 모든 이유의 이름이며, 크기순이 아니라 GeoIPHub의 점수 산정 코드가 확인하는 순서로 나열됩니다. 각 이름에는 점수 설정에 고정된 점수와 신뢰도가 있으며, 점수는 (점수 곱하기 신뢰도)의 합을 반올림하여 0과 100 사이로 제한한 값입니다. GeoIPHub의 코드는 41개의 이유를 명명할 수 있고, 현재 응답에 나타날 수 있는 것은 36개입니다.
검증된 크롤러인데 왜 review 점수가 나오나요?
GeoIPHub의 점수 산정에서 verified_crawler는 허용 목록이 아니라 가중치이기 때문입니다. 28.5점을 깎습니다(신뢰도 0.95에서 마이너스 30). 5.39.1.230의 AhrefsBot은 2026-10-29에 Spamhaus 등재도 있었으므로 스팸 및 블록리스트 이유가 할인보다 컸습니다. 크롤러 일치가 없었다면 64(step up)였을 점수가 35, review가 되었습니다.
점수가 0 미만이 될 수 있나요?
가중 합계는 가능하지만 점수는 불가능합니다. 66.249.66.1의 Googlebot은 2026-10-29에 합계가 마이너스 18.5(datacenter_ip와 verified_crawler)였으며 GeoIPHub의 API는 0을 반환했습니다. 음수 잔액이 다른 이유에 대한 크레딧으로 이월되지는 않습니다.
wireguard_open은 GeoIPHub가 WireGuard 핸드셰이크를 완료했다는 뜻인가요?
아닙니다. GeoIPHub에는 WireGuard 프로브가 없습니다. wireguard_open은 VPN 공급자가 직접 공개한 서버 목록에서 해당 서버를 WireGuard로 표시했다는 뜻입니다. 우리의 프로브는 SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE(v1과 v2), PPTP, L2TP를 다루므로 openvpn_open, pptp_open, l2tp_open, socks5_open, http_proxy_open이 프로브 결과입니다.
역방향 DNS가 있는 주소에서 no_ptr_datacenter가 보이는 이유는 무엇인가요?
이 이유는 실시간 쿼리가 아니라 GeoIPHub에 저장된 역방향 DNS 레코드를 읽으며, 그 레코드에는 빈틈이 있습니다. 2026-10-29에 AhrefsBot 5.39.1.230과 Tor 출구 185.220.101.1에서 작동했지만 dig -x는 둘 다 정상적으로 해석했습니다. 5점짜리 이유이므로, 원시 합계가 아니라 신뢰하는 이유를 기준으로 규칙을 작성하십시오.
GeoIPHub API를 만드는 팀
GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.
