IP 위험 점수 몇 점에서 차단해야 할까요?
로그인, 가입, 결제별 IP 위험 점수 임계값을 실제 IP 다섯 개로 검증했습니다. 점수 하나, 조치 셋, 그리고 릴레이나 CGNAT 사용자가 block에 도달하지 않는 이유를 설명합니다.

차단해야 할 단일 IP 위험 점수 임계값은 없습니다. 같은 점수라도 로그인은 통과시키고, 가입은 검토 대상으로 표시하고, 결제는 3-D Secure로 보낼 수 있습니다. GeoIPHub의 0-100 척도는 기본적으로 25까지 allow, 50까지 review, 75까지 step up, 75 초과는 block이며, 이 가이드는 그 경계선을 행동별로 옮기고 2026년 10월 22일에 공개 주소 다섯 개로 검증한 결과를 담았습니다.

점수 하나, 문 세 개: 임계값으로 돌려 본 IP 다섯 개
API가 반환하는 같은 판정이라도 문마다 다르게 적용되며, 두 가지 점수 상한이 공유 주소가 도달할 수 있는 한계를 정합니다. 2026년 10월 22일 04:56 UTC에 키 없는 API로 공개 주소 다섯 개를 조회하고, 각 결과를 다음 절의 시작 임계값에 대응시켰습니다. 마지막 두 행은 조회가 아니라 점수 산정 설정에 정해진 상한입니다.
| 주소 | 정체 | 점수, 조치 | 로그인 | 가입 | 결제 |
|---|---|---|---|---|---|
185.220.101.1 | Tor 출구, TORSERVERS-NET, 함부르크 | 100, block | 차단 | 차단 | 차단 |
185.213.155.73 | Mullvad VPN 서버, 프랑크푸르트, Mullvad 자체 목록에 있음 | 100, block | 차단, 또는 정책에 따라 MFA | 차단 | 차단 |
5.39.1.230 | OVH의 검증된 AhrefsBot, Spamhaus ZEN 등재 | 35, review | 로그인 허용, 사유 기록 | 생성하고 검토 대상으로 표시 | 3-D Secure |
104.28.46.99 | Cloudflare의 iCloud Private Relay 출구 | 9, allow | 허용 | 허용 | 허용 |
45.33.32.156 | scanme.nmap.org, Linode 서버 | 10, allow | 허용 | 허용 | 허용 |
| 모든 Private Relay 주소 | 릴레이 상한 | 최대 60 | 최대 MFA | 최대 인증 | 최대 3-D Secure |
| 모든 CGNAT 주소 | 통신사급 NAT 상한 | 최대 50 | 로그인 허용, 기록 | 최대 검토 대상 표시 | 최대 3-D Secure |
이 표에서 실제로 조치할 만한 점이 네 가지 있습니다.
- 두 개의 100점은 이유가 다릅니다. Tor 출구의 methods는
tor_exit,datacenter_blocklisted,no_ptr_datacenter,known_spammer로, 스팸 이력이 있는 익명화 도구입니다. Mullvad 서버의 methods는known_vpn_server,wireguard_open,datacenter_with_vpn_proxy,no_ptr_datacenter이며threat.is_spammer는 false이고 DNS 블록리스트 등재도 없습니다. 고객이 VPN을 쓴다면 VPN 단독 사유의 차단을 MFA로 바꾸는 로그인 규칙은 합리적이며, 이 규칙은 Tor 출구에는 절대 적용되지 않습니다. - 가운데 행에서 행동별 임계값이 진가를 발휘합니다. 35점의 AhrefsBot은 로그인을 통과하고, 가입에서는 플래그되며, 결제에서는 3-D Secure로 갑니다. 그런데 검증된 SEO 크롤러가 이런 양식을 제출할 이유는 없으며, 점수만으로는 그것을 알 수 없습니다.
- 그 가운데 행은 2주 사이에 움직였습니다. 같은 주소가 10월 8일에는 23점이었고, 10월 19일에는 methods에
abusive_listed가 포함된 59점,step_up이었습니다. 10월 22일에는 그 method가 사라지고 점수는 35가 되어 로그인이 MFA에서 일반 로그인으로 내려갔습니다. 이 주소는 IP 주소를 조사하는 방법에서 자세히 다룹니다. 모든 결정과 함께 점수, methods, 날짜를 저장하고, 오래된 판정에 따라 조치하기 전에 조회를 다시 실행하십시오. - 공유 주소는 block에 도달할 수 없습니다. Private Relay는 60(
relay_max_score)으로 제한되어 기본 block 기준선 76을 넘을 수 없습니다. CGNAT는 review 구간의 최상단인 50(cgnat_max_score)으로 제한됩니다. 가장 엄격한 block 기준선인 결제의 66은 의도적으로 둘 다 위에 있습니다. 60 이하라면 상한이 걸린 릴레이 사용자가 주소를 공유한다는 이유만으로 거절당할 수 있습니다.
allow 두 행은 점수 산정이 가산 방식임을 보여 줍니다. 릴레이의 relay_ip 신호는 신뢰도 0.85에서 10점이며 반올림하면 9입니다. Linode 서버의 datacenter_ip는 0.5에서 20점이므로 10입니다. 호스팅은 살펴볼 이유이지 차단할 이유가 아니며, 릴레이는 통과시켜야 합니다. 이는 Private Relay와 WARP 트래픽을 탐지하는 방법에서 설명합니다.
로그인, 가입, 결제를 위한 IP 위험 점수 시작 임계값
시작 임계값은 잘못 허용했을 때의 비용이 커질수록 block 기준선을 조입니다. 로그인 76, 가입 71, 결제 66입니다. 시작점으로 삼고 자사의 사기 데이터로 조정하십시오.
| 행동 | 허용 | 검토 또는 추가 인증 | 차단 | 이유 |
|---|---|---|---|---|
| 로그인 | 0-50, 26-50은 기록 | 51-75: MFA 요구 | 76 이상 | 비밀번호와 MFA가 여전히 세션을 지킴 |
| 가입 | 0-25 | 26-50: 생성 후 플래그, 51-70: 이메일 또는 전화 인증 | 71 이상 | 가짜 계정은 만들기 쉬움 |
| 결제 | 0-25 | 26-65: 3-D Secure | 66 이상 | 잘못 허용하면 지불 거절로 이어짐 |
| API 또는 읽기 | 0-69 | 70-84: 속도 제한 | 85 이상 | 연동은 클라우드 서버에서 실행됨 |
명백한 경우에는 신호에 대한 몇 가지 규칙을 점수와 결합하십시오.
detection.is_tor가 true이면 모든 행동을 차단하십시오. 이유만으로 거절을 정당화할 수 있는 유일한 경우입니다.detection.is_relay또는threat.is_cgnat가 true이면 점수만으로 강제 차단하지 마십시오. 상한이 이미 이를 보장하지만, 나중에 누군가 block 기준선을 낮추더라도 이 규칙이 지켜 줍니다.- 결제에서는
review를step_up으로 취급하십시오. IP 사기 탐지 API 튜토리얼에 바로 이 재정의와 조회 시간 초과 시의 소프트 실패 처리를 담은, 검증된 Node와 Python 코드가 있습니다.
가입 시 각 유형의 주소가 반환하는 값과 점수가 통과시키는 것을 잡아내는 프리픽스별 속도 제한은 가입 시 가짜 계정 탐지에서 확인하십시오.
각 구간의 의미와 점수 하나가 만들어지는 방식은 IP 위험 점수를 읽는 방법에서 시작하십시오.
Tor 출구는 100점이며 methods가 이유를 말해 줍니다
다음은 2026년 10월 22일 04:56 UTC에 조회한 185.220.101.1의 실제 응답을 간추린 것입니다.
curl "https://api.geoiphub.com/v1/lookup/185.220.101.1" \
-H "x-api-key: YOUR_API_KEY"
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_proxy": false,
"is_vpn": false,
"is_tor": true,
"is_hosting": true,
"is_anonymous": true,
"anonymity_level": "high"
},
"threat": {
"is_spammer": true,
"threat_types": ["spammer", "tor"],
"dnsbl_sources": ["zen.spamhaus.org"]
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "no_ptr_datacenter", "known_spammer"]
}
}
fraud_score 100은 표의 모든 block 기준선을 넘으므로 로그인, 가입, 결제 모두 거절합니다. 이유 세 가지만으로 거기에 도달합니다. tor_exit(0.99에서 45점), known_spammer(0.9에서 40점), datacenter_blocklisted(0.75에서 30점)를 더하면 상한 100에 걸리기 전에 103점입니다. Tor는 단독으로 플래그되므로 detection.is_vpn은 false이고, 따라서 detection.is_tor는 강제 차단하면서 일반 VPN 사용자는 계속 추가 인증을 요구할 수 있습니다.
네 번째 이유는 우리 쪽의 결함입니다. no_ptr_datacenter는 이 주소에 역방향 DNS가 없다는 뜻인데, 같은 날 아침 04:57 UTC에 dig -x 185.220.101.1은 Tor 출구 호스트명을 반환했습니다. 우리 데이터베이스에 해당 레코드가 저장되어 있지 않으며 수정 사항은 기록되어 있습니다. 판정은 나머지 세 신호로 유지되지만, 원시 합계가 아니라 신뢰하는 신호를 기준으로 규칙을 작성해야 하는 좋은 이유입니다.
전역 기준선 하나가 실패하는 이유
기준선 하나가 실패하는 것은 엔드포인트마다 직면하는 공격이 다르기 때문입니다. 로그인 페이지는 크리덴셜 스터핑을 받아 냅니다. Verizon 2025 DBIR에 따르면 이는 하루 전체 인증 시도의 중앙값 19%, 최악의 날에는 44%를 차지했습니다. 결제는 카드 테스트에, 가입은 가짜 계정에 직면합니다. 그리고 Cloudflare Radar 2025 연말 리뷰에 따르면 2025년 12월 2일 HTML 요청 중 사람이 생성한 것은 47%에 불과했습니다.
성숙한 시스템은 이미 구간별로 조치합니다. Cloudflare의 봇 점수는 1에서 99까지이며 고객은 이를 기준으로 차단, 챌린지, 허용 규칙을 작성합니다(Cloudflare 봇 점수). OWASP는 IP 차단이 "우회하기 쉽기 때문에 단독 또는 주된 방어책으로 사용해서는 안 된다"고 말합니다(OWASP Credential Stuffing Cheat Sheet). 같은 문서는 MFA가 계정 침해의 99.9%를 막았을 것이라는 Microsoft의 분석을 인용합니다. 그래서 로그인의 추가 인증 구간은 저렴한 보험이 됩니다. NIST SP 800-63B는 예상치 못한 지리적 위치나 IP 주소 블록이 "추가적인 위험 기반 통제의 사용을 촉발할 수 있다"고 하면서도 "인증 요소를 대체하지는 않는다"고 밝힙니다(NIST SP 800-63B).
GeoIPHub는 설명 가능한 0-100 위험 점수를 36개의 가중 이유로 구성하고, 작동한 이유를 모두 scoring.detection_methods에 이름으로 남깁니다. 일부는 점수를 낮춥니다. 가정용 ISP 이유는 17점을 깎고(신뢰도 0.85에서 마이너스 20), 검증된 크롤러는 28.5점을 깎습니다(0.95에서 마이너스 30).
낮은 기준선은 공유 주소와 비공개 주소를 처벌합니다
"안전을 위해" 낮게 정한 block 기준선은 평범한 이유로 주소를 공유하거나 숨기는 고객을 돌려보냅니다.
- VPN 사용자. 2026년 8월 미국 성인 1,008명을 조사한 Security.org의 2026 VPN 보고서에서 42%가 개인 또는 업무 목적으로 VPN을 사용한다고 답했습니다. 일반적인 개인정보 보호(56%)와 일반적인 보안(51%)이 가장 큰 이유였습니다.
- 통신사급 NAT. RFC 6598은 CGNAT용으로
100.64.0.0/10을 예약해 두었으며, Cloudflare는 그 뒤에서 "수백, 심지어 수천 개의 클라이언트가 하나의 IP 주소에서 나온 것처럼 보일 수 있다"고 지적합니다. 또한 Cloudflare는 CGNAT IP가 다른 IP보다 속도 제한을 세 배 더 자주 받지만 봇 비율 중앙값은 4.8%와 4.7%로 거의 같다는 것을 확인했습니다(Cloudflare의 CGNAT 글). - iCloud Private Relay. 릴레이 홉 하나를 운영하는 Cloudflare는 Apple이 기기와 계정을 검증하므로, 사기 방지에 IP 주소를 사용하는 사이트가 Private Relay 연결을 "신뢰할 수 있다"고 말합니다(Cloudflare의 Private Relay 글).
GeoIPHub는 detection.is_mobile, detection.is_relay, threat.is_cgnat를 반환하며, 점수를 반환하기 전에 CGNAT 상한 50과 릴레이 상한 60을 적용합니다.
올바른 IP를 점수화하지 않으면 모든 임계값이 무의미합니다
조작된 X-Forwarded-For 값을 점수화하면 정성 들여 조정한 임계값이 실행되기도 전에 무력화됩니다. RFC 7239는 클라이언트를 포함해 경로상의 어떤 노드든 Forwarded 헤더를 수정할 수 있으므로 "올바르다고 신뢰할 수 없다"고 경고합니다(RFC 7239). MDN의 규칙은 X-Forwarded-For를 보안 용도로 사용할 때 "신뢰할 수 있는 프록시가 추가한 IP 주소만 사용해야" 하며, 운영 중인 프록시 수만큼 가장 오른쪽 항목에서부터 세어 찾으라는 것입니다(MDN: X-Forwarded-For). 우리는 보내 주신 IP를 그대로 점수화하므로, 먼저 신뢰하는 프록시 체인에서 IP를 도출하십시오.
임계값은 자사의 결과로 조정하십시오
표에서 시작한 뒤 증거를 바탕으로 각 기준선을 옮기십시오. 모든 결정에 점수, recommended_action, detection_methods, 날짜를 기록하고, 몇 주 뒤 확인된 사기 및 지불 거절과 비교하십시오. 결제 기준선 66이 55-65 구간의 지불 거절을 통과시킨다면 낮추되, Private Relay 사용자에게 서비스를 제공하는 한 60 이하로는 내리지 마십시오. 51-70 구간의 가입 인증이 불량 계정을 거의 잡지 못한다면 기준선을 올리십시오.
무료 플랜은 모든 필드를 포함해 하루 1,500회 조회를 제공합니다. 주소 하나를 직접 확인하려면 IP 위험 점수 검사기가 코드 없이 같은 점수와 이유를 보여 줍니다.
더 넓은 신호 집합은 실제 고객을 차단하지 않고 익명화 트래픽 탐지하기, 주거용 프록시 대 데이터센터 프록시 사기, 계정 탈취와 크리덴셜 스터핑 방지, 사용 단계에서 프로모션 및 쿠폰 악용 탐지, 결제 사기 탐지 스택에서 IP 신호의 위치 가이드를 참고하십시오.
자주 묻는 질문
차단 기준으로 좋은 IP 위험 점수는 몇 점인가요?
모든 상황에 통하는 단일 기준선은 없습니다. GeoIPHub의 기본 구간은 76 이상에서 차단합니다. 우리의 시작 임계값은 로그인에서 이를 유지하고, 가입에서는 71, 결제에서는 66으로 낮춥니다. 카드 미제시 부정 주문은 비밀번호를 다시 묻는 것보다 훨씬 큰 비용을 초래하기 때문입니다. 다른 공급자의 척도는 다르므로 어떤 기준선이든 해당 공급자의 구간에 맞춰 읽으십시오.
IP 위험 점수 75는 무엇을 의미하나요?
GeoIPHub의 0-100 척도에서 75는 step_up 구간의 최상단입니다. block은 76부터 시작합니다. 조용히 허용하지 말고 추가 인증을 요구하며, scoring.detection_methods를 확인하십시오. VPN 신호로 나온 75와 블록리스트 이력으로 나온 75는 서로 다른 대응이 필요하기 때문입니다. 실제 Tor 출구는 75에 있지 않습니다. 2026년 10월 22일 조회에서 185.220.101.1은 100점, block이었습니다.
VPN과 프록시 사용자를 자동으로 차단해야 하나요?
아닙니다. Security.org의 2026년 8월 미국 성인 1,008명 대상 설문에서 42%가 개인 또는 업무 목적으로 VPN을 사용한다고 답했고, 가장 큰 이유는 개인정보 보호와 보안이었습니다. VPN 플래그는 자동 거절이 아니라 추가 인증(step-up)을 요구할 사유로 취급하고, 강제 차단은 Tor 출구와 스팸 또는 블록리스트 이력이 있는 주소에 남겨 두십시오.
iCloud Private Relay나 CGNAT 사용자가 점수만으로 차단될 수 있나요?
GeoIPHub 기본 설정에서는 그렇지 않습니다. Private Relay 주소는 60, 통신사급 NAT 주소는 50으로 상한이 걸려 있어 둘 다 기본 block 기준선인 76보다 낮습니다. 모든 block 임계값을 60 위로 유지하면 공유 주소는 점수만으로 추가 인증은 받을 수 있어도 거절되지는 않습니다.
결제의 차단 임계값이 로그인보다 낮은 이유는 무엇인가요?
결제에서 잘못 허용하면 도난 카드로 상품이 발송되고 지불 거절(chargeback)로 돌아옵니다. 반면 로그인에서 잘못 허용해도 비밀번호와 2차 인증을 여전히 통과해야 합니다. 그래서 결제는 66부터, 로그인은 76부터 차단합니다.
GeoIPHub API를 만드는 팀
GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.


