DNS 누출과 WebRTC 누출은 VPN을 켰는데도 방문하려는 도메인이나 실제 공인 IP가 VPN 경로 밖으로 드러나는 현상입니다(유출이라고도 부릅니다). 원인은 대개 DNS 질의나 WebRTC의 UDP 통신이 터널·프록시를 거치지 않고 현재 네트워크로 바로 나가는 데 있습니다. 이 글은 두 현상의 원리, 원인별 대처, 직접 확인하는 절차, 그리고 StageVPN 앱과 StageVPN for Chrome이 각각 어떻게 처리하는지 표와 도식으로 정리합니다.
DNS 질의에는 무엇이 드러나나요?
DNS란 사람이 읽는 도메인 이름을 컴퓨터가 쓰는 IP 주소로 바꿔 주는 인터넷의 주소록 체계입니다. 브라우저에 주소를 입력하거나 앱이 서버에 접속할 때마다 기기는 먼저 DNS 서버(리졸버)에 '이 이름의 주소가 무엇인가'를 묻습니다. 그래서 DNS 질의 기록만 보아도 언제 어떤 서비스에 접속하려 했는지 상당 부분 알 수 있습니다. 질의에 담기는 것은 도메인 이름이며, 페이지 내용이나 입력한 값은 담기지 않습니다.
전통적인 DNS 질의는 암호화되지 않은 UDP 53번 포트로 오갑니다. 이를 보완하려고 질의를 HTTPS로 감싸는 DoH(RFC 8484)와 TLS로 감싸는 DoT(RFC 7858)가 만들어졌습니다. 다만 암호화 DNS를 써도 사이트에 HTTPS로 접속할 때 보내는 서버 이름(SNI)은 사이트와 브라우저가 ECH(암호화된 Client Hello)를 지원하지 않으면 네트워크에 보일 수 있습니다.
| 전달 방식 | 같은 Wi-Fi의 관찰자 | Wi-Fi 운영자·통신사 | 질의를 받는 DNS 서버 |
|---|---|---|---|
| 일반 DNS(평문) | 볼 수 있음 | 볼 수 있음 | 볼 수 있음, 내 공인 IP와 함께 |
| DoH·DoT(암호화 DNS) | 볼 수 없음 | 볼 수 없음, DNS 서버 주소는 보임 | 볼 수 있음, 내 공인 IP와 함께 |
| VPN 터널 안의 DNS | 볼 수 없음 | 볼 수 없음, VPN 서버와 통신한다는 사실만 보임 | 볼 수 있음, VPN 서버 IP와 함께 |
| DNS 누출 상태 | 평문이면 볼 수 있음 | 볼 수 있음 | 볼 수 있음, 내 공인 IP와 함께 |
DNS 누출이란 무엇이고 왜 생기나요?
DNS 누출이란 VPN을 켠 상태에서 웹 통신은 터널을 지나는데 DNS 질의만 터널 밖으로 나가 기존 통신사나 Wi-Fi의 DNS 서버로 전달되는 현상을 말합니다. 페이지 내용은 터널 안에서 암호화되더라도, 어떤 도메인을 찾았는지는 네트워크 쪽에 보일 수 있습니다.
- 내 기기앱·브라우저
- 평문 DNS 질의
- 공용 Wi-Fi카페 공유기
- 평문 DNS 질의
- 통신사 DNS기존 리졸버
- 노출될 수 있는 구간
- 내 기기앱·브라우저
- 터널 안 DNS
- 공용 Wi-Fi카페 공유기
- 터널 안 DNS
- VPN 서버StageVPN
- VPN 서버 IP로 질의
- DNS 서버VPN 구성에 지정
- VPN 암호화
| 원인 | 무슨 일이 생기나 | 확인과 대처 |
|---|---|---|
| VPN이 DNS 서버를 지정하지 않음 | 기기가 Wi-Fi에서 받은 DNS 서버를 계속 사용 | VPN 구성에 DNS가 포함되는지 확인하고 테스트 |
| IPv6가 터널 밖으로 나감 | VPN이 IPv4만 터널링하면 IPv6 질의와 통신은 그대로 나감 | 테스트에서 IPv6 결과도 확인 |
| 여러 네트워크에 동시 질의 | 일부 운영체제가 여러 네트워크 장치의 DNS에 동시에 물음(Windows의 Smart Multi-Homed Name Resolution 등) | 운영체제와 VPN 앱을 최신으로 유지하고 테스트 반복 |
| 기기·브라우저의 별도 DNS 설정 | 수동 DNS나 보안 DNS가 VPN 구성의 DNS 대신 쓰임 | 설정 확인, 기기 전체 VPN이면 이 질의도 터널을 지나지만 받는 곳은 지정한 DNS 사업자 |
| 다른 VPN·프록시·보안 앱 | 경로 설정이 서로 덮어씀 | 한 번에 하나만 켜기 |
| 브라우저 프록시만 사용 | 브라우저 밖 앱의 DNS는 원래 네트워크로 감 | 기기 전체 보호가 필요하면 앱 VPN 사용 |
| VPN 연결 끊김 | 끊긴 동안의 질의와 통신이 모두 일반 경로로 감 | 민감한 작업 전 연결 상태 확인 |
WebRTC는 어떻게 IP 주소를 알아내나요?
WebRTC란 브라우저에서 플러그인 없이 화상 통화, 음성 통화, 파일 전송을 할 수 있게 해 주는 웹 표준 기술입니다. 두 기기를 가장 짧은 경로로 잇기 위해 ICE(RFC 8445)라는 절차로 '연결 후보' 주소를 모으는데, 이 과정에서 기기의 주소 정보가 웹페이지의 스크립트에 전달됩니다. 화상 통화를 하지 않는 페이지라도 스크립트로 이 절차를 시작할 수 있습니다.
- 연결 객체 생성웹페이지 스크립트가 RTCPeerConnection을 만듭니다
- 로컬 후보 수집브라우저가 기기 네트워크 장치의 주소를 모읍니다
- STUN 질의UDP로 STUN 서버에 '내 주소가 어떻게 보이는지' 묻습니다
- 후보 전달STUN 서버가 알려 준 공인 주소를 포함한 후보 목록이 페이지에 전달됩니다
| 후보 종류 | 무엇인가 | 드러날 수 있는 정보 | 최근 브라우저의 보호 |
|---|---|---|---|
| host | 기기 네트워크 장치의 주소 | 사설 IP(192.168.x 등) | 무작위 .local 이름(mDNS)으로 가림, 카메라·마이크 권한을 준 사이트에는 보일 수 있음 |
| srflx(서버 반사) | STUN 서버가 본 내 공인 주소 | 공인 IP, 프록시를 우회하면 실제 IP | WebRTC IP 처리 정책으로 제한 가능 |
| relay | TURN 중계 서버의 주소 | 중계 서버 IP | 중계를 쓰면 상대에게 내 IP 대신 서버 주소가 보임 |
WebRTC 누출이란 무엇이고 언제 문제가 되나요?
WebRTC 누출이란 VPN이나 프록시를 쓰는데도 WebRTC의 STUN 요청이 그 경로를 거치지 않고 현재 네트워크로 바로 나가, 웹페이지가 사용자의 실제 공인 IP를 알아내는 현상을 말합니다. 주로 브라우저 프록시나 확장형 VPN에서 문제가 됩니다. 프록시는 웹 요청을 전달하지만, 브라우저 기본 설정에서 WebRTC의 UDP 통신은 프록시를 거치지 않기 때문입니다.
기기 전체 VPN에서는 사정이 다릅니다. STUN 요청을 포함한 모든 UDP 통신이 터널로 가므로 STUN 서버에 보이는 주소도 VPN 서버의 IP입니다. 다만 VPN 연결이 끊긴 순간이나 VPN이 IPv6를 터널링하지 않는 경우에는 실제 주소가 보일 수 있습니다.
브라우저 프록시와 기본 정책
- 웹 요청은 프록시를 거침
- STUN 요청은 UDP로 직접 나감
- 페이지가 실제 공인 IP를 볼 수 있음
브라우저 프록시와 disable_non_proxied_udp
- 프록시를 거치지 않는 UDP를 막음
- WebRTC는 프록시 경로만 사용
- 일부 통화는 연결 방식이나 품질이 달라짐
기기 전체 VPN
- STUN 요청도 터널을 지남
- 공인 주소 후보가 VPN 서버 IP
- 연결 끊김과 IPv6 처리는 확인 필요
Chrome은 WebRTC가 어떤 주소를 쓸지 정하는 'WebRTC IP 처리 정책'을 두고 있으며, 확장 프로그램이 이 값을 바꿀 수 있습니다. 각 값은 IETF의 WebRTC IP 주소 처리 권고(RFC 8828)에 정리된 네 가지 방식과 대응합니다.
| 정책 값 | 동작 | 노출 범위 |
|---|---|---|
| default | 모든 네트워크 장치로 후보를 수집 | 가장 넓음(로컬 주소는 mDNS로 가림) |
| default_public_and_private_interfaces | 기본 경로의 장치만 사용, 공인·사설 주소 모두 사용 | 다른 장치의 주소는 노출하지 않음 |
| default_public_interface_only | 기본 경로의 공인 주소만 사용 | 사설 주소는 노출하지 않음 |
| disable_non_proxied_udp | 프록시를 거치지 않는 UDP 금지, 프록시가 UDP를 지원하지 않으면 프록시를 거치는 TCP 사용 | 프록시 밖 경로의 주소를 노출하지 않음 |
누출 여부는 어떻게 확인하나요?
누출 확인의 원리는 VPN을 끈 상태와 켠 상태에서 사이트에 보이는 IP, DNS 질의를 보낸 리졸버, WebRTC 후보 주소를 비교하는 것입니다. VPN을 켠 뒤에도 원래 값이 보이면 누출을 의심합니다. 테스트는 실제로 쓰는 기기와 브라우저에서 해야 의미가 있습니다.
- VPN을 끈 상태에서 IP 확인 페이지를 열고 공인 IPv4 주소와, 있다면 IPv6 주소를 적어 둡니다.
- StageVPN 앱이나 StageVPN for Chrome을 연결하고 앱의 연결 완료 표시나 확장 아이콘의 ON 표시를 확인합니다.
- 같은 페이지를 다시 열어 IP가 VPN 서버 주소로 바뀌었는지 봅니다. IPv6가 원래 주소 그대로라면 IPv6 경로를 의심합니다.
- DNS 누출 테스트 페이지를 엽니다. 이런 페이지는 무작위 하위 도메인을 조회하게 한 뒤 그 질의를 보낸 리졸버를 보여 줍니다. 통신사나 공유기의 리졸버가 보이면 DNS 누출을 의심합니다.
- WebRTC 테스트 페이지에 표시되는 공인 IP가 1단계의 원래 IP와 같은지 봅니다. Chrome 주소창에 chrome://webrtc-internals를 입력하면 진행 중인 WebRTC 연결의 후보 주소를 직접 볼 수 있습니다.
- Wi-Fi와 모바일 데이터를 바꿔 가며, 브라우저를 다시 시작한 뒤에도 같은 결과인지 반복합니다.
| 관찰한 결과 | 의미 | 할 일 |
|---|---|---|
| 사이트에 VPN 서버 IP가 보임 | 웹 통신은 VPN 경로를 지남 | 정상 |
| IPv4는 바뀌었는데 IPv6가 원래 주소 | IPv6가 터널 밖으로 나감 | 다른 VPN 앱·설정이 경로를 바꾸는지 확인 |
| 리졸버가 통신사·공유기 것 | DNS 누출 가능성 | 별도 DNS 설정과 다른 앱 확인 후 재연결 |
| 리졸버가 공용 DNS 사업자 것 | VPN 구성의 DNS이거나 직접 지정한 보안 DNS | 사업자 이름만으로 누출이라 단정하지 않기 |
| WebRTC에 원래 공인 IP가 보임 | WebRTC 누출 | 확장 연결 상태와 WebRTC 설정을 제어하는 다른 확장 확인 |
| WebRTC에 .local 이름이나 사설 IP만 보임 | 공인 IP 노출은 아님 | 대체로 정상 |
StageVPN 앱과 StageVPN for Chrome은 어떻게 처리하나요?
StageVPN 앱은 모든 통신을 터널로 보내는 방식으로, StageVPN for Chrome은 이름 조회를 프록시에 맡기고 WebRTC 정책을 조정하는 방식으로 누출을 줄입니다. 보호 범위가 다르므로 처리 방식도 다릅니다.
| 항목 | StageVPN 앱(iPhone·Android) | StageVPN for Chrome |
|---|---|---|
| 보호 범위 | 기기 전체 | Chrome 브라우저 |
| VPN 경로로 보내는 통신 | IPv4·IPv6 전체(0.0.0.0/0, ::/0) | 프록시를 거치는 웹 요청(로컬 네트워크 주소 제외) |
| DNS 질의 | VPN 구성에 지정한 DNS 서버로 터널 안에서 전달 | 프록시 경유 요청은 프록시 서버가 이름 조회 |
| WebRTC | 모든 UDP 통신이 터널을 지남 | 연결 중 disable_non_proxied_udp 적용, 연결을 끊으면 원래 설정으로 |
| 현재 네트워크에 보이는 것 | VPN 서버와 암호화 통신을 한다는 사실과 데이터량 | 프록시 서버 주소의 이름 조회, 프록시와의 암호화 연결, Chrome 밖 앱의 통신 |
| 적용되지 않을 수 있는 경우 | VPN 연결이 끊긴 동안 | 다른 확장이나 회사 정책이 프록시·WebRTC 설정을 제어할 때 |
| 접속 기록(93일) | 조회한 도메인은 기록하지 않음 | 연결한 목적지 호스트 이름은 기록, 경로·검색어는 기록하지 않음 |
StageVPN은 별도의 DNS 누출 방지 설정 메뉴를 제공 기능으로 안내하지 않으며, 위 동작은 앱의 기본 VPN 구성과 확장의 연결 방식에 따른 것입니다(제공 범위 참고). 두 방식의 전체 차이는 브라우저 VPN과 앱 VPN 비교에서, 앱의 터널 구조는 WireGuard 원리 설명에서 볼 수 있습니다.
알아 두세요 누출이 없다는 것은 질의와 통신이 통신사 대신 VPN 경로를 지난다는 뜻이지, 어떤 기록도 남지 않는다는 뜻은 아닙니다. StageVPN은 통신비밀보호법에 따라 접속 기록을 93일 보관하며 항목은 접속 기록 보관 고지에, 공개하는 이유는 접속 기록 보관 정책을 공개하는 이유에 설명했습니다.
누출이 보이면 무엇부터 해야 하나요?
먼저 연결을 다시 맺고, 함께 켜진 다른 VPN·프록시와 별도 DNS 설정을 정리하는 순서로 확인합니다. 대부분은 설정이 겹쳐서 생깁니다.
- VPN 연결을 끊었다가 다시 연결한 뒤 같은 테스트를 반복합니다.
- 다른 VPN 앱이나 프록시·VPN 확장이 함께 켜져 있지 않은지 확인하고 하나만 남깁니다.
- 기기와 브라우저에 수동 DNS나 보안 DNS를 지정해 두었는지 확인합니다.
- 운영체제, 브라우저, StageVPN 앱과 확장을 최신 버전으로 업데이트합니다.
- Chrome 확장 사용 중 WebRTC에 원래 IP가 보이면 WebRTC 설정을 제어하는 다른 확장을 끄고 다시 연결합니다.
- 브라우저 밖 앱의 통신도 보호해야 한다면 확장 대신 기기 전체 VPN을 씁니다.
- 문제가 계속되면 기기 모델, 운영체제·앱 버전, 발생 시각, 테스트 결과를 정리해 고객 지원으로 문의합니다. 비밀번호나 인증 코드는 보내지 마세요.
누출 확인과 함께 점검할 기기 설정은 스마트폰 설정 10가지에, VPN만으로 해결되지 않는 위험은 VPN이 막아주는 것과 막지 못하는 것에 정리했습니다.
자주 묻는 질문
DNS가 누출되면 방문한 페이지 내용까지 보이나요?
보이지 않습니다. DNS 질의에는 도메인 이름만 담기므로 페이지 내용이나 입력한 값은 드러나지 않습니다. 다만 어떤 서비스에 언제 접속하려 했는지는 알 수 있으므로 누출은 막는 것이 좋습니다.
시크릿 모드를 쓰면 누출이 막히나요?
막히지 않습니다. 시크릿 모드는 기기에 방문 기록과 쿠키를 남기지 않는 기능일 뿐 DNS 질의나 WebRTC의 경로를 바꾸지 않습니다. StageVPN for Chrome을 시크릿 창에서 쓰려면 확장 관리 화면에서 '시크릿 모드에서 허용'을 켜야 합니다.
보안 DNS(DoH)를 켜면 VPN이 필요 없나요?
목적이 다릅니다. DoH는 DNS 질의만 암호화하며 사이트 접속 자체와 사이트가 보는 IP는 그대로입니다. VPN은 기기 또는 브라우저와 VPN 서버 사이의 통신 전체를 암호화하고 사이트에 보이는 IP를 바꿉니다.
WebRTC를 제한하면 화상회의를 못 쓰나요?
대부분은 쓸 수 있습니다. disable_non_proxied_udp에서는 WebRTC가 프록시를 거치는 경로만 쓰므로, TCP 기반 중계를 지원하는 서비스는 연결되지만 품질이 달라질 수 있습니다. 기기 전체 VPN에서는 UDP도 터널을 지나므로 이런 제약이 없습니다.
테스트 사이트마다 결과가 다른 이유는 무엇인가요?
측정 방식이 다르기 때문입니다. IPv4만 보는 곳과 IPv6까지 보는 곳이 있고, DNS 테스트도 리졸버를 찾는 방식이 달라 결과가 달라질 수 있습니다. 두 곳 이상에서, 여러 네트워크로 바꿔 가며 비교하세요.
IPv6를 꺼 두는 것이 좋은가요?
StageVPN 앱은 IPv6 통신도 터널로 보내도록 구성되어 있어 일반적으로 따로 끌 필요는 없습니다. 테스트에서 IPv6 주소가 원래대로 보인다면 다른 VPN 앱이나 기기 설정이 경로를 바꾸고 있는지 먼저 확인하세요.
참고 자료
- RFC 1034: Domain Names — Concepts and Facilities — DNS의 구조와 리졸버의 역할 (IETF)
- RFC 8484: DNS Queries over HTTPS (DoH) — HTTPS로 DNS 질의를 암호화하는 방식 (IETF)
- RFC 7858: DNS over TLS — TLS로 DNS 질의를 암호화하는 방식 (IETF)
- RFC 8445: Interactive Connectivity Establishment (ICE) — WebRTC 연결 후보의 종류와 수집 절차 (IETF)
- RFC 8828: WebRTC IP Address Handling Requirements — 브라우저가 WebRTC에 노출하는 주소의 범위 (IETF)
- chrome.privacy API — Chrome WebRTC IP 처리 정책 값 (Chrome for Developers)
- WebRTC API — RTCPeerConnection과 ICE 후보의 개념 (MDN Web Docs)
