IP 인텔리전스VPN 업체가 직접 공개한 서버 목록으로 IP 뒤의 VPN 제공업체 식별하기
VPN 제공업체가 공개하는 서버 목록과 IP를 대조해 그 뒤의 VPN 제공업체를 식별합니다. 우리가 조회한 어떤 IP에서도 WHOIS는 VPN을 언급하지 않았습니다.
2026년 10월 13일 05:22 UTC에 Mullvad의 릴레이 목록을 가져왔습니다. 릴레이 566개, WireGuard 서버 553대, 브리지 13개가 들어 있었고, Mullvad가 자사 소유 하드웨어로 표시한 것은 그중 124개뿐이었습니다. 소유 서버 중 하나인 Frankfurt의 185.213.155.73은 WHOIS에 "31173 Services Germany"로 등록되어 있고, 역방향 DNS가 없으며, AS39351이 광고합니다. 그 네트워크 기록 어디에도 "Mullvad"라는 말은 없습니다. 오직 목록만이 알려 줍니다.
이것이 "이 IP는 어떤 VPN인가"를 알려 주는 모든 도구의 핵심 비결이며, 그렇게 말해 주는 도구는 거의 없습니다. 아래에서는 제공업체들이 서버를 공개하는 엔드포인트를 정리하고, 테스트를 거친 Python 매처를 제시하며, 제공업체 목록에 있는 서버를 조회했을 때 우리 API가 반환한 결과를 대조군과 놓친 사례까지 포함하여 보여 드립니다. 마지막은 정책 표로 끝납니다. 탐지 측면, 즉 VPN이 애초에 어떻게 잡히는지는 신호별로 보는 VPN 탐지의 작동 원리를 읽으십시오.
IP 주소가 어떤 VPN에 속하는지 알 수 있습니까?
예, 제공업체가 공개하는 목록에 그 IP가 있을 때 가능합니다. VPN 앱은 연결하기 전에 서버가 어디에 있는지 알아야 하므로 제공업체는 그 목록을 앱에 제공하고, 그 목록 대부분은 공개되어 있습니다. 주소가 어떤 목록에도 없다면 프로브와 호스팅 신호로 VPN이라는 사실은 대개 알 수 있지만 누구의 것인지는 알 수 없습니다.
185.213.155.73을 처음부터 끝까지 추적해 보겠습니다. api.mullvad.net/www/relays/all/에 있는 Mullvad의 목록에는 이 주소의 행이 있으며 hostname은 "de-fra-wg-001", type은 "wireguard", city_name은 "Frankfurt", owned는 true, provider는 "31173"입니다. 마지막 필드는 호스팅 업체이며, 여기서는 Mullvad 자신입니다.
레지스트리는 다른 이야기를 합니다. 05:28 UTC에 연 RIPE의 RDAP 기록은 대역 이름을 NET-31173-185-213-155-0-24로, 등록자를 "31173 Services Germany"로 표시합니다. RIPE whois의 route 객체는 원점 AS를 AS39351로 알려 줍니다. dig -x 185.213.155.73을 실행했으나 아무 응답도 없었습니다.
그다음 05:27 UTC에 우리 API에서 조회했습니다. 아래는 줄인 사본이며 값은 편집하지 않았습니다.
{
"ip": "185.213.155.73",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB"
},
"whois": {
"org": "31173 Services AB infrastructure in Frankfurt, DE.",
"netname": "NET-31173-185-213-155-0-24",
"has_vpn_keywords": false
},
"detection": {
"is_vpn": true,
"vpn_provider": "Mullvad",
"vpn_confidence": 95
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "wireguard_open", "datacenter_with_vpn_proxy", "no_ptr_datacenter"]
}
}
whois.has_vpn_keywords를 보십시오. Mullvad 서버인데도 false이며, 우리가 조회한 모든 주소에서 false였습니다. WHOIS 텍스트는 VPN을 전혀 언급하지 않습니다. "Mullvad"라는 이름은 목록 대조에서 나왔고, vpn_confidence 95는 그 경로에 대해 우리 API가 부여하는 값입니다. block은 증거에서 나왔습니다. 호스팅 주소 위에서 WireGuard로 태그된 제공업체 목록 항목입니다.
WHOIS, 역방향 DNS, ASN이 VPN이 아니라 호스트의 이름을 알려 주는 이유
대부분의 VPN 서버는 임대한 머신 위에서 돌아가므로, 네트워크 기록은 집주인을 설명합니다. 우리 표본에서 M247(AS9009)은 NordVPN, PIA, AirVPN, IVPN, FastestVPN의 목록 서버를 호스팅합니다. Datacamp(AS212238)는 Mullvad의 New York 서버 하나와 IVPN의 Buenos Aires 서버 하나를 호스팅합니다. "M247이면 VPN"이라는 규칙은 호스팅 업체에 대한 추측입니다. 제공업체의 목록은 서버에 대한 증거입니다.
Mullvad가 이 점을 대신 입증해 줍니다. Mullvad의 목록은 모든 릴레이를 owned true 또는 false로 표시하고 provider에 호스트의 이름을 적습니다. 10월 13일 기준으로 566개 릴레이 중 124개가 owned: true였고, 가장 흔한 호스트는 DataPacket(128개 릴레이), Tzulo(127개), M247(98개)이었습니다. 05:33 UTC에 임대한 Mullvad 릴레이 두 개를 조회했습니다.
| 목록상의 Mullvad 릴레이 | 목록의 호스트 | 우리의 asn.org | vpn_provider, vpn_confidence | 점수, 조치 |
|---|---|---|---|---|
| 149.22.83.2, ar-bue-wg-001, owned false | DataPacket | CDNEXT - Datacamp Limited | Mullvad, 95 | 99, block |
| 91.90.123.2, be-bru-wg-101, owned false | M247 | M247 - M247 Europe SRL | Mullvad, 95 | 100, block |
둘 중 어느 쪽이든 ASN 검사는 "호스팅 업체"라고 말합니다. 목록은 Mullvad라고 말합니다. New York 릴레이 us-nyc-wg-301, 143.244.47.65도 Datacamp 위에서 같은 이야기를 합니다.
역방향 DNS는 더 약합니다. 05:28 UTC에 제공업체 목록에 있는 주소 20개에 dig -x를 실행했습니다. 11개는 아무것도 반환하지 않았고, 나머지 9개 중 VPN 브랜드를 이름에 담은 것은 하나도 없었습니다.
| IP | 목록 게시자 | dig -x가 반환한 값 |
|---|---|---|
| 143.244.47.65 | Mullvad | unn-143-244-47-65.datapacket.com |
| 149.22.83.100 | IVPN | unn-149-22-83-100.datapacket.com |
| 198.44.137.44 | Windscribe | static-198-44-137-44.cust.tzulo.com |
| 204.13.164.252 | Riseup | leapgwv6.bitmask.net |
| 185.244.212.69 | IVPN | 185.244.212.69.adsl.inet-telecom.org |
| 185.213.155.73 | Mullvad | no PTR |
Riseup의 이름은 브랜드가 아니라 VPN 소프트웨어인 LEAP과 Bitmask를 암시합니다. IVPN Vienna의 이름에는 "adsl"이 들어 있어 가정용 회선처럼 읽히는데, 이는 IVPN이 목록에 올린 서버입니다. PTR을 지나치게 해석하면 위험한 이유입니다.
ASN이 VPN의 이름을 알려 주는 것은 Mullvad가 AS39351로, Riseup이 AS16652로 그렇게 하듯 제공업체가 자체 네트워크를 운영하는 경우뿐입니다. 배경이 필요하면 ASN이 무엇이며 누구의 이름을 알려 주는지를 참고하십시오. 우리 API는 VPN 제공업체가 운영하는 네트워크의 짧은 표를 보유하고 있으며 거기에는 Mullvad의 AS39351이 들어 있습니다. 이 표가 아래 네 가지 명명 경로 중 하나입니다.
VPN 제공업체가 서버 IP를 공개하는 곳
다음은 제공업체 자체 앱이 읽는 목록입니다. "오늘 가져옴"은 우리 네트워크가 2026년 10월 13일에 200 응답을 받았다는 뜻이고, "오늘은 접근 불가"는 두 번 시도한 뒤 우리 네트워크에서 요청이 실패했다는 뜻입니다.
| 제공업체 | 앱이 읽는 목록 | IP가 있는 위치 | 2026년 10월 13일 상태 |
|---|---|---|---|
| Mullvad | api.mullvad.net/www/relays/all/ | ipv4_addr_in, ipv6_addr_in | 오늘 가져옴, 05:22 UTC: 릴레이 566개, 소유 124개 |
| AirVPN | airvpn.org/api/status/ | ip_v4_in1부터 ip_v4_in4까지 | 오늘 가져옴, 05:22 UTC: 서버 250대 |
| IVPN | api.ivpn.net/v5/servers.json | WireGuard 및 OpenVPN host 항목 | 오늘 가져옴, 05:22 UTC: 59개 위치의 WireGuard 호스트 89개 |
| PrivadoVPN | privadovpn.com/apps/servers_export.json | ip | 오늘 가져옴, 05:22 UTC: 서버 167대 |
| Riseup | api.black.riseup.net/3/config/eip-service.json, riseup.net/provider.json을 통해 확인 | ip_address | 오늘 가져옴, 05:23 UTC: 게이트웨이 21개 |
| NordVPN | api.nordvpn.com/v2/servers, gluetun의 NordVPN 업데이터 기준 | station | 오늘은 접근 불가 (시간 초과) |
| Surfshark | api.surfshark.com/v4/server/clusters, gluetun의 Surfshark 업데이터 기준 | 호스트명만 제공 | 오늘은 접근 불가 (TLS 오류 후 시간 초과) |
| Private Internet Access | serverlist.piaservers.net/vpninfo/servers/v6, PIA 자체 get_region.sh 기준 | 지역별 서버 IP | 오늘은 접근 불가 (TLS 오류) |
| Windscribe | assets.windscribe.com/serverlist/mob-v2/1/, gluetun의 Windscribe 업데이터 기준 | ip, ip2, ip3 | 오늘은 접근 불가 (시간 초과) |
접근하지 못한 네 곳도 실재하는 엔드포인트입니다. 제공업체의 공식 클라이언트나 오픈소스 클라이언트를 통해 알고 있으며, gluetun의 NordVPN 코드에는 station 필드가 "아마도 진입 IP 주소인 것 같다"는 주석까지 있습니다. 이들 API는 우리 스캐너가 실행되는 데이터센터의 요청을 차단하며, 10월 13일에는 이 글을 위해 사용한 네트워크에도 응답하지 않았습니다.
그래서 우리 API는 제공업체 자체의 서버 목록과 공개된 제3자 목록을 합쳐 VPN의 이름을 확인합니다. NordVPN, PIA, Windscribe의 경우 우리 스캐너는 2026년 10월 4일자로 저장해 둔 API 응답 사본으로 대체합니다. Surfshark 사본은 보유하고 있지 않습니다. 제3자 목록은 오픈소스 VPN 클라이언트 컨테이너인 gluetun 뒤에서 커뮤니티가 관리하는 서버 데이터인 gluetun-servers입니다. 우리는 20개가 넘는 제공업체의 파일을 불러오며, FastestVPN은 이것이 유일한 출처입니다. 오늘 가져온 네 개의 파일, 즉 ExpressVPN, FastestVPN, NordVPN, PIA는 모두 2026년 8월 6일자 타임스탬프를 갖고 있습니다.
IP로 VPN 제공업체를 직접 식별하기: Mullvad와 NordVPN
제공업체의 목록을 내려받아 주소와 정확히 일치하는 항목을 찾으십시오. Mullvad는 요청할 때마다 목록이 응답했으므로 쉬운 경우입니다. 다음은 2026년 10월 13일 05:29 UTC에 Python 3.9.6에서 표준 라이브러리만으로 실행한 스크립트입니다.
"""Check IPs against Mullvad's public relay list. Standard library only."""
import ipaddress, json, sys, urllib.request
URL = "https://api.mullvad.net/www/relays/all/"
def load_relays(url=URL):
with urllib.request.urlopen(url, timeout=30) as resp:
relays = json.load(resp)
index = {}
for r in relays:
for key in ("ipv4_addr_in", "ipv6_addr_in"):
if r.get(key):
index[ipaddress.ip_address(r[key])] = r
return relays, index
def match(index, ip):
try:
addr = ipaddress.ip_address(ip.strip())
except ValueError:
return None
if addr.version == 6 and addr.ipv4_mapped:
addr = addr.ipv4_mapped # ::ffff:141.98.252.67 becomes 141.98.252.67
return index.get(addr)
if __name__ == "__main__":
try:
relays, index = load_relays()
except Exception as e:
sys.exit(f"could not load Mullvad's list: {e}")
print(f"{len(relays)} relays, {len(index)} addresses")
ips = sys.argv[1:] or [line for line in sys.stdin if line.strip()]
for ip in ips:
r = match(index, ip)
if r:
result = f"{r['hostname']} {r['type']} {r['city_name']} owned={r['owned']} host={r['provider']}"
else:
result = "not on Mullvad's list"
print(f"{ip.strip():22} {result}")
명령줄에 입력 일곱 개를 전달했고 다음과 같이 출력되었습니다.
566 relays, 1122 addresses
185.213.155.73 de-fra-wg-001 wireguard Frankfurt owned=True host=31173
143.244.47.65 us-nyc-wg-301 wireguard New York, NY owned=False host=DataPacket
45.83.220.68 se-mma-wg-101 wireguard Malmö owned=True host=31173
45.83.220.7 not on Mullvad's list
::ffff:141.98.252.67 gb-lon-wg-001 wireguard London owned=True host=31173
102.129.235.17 not on Mullvad's list
not-an-ip not on Mullvad's list
로그 열을 넘기듯 빈 줄과 공백이 섞인 세 줄을 stdin으로도 전달했고, 45.83.220.70이 se-mma-wg-103과 일치했습니다. 404를 반환하는 URL을 지정하면 "could not load Mullvad's list: HTTP Error 404: Not Found"를 출력하고 종료 상태 1로 끝납니다. 주의할 점이 두 가지 있습니다. 잘못된 입력은 오류가 아니라 목록에 없는 것으로 보고되며, 브리지 13개도 함께 매칭되므로 type 열을 읽어야 합니다.
NordVPN도 같은 방식으로 탐지하는 방법. NordVPN의 목록은 각 서버의 IP를 station 필드에 담고 있으며, 10월 4일에 저장한 사본에는 서버마다 하나씩 있습니다. 라이브 엔드포인트는 10월 13일에 우리 네트워크에서 두 번 시간 초과되었으므로, 실행해 보지 못한 NordVPN 코드는 공개하지 않습니다. NordVPN이 응답하는 네트워크에서 같은 정확 일치 로직을 실행하십시오.
주소를 하나씩 확인하려면 아무 IP나 VPN 여부와 제공업체를 확인할 수 있으며, 이 도구는 detection.vpn_provider에 이름을 반환합니다. 코드에서는 경로에 IP를 넣은 요청 한 번입니다.
curl https://api.geoiphub.com/v1/lookup/185.213.155.73 \
-H "x-api-key: YOUR_API_KEY"
vpn_provider는 무료 플랜에 포함되어 있으며, 무료 플랜은 모든 데이터 필드를 하루 1,500건 조회까지 제공합니다. 이름을 키로 무언가를 만든다면 문자열 전체가 아니라 시작 부분을 일치시키십시오. 우리 API는 목록에 있는 서버에는 "Mullvad"를, ASN 경로에는 "Mullvad (31173 Services)"를 반환했습니다. 다음은 05:34 UTC에 키 없이 실행한 스니펫입니다.
import json, sys, urllib.request
def lookup(ip, key=None):
# A custom User-Agent: our API answered Python's default one with a 403.
headers = {"User-Agent": "vpn-provider-check/1.0"}
if key:
headers["x-api-key"] = key
req = urllib.request.Request(f"https://api.geoiphub.com/v1/lookup/{ip}", headers=headers)
with urllib.request.urlopen(req, timeout=10) as resp:
return json.load(resp)
for ip in sys.argv[1:]:
data = lookup(ip)
provider = data["detection"]["vpn_provider"]
named = provider != "none"
is_mullvad = provider.startswith("Mullvad") # "Mullvad" or "Mullvad (31173 Services)"
print(ip, repr(provider), "named" if named else "unnamed",
"mullvad" if is_mullvad else "-", "is_vpn" if data["detection"]["is_vpn"] else "not_vpn",
data["scoring"]["recommended_action"])
185.213.155.73 'Mullvad' named mullvad is_vpn block
45.83.220.7 'Mullvad (31173 Services)' named mullvad is_vpn review
102.129.235.17 'none' unnamed - is_vpn block
세 번째 줄이 설계의 기준으로 삼아야 할 경우입니다. 이름은 없지만 여전히 VPN이고, 여전히 block입니다.
반대로 자신의 연결이 NordVPN으로 보이는지 묻는 경우라면, 연결한 상태에서 내 연결이 보여 주는 IP 확인을 여십시오.
제공업체 목록에 있는 IP에 대해 우리 API가 반환한 결과
우리가 표본으로 삼은 모든 제공업체의 목록 서버는 이름이 확인되어 반환되었고, vpn_confidence는 네 가지 경로 중 어느 것이 이름을 밝혔는지 알려 줍니다. 이름이 확인된 행에서 이 값은 경로에 대응합니다.
| vpn_confidence | IP의 이름을 밝힌 경로 |
|---|---|
| 95 | 제공업체 자체의 서버 목록 |
| 90 | gluetun 파일의 서버 호스트명을 우리가 이 IP로 확인한 것 |
| 85 | VPN 제공업체가 운영하는 네트워크의 짧은 표 |
| 80 | 공개 gluetun 서버 목록 |
이 조회는 2026년 10월 13일 05:27에서 05:28 UTC 사이에 실행했습니다. 마지막 열에는 응답한 VPN 핸드셰이크 프로브만 표시했으며, detection_methods의 나머지는 표에서 뺐습니다.
| IP | 목록상의 제공업체와 서버 | IP를 찾은 위치 | vpn_provider | vpn_confidence | 점수, 조치 | 응답한 프로브 |
|---|---|---|---|---|---|---|
| 185.213.155.73 | Mullvad, de-fra-wg-001 | Mullvad, 오늘 가져옴 | Mullvad | 95 | 100, block | wireguard_open |
| 143.244.47.65 | Mullvad, us-nyc-wg-301, owned false | Mullvad, 오늘 가져옴 | Mullvad | 95 | 99, block | wireguard_open |
| 82.102.19.137 | NordVPN, be148 | 10월 4일자 NordVPN 사본, gluetun에도 있음 | NordVPN | 80 | 99, block | wireguard_open |
| 173.239.247.129 | PIA, Vietnam | 10월 4일자 PIA 사본, gluetun에도 있음 | PIA | 80 | 51, step_up | none |
| 198.44.137.44 | Windscribe, Dallas, us-central-117 | 10월 4일자 Windscribe 사본 | Windscribe | 95 | 100, block | ipsec_open, wireguard_open |
| 185.156.175.170 | AirVPN, Achernar, Zurich | AirVPN, 오늘 가져옴 | AirVPN | 95 | 99, block | wireguard_open |
| 149.22.83.100 | IVPN, ar1.wg, Buenos Aires | IVPN, 오늘 가져옴 | IVPN | 95 | 99, block | wireguard_open |
| 85.12.5.56 | PrivadoVPN, hkg-006 | PrivadoVPN, 오늘 가져옴 | PrivadoVPN | 90 | 36, review | none |
| 204.13.164.252 | Riseup, vpn01-sea | Riseup, 오늘 가져옴 | Riseup | 95 | 48, review | none |
| 31.171.152.205 | ExpressVPN, Albania | 8월 6일자 gluetun 파일 | ExpressVPN | 80 | 51, step_up | none |
| 46.102.153.134 | FastestVPN, au-stream, Sydney | 8월 6일자 gluetun 파일 | FastestVPN | 90 | 99, block | wireguard_open |
| 45.83.220.7 | Mullvad의 목록에 없음 | 없음 | Mullvad (31173 Services) | 85 | 46, review | none |
세 개의 행은 설명이 필요합니다. NordVPN과 PIA 서버는 저장해 둔 사본에 있지만 gluetun 값인 80으로 반환되었고, 둘 다 gluetun의 파일에 있습니다. PrivadoVPN 서버는 오늘 PrivadoVPN 자체 내보내기에 있는데도 95가 아니라 90으로 반환되었습니다. 이름이 호스트명 hkg-006.vpn.privado.io를 확인하는 과정에서 나왔기 때문이며, 이 호스트명은 gluetun의 PrivadoVPN 파일에도 들어 있습니다. 경로는 IP를 찾은 목록이 아니라 vpn_confidence에서 읽으십시오. ExpressVPN은 우리가 자체 목록을 가져오는 아홉 개 제공업체에 속하지 않습니다. gluetun에 등재된 ExpressVPN 주소 하나가 이름이 확인되어 반환되었으나, 이는 그 경로가 작동한다는 것을 보여 줄 뿐 우리가 ExpressVPN을 포괄한다는 뜻이 아닙니다.
마지막 행은 ASN 경로입니다. 45.83.220.7은 Mullvad의 목록에 없습니다. 오늘 목록에는 그 /24에 .7이 아니라 .68, .69, .70이 있습니다. 이 주소의 이름이 확인된 것은 네트워크인 AS39351이 Mullvad의 운영사에 속하기 때문입니다.
{
"ip": "45.83.220.7",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB"
},
"whois": {
"org": "31173 Services AB infrastructure in Malmo, SE.",
"netname": "NET-31173-45-83-220-0-24",
"has_vpn_keywords": false
},
"detection": {
"is_vpn": true,
"vpn_provider": "Mullvad (31173 Services)",
"vpn_confidence": 85
},
"scoring": {
"fraud_score": 46,
"recommended_action": "review",
"detection_methods": ["known_vpn_server", "datacenter_ip"]
}
}
여기서도 known_vpn_server가 작동한다는 점에 유의하십시오. 이 방식 이름은 "제공업체의 목록에 있음"을 뜻하지 않으며, 이 행에서는 네트워크 표에서 나왔습니다. 경로는 vpn_confidence에서 읽되, vpn_provider가 "none"이 아닌 행에서만 읽으십시오.
일부 VPN IP가 "none"으로 반환되는 이유
"none"은 그 IP가 우리가 현재 보유한 어떤 목록에도 없다는 뜻입니다. 그 IP가 VPN이 아니라는 뜻도, 제공업체의 인접 주소가 깨끗하다는 뜻도 아닙니다.
NordVPN의 서버 pl128, 194.99.105.99는 10월 4일에 저장한 NordVPN 응답에 온라인으로 등재되어 있습니다. 오늘은 vpn_provider가 "none"으로 반환되었지만 is_vpn은 true, 점수 98, block이었고 방식 중에 ipsec_open이 있었습니다. 이 주소를 잡아낸 것은 IPsec 핸드셰이크이며, 이름을 밝힌 것은 아무것도 없었습니다. PIA의 Liechtenstein 서버 91.90.122.25는 같은 날 PIA의 목록에 있습니다. 오늘은 is_vpn이 false이고 점수는 64, step_up으로 반환되었으며, 차단 목록과 호스팅 신호만으로 나온 결과입니다.
이 두 주소는 모두 gluetun의 파일에 없지만, 위에서 이름이 확인된 NordVPN과 PIA 행은 둘 다 있습니다. 오늘은 NordVPN이나 PIA의 API를 다시 가져올 수 없었으므로, 10월 4일 이후 어느 서버든 폐기되었거나 주소가 바뀌었을 수 있습니다. 더 좁지만 확실하게 말할 수 있는 것은 이렇습니다. 서버의 이름이 확인되는 것은 우리가 현재 보유한 목록에 있을 때뿐입니다.
오늘 목록을 가져온 제공업체에서도 놓친 사례가 있습니다. 91.90.123.29는 목록에 있는 Mullvad 릴레이 91.90.123.2와 같은 /24에 있지만 Mullvad의 목록에는 없습니다. IPinfo의 제공업체 페이지는 10월 13일에 이 주소를 Mullvad 예시 IP로 보여 주었습니다. 우리 API는 is_vpn false, vpn_provider "none", 점수 12, allow를 반환했습니다. 이 주소는 출구이거나 목록에 있는 주소 옆의 미등재 주소일 수 있으며, 이는 정황일 뿐 증거는 아닙니다. 어느 쪽이든 목록 대조는 목록에 있는 주소만 다루며 그 옆의 주소는 다루지 않습니다.
문서화된 대조군은 이름은 없지만 탐지는 된 경우를 보여 줍니다. AS834 IPXO에 있는 102.129.235.17은 is_vpn true, vpn_provider "none", 점수 92, block을 반환했고 known_vpn_server, openvpn_open, ipsec_open이 작동했습니다. 이름 없는 서버도 우리 스캐너와 OpenVPN이나 IPsec 핸드셰이크를 완료하면 여전히 잡힙니다. 프로브는 위에 링크한 허브 글에서 다룹니다.
VPN IP가 이름 없이 남는 흔한 이유는 다음과 같습니다.
- 공개 목록이 없음. 일부 제공업체는 목록을 전혀 공개하지 않으며, 자체 호스팅 VPN은 어떤 목록에도 나타나지 않습니다.
- 목록에 접근할 수 없음. 우리가 가져오는 아홉 개 목록 중 네 개는 데이터센터를 차단하므로, 사본이 있으면 사본으로, 없으면 gluetun으로 작업합니다.
- 교체. 서버가 우리의 마지막 사본 이후 목록에서 빠지거나 주소를 바꿀 수 있습니다.
- VPN이 아니라 프록시임. 프록시에는 대조할 제공업체 목록이 없습니다. 데이터센터, 주거용, 모바일 프록시를 참고하십시오.
iCloud Private Relay와 Cloudflare WARP는 이 의미에서 VPN 제공업체가 아닙니다. 별도의 필드인 relay_provider와 별도의 정책이 적용되며, 이는 iCloud Private Relay와 Cloudflare WARP에서 다룹니다.
이름이 확인된 VPN이 더 위험한 VPN은 아닙니다
이름은 누가 서버를 운영하는지를 알려 주고, 점수는 열린 핸드셰이크 포트, 호스팅, 악용 이력 같은 증거에서 나옵니다. 우리 표본에서 가장 낮은 점수 몇 개는 이름이 확인된 서버에 돌아갔고, 가장 높은 점수 중 하나는 이름 없는 서버에 돌아갔습니다.
| IP | vpn_provider | 점수, 조치 |
|---|---|---|
| 85.12.5.56 | PrivadoVPN | 36, review |
| 45.83.220.7 | Mullvad (31173 Services) | 46, review |
| 204.13.164.252 | Riseup | 48, review |
| 102.129.235.17 | none | 92, block |
우리의 구간은 25까지 allow, 50까지 review, 75까지 step_up, 75 초과는 block입니다. PrivadoVPN의 서버는 우리 데이터에서 어떤 핸드셰이크 프로브에도 응답하지 않았으므로 known_vpn_server만 작동했고 review에 머물렀습니다. 이름 없는 서버는 두 개에 응답했습니다. 이것이 올바른 방향입니다. 규칙은 서버에 누구의 로고가 붙어 있는지가 아니라 우리가 관찰한 것에 가중치를 두어야 합니다. 신호 가중치는 점수가 만들어지는 방식 페이지에 있습니다.
진입 IP, 교체된 서버, 오래된 이름
제공업체 목록은 앱이 연결하는 주소를 알려 줍니다. 우리 표본의 대부분의 서버에서는 그 같은 주소가 우리 프로브에 응답했지만, 우리가 검증한 것은 목록에 있는 주소의 이름이 확인된다는 점뿐이며 제공업체가 사용하는 모든 출구 주소가 목록에 있다는 것은 아닙니다.
필드 이름에 "in"이 들어 있습니다. Mullvad는 ipv4_addr_in을 사용하고, AirVPN은 서버당 네 개의 주소를 ip_v4_in1부터 ip_v4_in4까지로 공개합니다. Surfshark의 목록은 호스트명만 제공하므로 무언가를 대조하려면 누군가 이름을 IP로 확인해야 합니다. 우리의 90 경로는 gluetun 파일의 서버 호스트명에 대해 이를 수행합니다. FastestVPN의 au-stream.jumptoserver.com, 46.102.153.134가 이름을 얻은 방식입니다.
목록에는 읽어야 할 상태 정보도 담겨 있습니다. 오늘 Mullvad의 목록은 24개의 릴레이를 active: false로 표시하는데, 여기에는 45.83.220.68인 se-mma-wg-101이 포함되며 우리 API는 이를 여전히 95점으로 "Mullvad"라고 부릅니다. 목록에 있는 서버는 제공업체의 서버 군에 관한 사실이지, 그 서버가 오늘 트래픽을 실어 날랐다는 증거가 아닙니다. 업체마다 VPN IP 개수가 크게 다른 이유도 이것입니다. 서로 다른 날짜에 서버, 목록에 오른 진입 주소, 관찰된 출구 주소, 또는 대역 전체처럼 서로 다른 것을 세기 때문입니다. 우리가 인용하는 개수는 Mullvad 자체의 목록뿐입니다. 제공업체 목록의 갱신 일정은 여기서 공개하지 않습니다. 매처를 직접 실행한다면 배치마다 먼저 목록을 가져오십시오.
제공업체 이름으로 무엇을 할 것인가
이름은 정책과 조사에 사용하고, 차단 스위치로 쓰지 마십시오. 결정은 recommended_action과 그 뒤의 증거에 근거하고, 예외와 보고는 이름에 근거하십시오.
| 보이는 것 | 조치 | 이유 |
|---|---|---|
이름이 확인된 VPN (vpn_provider 설정됨) | recommended_action을 따르고, 직접 선택하는 허용 목록, 라이선스 로그, 운영자별 악용 그룹화에 이름을 사용 | 이름은 귀속이지 위험이 아님: PrivadoVPN은 36점, review였고 Mullvad의 Frankfurt 서버는 100점, block이었음 |
이름 없는 VPN (is_vpn true, vpn_provider "none") | 같은 점수의 이름이 확인된 VPN과 똑같이 취급 | 102.129.235.17은 이름 없이 92점을 받음 |
릴레이 (is_relay true) | 허용하고 세션을 점수화 | 릴레이는 VPN 제공업체가 아니며 relay_provider를 사용함 |
깨끗함 (is_vpn false, 릴레이 아님) | 다른 신호가 작동하지 않으면 허용 | 익명화 도구의 증거가 없음. 다만 PIA의 91.90.122.25처럼 목록에 있던 서버가 빠질 수 있음 |
흔한 실수는 첫 번째 행을 차단 규칙으로 바꾸는 것이며, 그러면 제공업체의 고객이 VPN 탐지 오탐이 됩니다. 이번 주에 직접 로그에서 실행해 볼 두 가지 점검이 있습니다.
- 이름을 키로 삼은 규칙을 찾으십시오. 규칙에서
vpn_provider를 검색하십시오. "제공업체 이름이 확인되면 차단" 같은 규칙은 이름 없는 92점은 통과시키고 이름이 확인된 36점은 차단합니다. 대신 조치와 증거를 키로 삼고, 이름은 접두사로 일치시키십시오. - 로그를 하나의 목록과 대조하십시오. 최근 30일간의 가입 또는 로그인 IP를 Mullvad 매처에 넣고 일치 건수를 세십시오. 그 요청 중 규칙이 거부한 건수와 비교한 다음, IP 조회 도구에서 몇 건을 표본으로 확인해 보십시오.
자주 묻는 질문
IP 주소가 어떤 VPN에 속하는지 알 수 있습니까?
예, 그 IP가 VPN 제공업체가 자사 앱을 위해 공개하는 서버 목록에 있을 때 가능합니다. 어떤 목록에도 없다면 대개 VPN이라는 사실은 알 수 있지만 누구의 것인지는 알 수 없습니다.
NordVPN IP 주소 목록이 있습니까?
NordVPN의 앱은 api.nordvpn.com에서 목록을 읽어 오며, 이 목록은 각 서버의 IP를 station 필드로 제공합니다. 2026년 10월 13일에는 우리 네트워크의 요청에 응답하지 않아 저장해 둔 사본을 사용했습니다.
WHOIS나 역방향 DNS에 VPN 제공업체가 나옵니까?
드뭅니다. 대부분의 VPN 서버는 M247 같은 임대 호스팅 네트워크 위에 있어서 WHOIS와 역방향 DNS에는 호스트 업체의 이름이 나옵니다. Mullvad 자체의 Frankfurt 대역조차 31173 Services 명의로 등록되어 있습니다.
vpn_provider가 none이라는 것은 무슨 뜻입니까?
그 IP가 우리가 보유한 어떤 서버 목록에도 없다는 뜻입니다. 그 IP가 VPN이 아니라는 뜻은 아닙니다. is_vpn과 scoring.detection_methods를 확인하십시오.
이름이 확인된 VPN은 더 높은 위험 점수를 받습니까?
아닙니다. 목록에 있는 PrivadoVPN 서버는 36점, review였고, 이름이 없는 VPN은 92점, block이었습니다. 이름은 누가 서버를 운영하는지를 알려 주고, 점수는 증거에서 나옵니다.
어떤 VPN 제공업체가 서버 목록을 공개합니까?
Mullvad, AirVPN, IVPN, PrivadoVPN, Riseup은 2026년 10월 13일에 우리의 공개 요청에 응답했습니다. NordVPN, Surfshark, PIA, Windscribe는 앱을 위한 목록을 공개하지만 우리 네트워크에서는 응답하지 않았습니다.
GeoIPHub API를 만드는 팀
GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.
사기 방지