WebRTC 유출 테스트

WebRTC는 브라우저가 평소에는 보내지 않을 주소를 웹사이트에 넘겨줄 수 있습니다. VPN 뒤에 있는 실제 주소도 예외가 아닙니다. 이 테스트는 Cloudflare와 Google이 운영하는 STUN 서버 3곳에 묻고, 돌아온 모든 주소와 각 주소의 정체를 보여 주며, 웹사이트가 이미 보는 주소와 비교합니다. 테스트할 수 없는 것이 있으면 초록색 체크 표시를 보여 주는 대신 그렇다고 알려 줍니다.

Cloudflare와 Google STUN을 상대로 브라우저에서 실행 · 아무것도 저장하지 않음 · 후보 종류는 RFC 8445 기준

어차피 웹사이트에 보이는 것IPv4IPv6연결을 확인하는 중…

WebRTC가 내놓은 모든 주소

WebRTC가 내놓는 주소가 STUN 서버가 응답하는 대로 한 줄씩 여기에 표시됩니다.

WebRTC가 찾은 주소는 저희에게 전송되지 않습니다. 화상 통화와 마찬가지로 브라우저가 직접 STUN 서버에 묻습니다. 웹사이트에 무엇이 보이는지 보여 주기 위해, 페이지는 DNS 유출 테스트와 마찬가지로 ipify.org와 저희 서버에 내 주소와 그 네트워크를 묻습니다.

WebRTC 유출이란 무엇인가요?

WebRTC는 화상 통화를 가능하게 하는 브라우저 기능입니다. 두 사람을 직접 연결하기 위해 내 기기에 닿을 수 있는 모든 주소를 모아 페이지에 제공하는데, 여기에는 브라우저가 평범한 요청에서는 절대 보내지 않을 주소도 포함됩니다.

이 수집 과정을 ICE 후보 수집이라고 하며, RFC 8445에 정의되어 있습니다. 브라우저는 먼저 내 네트워크 인터페이스에 있는 주소를 나열한 다음, STUN 서버에 “내가 어떤 주소에서 오는 것으로 보이나요?”라고 물어 그 답도 추가합니다. 인터넷의 어떤 페이지든 JavaScript 몇 줄로 이 과정을 시작해 도착하는 후보를 모두 읽을 수 있으며, 권한을 묻는 창도 뜨지 않습니다. 통화는 권한 요청 없이도 이루어져야 하므로, 이것이 설계 의도입니다.

그 주소 중 하나가 내가 숨기던 주소일 때 유출이 됩니다. VPN은 브라우저 요청이 지나는 경로를 바꾸지만, WebRTC는 운영체제에 모든 인터페이스를 물을 수 있습니다. 그래서 물리적 연결이 아직 살아 있는 기기에서는 VPN 주소와 나란히 실제 주소가 나타날 수 있습니다. 무언가가 고장 난 것이 아닙니다. 이 기능은 설계된 그대로 작동하고 있을 뿐입니다.

어떤 페이지든 시작할 수 있는 것수집 한 번을 단계별로

스크립트 전체

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

출력된 내용

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

각 줄의 의미

host이 기기에 있는 주소8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local브라우저가 가림
srflxSTUN 서버가 본 주소203.0.113.7인터넷에서 라우팅 가능

가정용 연결에서 한 번 수집한 예이며, 주소는 문서용 주소입니다. 사설 주소는 원래 모습 그대로 브라우저 밖으로 나가지 않습니다. STUN 서버에는 기기가 아니라 공유기의 공인 쪽이 보이며, 두 답 모두 물어본 스크립트로 갑니다.

WebRTC 유출 테스트 결과: 모든 ICE 후보를 종류, 주소의 정체, 판정과 함께 보여 주는 화면 — 테스트 실행 예입니다. 각 STUN 서버의 응답, WebRTC가 드러낸 모든 주소, 그 주소의 종류, 그리고 웹사이트가 이미 보는 주소인지를 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

WebRTC 유출은 어떻게 확인하나요?

위의 테스트를 시작하세요. STUN 서버 3곳에서 후보를 모으고, 각 주소의 정체를 가려낸 뒤, 라우팅 가능한 주소를 웹사이트가 이미 보는 주소와 비교합니다.

가능한 결과는 둘이 아니라 셋입니다. 유출 없음은 WebRTC가 내놓은 라우팅 가능한 주소가 모두 사이트가 이미 가진 주소라는 뜻입니다. 유출은 적어도 하나가 그렇지 않거나, 내 기기 자체의 주소가 직접 제공되었다는 뜻입니다. 테스트 못 함은 WebRTC가 꺼져 있거나 차단되었거나, 응답한 STUN 서버가 없다는 뜻이며, 대부분의 도구가 슬쩍 통과로 바꿔 버리는 결과입니다.

VPN을 쓴다면 두 번 실행하세요. 한 번은 VPN을 끄고 평소 주소를 확인하고, 한 번은 켠 상태로 실행합니다. 중요한 것은 두 번째 실행이며, 두 결과의 차이가 답입니다. 페이지가 첫 번째 결과를 보관하므로 아무것도 적어 두지 않고 비교할 수 있습니다.

결과는 둘이 아니라 셋각 결과의 의미

