꼭 알아야 할 IP 데이터 필드 전체 목록
실제 GeoIPHub 응답에 담긴 모든 IP 데이터 필드: 10개 그룹의 103개 필드를 유형, 실제 예시 값과 함께 정리하고 11개의 자리표시자를 명확히 표시했습니다.

"IP 주소에서 어떤 데이터를 얻을 수 있나요?"라고 물으면 대부분의 답은 "대략적인 위치"에서 멈춥니다. 그것은 IP 인텔리전스 전체 그림에서 가장 작은 부분입니다. 같은 주소는 어느 네트워크가 소유하는지, 가정용 회선인지 임대 서버인지, VPN인지 Tor 출구인지 프라이버시 릴레이인지, 차단 목록에 올라 있는지, 검증된 크롤러인지도 알려 줍니다. 탐지 필드가 어떻게 만들어지는지는 VPN 및 프록시 탐지의 작동 방식을 참고하십시오.
이 참조 자료는 7월 버전 이후 많이 바뀌었습니다. API에 필드 세 개가 추가되었고, 우리 표에서 두 개가 빠져 있었으며, Tor 출구의 점수가 79에서 100으로 바뀌었고, 7월 표가 잘못 설명한 값을 반환하는 필드도 여럿입니다. 아래의 모든 예시는 2026년 10월 22일의 GET api.geoiphub.com/v1/lookup/{ip}에서 가져왔으며, 무료 IP 조회 도구로 어느 것이든 재현할 수 있습니다.

