본문으로 건너뛰기
IP 인텔리전스

VPN 및 프록시 탐지는 실제로 어떻게 작동하는가: 신호별 해설

VPN 탐지가 실제로 어떻게 작동하는지 설명합니다. 제공업체 목록과 ASN 분석부터 프로토콜 프로빙까지, 최신 VPN·프록시 탐지의 신호를 살펴봅니다.

작성자GeoIPHub 팀게시일읽는 시간20분 분량
바깥에서 탐침 빔이 닿는 빛의 고리 터널, VPN과 프록시 탐지의 작동 방식을 나타냄

사기, 남용, 컴플라이언스를 다루는 팀이라면 결국 같은 질문에 이릅니다. 이 IP 주소는 무언가를 숨기고 있는가? (기본부터 알고 싶다면 VPN이란 무엇이며 VPN 트래픽을 어떻게 탐지하는지부터 읽어 보세요. 이 글은 그 내부 구조를 깊이 다룹니다.) 솔직한 답은 단일 검사로는 알 수 없다는 것입니다. 상용 VPN, 데이터센터 SOCKS 프록시, 봇넷에서 빌린 주거용 프록시, Tor 출구 노드는 네트워크상에서 모두 다르게 보이며(프록시 유형 분석에서 각 계열을 다룹니다), 각각 서로 다른 단순 탐지 방법을 무력화합니다.

이 가이드에서는 실제 운영 수준의 탐지 시스템이 활용하는 신호를 차례로 살펴봅니다. 여기에는 GeoIPHub가 사용하지 않는 두 가지(지연 시간 검사와 행동 모델링)도 포함됩니다. GeoIPHub는 같은 영역을 다루는 일곱 가지 검증 방법군으로 자체 판정을 만듭니다. 각 계층마다 무엇을 볼 수 있고 무엇을 볼 수 없는지, 그리고 결과가 어떻게 합쳐져 실제로 사용하는 응답 필드인 is_vpn, is_proxy, is_residential_proxy, is_tor가 되는지 확인할 수 있습니다.

일부는 튕겨 나오며 구체에 닿는 가느다란 빛줄기, 프로토콜 핸드셰이크 프로브를 나타냄
응답하는 핸드셰이크는 증거이고, 목록의 항목은 주장입니다.

제공업체 서버 목록

가장 신뢰할 수 있는 증거는 가장 직접적인 것입니다. VPN 제공업체는 서버 인프라를 공개합니다. 앱이 연결하려면 엔드포인트 목록이 필요하고, 많은 제공업체가 모든 서버의 호스트 이름과 IP를 나열하는 공식 API나 설정 번들을 제공합니다.

탐지 시스템은 이런 출처를 지속적으로 수집합니다. 어떤 IP가 NordVPN이나 Mullvad의 공개 서버 목록에 나타나면 일치 결과로 제공업체 이름을 알 수 있지만, 이는 정확히 그 IP가 우리가 보유한 목록에 있을 때만 해당합니다. 목록에 없는 서버도 아래의 다른 신호로 잡아낼 수 있으며, 이 경우 이름은 알 수 없는 채로 남습니다. 그래서 좋은 API는 is_vpn: true뿐 아니라 제공업체 이름 자체를 반환할 수 있고, 플래그를 세운 서버에 대해 이름을 반환하지 않을 때도 있습니다.

한계는 커버리지입니다. 공개된 목록은 공개하는 제공업체만 잡아냅니다. 따라서 이 계층은 소비자 VPN 트래픽의 대부분을 차지하는 대형 상용 VPN에 가장 강하고, 개인 또는 자체 호스팅 VPN에는 가장 약합니다.

ASN과 호스팅 인프라

모든 IP는 자율 시스템(AS), 즉 그 IP를 인터넷에 광고하는 네트워크에 속합니다. ASN은 누가 그 네트워크를 운영하는지를 알려 주며, 이는 강력한 사전 정보가 됩니다.

  • AS396982(Google Cloud)가 광고하는 IP는 소파에 앉은 사람이 아니라 거의 확실히 서버입니다.
  • 주거용 ISP(Comcast, Deutsche Telekom, Jio)가 광고하는 IP는 아마도 일반 사용자 회선일 것입니다.
  • VPN 엔드포인트가 있었던 이력이 있는 장거리 호스팅 또는 코로케이션 ASN은 그 대역에 속한 모든 IP의 사전 확률을 높입니다.