유출 없음
WebRTC가 내놓은 라우팅 가능한 주소가 모두 웹사이트가 이미 가진 주소입니다.
WebRTC가 내놓은 것
- 198.51.100.23STUN 서버가 본 주소웹사이트에 이미 보임
- 8b7f4e2a-….local이 기기에 있는 주소브라우저가 가림
웹사이트에 보이는 것
198.51.100.23
유출
웹사이트가 이미 가진 주소가 아닌 주소가 적어도 하나 있거나, 내 기기 자체의 주소가 직접 제공되었습니다.
WebRTC가 내놓은 것
- 198.51.100.23STUN 서버가 본 주소웹사이트에 이미 보임
- 2001:db8:4a1f:7c00::1c이 기기에 있는 주소웹사이트에는 보이지 않음
웹사이트에 보이는 것
198.51.100.23
테스트 못 함
WebRTC가 꺼져 있거나 차단되었거나, 응답한 STUN 서버가 없습니다. 아무것도 측정되지 않았습니다.
stun.cloudflare.com응답 없음
stun.l.google.com응답 없음
대부분의 도구가 여기서 보여 주는 것~~유출 없음~~

두 번 실행

VPN 끔

WebRTC가 내놓은 것203.0.113.7

웹사이트에 보이는 것203.0.113.7

유출 없음

VPN 켬

WebRTC가 내놓은 것198.51.100.23203.0.113.7

웹사이트에 보이는 것198.51.100.23

VPN을 켜도 남은 것

유출

각 결과와 그 결과를 내는 실행입니다. VPN을 끄면 WebRTC의 주소와 웹사이트의 주소가 같습니다. 켜면 둘 다 바뀌어야 하며, 그대로 남는 주소가 답입니다.

VPN이 WebRTC 유출을 막아 주나요?

VPN만으로는 막지 못합니다. VPN은 트래픽이 가는 곳을 바꾸지만, WebRTC는 운영체제에 어떤 인터페이스가 있는지 물을 수 있고, 물리적 인터페이스는 대개 그대로 있습니다.

IETF의 설명은 정확합니다. “클라이언트가 가상 사설망(VPN)으로 물리적 위치를 숨기려 하고, VPN과 로컬 OS가 여러 인터페이스를 통한 라우팅을 지원한다면, WebRTC는 VPN의 공인 주소뿐 아니라 VPN이 작동하는 기반인 ISP의 공인 주소까지 찾아낼 수 있다.” 두 주소가 모두 제공되며, 찾아보는 페이지는 둘 다 읽을 수 있습니다.

일부 VPN 클라이언트는 운영체제 수준에서 모든 트래픽을 라우팅하거나, WebRTC를 제한하는 브라우저 확장 프로그램을 함께 제공해 이 틈을 막습니다. 둘 다 효과가 있지만, 둘 다 짐작하지 말고 확인해야 하는 것이며, 이 페이지가 바로 그 용도입니다. VPN 자체의 유출 테스트 페이지가 보호되고 있다고 말해도, 그것은 독립적인 증거가 아닙니다.

VPN은 켜져 있고, Wi-Fi도 연결된 상태인터페이스 둘, 답도 둘

페이지가 받는 것

198.51.100.23srflxSTUN 서버가 본 주소VPN 경유웹사이트에 이미 보임
203.0.113.7srflxSTUN 서버가 본 주소Wi-Fi 경유, 터널 밖웹사이트에는 보이지 않음

RFC 8828

틈을 막는 방법

운영체제 수준의 라우팅터널 밖으로 나가는 것이 없으므로, STUN 서버에는 VPN의 주소만 보입니다.
VPN의 브라우저 확장 프로그램브라우저 안에서 WebRTC를 제한하므로, 다른 인터페이스에는 아예 묻지 않습니다.
짐작하지 말고 확인하기VPN을 켠 상태로 이 테스트를 실행하세요. VPN 자체의 유출 테스트 페이지는 독립적인 증거가 아닙니다.

IETF가 RFC 8828에서 설명하는 경우입니다. VPN과 운영체제가 둘 이상의 인터페이스로 라우팅하므로, WebRTC는 VPN의 공인 주소와 그 아래에 있는 제공업체의 주소를 찾아냅니다.

호스트 후보, 서버 반사 후보, 릴레이 후보는 각각 무엇인가요?

호스트 후보는 내 기기 자체에 있는 주소입니다. 서버 반사 후보는 STUN 서버가 본 주소, 즉 NAT의 공인 쪽 주소입니다. 릴레이 후보는 TURN 서버의 주소이며, 내 주소가 아닙니다.

이 구분은 중요하지만, 대부분의 유출 테스트는 이를 버립니다. 내 공인 IPv4를 담은 서버 반사 후보는 대개 새로운 정보가 아닙니다. 지금 쓰고 있는 연결에서 웹사이트가 받는 주소와 같기 때문입니다. 라우팅 가능한 주소를 담은 호스트 후보는 다릅니다. 기기 자체의 주소가 페이지에 직접 제공된 것입니다. 가정의 공유기만이 아니라 이 기기 자체를 식별하며, 네트워크가 바뀌면 함께 바뀝니다.