2026년 10월 22일 실제 응답 7건에서 103개 필드를 세었습니다
2026년 10월 22일 04:56에서 04:57 UTC 사이에 응답 7건을 가져와 10개 그룹에 걸친 103개 필드를 세었습니다. 5개 필드는 7월 이후 이 목록에 새로 추가되었고, 11개는 자리표시자입니다. 일곱 개의 주소는 서로 다른 그룹이 작동하도록 고른 공개 인프라였습니다.
| IP | 정체 | 2026년 10월 22일 판정 |
|---|---|---|
| 185.220.101.1 | Tor 출구, TORSERVERS-NET, 함부르크 | 100, block |
| 185.213.155.73 | Mullvad VPN 서버, 프랑크푸르트 | 100, block |
| 66.249.66.1 | Googlebot | 0, allow |
| 104.28.46.99 | Cloudflare의 iCloud Private Relay 출구 | 9, allow |
| 45.33.32.156 | scanme.nmap.org, Linode 서버 | 10, allow |
| 8.8.8.8 | Google Public DNS(애니캐스트) | 10, allow |
| 1.1.1.1 | Cloudflare DNS(애니캐스트) | 10, allow |
작은 Node 스크립트로 모든 응답을 순회하며 각 리프 필드를 나열했고, geo.country_names는 번역 맵이므로 하나의 필드로 셌습니다. 일곱 개 응답은 모두 정확히 같은 103개 키를 가지고 있었습니다. 구성은 다음과 같습니다.
| 그룹 | 필드 | 현재 자리표시자 |
|---|---|---|
| ip | 1 | 0 |
| asn | 12 | 0 |
| geo | 15 | 0 |
| whois | 8 | 0 |
| network | 7 | 3 (open_ports, service, cloud_region) |
| detection | 23 | 0 |
| threat | 25 | 7 (blocklist_sources, crawler.spoofed, botnet.last_seen, 허니팟 필드 3개, spammer_last_seen) |
| dns | 3 | 0 |
| scoring | 4 | 0 |
| meta | 5 | 1 (sources) |
| 합계 | 103 | 11 |
5개 필드가 이 목록에 새로 추가되었습니다. 세 개는 10월에 API에 추가되었습니다. detection.residential_proxy_status, residential_proxy_evidence, residential_proxy_last_seen입니다. 이들은 이제 API 필드 참조에 예약됨으로 표시되어 있습니다. 나머지 둘인 threat.crawler.unverified와 threat.spammer_last_seen은 7월에도 응답에 있었으나 예전 표에서 빠뜨렸을 뿐입니다. 7월 목록에서 제거된 필드는 없습니다.
11개 필드는 자리표시자입니다. API의 응답 빌더를 확인했습니다. 그중 열 개는 모든 조회에서 상수 빈 값([], "none", 0)으로 기록되며, crawler.spoofed는 아직 뒷받침하는 데이터 소스가 없습니다. 여덟 개의 필드는 데이터를 담고 있지만 예약됨 상태이므로 값을 표시하지 않습니다. blocklist_count, 두 그룹의 ptr_pattern, 그리고 주거용 프록시 필드 다섯 개입니다. 아래 표는 두 종류를 모두 표시합니다.
Tor 출구 조회 하나로 보는 10개 그룹의 맞물림
그룹은 주소 하나를 따라가 보면 가장 이해하기 쉽습니다. 다음은 Tor 출구인 185.220.101.1의 실제 응답이며, 이야기를 전하는 필드만 추렸습니다.
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"asn_type": "hosting",
"connection_type": "datacenter",
"rpki": "valid"
},
"geo": {
"country_code": "DE",
"city": "Hamburg (Hamburg-Nord)",
"timezone": "Europe/Berlin",
"geo_confidence": 0.8
},
"whois": {
"org": "none",
"netname": "ARTIKEL10",
"status": "ASSIGNED PA",
"registered": "2017-09-12T00:00:00.000Z"
},
"network": {
"ptr_record": "none",
"fcrdns_valid": "none",
"abuse_contact": "abuse@artikel10.org"
},
"detection": {
"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,
"confidence": 0.7402500000000001,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "no_ptr_datacenter", "known_spammer"]
},
"meta": {
"last_classified_at": "2026-10-22T04:56:41.816Z",
"last_scanned": "2026-10-20T18:45:48.000Z",
"latency_ms": 2
}
}
그룹들은 서로를 뒷받침합니다. ASN은 호스팅이라고 말하고, detection.is_tor는 Tor Project의 출구 목록에서 오며, threat.dnsbl_sources는 Spamhaus ZEN 등재를 보여 주고, scoring 그룹은 이 모두를 작동한 네 가지 방법과 함께 block으로 집계합니다.
응답에는 공백도 하나 보입니다. ptr_record가 "none"이어서 no_ptr_datacenter가 작동했지만, 같은 날 아침 실시간 dig -x 185.220.101.1은 tor-exit 호스트 이름을 반환했습니다. 일부 주소에서는 API가 저장한 역방향 DNS가 실시간 레코드보다 뒤처집니다. 이 글의 7월 버전에 나왔던 rdns_tor가 더 이상 작동하지 않는 이유도 이 공백 때문입니다. 그룹 사이의 이러한 교차 확인이 이렇게 많은 필드를 담는 이유입니다. 이제 각 그룹을 차례로 보겠습니다.
1. IP 자체(ip)
ip 필드는 API가 해석한 정확한 주소를 문자열로 되돌려 줍니다. 의도한 대로 조회했는지 확인하는 데 쓰십시오. 특히 X-Forwarded-For 헤더를 파싱한 뒤에는 엉뚱한 홉을 고르는 것이 전형적인 버그입니다. 직접 만드는 캐시의 자연스러운 키이기도 합니다.
IPv4와 IPv6 모두 허용됩니다. 자신의 공개 주소가 무엇인지 모르겠다면 내 IP 확인 도구가 웹사이트가 그로부터 추론할 수 있는 모든 것과 함께 보여 줍니다.
2. 네트워크와 ASN 데이터(asn)
asn 그룹은 어느 네트워크가 주소를 알리는지 알려 주며, 얻을 수 있는 IP 데이터 중 가장 신뢰할 만한 축에 속합니다. 라우팅 가능한 모든 IP는 Autonomous System에 속하며, 이는 추정이 아니라 전역 라우팅 테이블에서 나옵니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (8.8.8.8) |
|---|---|---|---|
| asn | number | IP를 알리는 Autonomous System Number | 15169 |
| org | string | AS를 운영하는 조직 | GOOGLE - Google LLC |
| asn_type | string | 네트워크 분류: isp, hosting, cdn, mobile, satellite, unknown | hosting |
| user_type | string | 사용 분류. 예: hosting, residential, cellular, content_delivery_network | hosting |
| isp | string | ISP 이름(현재 org와 같은 값) | GOOGLE - Google LLC |
| domain | string | 네트워크와 연관된 도메인 | none |
| connection_type | string | datacenter, residential, mobile, satellite, unknown | datacenter |
| access_type | string | rDNS 표식에서 읽은 접속 매체: fiber, cable, dsl, cellular, datacenter | datacenter |
| carrier | string | 셀룰러 IP의 이동통신사 이름 | none |
| mcc | string | 셀룰러 IP의 Mobile Country Code | none |
| mnc | string | 셀룰러 IP의 Mobile Network Code | none |
| rpki | string | RPKI 경로 출발지 검증: valid, invalid, unknown | valid |
값은 주소에 따라 달라집니다. 1.1.1.1은 asn_type: "cdn"과 user_type: "content_delivery_network"로, Googlebot은 user_type: "search_engine_spider"로 반환되었습니다. Private Relay 출구는 asn_type: "unknown", connection_type: "unknown", user_type: "consumer_privacy_network"를 반환했습니다. 7월 이후 한 가지가 바뀌었습니다. 8.8.8.8은 이제 rpki: "valid"를 반환하지만 문서 샘플에는 여전히 "invalid"가 나와 있습니다.
주시해야 할 필드는 connection_type입니다. 소비자 로그인에 데이터센터 주소가 나타나면 다시 살펴볼 만합니다. 다만 호스팅만으로는 사기가 아닙니다. 45.33.32.156은 평범한 호스팅이며 10점, allow를 받았습니다. 무료 데이터센터 IP 확인으로 어떤 주소든 확인할 수 있고, IP 지리적 위치 API 페이지에서 ASN 모델을 다룹니다.
3. 지리적 위치 데이터(geo)
geo 그룹은 주소를 지도 위에 놓으며, 가장 자주 과신하게 되는 그룹입니다. 15개 필드 모두 우리가 실행한 모든 조회에서 데이터를 담고 있었습니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (1.1.1.1) |
|---|---|---|---|
| country_code | string | ISO 3166-1 alpha-2 국가 코드 | AU |
| country_name | string | 국가 이름 | Australia |
| country_names | object | 언어 코드를 키로 하는 현지화된 국가 이름 | { en, de, es, fr, ja, ... } |
| country_geoname_id | number | 국가의 GeoNames ID | 2077456 |
| continent_code | string | 두 글자 대륙 코드 | OC |
| continent_name | string | 대륙 이름 | Oceania |
| continent_geoname_id | number | 대륙의 GeoNames ID | 6255151 |
| is_in_european_union | boolean | 국가가 EU 회원국인지 여부 | false |
| flag_emoji | string | 국가의 유니코드 국기 | 🇦🇺 |
| region | string | 주, 도 또는 지역 | New South Wales |
| city | string | 가장 가능성 높은 도시 추정 | Sydney |
| timezone | string | IANA 시간대 또는 "none" | Australia/Sydney |
| latitude | number | 대략적인 위도 | -33.8688 |
| longitude | number | 대략적인 경도 | 151.209 |
| geo_confidence | number | 도시 답변에 대한 신뢰도, 0에서 1 | 0.8 |
국가는 확실하고 도시는 대략적입니다. 역방향 DNS 지리적 위치에 대한 동료 심사 연구는 2018년 데이터를 사용해 상용 데이터베이스 두 곳의 중앙값 오차를 11.1km와 16.7km로 측정했습니다. 더 많은 증거는 IP 지리적 위치는 얼마나 정확한가에서 다룹니다. 도시는 핀이 아니라 반경으로 취급하고, IP로 사람의 위치를 찾는 데 절대 사용하지 마십시오.
geo_confidence는 detection.is_anycast와 함께 읽으십시오. 1.1.1.1은 시드니에 대해 0.8을 반환했지만 is_anycast: true이기도 합니다. 같은 주소가 여러 곳에서 동시에 알려지기 때문입니다. 애니캐스트 주소에서 도시는 여러 가능한 위치 중 하나일 뿐입니다.
공백이 두 가지 더 나타났습니다. 조회한 미국 주소 세 개(8.8.8.8, Googlebot의 66.249.66.1, 45.33.32.156) 모두에서 도시는 채워졌는데도 timezone은 "none"으로 돌아왔으므로, 필요할 때는 직접 시간대를 도출하십시오. 그리고 Private Relay 출구 104.28.46.99는 앙골라 루안다로 위치가 나왔지만 Apple의 자체 출구 목록은 해당 범위를 잠비아 루사카로 표기합니다. 릴레이는 릴레이 IP를 Apple의 출구 목록과 대조하기에서 설명한 대로 Apple의 행에서 위치를 가져오십시오.
4. WHOIS 및 등록 데이터(whois)
whois 그룹은 누가 언제 블록을 등록했는지를 5개 지역 인터넷 레지스트리에서 RDAP로 가져와 알려 줍니다. 지리적 위치가 놓치는 소유권 계층을 더해 줍니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (1.1.1.1) |
|---|---|---|---|
| org | string | 등록 조직 | APNIC and Cloudflare DNS Resolver project |
| country | string | 등록 국가(geo와 다를 수 있음) | AU |
| netname | string | 넷블록 이름 | APNIC-LABS |
| status | string | 블록의 할당 상태 | ASSIGNED PORTABLE |
| registered | string (ISO 8601) | 등록 날짜(공개된 경우) | 2011-08-11T00:00:00.000Z |
| last_changed | string (ISO 8601) | 레지스트리 레코드가 마지막으로 변경된 시점 | 2023-04-26T22:57:58.000Z |
| has_vpn_keywords | boolean | 레지스트리 텍스트가 46개 VPN 키워드 중 하나와 일치 | false |
| has_hosting_keywords | boolean | 레지스트리 텍스트가 27개 호스팅 키워드 중 하나와 일치 | false |
커버리지는 레지스트리마다 다릅니다. 8.8.8.8과 45.33.32.156은 org, netname, status, last_changed에 "none"을 반환했고 country와 registered만 채워졌습니다. Mullvad 서버의 레코드는 풍부했습니다. netname: "NET-31173-185-213-155-0-24", 등록일 2017-07-19, 마지막 변경 2025-11-11입니다.
키워드 플래그는 보조 증거일 뿐 단독으로 플래그할 이유가 되지 않습니다. 일곱 주소 모두에서 둘 다 false였고, 레지스트리 org가 VPN에 대한 언급 없이 "31173 Services AB infrastructure in Frankfurt, DE."라고 적힌 Mullvad 서버도 마찬가지였습니다. 그래서 다음 섹션의 제공업체 목록이 더 중요합니다.
5. 네트워크 증거(network)
network 그룹은 역방향 DNS와 레지스트리의 abuse 연락처를 담고 있습니다. 7개 필드 중 3개는 현재 자리표시자입니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (8.8.8.8) |
|---|---|---|---|
| ptr_record | string | 저장된 역방향 DNS(PTR) 호스트 이름 | dns.google |
| ptr_pattern | string | PTR 호스트의 분류. 예약됨: 값을 표시하지 않음 | (표시 안 함) |
| fcrdns_valid | boolean, or "none" | PTR 호스트가 이 IP로 다시 해석됨. 저장된 PTR이 없으면 "none" | true |
| abuse_contact | string | 레지스트리 레코드의 abuse 주소 | network-abuse@google.com |
| open_ports | number[] | 자리표시자: 현재 항상 [] | [] |
| service | string | 자리표시자: 현재 항상 "none" | none |
| cloud_region | string | 자리표시자: 현재 항상 "none" | none |
abuse_contact는 활동을 신고해야 할 때 찾게 되는 필드이며, 우리 주소 일곱 개 중 다섯 개에서 채워졌습니다. fcrdns_valid는 단순한 불리언이 아닙니다. 저장된 PTR이 없는 Tor 출구, Mullvad 서버, 릴레이에 대해서는 문자열 "none"을 반환했습니다. === false를 검사하는 코드는 이 경우를 놓칩니다.
저장된 PTR은 확인하지 않고 믿지 마십시오. Googlebot 66.249.66.1의 경우 저장된 ptr_record는 인접한 주소의 것이고, 실시간 dig -x는 crawl-66-249-66-1.googlebot.com을 반환합니다. 8.8.8.8 값(dns.google)과 1.1.1.1 값(one.one.one.one)은 같은 날 아침 dig -x로 확인했습니다.
open_ports는 프로브가 응답했을 때도 비어 있습니다. 모든 조회에서 []로 기록됩니다. Mullvad 서버의 wireguard_open은 프로브 결과가 아니라는 점에 유의하십시오. Mullvad의 서버 목록이 그 서버를 WireGuard로 태그했다는 뜻입니다. 이 필드가 연결되기 전까지 openvpn_open 같은 프로브 결과는 scoring.detection_methods에서 읽으십시오.
6. VPN, 프록시, Tor, 릴레이 탐지(detection)
detection 그룹은 주소가 사용자를 익명화하는지, 그리고 어떻게 하는지에 답합니다. 23개 필드로 가장 큰 그룹이며, 그중 세 개는 7월 이후 새로 추가되었습니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (185.213.155.73, Mullvad) |
|---|---|---|---|
| is_proxy | boolean | 능동 프로빙 중 오픈 프록시로 응답함 | false |
| is_vpn | boolean | 핸드셰이크, 제공업체 목록, ASN 또는 WHOIS로 확인된 VPN 인프라 | true |
| is_tor | boolean | 매일 갱신되는 Tor Project 출구 목록에 있음 | false |
| is_hosting | boolean | 호스팅 또는 클라우드 인프라 | true |
| is_relay | boolean | 프라이버시 릴레이. VPN과 별도로 보고 | false |
| is_mobile | boolean | 모바일 통신사 네트워크 | false |
| is_satellite | boolean | 위성 ISP | false |
| is_anycast | boolean | 여러 위치에서 알려짐 | false |
| is_residential_proxy | boolean | 예약됨: 작동하는 기능이 아니므로 의존하지 마십시오 | (표시 안 함) |
| is_public_proxy | boolean | 공개적으로 등재된 오픈 프록시 | false |
| is_anonymous | boolean | VPN, 프록시 또는 Tor에 해당하면 true | true |
| proxy_type | string | 탐지된 프록시의 프로토콜 | none |
| anonymity_level | string | none, low, medium 또는 high | medium |
| vpn_provider | string | 목록에 있을 때 식별된 VPN 운영자 | Mullvad |
| vpn_provider_tier | string | 제공업체 이름에서 파생된 라벨. 이를 기반으로 만들지 마십시오 | (표시 안 함) |
| relay_provider | string | 식별된 릴레이 운영자 | none |
| proxy_score | number | 0에서 100까지의 프록시 가능성 | 0 |
| vpn_confidence | number | 0에서 100. 어떤 식별 경로가 작동했는지도 보여 줌 | 95 |
| residential_proxy_status | string | 2026년 10월 신규, /docs에는 없음. 예약됨 | (표시 안 함) |
| residential_proxy_evidence | string | 2026년 10월 신규, /docs에는 없음. 예약됨 | (표시 안 함) |
| residential_proxy_last_seen | string | 2026년 10월 신규, /docs에는 없음. 예약됨 | (표시 안 함) |
| residential_proxy_score | number | is_residential_proxy와 함께 예약됨 | (표시 안 함) |
| last_seen | string (ISO 8601) | 탐지가 마지막으로 바뀐 시점 | 2026-10-20T20:17:50.000Z |
vpn_provider가 동그라미를 칠 필드입니다. 대부분의 API는 IP가 "VPN"이라고 말할 수 있지만, 운영자 이름을 대려면 제공업체 목록이 필요합니다. 우리는 아홉 제공업체의 자체 서버 목록, 공개 서드파티 목록, 또는 알려진 VPN 네트워크의 짧은 표에서 VPN 이름을 정하며, vpn_confidence가 어느 경로가 작동했는지 보여 줍니다. 여기서 95는 Mullvad 자체 목록을 뜻합니다. 주소가 어느 목록에도 없으면 핸드셰이크로 VPN임이 입증되더라도 vpn_provider는 "none"을 반환합니다. 이 경로는 VPN이 자체 서버 목록으로 이름이 정해지는 방식에서 추적하며, VPN 탐지 테스트로 어떤 주소든 시험해 볼 수 있습니다.
is_relay와 relay_provider는 한 쌍으로 동작합니다. 104.28.46.99는 is_relay: true, relay_provider: "iCloud Private Relay", 점수 9, allow를 반환했습니다. API는 Cloudflare가 공개한 WARP 연결 범위, 즉 WARP 앱이 연결하는 주소에 대해서는 "Cloudflare WARP"를, Apple의 목록이 다루지 않는 다른 Cloudflare 프라이버시 출구에 대해서는 문서화되지 않은 "Cloudflare"를 반환하기도 합니다.
is_anonymous는 릴레이를 포함하지 않습니다. /docs는 릴레이를 포함한 모든 익명화 수단에 대해 true라고 설명하지만, 릴레이 출구는 anonymity_level: "medium"과 함께 is_anonymous: false를 반환했습니다. 이 플래그는 VPN, 프록시, Tor만 추적하므로 is_relay는 따로 읽으십시오.
새로 추가된 주거용 프록시 필드 세 개는 예약됨입니다. 10월 백엔드 변경과 함께 들어왔고 아직 문서화되지 않았습니다. 주거용 프록시 탐지는 현재 제공하는 기능이 아니므로, 주거용 프록시 필드 다섯 개 모두를 예약됨으로 취급하고 이를 기반으로 규칙을 만들지 마십시오. 그런 트래픽이 걱정된다면 IP 조회가 볼 수 있는 것과 볼 수 없는 것에서 설명합니다.
7. 위협 및 봇 인텔리전스(threat)
threat 그룹은 주소가 악성으로 알려져 있는지, 아니면 우호적인 봇으로 알려져 있는지를 묻습니다. 25개 필드가 있으며 그중 7개는 자리표시자입니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (66.249.66.1, Googlebot) |
|---|---|---|---|
| is_abusive | boolean | 악용 중심 위협 피드에 있음 | false |
| is_bogon | boolean | 할당되지 않았거나 예약된 공간 | false |
| is_crawler | boolean | 알려진 크롤러 또는 AI 봇 | true |
| is_spammer | boolean | 알려진 스팸 발신원 | false |
| is_scanner | boolean | 인터넷 전체 스캐너 범위 | false |
| is_botnet | boolean | 봇넷 C2 주소(Feodo Tracker 데이터) | false |
| is_cgnat | boolean | 통신사급 NAT. 점수에 상한이 적용됨 | false |
| threat_types | string[] | 해당하는 모든 위협 카테고리 | [] |
| blocklist_count | number | 예약됨: 의존하지 마십시오 | (표시 안 함) |
| blocklist_sources | string[] | 자리표시자: 현재 채워지지 않음 | (표시 안 함) |
| dnsbl_sources | string[] | 3개의 DNS 차단 목록 영역 중 어디에 등재되었는지 | [] |
| crawler.verified | boolean | 운영자의 공식 IP 범위와 일치함 | true |
| crawler.unverified | boolean | 크롤러처럼 보이지만 공식 범위에는 없음 | false |
| crawler.spoofed | boolean | 자리표시자: 아직 데이터 소스 없음 | (표시 안 함) |
| crawler.name | string | 하이픈 없이 쓴 봇 이름 | Googlebot |
| crawler.operator | string | 봇을 운영하는 주체 | |
| crawler.category | string | 봇 카테고리 | search_engine |
| crawler.verification_method | string | 신원이 확인된 방법 | ip_range_list |
| botnet.role | string | 알려진 경우 봇넷에서의 역할 | none |
| botnet.family | string | 알려진 경우 악성코드 계열 | none |
| botnet.last_seen | string | 자리표시자: 현재 항상 "none" | none |
| honeypot.hits_30d | number | 자리표시자 | (표시 안 함) |
| honeypot.type | string | 자리표시자 | (표시 안 함) |
| honeypot.last_hit | string | 자리표시자 | (표시 안 함) |
| spammer_last_seen | string | 자리표시자: 현재 항상 "none" | none |
Tor 출구는 이 표의 나머지 절반을 채웁니다. is_spammer: true, threat_types: ["spammer", "tor"], dnsbl_sources: ["zen.spamhaus.org"]입니다. Mullvad 서버는 threat_types: ["vpn"]을 반환했으므로 이 배열은 익명화 플래그도 반영합니다.
crawler 객체에 봇 관련 결정이 담겨 있습니다. 66.249.66.1에 대해 API는 verified: true, name: "Googlebot", operator: "Google", verification_method: "ip_range_list"를 반환했으며, 10개 운영자의 공식 크롤러 범위 피드 19개와 대조한 결과입니다. 10월 조회에서 본 카테고리는 search_engine, ai, fetcher입니다. 이름에서는 하이픈이 빠지므로 Google의 사용자 요청형 페처는 GoogleUserTriggeredFetcher로 돌아옵니다.
위조 탐지는 사용자 코드에서 이루어집니다. API는 IP만 보고 User-Agent는 보지 않습니다. Googlebot이라고 주장하지만 crawler.verified: false가 반환되는 요청은 검증되지 않은 것이며, 그 비교는 사용자가 해야 합니다. IP 기반 봇 탐지와 IP, rDNS, CIDR로 AI 크롤러 검증하기에서 방법을 보여 줍니다.
is_cgnat은 결정을 엄격하게 하지 말고 완화해야 합니다. CGNAT 주소는 많은 가입자가 공유하므로 점수에 상한이 적용되며, 한 명의 악성 사용자가 통신사 전체를 차단해서는 안 됩니다. 이 그룹의 배경이 되는 피드는 위협 인텔리전스 개요를 참고하십시오.
8. 역방향 DNS(dns)
dns 그룹은 network의 역방향 DNS 필드 세 개를 반복하므로, rDNS만 필요한 코드는 작은 객체 하나만 읽으면 됩니다. 값은 우리가 가져온 모든 응답에서 network의 사본과 동일합니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (1.1.1.1) |
|---|---|---|---|
| ptr_record | string | 저장된 PTR 호스트 이름 | one.one.one.one |
| ptr_pattern | string | 예약됨: 값을 표시하지 않음 | (표시 안 함) |
| fcrdns_valid | boolean, or "none" | PTR이 이 IP로 다시 해석됨 | true |
신뢰할 만한 것은 fcrdns_valid입니다. 같은 IP로 정방향 해석되는 PTR은 역방향 영역을 제어하는 누구나 설정할 수 있는 PTR 문자열만 있을 때보다 훨씬 강한 증거입니다. 5번 섹션과 같은 주의가 적용됩니다. 저장된 PTR을 인용하기 전에 실시간 dig -x와 비교하십시오.
9. 위험 점수(scoring)
scoring 그룹은 증거를 결정으로 바꿉니다. 필드는 네 개이며, 점수를 감사 가능하게 만드는 것은 detection_methods입니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (185.220.101.1, Tor) |
|---|---|---|---|
| fraud_score | number | 0에서 100까지의 위험 점수, 높을수록 위험 | 100 |
| confidence | number | 판정을 뒷받침하는 증거, 0에서 1 | 0.7402500000000001 |
| recommended_action | string | allow, review, step_up 또는 block | block |
| detection_methods | string[] | 작동한 정확한 신호 | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer |
fraud_score는 36개의 가중 사유를 결합하며, 일부 사유는 점수를 차감합니다. Googlebot이 그 예입니다. datacenter_ip와 verified_crawler가 모두 작동했고 점수는 0이 되었습니다. 릴레이 점수는 상한이 60이므로 릴레이는 block에 도달할 수 없습니다. recommended_action은 점수를 구간에 매핑합니다.
| 점수 | recommended_action | 의미 |
|---|---|---|
| 0~25 | allow | 의미 있는 위험 증거 없음 |
| 26~50 | review | 일부 신호 작동. 기록하고 지켜볼 것 |
| 51~75 | step_up | 상당한 증거. 챌린지를 추가할 것 |
| 76~100 | block | 여러 신호에서 나온 강한 증거 |
confidence는 문자열이 아니라 숫자로 출력하십시오. 부동소수점 잡음이 그대로 들어옵니다. 모델은 IP 위험 점수 가이드와 각 사유가 점수와 신뢰도를 정하는 방식에서, 임계값을 어디에 둘지는 로그인, 가입, 결제의 IP 위험 점수 임계값 선택에서 설명합니다. IP 위험 점수 확인으로 어떤 주소든 점수를 매길 수 있습니다.
10. 메타데이터(meta)
meta 그룹은 응답의 날짜를 매기고 요청을 식별합니다. 5개 필드 중 둘은 이름이 암시하는 것과 의미가 다릅니다.
| 필드 | 유형 | 알려 주는 내용 | 예시 (104.28.46.99) |
|---|---|---|---|
| last_classified_at | string (ISO 8601) | 이 응답이 만들어진 시점 | 2026-10-22T04:56:51.010Z |
| last_scanned | string (ISO 8601) | 이 IP의 탐지가 마지막으로 바뀐 시점 | 2026-10-20T18:52:36.000Z |
| request_id | string | 이 조회의 고유 ID. 지원 문의 시 인용 | aa25852e-0dc1-4fd6-8780-3b9283d13aba |
| latency_ms | number | 서버 측 처리 시간 | 3 |
| sources | string[] | 자리표시자: 현재 항상 [] | [] |
last_classified_at은 분류 시점이 아니라 응답 시점입니다. 일곱 번의 조회 모두에서 요청을 보낸 시점으로부터 약 1초 이내였습니다. 최신성은 last_scanned로 판단하십시오. 모든 응답에서 detection.last_seen과 같은 값이었고, 일곱 개 모두 10월 20일자였습니다.
오래된 IP 데이터는 틀린 IP 데이터입니다. 범위는 주인이 바뀌기 때문입니다. 분류가 틀렸다고 생각될 때 인용하는 것이 request_id입니다. 지연 시간은 일곱 번의 조회에서 서버 측 기준 0에서 3ms였습니다.
다른 제공업체는 같은 필드를 어떻게 부르는가
다른 IP 데이터 제공업체도 겹치는 영역을 다루지만 필드 이름이 다르며, 일부는 더 풍부한 필드를 상위 플랜에 둡니다. 2026년 10월 22일에 세 제공업체의 공개 문서를 읽고 그 페이지가 명시한 내용만 남겼습니다.
| 제공업체 | 문서화된 필드 | 문서의 설명 | 가장 가까운 GeoIPHub 필드 |
|---|---|---|---|
| MaxMind | location.accuracy_radius | 좌표 주변의 "대략적인 정확도 반경(킬로미터)" | geo.geo_confidence (0에서 1, 반경 없음) |
| MaxMind | traits.user_type | consumer_privacy_network, content_delivery_network, search_engine_spider를 포함한 15개 값 | asn.user_type. 우리 조회에서 같은 세 문자열을 반환함 |
| MaxMind | anonymizer object | 익명화 플래그를 traits에서 provider_name을 포함한 하나의 객체로 이동 | detection.vpn_provider |
| IPinfo | vpn, proxy, tor, relay, hosting, service | service는 "VPN, 프록시 또는 익명화 서비스의 이름" | detection.is_* 플래그, vpn_provider, relay_provider |
| IPinfo | 플랜별 커버리지 | Core는 is_anonymous와 is_hosting만 포함. Plus와 Max는 /anonymous 엔드포인트 사용 | 모든 플랜에서 모든 필드 |
| IPinfo | asn.type | 예시: isp, business, hosting, education | asn.asn_type |
| IPQualityScore | fraud_score | IP, 사용자 에이전트, 언어 및 기타 선택 입력으로 구성. 75 이상은 의심, 90 이상에서 플래그 또는 차단을 제안 | scoring.fraud_score, IP만으로 산출. 75 초과에서 block |
| IPQualityScore | is_crawler | 호스트 이름 또는 IP로 검증된, 확인된 검색 엔진 크롤러 | threat.crawler.verified, 공식 IP 범위 기반 |
| IPQualityScore | connection_type | Residential, Corporate, Education, Mobile 또는 Data Center | asn.connection_type |
출처: MaxMind GeoIP 웹 서비스 응답, IPinfo 프라이버시 탐지 데이터, IPinfo ASN 데이터, IPQualityScore 프록시 탐지 응답 매개변수.
두 가지 실용적인 점이 따라옵니다. 점수의 척도는 문서화된 임계값과 함께 볼 때만 의미가 있습니다. IPQualityScore의 75는 "의심"이지만 우리의 76은 이미 block입니다. 그리고 이름이 같은 필드도 다른 뜻일 수 있으므로, 이름이 아니라 문서화된 의미로 필드를 매핑하십시오. IP 데이터 제공업체 선택을 위한 구매자 체크리스트는 이를 어떤 API에든 실행할 수 있는 짧은 테스트로 정리합니다.
결정별로 중요한 IP 데이터 필드
103개 필드가 한꺼번에 필요한 경우는 드뭅니다. 결정에 맞는 필드를 고르고 자리표시자는 건너뛰십시오.
| 사용 사례 | 가장 중요한 필드 | 주의할 점 |
|---|---|---|
| 로그인 또는 결제 시 사기 검사 | scoring.fraud_score, recommended_action, detection_methods, detection.is_vpn, is_tor, is_proxy | geo만으로 즉시 차단하지 마십시오. is_cgnat이 점수에 상한을 두는 데는 이유가 있습니다 |
| 지역 규정 준수 및 라이선스 | geo.country_code, geo.region, detection.is_relay | 도시는 대략적임. 릴레이의 geo는 Apple의 목록과 다를 수 있음 |
| 봇 및 크롤러 관리 | threat.crawler.verified, crawler.name, crawler.category | 주장된 User-Agent와 직접 비교하십시오. crawler.spoofed는 자리표시자 |
| 악용 신고 및 조사 | network.abuse_contact, whois.netname, threat.dnsbl_sources | 인용하기 전에 저장된 PTR을 dig로 확인하십시오 |
| 현지화 | geo.country_code, geo.timezone | timezone은 "none"일 수 있음. 애니캐스트 IP에서 geo_confidence는 참고용 힌트 |
조사에서는 필드만큼이나 그룹을 읽는 순서가 중요합니다. IP 주소 조사 단계별 가이드는 실제 IP 세 개를 이 그룹들을 차례로 사용하는 열두 가지 수동 점검으로 안내합니다.
개발하기 전에 필드를 직접 확인하십시오
필드 목록은 변하므로, 가장 안전한 습관은 직접 세어 보는 것입니다. 조회 한 번을 실행하고 리프 키를 나열하십시오.
curl -s https://api.geoiphub.com/v1/lookup/8.8.8.8 \
-H "x-api-key: YOUR_API_KEY" \
| jq 'del(.geo.country_names)
| [paths(type != "object") | select(all(.[]; type == "string"))]
| length + 1'
이 필터는 각 배열을 하나의 필드로 세고, 배열 요소는 건너뛰며, country_names를 하나의 필드로 다시 더합니다. 저장해 둔 응답 일곱 개 모두에서 103을 출력했습니다. 숫자가 다르다면 키를 API 참조 및 이 글과 비교해 보십시오. 키 없이 테스트한다면 호출 속도를 조절하십시오. 1분 안의 30번째 키 없는 요청은 이미 429를 반환하고 IP를 두 시간 동안 차단합니다.
자주 묻는 질문
IP 주소에서 어떤 데이터를 얻을 수 있습니까?
위치보다 훨씬 많습니다. 2026년 10월 22일의 실제 GeoIPHub 조회는 10개 그룹에 걸친 103개 필드를 반환했습니다. IP 자체, 네트워크(ASN, ISP, 연결 유형, RPKI), 대략적인 지리적 위치, WHOIS 레지스트리 데이터, 네트워크 증거와 역방향 DNS, 목록에 있을 경우 제공업체 이름까지 포함한 VPN, 프록시, Tor, 릴레이 탐지, 위협 및 검증된 크롤러 신호, 설명 가능한 0에서 100까지의 위험 점수, 요청 메타데이터입니다. 이 필드 중 11개는 현재 고정된 빈 값을 반환하는 자리표시자입니다.
IP 주소로 정확한 집 주소를 알 수 있습니까?
아니요. IP 지리적 위치는 대략적인 지역(기껏해야 도시나 지역)을 추정할 뿐이며 도로명 주소나 특정인을 알려 주지 않습니다. 도시 수준의 결과는 부정확하며, 모바일, CGNAT, VPN 연결에서는 더욱 약해집니다. IP만으로 주소 수준의 정확도를 주장하는 쪽은 과장하는 것입니다.
IP 데이터에서 ASN이란 무엇입니까?
Autonomous System Number는 IP 주소를 인터넷에 알리는 네트워크를 식별합니다. 예를 들어 8.8.8.8은 AS15169, GOOGLE - Google LLC를 반환합니다. ASN과 해당 조직은 전역 라우팅 테이블에서 나오므로, 물리적 위치에 대한 추측과 달리 가장 신뢰할 만한 IP 데이터 필드에 속합니다.
IP 위험 점수란 무엇이며 어떻게 계산됩니까?
IP 위험 점수는 주소가 얼마나 위험해 보이는지를 요약하는 0에서 100까지의 단일 숫자입니다. GeoIPHub는 36개의 가중 사유를 결합하고 검증된 크롤러 같은 면책 사유를 차감하여, 작동한 정확한 방법과 권장 조치를 반환합니다. 25까지는 allow, 50까지는 review, 75까지는 step_up, 75 초과는 block입니다. 2026년 10월 22일에 조회한 Tor 출구는 네 가지 방법이 나열되며 100점을 받았습니다.
레지덴셜 IP와 데이터센터 IP의 차이는 무엇입니까?
레지덴셜 IP는 소비자용 ISP가 가정 회선에 할당한 것이고, 데이터센터(호스팅) IP는 클라우드나 서버 제공업체의 것입니다. 이 구분은 asn.connection_type과 asn.asn_type 필드에 있습니다. 10월에 조회한 7건 중 Mullvad VPN 서버, Tor 출구, Googlebot은 모두 connection_type이 datacenter로 반환되었습니다.
모든 IP API 제공업체가 모든 플랜에서 같은 필드를 반환합니까?
아니요. IPinfo 문서에 따르면 Core 플랜에는 is_anonymous와 is_hosting 프라이버시 플래그만 포함되며, 더 충실한 프라이버시 필드는 Plus, Max, 맞춤형 API에 있습니다. GeoIPHub는 하루 1,500회 조회의 무료 플랜을 포함한 모든 플랜에서 모든 필드를 반환합니다.
IP 지리적 위치에서 정확도 반경은 무엇을 의미합니까?
정확도 반경은 반환된 좌표를 중심으로 실제 위치가 있을 가능성이 높은 거리(킬로미터)입니다. MaxMind는 이를 location.accuracy_radius로 문서화합니다. GeoIPHub는 반경을 반환하지 않고, 도시를 판단할 증거가 충분하지 않으면 0이 되는 0에서 1 사이의 값인 geo.geo_confidence를 반환합니다.
GeoIPHub API를 만드는 팀
GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.