데이터센터 탐지만으로도 상당수의 VPN과 프록시를 잡아냅니다. 대부분의 익명화 인프라가 클라우드 서버를 임대하기 때문입니다. 하지만 VPN 엔드포인트와 평범한 웹 서버를 구분하지는 못합니다. 그러려면 다음 계층이 필요합니다.

능동적 프로토콜 프로빙

대부분의 조회용 데이터베이스가 건너뛰는 계층이며, 추측과 검증을 가르는 차이입니다. VPN 서버는 VPN 프로토콜 핸드셰이크에 응답해야 합니다. 그것이 서버의 역할이기 때문입니다. 그래서 탐지 시스템은 문을 두드려 누가 응답하는지 확인할 수 있습니다.

  • OpenVPN은 수신 포트에서 특징적인 TLS 또는 UDP 핸드셰이크에 응답합니다.
  • IKEv2/IPsec은 UDP 500/4500에서 식별 가능한 페이로드로 응답합니다.
  • PPTP와 L2TP는 제어 채널 요청에 응답합니다.
  • SOCKS5와 HTTP 프록시는 각자의 인사(greeting) 절차를 완료합니다.

WireGuard는 예외입니다. 서버는 이미 알고 있는 키에서 첫 메시지가 오지 않으면 침묵을 유지하므로, 외부 프로브로는 확인할 수 없습니다. GeoIPHub의 wireguard_open 방법은 핸드셰이크가 아니라, 해당 서버를 WireGuard로 표시한 제공업체의 공개 서버 목록에서 나옵니다.

어떤 IP가 OpenVPN 핸드셰이크를 완료한다면 그 IP는 OpenVPN을 실행하고 있는 것입니다. 통계적 추론이 필요 없습니다. GeoIPHub는 8개 프로토콜에 걸쳐 프로빙하고 어떤 핸드셰이크가 성공했는지 정확히 기록하므로, is_vpn의 근거는 이름이 붙어 있고 감사할 수 있습니다.

GeoIPHub API
curl -H "x-api-key: YOUR_API_KEY" \ https://api.geoiphub.com/v1/lookup/102.129.235.17
GeoIPHub API
{ "ip": "102.129.235.17", "asn": { "asn": 834, "org": "IPXO - IPXO LLC", "asn_type": "vpn", "connection_type": "datacenter" }, "detection": { "is_vpn": true, "is_proxy": false, "is_tor": false, "is_anonymous": true, "vpn_provider": "none", "vpn_confidence": 100 }, "scoring": { "fraud_score": 92, "recommended_action": "block", "detection_methods": ["known_vpn_server", "openvpn_open", "ipsec_open"] } }

여기서 detection_methods의 openvpn_open과 ipsec_open은 이 주소가 알려진 VPN 서버 데이터와의 일치에 더해 OpenVPN과 IPsec 프로브에 응답했음을 기록합니다. vpn_provider는 여기서 "none"이므로 어떤 브랜드도 지정되지 않았습니다. 판정은 제공업체 라벨이 아니라 이름이 붙은 프로토콜 증거로 뒷받침됩니다.

능동적 프로빙에는 비용이 하나 있습니다. 인프라와 시간이 든다는 점이며, 그래서 요청마다 실행하지 않고 백그라운드에서 지속적으로 실행됩니다. 프로브 결과는 캐시되고 갱신되므로 API는 밀리초 단위로 응답할 수 있습니다.

포트와 서비스 핑거프린트

완전한 핸드셰이크가 불가능한 경우에도 IP의 열린 서비스가 이루는 모양은 정보가 됩니다. 주거용 회선은 보통 아무것도 노출하지 않습니다. VPN 엔드포인트는 작지만 특징적인 포트 집합을 노출합니다. 프록시 팜은 서브넷 전체에 걸쳐 관리 패널, SSH, 프록시 포트를 노출합니다.

서비스 핑거프린팅은 잘못 설정되었거나 브랜드가 없는 익명화 도구도 잡아냅니다. TCP 1080에서 SOCKS 배너로 응답하는 서버는 어떤 목록에 올라 있든 아니든 프록시입니다.

지연 시간과 위치 일관성

지리는 물리 법칙에 흔적을 남깁니다. 어떤 IP가 (등록 데이터상) 상파울루에 있다고 주장하는데, 전 세계 관측 지점에서 측정한 왕복 시간이 암스테르담을 가리킨다면 무언가가 트래픽을 중계하고 있는 것입니다. 지연 시간 기반 검사는 특히 다음에 유용합니다.

  • 위치를 속인 VPN 서버: "브라질" 서버를 내세우지만 실제로는 마이애미에 있는 제공업체.
  • 숨겨진 실제 위치로 트래픽을 전달하는 GRE/터널 릴레이.