페이지는 모든 주소 옆에 종류를 표시하고, 전송 방식, 포트, 그리고 반사 후보가 가리키는 관련 주소도 함께 보여 줍니다. 릴레이 후보는 TURN 서버 자체의 주소로, 나에 대해 아무것도 드러내지 않습니다. 이 테스트는 TURN 서버를 쓰지 않으므로, 릴레이 후보가 나타난다면 페이지의 다른 무언가가 그것을 설정했다는 뜻입니다.

후보 하나를 항목별로페이지가 받는 그대로

candidate:1467250027파운데이션
1컴포넌트
udp전송 방식
1686052607우선순위
203.0.113.7주소
54400포트
typ srflx종류
raddr 0.0.0.0 rport 9관련 주소
generation 0확장

로컬 주소를 가리는 환경에서는 비워짐: 0.0.0.0, 포트 9

네 가지 종류

typ host이 기기에 있는 주소
내 네트워크 인터페이스 중 하나에 있는 주소.
사설 주소는 가려집니다. 라우팅 가능한 주소는 기기 그 자체이며, 가장 심각한 발견입니다.
라우팅 가능하면 가장 심각
typ srflxSTUN 서버가 본 주소
STUN 서버가 본 공유기의 공인 쪽.
대개 웹사이트가 이미 내 연결에서 받는 주소입니다.
대개 새로운 정보 아님
typ prflx상대방이 본 주소
통화 상대방이 본 공유기의 공인 쪽.
상대방과 연결하는 동안에만 발견되므로, 통화가 없는 테스트에서는 나타나지 않습니다.
통화 중에만
typ relay릴레이 서버 자체의 주소
나를 위해 트래픽을 중계하는 TURN 서버의 주소.
내 주소가 아니라 서버의 주소입니다. 이 테스트는 TURN 서버를 쓰지 않으므로, 여기 나타난 것은 다른 무언가가 설정한 것입니다.
나에 대한 정보 없음

후보의 주소는 웹사이트에 보이는 주소와 비교되고, 후보의 종류는 그 차이가 얼마나 심각한지 알려 줍니다. 정의는 RFC 8445, 섹션 4에 따릅니다.

mDNS .local 주소란 무엇이며, 나를 보호해 주나요?

최신 브라우저는 사설 주소를 페이지에 제공하기 전에 .local로 끝나는 무작위 이름으로 바꿉니다. 이 방법은 효과가 있습니다. 단, 사설 주소에 한해서입니다. 공인 주소를 숨기려고 만든 것은 처음부터 아닙니다.

Chrome은 버전 76부터 기본으로 이렇게 하고, Firefox는 media.peerconnection.ice.obfuscate_host_addresses가 true로 설정되어 있습니다. 그래서 페이지는 192.168.1.20 대신 8b7f4e2a-….local 같은 값을 받으며, 이는 내 네트워크 밖의 누구에게도 의미가 없습니다. Safari는 한발 더 나아가, 사이트가 카메라나 마이크 권한을 얻기 전까지는 호스트 후보를 전혀 제공하지 않습니다. 위의 테스트는 이런 .local 이름을 알아보고, 발견 사항이 아니라 보호 기능이 작동하는 것으로 보고합니다.

이를 정의한 IETF 초안은 이 방법이 하지 않는 일을 분명히 밝힙니다. “이미 인터넷에 노출된 주소는 웹 서버가 쉽게 관찰할 수 있으므로 mDNS로 보호할 필요가 없다.” 그래서 서버 반사 후보에는 여전히 내 공인 IPv4가 담기며, 사람들이 놀라는 부분이지만, 라우팅 가능한 IPv6 주소가 있는 기기는 그 주소를 호스트 후보로 여전히 제공할 수 있습니다. 알아 둘 구멍이 하나 더 있습니다. Chrome은 이미 카메라나 마이크 권한이 있는 사이트에서는 이 보호 기능을 끄므로, 전에 쓴 적 있는 화상 통화 사이트는 내 실제 로컬 주소를 봅니다.

.local 이름이 대신하는 것그리고 그대로 두는 것

브라우저가 가진 것

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

페이지가 받는 것

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

브라우저별 기본 동작

Chrome버전 76, 2019년 8월
Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
Safari사이트가 카메라나 마이크 권한을 얻기 전까지 호스트 후보 없음

이 방식은 IETF 초안이며, 2021년 12월에 마지막으로 개정되었고 RFC로 발행되지 않았습니다. draft-ietf-mmusic-mdns-ice-candidates-03

WebRTC가 제공할 수 있는 주소가려지나요?

192.168.1.20내 사설 IPv4, 호스트 후보로가려짐무작위 이름으로 바뀝니다. 페이지는 내 네트워크에 대해 아무것도 알 수 없습니다.

203.0.113.7내 공인 IPv4, STUN 서버의 후보로보임이미 공개되어 있으므로 그대로 남습니다. 관련 주소만 지워집니다.

2001:db8:4a1f:7c00::1c라우팅 가능한 IPv6, 호스트 후보로보임역시 공개 주소이므로, 가림 처리는 처음부터 대상으로 삼지 않았습니다.

2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07임시 IPv6 주소보일 수 있음초안은 브라우저가 선택에 따라 가리지 않고 둘 수 있게 합니다.

