웹사이트가 실제로 보는 것
페이지를 열 때 서버가 확실하게 아는 네트워크 정보는 하나뿐입니다. 연결이 들어온 IP 주소입니다. “어디에 있는지”, “어떤 네트워크인지”는 모두 그 주소에서 끌어내거나 요청의 나머지 부분에서 추정한 것입니다.
사이트는 주소로 다음을 조회합니다.
- 누가 가진 주소인가. 모든 공인 주소는 AS 번호(ASN)와 등록 이름이 있는 네트워크에 속합니다. 가정용 ISP, 이동통신사, AWS, 호스팅 회사 같은 곳입니다.
- 어디쯤인가. IP 위치는 상용 데이터베이스의 추정입니다. 가정용 회선은 대개 나라는 맞고 도시도 근처로 나오는 경우가 많습니다. VPN 출구는 제공자가 서버가 있다고 밝힌 곳으로 나옵니다.
- 평판은 어떤가. VPN 출구, Tor 출구, 공개 프록시, 악용에 쓰인 주소의 목록입니다.
주소 말고도 요청 자체에 힌트가 있습니다. User-Agent와 언어 헤더, 브라우저의 시간대(페이지의 어떤 스크립트든 읽을 수 있음), TLS 핸드셰이크 모양, 그리고 일부 프록시를 거치면 붙는 Via나 X-Forwarded-For 같은 헤더입니다. 이런 헤더는 프록시를 대놓고 알려 줍니다.
VPN·프록시 탐지는 어떻게 작동하나
한 가지 방법으로 되지 않습니다. 탐지 서비스는 약한 신호 여러 개를 쌓습니다.
주소가 속한 네트워크
가장 싸고 효과적인 방법입니다. 일반 사용자는 ISP와 이동통신사에서 접속하지, AWS나 DigitalOcean, Hetzner에서 접속하지 않습니다. 상용 VPN과 프록시는 대부분 데이터센터 서버를 빌려 쓰기 때문에 출구 주소가 호스팅 ASN에 속합니다. “이 주소는 데이터센터에 있다”는 사실 하나로 대부분이 걸리고, 클라우드에서 돌아가는 스크레이퍼와 봇도 함께 걸립니다.
회사 트래픽이 걸리는 이유도 이것입니다. 클라우드 보안 게이트웨이와 VPN 장비도 데이터센터 대역에서 나갑니다.
알려진 출구 목록
공개된 목록도 있습니다. Tor 프로젝트는 현재 Tor 출구 주소 목록을 공개하고, Apple은 사이트가 막지 말고 알아볼 수 있도록 iCloud 비공개 릴레이의 출구 대역을 공개합니다.
상용 IP 인텔리전스 업체는 자체 목록을 만듭니다. 크게 보면 VPN 서비스에 직접 접속해 받은 출구 주소를 기록하고, 공개 프록시를 스캔하는 방식입니다. 대형 소비자용 VPN은 잘 잡습니다. 작은 VPN이나 직접 띄운 VPN은 잘 못 잡고, 업체끼리 답이 엇갈리는 경우도 광고에서 말하는 것보다 많습니다.
진짜 주소가 새어 나가는 경우
VPN이나 프록시는 실제로 그것을 거치는 트래픽에 대해서만 주소를 숨깁니다.
WebRTC. 브라우저 영상 통화에 쓰이는 WebRTC는 UDP로 STUN 서버에 “내 주소가 뭐로 보이나요?”라고 묻습니다. 전체 트래픽을 터널로 보내는 VPN이라면 이 UDP도 터널로 가서 새로 드러나는 것이 없습니다. 브라우저의 HTTP·HTTPS 요청만 실어 나르는 브라우저 확장 프록시라면, 이 UDP가 평소 회선으로 바로 나가서 진짜 공인 주소를 묻는 페이지에 알려 줄 수 있습니다. 요즘 브라우저는 기본적으로 이 방법으로 내부망(LAN) 주소를 드러내지 않지만(무작위 .local 이름으로 바꿈), 공인 주소는 별개의 문제입니다.
DNS. 웹 트래픽은 VPN으로 가는데 시스템이 계속 ISP의 DNS 리졸버를 쓰면, 내가 찾아보는 사이트가 전부 ISP에 알려집니다. ‘DNS 누출’ 테스트는 테스트 업체가 관리하는 도메인 아래 무작위 호스트명을 브라우저가 조회하게 만든 뒤, 어느 리졸버가 물어 왔는지 봅니다. ISP 리졸버가 왔다면 DNS가 터널 밖에 있는 것입니다.
IPv6. IPv4만 터널로 보내는 VPN도 있습니다. 회선에 IPv6가 있으면, IPv4·IPv6를 둘 다 지원하는 사이트로의 연결은 IPv6로 터널을 거치지 않고 진짜 주소로 나갈 수 있습니다.
앞뒤가 안 맞는 신호
위의 것들과 함께 쓰이는 더 약한 신호들입니다.
- 시간대와 위치. 브라우저는
Asia/Seoul인데 IP는 프랑크푸르트로 나옵니다. - 지연 시간. 패킷이 터널을 돌아오느라, 주장하는 위치로 설명되지 않을 만큼 왕복 시간이 깁니다.
- 연결 지문. 터널은 패킷 크기(MTU)를 줄이고, 이것이 TCP 핸드셰이크 값에 드러날 수 있습니다. TCP/IP나 TLS 지문이 User-Agent의 운영체제와 맞지 않으면 의심을 받습니다.
- 양. 한 시간에 한 주소에서 계정 수백 개가 가입합니다.
탐지가 대부분 놓치는 것
주거용(residential) 프록시. 일부 프록시 네트워크는 실제 가정 회선을 거쳐 트래픽을 내보냅니다. 사람들 기기에 깔린 앱·SDK를 통하거나 가정 회선을 빌리는 식입니다. 출구 주소는 평범한 ISP 소속이고, 평범한 도시로 나오고, 이력도 깨끗합니다. IP 기반 탐지로는 잡을 근거가 거의 없습니다.
집에 띄운 내 VPN. 집 공유기에 WireGuard 서버를 두고 카페에서 쓰면, 트래픽은 우리 집 ISP로 나갑니다. 사이트 입장에서는 집에 앉아 있는 것과 구분할 수 없습니다.
반대 방향 문제도 있습니다. CGNAT과 이동통신사는 실제 사용자 여러 명을 공인 주소 하나 뒤에 둡니다. 하나를 막으면 동네 하나를 막는 셈입니다. 그래서 상식적인 서비스는 악용이 그쪽에서 오더라도 이동통신사 대역을 통째로 막는 일이 드뭅니다.
DechoNet IP 확인이 보여 주는 것과 못 보는 것
IP 확인은 모든 정보를 브라우저가 우리 엣지에 맺은 연결에서 읽습니다. 무언가를 수집하려고 브라우저에서 스크립트를 돌리지 않습니다.
보여 주는 것은 이렇습니다.
- 이번 연결의 주소. IPv4든 IPv6든 브라우저가 쓴 쪽 하나만 보여 줍니다. 둘 다 있어도 다른 쪽은 나오지 않습니다.
- ASN, 네트워크 이름, 추정 위치(나라, 도시). 그 연결에 대한 Cloudflare의 메타데이터에서 가져오고, TLS 버전, HTTP 프로토콜, User-Agent도 함께 보여 줍니다.
- 유형(Type). ASN이 대형 클라우드(Amazon, Google, Microsoft, Cloudflare 등)의 짧은 목록에 있거나 네트워크 이름이 그와 맞으면 Cloud, 잘 알려진 호스팅 회사(DigitalOcean, Linode, Vultr, OVH, Hetzner 등)이거나 이름에 “hosting”, “data center” 같은 말이 들어 있으면 Hosting, 네트워크 등록 이름에 몇몇 VPN 브랜드(Mullvad, NordVPN, ExpressVPN, Surfshark, CyberGhost, Private Internet Access)가 들어 있을 때만 VPN입니다. 나머지는 전부 ISP입니다.
- 프록시(Proxy). Cloudflare가 측정한 이 연결의 TCP 왕복 시간이 500ms를 넘으면 Yes입니다. 그 밖의 근거는 없습니다.
이것이 무슨 뜻인지 분명히 해 둡니다. 대부분의 VPN 업체는 자기 이름의 네트워크를 따로 운영하지 않고 호스팅 회사 서버를 빌립니다. 그래서 출구가 VPN이 아니라 Hosting이나 Cloud로 나오고, 목록에 없는 업체는 빌린 네트워크 이름 그대로 나옵니다. 가정용 회선 위의 VPN이나 프록시는 ISP로 나옵니다. Cloudflare가 운영하는 WARP와 비공개 릴레이 출구는 Cloud로 나옵니다.
프록시 칸은 탐지가 아니라 지연 시간 힌트입니다. 같은 나라 안의 VPN 서버는 몇 밀리초밖에 더하지 않아서 걸리지 않습니다. SOCKS나 HTTP 프록시도 대개 걸리지 않습니다. Cloudflare가 재는 TCP 연결은 내가 아니라 프록시에서 시작하기 때문입니다. 걸리는 경우는 멀리 떨어진 VPN 출구, 왕복 시간이 긴 위성 회선, 혼잡한 모바일 연결입니다.
이 도구가 답하는 질문은 하나입니다. 내가 접속할 때 사이트에는 무엇이 보이고, 내 트래픽은 어느 네트워크로 나가는가. IP 평판 서비스가 아니고, 아무 주소나 조회할 수도 없습니다. 그건 다음 절의 방법으로 합니다.
로그에 찍힌 IP 확인하기
내 주소가 아닌 IP는 단계별로 확인합니다.
누가 가진 주소인가. ASN 조회에 IP를 넣으면 네트워크, 보유자, 그 네트워크가 알리는 프리픽스가 나옵니다. 터미널에서는 Team Cymru의 whois 서비스가 같은 매핑을 한 줄로 줍니다.
$ whois -h whois.cymru.com " -v 8.8.8.8"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
15169 | 8.8.8.8 | 8.8.8.0/24 | US | arin | 2023-12-28 | GOOGLE - Google LLC, US
가정용 ISP나 이동통신사라면 “사람일 가능성이 높음”입니다. 클라우드나 호스팅 업체라면 서버, VPN, 프록시, 회사 게이트웨이 중 하나입니다.
역방향 DNS 이름. 역방향 DNS 조회나 dig -x 203.0.113.10 +short로 봅니다. ec2-…compute.amazonaws.com 같은 클라우드 이름이나 호스팅 회사의 일반적인 이름이면 ASN이 말한 것을 확인해 줍니다. ISP는 고객 회선에 “dyn”, “pool”, “dsl” 같은 말이 들어간 이름을 붙이는 경우가 많습니다. PTR이 아예 없는 주소도 많고, 그것만으로는 아무것도 증명하지 못합니다.
Tor. Tor 프로젝트의 출구 목록과 대조합니다.
평판. VPN·프록시 점수가 필요하면 상용 IP 인텔리전스 API를 쓰고, 가능하면 두 곳을 비교하세요. 결과는 확률로 다룹니다.
클라이언트를 의심하기 전에, 로그에 찍힌 주소가 정말 클라이언트 주소인지 먼저 확인하세요. 모든 요청이 주소 한두 개에서 오는 것처럼 보인다면 내 로드밸런서나 CDN 주소를 기록하고 있을 가능성이 큽니다. 신뢰하는 프록시 뒤의 nginx라면 이렇게 합니다.
set_real_ip_from 10.0.0.0/8; # 로드밸런서 대역
real_ip_header X-Forwarded-For;
real_ip_recursive on;
X-Forwarded-For는 내가 운영하는 프록시가 붙인 것만 믿으세요. 이 헤더는 누구나 보낼 수 있고, 인터넷에서 온 것을 그대로 믿으면 클라이언트가 자기 IP를 마음대로 정하게 됩니다.
내가 VPN·프록시로 판정될 때
VPN을 안 쓰는 것 같은데 사이트가 VPN이나 프록시로 취급한다면, IP 확인을 열고 네트워크 이름을 보세요.
- VPN 브랜드, 호스팅 회사, 클라우드라면 무언가가 트래픽을 우회시키고 있습니다. VPN 앱, 백신의 ‘안전 브라우징’·‘웹 보호’ 기능, 브라우저 확장, iCloud 비공개 릴레이(설정 → 내 이름 → iCloud → 비공개 릴레이), Cloudflare WARP, 브라우저의 프록시 설정을 확인하세요. 회사 노트북이라면 회사 게이트웨이일 가능성이 크고, 이건 IT 부서만 바꿀 수 있습니다.
- 평소 쓰는 ISP나 이동통신사라면 사이트가 평판 점수나 다른 신호를 쓰고 있는 것입니다. CGNAT과 모바일 주소는 공유되므로 점수에 다른 사용자의 행동이 반영됐을 수 있습니다. 네트워크를 바꾸면(와이파이 ↔ 모바일 데이터) 대개 다른 주소를 받습니다. 그래도 안 되면 사이트에 문의하세요.
사이트를 운영한다면
운영자 입장에서 몇 가지 의견입니다.
- IP 유형만으로 차단하지 마세요. 데이터센터 주소에는 회사 사용자, 비공개 릴레이 사용자, 개인정보를 지키려는 사람이 섞여 있습니다. 이 신호는 일괄 403이 아니라 위험에 비례한 마찰(CAPTCHA, 추가 인증, 수동 검토)을 더하는 데 쓰세요.
- 가능하면 행동을 근거로 막으세요. 한 주소에서 1분에 가입 10건은 “데이터센터 주소”보다 훨씬 강한 신호입니다.
- 주거용 프록시는 뚫고 들어온다고 가정하세요. 계정 악용을 막는 수단이 IP 평판뿐이라면, 돈을 쓰는 공격자는 이미 그걸 넘어서 있습니다.
- 판단 근거를 확인하세요. HTTP 점검은 내 네트워크 밖에서 보낸 요청에 사이트가 어떻게 응답하는지 보여 줍니다. 차단이나 챌린지가 생각한 곳에서 걸리는지 확인할 때 쓸 수 있습니다.
주소에 관한 또 다른 흔한 질문(집이나 휴대폰 IP가 저절로 바뀌는 이유)은 공인 IP가 자꾸 바뀌는 이유를 보세요.
내 도메인에서 바로 확인
무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.