WebRTC Leak Test

Introduction

The DeviceHub WebRTC Leak Test is a free online ICE candidate diagnostic that creates a local RTCPeerConnection, gathers host, srflx, relay, and prflx IP addresses from candidate lines and local SDP, compares them against your public HTTP IP from DeviceHub and ipify resolution, and displays every extracted address on screen, without pretending to be a full penetration test or a replacement for VPN vendor desktop suites. Privacy-conscious VPN users, remote workers validating split-tunnel browsers, WebRTC application developers reproducing ICE behavior, support agents collecting candidate lists for VoIP tickets, and security trainers demonstrating why WebRTC bypasses naive HTTP-only leak checks all click Start once and read categorized IPs. DeviceHub states limits plainly: WebRTC leak shows candidate IPs and those values are privacy-sensitive; you should understand what you share on-screen before screenshotting or screen-sharing during a support call. This page uses a public STUN server to encourage srflx candidates; it does not guarantee every real-time call path, does not audit TURN credentials, and does not certify regulatory compliance. Pair with DNS Privacy Check for best-effort DoH and HTTP IP context without definitive resolver logging. Pair with IP Address for Cloudflare edge metadata on the HTTP path. Pair with IPv6 Test when family differences matter beside ICE. Pair with Browser category WebRTC Test when you only need RTCPeerConnection constructor smoke without ICE IP disclosure. Journalists demonstrating VPN marketing gaps capture host rows beside HTTP IP in the same screenshot, with consent. Hospital telehealth admins verify managed Chrome still exposes ICE after policy pushes. Gamers blaming VPN for Discord voice issues attach candidate mismatches beside HTTP IP in tickets. Enterprise zero-trust reviewers document that browser WebRTC can reveal LAN segments even when HTTP egress looks clean. Video conferencing vendors reproducing one-way audio tickets compare ICE lists before blaming codecs. Privacy researchers teaching campus workshops emphasize that host candidates expose RFC1918 space even when srflx looks VPN-clean. Managed Chrome policies that disable WebRTC entirely show unsupported here, distinct from leak-positive results. IPv6 literals in candidate lines appear when dual-stack interfaces participate, compare with IPv6 Test when family confusion spans tools.

What this tool does

On Start, the page resolves public HTTP IP via resolvePublicIp, instantiates RTCPeerConnection with a public STUN URL, creates a data channel, runs createOffer and setLocalDescription, listens for onicecandidate events until gathering completes or a timeout elapses, parses candidate lines into host, srflx, relay, and prflx buckets, deduplicates IPs, flags host and srflx addresses that differ from the public HTTP IP, and renders candidate lists on screen. Stop closes the peer connection and clears timers. It does not send media, does not upload SDP to DeviceHub servers, and does not dial arbitrary TURN beyond default ICE behavior. Privacy copy warns that local and public IPs appear visibly. Unsupported browsers disable Start when RTCPeerConnection is missing. Permissions remain none for DeviceHub metadata, WebRTC itself exposes IPs without microphone grants on this diagnostic. mDNS obfuscation on some browsers may reduce host IP literal exposure, results vary by engine and policy. Relay-only VPN configurations may show fewer srflx surprises while host LAN IPs still appear from the local interface list. Candidate raw lines truncate for display width but retain type and protocol labels for ticket paste. pagehide and Stop both tear down peers to avoid leaving gathering active on kiosks. Timeout gathering ends with partial lists rather than infinite spinners, document timeout state when srflx might arrive late on slow STUN paths.

When to use it

Run WebRTC Leak Test when a VPN claims to hide your IP yet voice or video apps behave oddly, after enabling WebRTC blockers or enterprise policies, before pasting ICE logs into WebRTC bug tickets, and when DNS Privacy Check inconclusive rows need candidate-side comparison. Prefer WebRTC Test in Browser category when you only need constructor presence without IP lists. Prefer IP Address for a calm HTTP-only egress snapshot. Avoid screen-sharing this tab during public streams without reviewing host rows first. Avoid treating no mismatch as proof against all leak classes, HTTP-only VPNs and timing windows differ. Run inside the same browser profile as the failing meet.google.com or Discord session. Run after toggling VPN kill switch settings. Run on mobile Chrome where WebView apps may differ from the system browser ICE list. Run before enabling browser extensions that promise WebRTC leak protection so you capture before-and-after candidate sets. Run when split-tunnel corporate VPN docs claim WebRTC is blocked yet browser ICE still enumerates host adapters. Run after Firefox ESR upgrades when telehealth apps suddenly fail, constructor versus leak tools answer different questions.