192.168.1.20카메라나 마이크 권한이 있는 사이트에서의 모든 로컬 주소가림 꺼짐Chrome은 그런 사이트에서 가림 처리를 끕니다. 사이트에 실제 로컬 주소가 보입니다.

가림 처리는 내 네트워크만 아는 정보를 숨깁니다. 웹사이트가 어차피 볼 수 있는 정보는 그대로 둡니다. 실수가 아니라 설계입니다.

IPv6가 마지막으로 남은 유출인 이유

전역 IPv6 주소는 NAT 뒤의 가정 전체가 아니라 기기 한 대의 것이며, mDNS는 일부러 이 주소를 건드리지 않습니다. WebRTC가 아직도 내주는 것 중 신원을 가장 잘 드러내는 정보입니다.

IPv4에서는 가정용 공유기의 NAT가 모든 기기를 주소 하나 뒤에 두므로, 서버 반사 후보가 페이지에 알려 주는 내용은 평소 연결이 이미 알려 주는 것과 거의 같습니다. IPv6에는 NAT가 없습니다. 기기마다 라우팅 가능한 자체 주소가 있고, 그 주소를 담은 호스트 후보는 회선이 아니라 기기를 가리킵니다. VPN이 IPv4만 실어 나른다면(많은 VPN이 그렇습니다), 그 IPv6 주소는 아예 터널 밖에 있기도 합니다.

개인정보 보호 확장이 도움이 됩니다. 임시 IPv6 주소는 주기적으로 바뀌기 때문입니다. 하지만 주소를 숨겨 주지는 않습니다. mDNS 초안은 이런 주소를 가리지 않고 둘 수도 있다고 합니다. 위의 테스트는 라우팅 가능한 IPv6 호스트 후보를 찾을 수 있는 가장 심각한 발견으로 표시하며, 내 연결에 IPv6가 있는지는 IPv6 테스트에서 알 수 있습니다.

주소가 가리키는 대상같은 기기 세 대, 두 가지 경우

IPv4, NAT 뒤IPv6, NAT 없음

노트북192.168.1.202001:db8:4a1f:7c00::1c

휴대폰192.168.1.212001:db8:4a1f:7c00::2b

TV192.168.1.222001:db8:4a1f:7c00::3d

공유기203.0.113.7회선 전체에 주소 하나기기마다 주소 하나

전역 IPv6 주소의 두 부분

2001:db8:4a1f:7c00네트워크 프리픽스: 내 회선 /64:8d3:5e2f:a41c:9b07인터페이스 ID: 이 기기

고정2001:db8:4a1f:7c00::1c
임시: 주기적으로 바뀜2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

IPv4만 실어 나르는 VPN

IPv4198.51.100.23터널 안
IPv62001:db8:4a1f:7c00::1c터널 밖

IPv4 NAT 뒤에서는 가정이 주소 하나를 함께 쓰지만, IPv6에서는 기기마다 자체 주소가 있고 호스트 후보가 그 주소를 직접 제공합니다. 테스트는 라우팅 가능한 IPv6 호스트 후보를 가장 심각한 발견으로 다룹니다.

브라우저별로 WebRTC 유출을 막는 방법

Firefox에는 효과가 있는 설정이 있습니다. Edge에는 엔터프라이즈 정책이 있습니다. Safari는 이미 후보를 제한합니다. 사람들이 여전히 추천하는 브라우저 확장 프로그램은 더 이상 아무 효과가 없습니다.

Firefox에서는 about:config → media.peerconnection.ice.default_address_only가 모든 주소 대신 주소 하나만 보내게 하고, media.peerconnection.ice.relay_only는 수집을 릴레이 후보로 제한합니다. 후자는 직접 통화를 깨뜨리지만 나머지는 모두 숨깁니다. 둘 다 기본값은 꺼짐이며, 사설 주소의 mDNS 가림 처리(media.peerconnection.ice.obfuscate_host_addresses)는 이미 켜져 있습니다. Edge에서는 WebRtcLocalIpsAllowedUrls 정책으로 로컬 주소를 볼 수 있는 사이트를 정합니다. Microsoft 자체 문서는 사이트를 추가하면 “보호가 약해진다”고 적고 있습니다. Chrome에는 일반 사용자를 위한 같은 설정이 없습니다. Safari는 따로 설정하지 않아도 가장 엄격합니다. 카메라나 마이크 권한이 없으면 WebKit은 서버 반사 후보와 릴레이 후보만 제공하고, 호스트 후보는 전혀 제공하지 않습니다.

여전히 널리 추천되는 두 가지 방법은 이미 쓸모가 없습니다. uBlock Origin의 “WebRTC로부터 로컬 IP 주소 유출을 방지” 옵션은 버전 1.38에서 제거되었으며, 당시 설명은 “Android용 Firefox를 제외하면 최신 브라우저에서는 더 이상 필요하지 않다”였습니다. 그리고 Google의 WebRTC Network Limiter 확장 프로그램은 스토어에 아직 올라와 있지만 실행되지 않습니다. 2025년 7월 Chrome 138부터 모든 Chrome 사용자에게 Manifest V2 확장 프로그램이 비활성화되었기 때문입니다. 둘 중 하나를 설치하라고 하는 페이지는 몇 년째 업데이트되지 않은 것입니다.