이 계층이 단독으로 작동하는 일은 드물지만, 호스팅 신호와 결합하면 강력한 보강 증거가 됩니다.

주거용 프록시의 행동

주거용 프록시는 가장 어려운 유형입니다. 출구 IP가 실제로 가정용 ISP에 속하기 때문입니다. 목록 검사는 통과합니다. ASN 검사도 통과합니다. 프로빙을 해도 아무것도 수신 대기하고 있지 않습니다. "서버"가 누군가의 무료 모바일 앱에 숨겨진 SDK이기 때문입니다.

따라서 탐지는 인프라에서 시간에 따른 행동으로 옮겨 갑니다.

  • 같은 주거용 IP가 알려진 프록시 마켓플레이스 전반에서 출구로 나타남.
  • 있을 법하지 않은 세션 다양성: 가정 IP 하나가 시간당 수십 개의 기기 핑거프린트를 제시함.
  • DHCP 갱신이 아니라 프록시 네트워크의 로테이션과 일치하는 교체 패턴.
  • ISP 유형 불일치: 이동통신사 IP가 지속적으로 데이터센터 수준의 요청량을 만들어 냄(모바일 프록시 식별 가이드에서 통신사 IP가 특수한 경우인 이유를 다룹니다).

주거용 출구에 is_proxy와 별도의 필드를 두는 이유가 여기에 있습니다. 증거의 종류가 다르고, 적절한 대응도 다르기 때문입니다. IP 조회로 여기서 무엇을 볼 수 있는지는 분명히 해 두어야 합니다. GeoIPHub의 is_residential_proxy는 프록시 네트워크 구성원임을 직접 관찰한 것이 아니라 ASN에 기반한 대략적인 추론이므로, 증거가 아니라 힌트로 다루세요. 로그에서 가정용 ISP 트래픽이 갑자기 수상해 보인다면 내 트래픽에 주거용 프록시가 이렇게 많은 이유에서 흔한 원인을 짚어 줍니다. 결제 흐름에서의 주거용 프록시 적중은 소비자 VPN 적중보다 훨씬 강한 사기 신호입니다.

Tor 디렉터리 데이터

Tor는 설계상 쉬운 대상입니다. Tor 네트워크는 릴레이와 출구 노드의 합의(consensus) 정보를 공개하며 이를 계속 갱신합니다. 공개된 출구 목록을 대조하면 is_tor를 거의 완벽한 정확도로 판별할 수 있으며, 단 하나 주의할 점은 시점입니다. 출구 노드는 참여했다 떠나므로, 디렉터리는 매주가 아니라 촘촘한 주기로 다시 수집해야 합니다.

프라이버시 릴레이는 정반대의 경우입니다. Apple은 모든 iCloud Private Relay 출구 주소를 공개하므로 릴레이 역시 정확히 일치시킬 수 있지만, 릴레이 자체만으로는 차단 목록이 아니라 allow에 해당합니다. 두 릴레이와, Cloudflare가 WARP 출구 목록을 공개하지 않는 이유는 iCloud Private Relay 및 Cloudflare WARP 탐지에서 다룹니다.

신호 간 신뢰도

마지막 계층은 병합입니다. 앞선 각 계층은 신뢰도 특성이 서로 다른 증거를 만들어 냅니다.

신호 계층탐지 대상작동 시 신뢰도사각지대
제공업체 목록상용 VPN매우 높음(제공업체 특정 가능)개인 VPN
ASN / 호스팅데이터센터 익명화 도구중간(증거가 아닌 사전 정보)주거용 출구
능동적 프로빙실행 중인 VPN/프록시 데몬매우 높음(검증됨)SDK 기반 프록시
포트 핑거프린트브랜드 없는 프록시높음방화벽으로 막힌 엔드포인트
지연 시간 검사위치를 속이는 릴레이중간가까운 곳의 릴레이
행동 모델주거용 프록시중간~높음갓 생긴 IP
Tor 디렉터리출구 노드거의 확실브리지