How it works

ICE gathering enumerates local interfaces as host candidates, contacts STUN for srflx reflexive addresses, and may allocate relay candidates when TURN is configured, this diagnostic uses default browser ICE with a public STUN server only. Candidate strings embed IP literals parsed by splitting SDP lines. Public HTTP IP comes from the same DeviceHub and ipify stack as other network tools, enabling side-by-side mismatch detection. Gathering stops on icegatheringstate complete, null candidate, Stop click, or timeout, whichever comes first. pagehide closes connections to avoid orphaned peers. Secure HTTPS context is expected for modern WebRTC. DeviceHub does not store candidate lists server-side during this test. Third-party STUN sees STUN binding requests from your client, standard WebRTC behavior, not hidden. Compare honesty limits with DNS Privacy Check which cannot log ISP resolvers, together they form hints, not courtroom proof. prflx peer-reflexive candidates appear on some paths when connectivity checks discover alternate routes, listed separately from srflx when parsed. Data channel creation encourages ICE gathering without requesting camera tracks, keeps permissions none while still producing candidates.

Step-by-step instructions

1. Open WebRTC Leak Test over HTTPS in the browser profile and VPN state where the symptom occurs; warn viewers if screen-sharing because IPs will appear.
2. Click Start and wait for HTTP IP resolution and ICE gathering to populate host, srflx, relay, and prflx rows.
3. Review mismatch lines comparing host and srflx IPs against public HTTP IP; note that local LAN host addresses are expected and sensitive.
4. Click Stop when finished so the peer connection closes; do not leave gathering running on shared kiosks.
5. Open DNS Privacy Check and IP Address to layer HTTP and DoH hints beside ICE results without expecting any single tool to certify VPN perfection.
6. For constructor-only smoke without IP disclosure, use Browser category WebRTC Test instead of this Network leak diagnostic.

Common problems

Users panic at 192.168 host rows without understanding normal ICE host candidates, education matters. Expecting zero IPs on screen misunderstands WebRTC leak diagnostics entirely. RTCPeerConnection missing in embedded WebViews looks like DeviceHub failure, it is environment stripping. VPNs that proxy HTTP only may show clean HTTP IP while srflx reveals real egress, mismatch row is the clue. mDNS host candidate hiding on some Chromium builds reduces literal host IPs, not universal. Stopping early before gathering completes yields incomplete srflx lists. Comparing ICE results from a headless automation profile to interactive Chrome misleads, label capture context. Assuming relay rows always appear forgets that TURN must be configured, this test uses STUN only. Firefox private windows may differ from normal profiles, capture the profile users actually call from. Corporate policies blocking UDP entirely can yield empty srflx while host rows remain, network path issue separate from DeviceHub parsing.

Privacy explanation

WebRTC leak test displays candidate IP addresses on your screen including possible local LAN host addresses, that is privacy-sensitive by design. DeviceHub warns before and during the test. Public HTTP IP resolution may use /api/client-ip or ipify fallbacks with third-party observation when fallbacks run. STUN servers see binding requests from your client during gathering. DeviceHub does not upload candidate lists to its servers for this page. Permissions metadata stays none; no camera or microphone is requested here. Stop the test on shared PCs before walking away. Redact screenshots before posting publicly if host IPs reveal internal network topology. Understanding what you share on-screen is a user responsibility DeviceHub cannot remove without defeating the diagnostic purpose. Support agents on remote desktop sessions must ask the user to read candidate rows locally, the agent's ICE list reflects the agent machine, not the user's VPN path.