각 브라우저가 제공하는 것각 업체의 문서와 대조해 확인

Firefox효과 있는 설정
about:config
- media.peerconnection.ice.obfuscate_host_addresses기본값 true사설 주소를 가립니다. 이미 켜져 있습니다.
- media.peerconnection.ice.default_address_only기본값 false설정할 값 true모든 주소 대신 주소 하나만 보냅니다.
- media.peerconnection.ice.relay_only기본값 false설정할 값 true릴레이 후보만. 가장 많이 숨기지만 직접 통화가 깨집니다.
Edge엔터프라이즈 정책
WebRtcLocalIpsAllowedUrls
로컬 주소를 볼 수 있는 사이트를 나열합니다.
설정하지 않음: 로컬 주소가 계속 가려집니다.
Microsoft 자체의 안내: 사이트를 추가하면 보호가 약해집니다.
Windows와 macOS, 버전 80 이상
Chrome설정 없음
일반 사용자를 위한 설정이 없습니다.
버전 76부터 사설 주소를 기본으로 가립니다.
카메라나 마이크 권한이 있는 사이트에서는 예외입니다.
Safari기본으로 엄격
카메라나 마이크 권한이 없으면 STUN 서버 후보와 릴레이 후보만.
호스트 후보는 전혀 없음.

더 이상 통하지 않는 조언

~~Prevent WebRTC from leaking local IP addresses~~
uBlock Origin
버전 1.38에서 제거됨
uBlock Origin에 따르면 Android용 Firefox를 제외하면 최신 브라우저에서는 더 이상 필요하지 않습니다.
~~WebRTC Network Limiter~~
Google · Chrome Web Store
아직 등록되어 있지만 실행 불가
Chrome 138(2025년 7월)부터 모든 Chrome 사용자에게 Manifest V2 확장 프로그램이 비활성화되었습니다.

각 업체의 공식 문서를 이 페이지를 확인한 날에 읽은 내용입니다. 마지막 두 가지 중 하나를 설치하라고 여전히 권하는 페이지는 몇 년째 업데이트되지 않았습니다.

WebRTC 유출, DNS 유출, IP 유출은 어떻게 다른가요?

VPN을 우회하는 서로 다른 세 가지 방식입니다. WebRTC 유출은 주소를 보여 주고, DNS 유출은 누가 내 조회에 응답하는지 보여 주며, IP 유출은 트래픽이 아예 터널에 들어가지 않은 단순한 경우입니다.

WebRTC 유출은 주소를 자진해서 내놓도록 설계된 기능을 통해 브라우저가 내놓는 주소의 문제입니다. DNS 유출은 어떤 리졸버가 내 조회에 응답하는지의 문제입니다. 트래픽은 VPN을 거쳐도 조회는 여전히 제공업체의 리졸버로 갈 수 있으며, 그러면 제공업체는 내가 방문하는 모든 사이트를 알게 됩니다. 저희 DNS 유출 테스트는 저희 자체 네임서버로 이를 확인하므로, 어떤 리졸버가 물어 왔는지 정확히 볼 수 있습니다.

일반적인 의미의 IP 유출은 웹사이트가 그냥 보는 주소이며, 내 IP 주소 확인이나 내 ISP 확인에서 확인할 수 있습니다. VPN을 바꾼 뒤에는 세 가지를 함께 실행하세요. 각각 따로 실패하므로, 한쪽 결과가 깨끗해도 나머지에 대해서는 아무것도 알 수 없습니다.

VPN을 우회하는 세 가지 길각각 따로 실패함

IP 유출
새어 나가는 것모든 요청에 담기는 주소
알게 되는 쪽내가 방문하는 모든 사이트
확인 도구내 IP 주소 확인 내 ISP 확인
DNS 유출
새어 나가는 것어떤 리졸버가 내 조회에 응답하는지
알게 되는 쪽내 제공업체, 내가 조회하는 모든 사이트에 대해
확인 도구DNS 유출 테스트
WebRTC 유출
새어 나가는 것브라우저가 페이지에 제공하는 주소
알게 되는 쪽묻는 페이지라면 어디든, 권한 요청 없이
확인 도구WebRTC 유출 테스트

각각 따로 실패합니다. 한쪽 결과가 깨끗해도 나머지 두 가지에 대해서는 아무것도 알 수 없습니다. VPN을 바꾼 뒤에는 세 가지를 모두 실행하세요.

이 테스트가 STUN 서버 여러 곳에 묻는 이유

“돌아온 주소가 없다”와 “주소가 없다”는 똑같아 보이지만, 좋은 소식은 그중 하나뿐이기 때문입니다.

회사 방화벽, 제한이 엄격한 VPN, UDP를 막는 네트워크는 STUN 서버의 응답을 막을 수 있습니다. 한 업체에만 묻고 아무것도 보지 못한 테스트는 아무것도 알아내지 못한 것입니다. 그런데도 흔히 초록색 체크 표시를 보여 줍니다. 이 테스트는 Cloudflare가 문서로 공개한 STUN 엔드포인트와 Google의 엔드포인트에 묻고, 각각 따로 보고하며, 어느 서버도 응답하지 않으면 테스트하지 못했다고 알립니다.

