# What is a WebRTC leak? > A WebRTC leak is a page learning your real IP address through WebRTC's STUN requests, which can go around a proxy or VPN instead of through it. Source: https://mosaicbrowser.com/glossary/webrtc-leak ## WebRTC leak: when a page finds the address behind your proxy A WebRTC leak is when a web page learns an IP address you meant to hide, usually your real public address behind a proxy or VPN, because WebRTC sends its own UDP connectivity checks outside the browser's proxy. The page reads the address from the ICE candidates WebRTC gathers, with no permission prompt. ![WebRTC leak, drawn as a mosaic of tiles](https://mosaicbrowser.com/covers/webrtc-leak.webp) WebRTC is the part of the browser that makes video calls and peer-to-peer connections work. To connect two people directly, it has to find every route to the machine it runs on, so it asks the network. A page can start that process with a few lines of JavaScript, read the results, and close the connection without ever placing a call. ## How a WebRTC leak happens When a page creates an `RTCPeerConnection`, the browser gathers ICE candidates: the addresses a peer could use to reach it ([MDN](https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate)). Host candidates are the machine's own network interfaces. Server-reflexive candidates, `srflx`, come from asking a STUN server "what address do you see me at?" over UDP. That UDP request is the leak. A browser proxy carries web traffic, and most proxies do not carry UDP at all. So unless the browser is told otherwise, the STUN request goes straight out of your network, and the STUN server answers with your real public address. The page reads it from the candidate. The IETF's [RFC 8828](https://www.rfc-editor.org/rfc/rfc8828) names this case directly: when a client is behind a proxy but direct internet access is permitted, "WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client." Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Matched to the exit](https://mosaicbrowser.com/features/exit-matching) ## What a site does with it A site that sees a proxy exit in Frankfurt and a WebRTC candidate in Vienna knows two things: the visitor is behind a proxy, and where they really are. Every profile on one computer that leaks shows the same home address, so the leak links them all to each other as well, whatever their [browser fingerprints](https://mosaicbrowser.com/glossary/browser-fingerprint) say. For anyone keeping accounts apart, that undoes the proxy entirely. Local addresses were once part of the leak too. Chrome now replaces host candidates with random `.local` mDNS names, so a page sees a name like `a1b2c3….local` instead of `192.168.1.20`. The real local address still appears once a page has been granted camera or microphone access, and it is the same for every profile on the machine. ![A Mosaic leak test: every surface a site reads, checked from inside the profile page](https://mosaicbrowser.com/shots/leak-test.png) *The leak test runs inside the profile's own page* ## How to check for one Connect through your proxy, then open a WebRTC test page such as [BrowserLeaks' WebRTC test](https://browserleaks.com/webrtc). Read every public address it lists. If one of them is your own address and not the proxy's exit, you have a leak. Run it again after any change, because a fix you cannot see working is a guess. The Chrome settings, policies and extension that close the leak by hand are in [fix a WebRTC leak in Chrome](https://mosaicbrowser.com/guides/fix-webrtc-leak-in-chrome). ## How Mosaic handles it When a profile has a proxy and the setting that blocks non-proxied UDP is on, as it is by default, Mosaic launches the engine with `--webrtc-ip-handling-policy=disable_non_proxied_udp`, so WebRTC cannot send UDP around the proxy. It stops WebRTC from going around the proxy; it does not route WebRTC through it. mDNS hiding stays on, as in stock Chrome. Measured on our own engine, one fresh browser per run: with no policy, WebRTC gathered 2 candidates, one carrying the computer's real public address; with the policy, it gathered 0, with `RTCPeerConnection` still present. That is what any machine on a network that blocks UDP looks like, where a browser with no WebRTC at all looks like nothing real. We found our own mistakes on the way there. Two of the three WebRTC switches our launcher used to send, `--webrtc-ip` and `--force-webrtc-ip-handling-policy`, do not exist in Chromium, which accepts an unknown switch without a word. Since then, a switch name is checked against the engine binary before we rely on it. The engine also gives each profile its own local address for the case where camera or microphone access is granted, and each profile's timezone and language follow its proxy's exit ([matched to the exit](https://mosaicbrowser.com/features/exit-matching)), so the address a site does see agrees with the rest of the profile. ## Sources 1. [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828), read November 2, 2026 2. [MDN: RTCIceCandidate](https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate), read November 2, 2026 3. [BrowserLeaks: WebRTC Leak Test](https://browserleaks.com/webrtc), read November 2, 2026 ## Questions ### Does a VPN stop WebRTC leaks? Not always. RFC 8828 describes a split-tunnel VPN letting WebRTC discover both the VPN's address and the ISP address underneath it. A full-tunnel VPN that carries all traffic, UDP included, does not leak that way. ### Is disabling WebRTC the best fix? Removing WebRTC entirely makes a browser that no real Chrome resembles, because every Chrome has RTCPeerConnection. Stopping it from sending UDP around the proxy keeps the API present and gathers nothing to leak. ### Can a WebRTC leak reveal my local IP address? Chrome hides local addresses behind random .local mDNS names by default. The real local address becomes visible to a page once it has been granted camera or microphone access. ### How do I test for a WebRTC leak? Browse through the proxy and open a WebRTC leak test page. If any address it lists is not the proxy's exit, the browser is leaking. ## Related [How to fix a WebRTC leak in Chrome](https://mosaicbrowser.com/guides/fix-webrtc-leak-in-chrome): How to fix a WebRTC leak in Chrome: one setting stops WebRTC sending UDP around your proxy, by policy, flag or Google's extension. Measured: 2 to 0. [How to check your browser fingerprint, and read the result](https://mosaicbrowser.com/guides/check-your-browser-fingerprint): How to check your browser fingerprint: a uniqueness test says how rare it is, a consistency scanner whether it could be real. Run each twice. [Residential proxy: an exit on a home internet connection](https://mosaicbrowser.com/glossary/residential-proxy): A residential proxy sends your traffic out through an address an ISP assigned to a home connection, so sites see a household rather than a data center. [Browser fingerprint: what a site can read about your machine](https://mosaicbrowser.com/glossary/browser-fingerprint): A browser fingerprint is the set of values a site reads about your browser and computer, which together recognize you without cookies. What goes into one. [Match browser timezone to proxy exits, automatically](https://mosaicbrowser.com/features/exit-matching): No need to match browser timezone to proxy by hand: Mosaic sets each profile's timezone, language and location from the measured exit, before every launch.    ## See webRTC leak on a real profile Mosaic shows the values a site reads, per profile, and runs a leak test from inside the profile’s own page. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.