방어 가능한 판정은 이들을 함께 저울질합니다. 중간 신뢰도 신호 하나가 불리언을 뒤집어서는 안 되며, 독립적인 고신뢰도 신호 두 개라면 뒤집을 수 있습니다. 따라서 탐지 API에서 기대해야 할 출력은 세 가지입니다. 라우팅 결정을 위한 불리언, 감사 가능성을 위한 이름이 붙은 탐지 방법, 그리고 신호들이 얼마나 서로를 뒷받침하는지를 나타내는 위험 점수입니다. 이름이 붙은 방법은 잘못 플래그가 세워진 사용자에게도 필요합니다. 내 IP가 VPN이나 프록시로 플래그되는 이유 해설에서는 실제 주소를 대상으로 이를 읽어 봅니다.

VPN 탐지 활용하기: 조합으로 라우팅하세요

실무에서 기억할 세 가지입니다.

  1. is_vpn만으로 차단 목록을 만들지 마세요. 결제 고객 중에도 소비자 VPN을 쓰는 사람이 많습니다(실제 고객을 돌려보내지 않고 익명화 트래픽을 플래그하는 방법 참고). 조합으로 라우팅하세요. VPN + 데이터센터 + 남용 이력은 VPN 단독과는 전혀 다른 상황입니다.
  2. 주거용 프록시 신호에는 높은 가중치를 두되, 추론된 값임을 염두에 두세요. 개인정보 보호를 위해 주거용 출구를 빌리는 사람은 없습니다. 정상적인 사용 비율은 VPN에 비해 극히 작습니다. 다만 IP 수준의 주거용 플래그는 대략적인 추론이므로, 자체 세션 신호와 함께 사용하세요.
  3. 정적 목록보다 검증된 탐지를 선호하세요. 어떤 벤더에게든 IP가 VPN임을 어떻게 아는지 물어보세요. 답이 "라이선스를 받은 데이터베이스"라면 그 데이터는 이미 낡아 가고 있습니다. 능동적 프로빙과 지속적으로 수집되는 제공업체 목록이 인프라의 변화 속도를 따라갑니다.

모든 계층의 출력을 직접 확인할 수 있습니다. 무료 IP 조회 도구에서 아무 IP나 조회하거나 내 VPN 연결을 테스트해 보세요. 가입은 필요하지 않습니다.

자주 묻는 질문

VPN 탐지가 100% 정확할 수 있나요?

아닙니다. 탐지는 확률적입니다. 인프라를 공개하는 상용 VPN은 매우 높은 신뢰도로 탐지되지만, 새 클라우드 IP에서 운영되는 소규모 개인 VPN은 탐지하기 더 어렵습니다. 그래서 좋은 API는 단순한 불리언 값이 아니라 신호별 근거와 신뢰도 수준을 함께 반환합니다.

탐지 관점에서 프록시와 VPN은 어떻게 다른가요?

VPN은 네트워크 계층에서 모든 트래픽을 터널링하며, 보통 서버에서 특정 프로토콜 핸드셰이크(OpenVPN, WireGuard, IKEv2)에 응답합니다. 프록시는 애플리케이션 계층 트래픽(HTTP, SOCKS)을 중계하며 서로 다른 포트와 핑거프린트를 노출합니다. 탐지 시스템은 두 계열을 별도로 프로빙합니다.

주거용 프록시는 왜 탐지하기 그렇게 어려운가요?

출구 IP가 실제로 가정용 ISP에 속해 있어서 목록 기반 검사와 ASN 기반 검사를 통과하기 때문입니다. 따라서 탐지는 행동 증거에 의존합니다. 같은 IP가 프록시 네트워크에 나타나는지, 비정상적인 재사용 패턴이 있는지, ISP 유형과 관찰된 트래픽이 어긋나는지를 봅니다.

사기 방지를 위해 모든 VPN 사용자를 차단하는 것이 합리적인가요?

대체로 그렇지 않습니다. 많은 정상 사용자가 개인정보 보호를 위해 VPN을 통해 접속합니다. 더 나은 방식은 VPN 사용을 위험 점수의 가중 입력값 하나로 취급하고, 데이터센터 호스팅, 남용 이력, 불가능한 이동과 같은 다른 신호와 함께 나타날 때만 대응 수위를 높이는 것입니다.

VPN 탐지 데이터는 얼마나 최신이어야 하나요?

매우 최신이어야 합니다. VPN 제공업체는 서버를 매일 교체하고 프록시 네트워크는 IP를 시간 단위로 바꿉니다. 지속적인 재프로빙과 제공업체 목록의 재수집에 기반한 탐지는 정확도를 유지하지만, 정적 데이터셋은 몇 주 안에 낡아 버립니다.

작성자

GeoIPHub 팀

GeoIPHub API를 만드는 팀

GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.

이 글 공유하기
더 많은 글

관련 글