서버 선택은 의도적입니다. Cloudflare는 stun.cloudflare.com:3478을 제품의 일부로 공개하므로 읽어 볼 약관이 있습니다. Google의 stun.l.google.com:19302는 Google 자체 WebRTC 검사 도구의 기본값으로만 문서화되어 있고 공개된 약관이 없어, 유일한 근거가 아니라 두 번째 의견으로 씁니다. Twilio의 서버는 자격 증명이 필요하고, Mozilla는 자주 언급되는 것과 달리 문서로 밝힌 공개 STUN 서버가 없습니다.

공개 STUN 서버그리고 이 테스트가 묻는 서버

Cloudflare물어봄
stun.cloudflare.com:3478
문서로 공개된 엔드포인트로, 제품의 일부이며 읽어 볼 약관이 있습니다.
Google물어봄, 두 번째 의견으로
stun.l.google.com:19302
Google 자체 WebRTC 검사 도구의 기본값으로만 문서화되어 있습니다. 공개된 약관이 없습니다.
Twilio묻지 않음
global.stun.twilio.com:3478
Twilio API에서 받은 자격 증명이 필요합니다. 모든 페이지에 열려 있지 않습니다.
Mozilla묻지 않음
공개 서버 없음
문서로 밝힌 공개 STUN 서버가 없습니다. Firefox에는 기본 ICE 서버가 아예 없습니다.

서버가 응답하지 않을 때

응답함응답함결과 유효

응답함응답 없음결과 유효, 응답 없는 서버를 명시

응답 없음응답함결과 유효, 응답 없는 서버를 명시

응답 없음응답 없음테스트 못 함

두 운영자에게 따로 묻습니다. 서버 하나가 응답하지 않으면 그 서버를 밝히고 결과는 유효합니다. 어느 서버도 응답하지 않으면 아무것도 측정되지 않은 것이며, 테스트는 통과를 보여 주는 대신 그렇다고 알려 줍니다.

내 IP 주소는 개인정보인가요?

EU에서 동적 IP 주소는, 인터넷 제공업체가 가진 정보로 나를 식별할 수 있는 웹사이트 운영자에게 개인정보입니다. 유럽연합 사법재판소가 2016년에 그렇게 판결했습니다.

사건은 Breyer 사건(C-582/14)으로, 2016년 10월 19일에 판결이 나왔으며, 재판소의 보도자료는 이렇게 요약합니다. “방문자의 동적 인터넷 프로토콜 주소는, 웹사이트 운영자가 인터넷 접속 제공업체가 보유한 해당 방문자에 관한 추가 정보로 그 방문자를 식별할 수 있는 법적 수단을 가진 경우, 그 운영자와의 관계에서 개인정보에 해당한다.” 같은 보도자료는 사이트가 공격으로부터 스스로를 방어하기 위해 그 일부를 보관할 정당한 이익을 가질 수 있다는 점도 언급합니다.

이 페이지가 브라우저 안에서 작동하는 이유가 바로 그것입니다. ICE 후보는 브라우저가 모으고, 브라우저 안에서 비교하고, 나에게 보여 줍니다. WebRTC가 찾은 주소는 저희에게 전송되지 않으므로, 저희가 보관하거나 넘겨주거나 잃어버릴 것이 전혀 없습니다. 테스트가 실행되는 동안 네트워크 패널을 지켜볼 수 있습니다.

Breyer 판결유럽연합 사법재판소

C-582/14Breyer v Bundesrepublik Deutschland2016년 10월 19일

웹사이트 운영자로그에 남은 주소와 시각203.0.113.7 · 14:02:37
그 정보를 얻을 법적 수단
인터넷 접속 제공업체그 시각에 그 주소를 누가 쓰고 있었는지203.0.113.7 · 14:02:37 →
그 운영자에게는 개인정보

재판소의 보도자료: 사이트는 공격으로부터 스스로를 방어하기 위해 그 일부를 보관할 정당한 이익을 가질 수 있음.

이 페이지에서는

내 브라우저

수집
분류
비교
표시

통화와 마찬가지로 내 공인 주소를 봄
dnsrobot.net후보는 전송되지 않음

사건 C-582/14, Breyer. 동적 IP 주소는 제공업체의 기록으로 나를 식별할 법적 수단을 가진 웹사이트 운영자에게 개인정보입니다. 이 페이지는 후보를 브라우저 안에 둡니다.

WebRTC 유출 테스트: 자주 묻는 질문

WebRTC 유출이란 무엇인가요?

WebRTC는 화상 통화를 가능하게 하는 브라우저 기능입니다. 두 사람을 직접 연결하기 위해 내 기기에 닿을 수 있는 모든 주소를 모아, 권한 요청 없이 페이지에 제공합니다. 그 주소 중 하나가 내가 숨기던 주소일 때 유출이 됩니다. 대표적인 예는 VPN을 켠 상태의 실제 주소로, WebRTC는 웹 브라우징에 쓰는 인터페이스만이 아니라 모든 네트워크 인터페이스를 물을 수 있기 때문입니다.

WebRTC 유출은 어떻게 테스트하나요?

이 페이지에서 테스트를 시작하세요. 두 운영자의 STUN 서버 3곳에 묻고, WebRTC가 내놓은 모든 주소를 각 주소의 정체와 함께 나열하며, 라우팅 가능한 주소를 웹사이트가 이미 보는 주소와 비교합니다. VPN을 쓴다면 VPN을 끈 상태로 한 번, 켠 상태로 한 번 실행하세요. 두 실행의 차이가 답입니다.

VPN이 WebRTC 유출을 막아 주나요?

VPN만으로는 막지 못합니다. VPN은 트래픽이 가는 곳을 바꾸지만, WebRTC는 운영체제에 어떤 인터페이스가 있는지 물을 수 있고, 물리적 연결도 대개 그중 하나로 남아 있습니다. IETF 문서는 WebRTC가 “VPN의 공인 주소뿐 아니라 VPN이 작동하는 기반인 ISP의 공인 주소까지” 찾아낼 수 있다고 말합니다. 이 틈을 막는 VPN 클라이언트도 있으며, 내 VPN이 막았는지는 이 테스트가 알려 줍니다.

결과에 나오는 .local 주소는 무슨 뜻인가요?

mDNS이며, 좋은 소식입니다. 최신 브라우저는 사설 주소를 페이지에 제공하기 전에 .local로 끝나는 무작위 이름으로 바꾸므로, 사이트는 그 이름으로는 내 가정 네트워크에 대해 아무것도 알 수 없습니다. Chrome은 버전 76부터 이렇게 하고 있으며, Firefox도 마찬가지입니다. Safari는 한발 더 나아가, 사이트가 카메라나 마이크 권한을 얻기 전까지는 호스트 후보를 전혀 제공하지 않습니다. 테스트는 이를 발견 사항이 아니라 보호 기능이 작동하는 것으로 표시합니다.

mDNS가 로컬 IP를 숨기면 안전한가요?

부분적으로만 그렇습니다. mDNS는 사설 주소를 숨기고, 이미 공개된 주소는 분명히 숨기지 않도록 설계되었습니다. 이를 정의한 IETF 초안에 그렇게 적혀 있습니다. 내 공인 IPv4는 여전히 서버 반사 후보로 나타나며, 라우팅 가능한 IPv6 주소가 있는 기기는 그 주소를 직접 제공할 수 있습니다. 또한 Chrome은 이미 카메라나 마이크 권한을 가진 사이트에서는 이 보호 기능을 끕니다.

테스트가 가끔 “테스트 못 함”이라고 표시하는 이유는 무엇인가요?

그것이 사실이기 때문입니다. WebRTC가 꺼져 있거나, 확장 프로그램이나 정책으로 차단되었거나, 응답한 STUN 서버가 없다면(방화벽, 제한이 엄격한 VPN, UDP를 막는 네트워크) 아무것도 측정되지 않은 것입니다. 대부분의 도구는 이런 상황에서 초록색 체크 표시를 보여 주는데, 이는 유출 테스트가 할 수 있는 가장 오해를 부르는 일입니다. 이 테스트는 무슨 일이 있었는지 말하고, 어떤 서버가 응답하지 않았는지 밝힙니다.

Firefox에서 WebRTC를 끄려면 어떻게 하나요?

Firefox가 문서로 안내하는 설정은 WebRTC를 끄는 것이 아니라 제한합니다. about:config에서 media.peerconnection.ice.default_address_only는 모든 주소 대신 주소 하나만 보내게 하고, media.peerconnection.ice.relay_only는 수집을 릴레이 후보로 제한합니다. 후자가 가장 많이 숨기지만 직접 통화가 깨집니다. 사설 주소 가림 처리인 media.peerconnection.ice.obfuscate_host_addresses는 이미 기본으로 켜져 있습니다. 하나를 바꿀 때마다 테스트를 다시 실행해 실제로 무엇이 달라졌는지 확인하세요.

Chrome에서 WebRTC 유출을 막으려면 어떻게 하나요?

Chrome은 일반 사용자에게 관련 설정을 제공하지 않습니다. 사설 주소의 mDNS 가림 처리가 기본으로 켜져 있으며, 그것이 받을 수 있는 보호입니다. Chrome과 같은 엔진을 쓰는 Edge에는 WebRtcLocalIpsAllowedUrls 엔터프라이즈 정책이 있습니다. 여전히 널리 추천되는 확장 프로그램은 효과가 없습니다. uBlock Origin은 버전 1.38에서 WebRTC 옵션을 제거했고, Google의 WebRTC Network Limiter는 Chrome 138에서 Manifest V2가 비활성화된 뒤로 실행되지 않습니다.

호스트 후보와 서버 반사 후보는 어떻게 다른가요?

호스트 후보는 내 기기 자체에 있는 주소입니다. 서버 반사 후보는 STUN 서버가 본 주소, 즉 NAT의 공인 쪽 주소로, 대개 웹사이트가 이미 내 연결에서 받는 주소입니다. 라우팅 가능한 호스트 후보가 더 심각한 발견입니다. 기기 자체의 주소이며, IPv6에서는 가정이 아니라 기기를 식별하기 때문입니다.

WebRTC 유출과 DNS 유출은 같은 것인가요?

아닙니다. WebRTC 유출은 주소를 드러내고, DNS 유출은 어떤 리졸버가 내 조회에 응답하는지 드러냅니다. DNS 유출이 있으면 트래픽 자체는 VPN을 거쳐도 제공업체가 내가 방문하는 모든 사이트를 알게 됩니다. 둘은 따로 실패하므로, 한쪽 결과가 깨끗해도 다른 쪽에 대해서는 아무것도 알 수 없습니다. VPN을 바꾼 뒤에는 저희 DNS 유출 테스트도 함께 실행하세요.

이 테스트는 내 IP 주소를 어딘가로 보내나요?

어떤 웹사이트든 볼 수 있는 만큼만 보냅니다. 화상 통화와 마찬가지로 브라우저가 STUN 서버에 연결하며, 그것이 바로 테스트입니다. 웹사이트에 무엇이 보이는지 알아내기 위해, 페이지는 DNS 유출 테스트와 마찬가지로 ipify.org와 저희 서버에 내 주소와 그 네트워크를 묻습니다. WebRTC가 찾은 주소는 브라우저 안에 남으며, 저희에게는 하나도 전송되지 않습니다. 테스트가 실행되는 동안 네트워크 패널을 지켜보세요.

EU 법에서 IP 주소는 개인정보인가요?

EU의 웹사이트 운영자에게 동적 IP 주소는, 그 운영자가 인터넷 제공업체가 보유한 정보로 나를 식별할 합법적인 수단을 가진 경우 개인정보입니다. 이는 2016년 10월 Breyer 사건(C-582/14)에서 유럽연합 사법재판소가 내린 판결입니다. 이 페이지가 테스트 중 WebRTC 부분을 저희 서버가 아니라 브라우저 안에서 진행하는 이유 중 하나입니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

WebRTC 유출 테스트

WebRTC 유출이란 무엇인가요?

WebRTC 유출은 어떻게 확인하나요?

VPN이 WebRTC 유출을 막아 주나요?

호스트 후보, 서버 반사 후보, 릴레이 후보는 각각 무엇인가요?

mDNS .local 주소란 무엇이며, 나를 보호해 주나요?

IPv6가 마지막으로 남은 유출인 이유

브라우저별로 WebRTC 유출을 막는 방법

WebRTC 유출, DNS 유출, IP 유출은 어떻게 다른가요?

이 테스트가 STUN 서버 여러 곳에 묻는 이유

내 IP 주소는 개인정보인가요?

WebRTC 유출 테스트: 자주 묻는 질문

WebRTC 유출이란 무엇인가요?

WebRTC 유출은 어떻게 테스트하나요?

VPN이 WebRTC 유출을 막아 주나요?

결과에 나오는 .local 주소는 무슨 뜻인가요?

mDNS가 로컬 IP를 숨기면 안전한가요?

테스트가 가끔 “테스트 못 함”이라고 표시하는 이유는 무엇인가요?

Firefox에서 WebRTC를 끄려면 어떻게 하나요?

Chrome에서 WebRTC 유출을 막으려면 어떻게 하나요?

호스트 후보와 서버 반사 후보는 어떻게 다른가요?

WebRTC 유출과 DNS 유출은 같은 것인가요?

이 테스트는 내 IP 주소를 어딘가로 보내나요?

EU 법에서 IP 주소는 개인정보인가요?

DNS 유출 테스트

IPv6 테스트

IP 조회

내 ISP 확인

DNS 조회

Traceroute

WebRTC 유출이란 무엇인가요?

WebRTC 유출은 어떻게 확인하나요?

VPN이 WebRTC 유출을 막아 주나요?

호스트 후보, 서버 반사 후보, 릴레이 후보는 각각 무엇인가요?

mDNS .local 주소란 무엇이며, 나를 보호해 주나요?

IPv6가 마지막으로 남은 유출인 이유

브라우저별로 WebRTC 유출을 막는 방법

WebRTC 유출, DNS 유출, IP 유출은 어떻게 다른가요?

이 테스트가 STUN 서버 여러 곳에 묻는 이유

내 IP 주소는 개인정보인가요?

WebRTC 유출 테스트: 자주 묻는 질문

WebRTC 유출이란 무엇인가요?

WebRTC 유출은 어떻게 테스트하나요?

VPN이 WebRTC 유출을 막아 주나요?

결과에 나오는 .local 주소는 무슨 뜻인가요?

mDNS가 로컬 IP를 숨기면 안전한가요?

테스트가 가끔 “테스트 못 함”이라고 표시하는 이유는 무엇인가요?

Firefox에서 WebRTC를 끄려면 어떻게 하나요?

Chrome에서 WebRTC 유출을 막으려면 어떻게 하나요?

호스트 후보와 서버 반사 후보는 어떻게 다른가요?

WebRTC 유출과 DNS 유출은 같은 것인가요?

이 테스트는 내 IP 주소를 어딘가로 보내나요?

EU 법에서 IP 주소는 개인정보인가요?

관련 도구

DNS 유출 테스트

IPv6 테스트

IP 조회

내 ISP 확인

DNS 조회

Traceroute