What is my IP leaking? WebRTC, DNS and IPv6 leaks explained

Changing the address a website sees is the easy part. The hard part is making sure nothing else on your machine quietly reveals the address you were trying to hide. Three channels do this most often, and all three bypass the proxy or VPN because they use a different code path inside your operating system or browser than ordinary web requests. If you only test with a "what is my IP" page and it shows the exit address, you have checked the front door while three side doors stand open.

The three classic leaks are WebRTC, DNS and IPv6. Each has a different cause and a different fix. Understanding the mechanism matters, because a "leak protection" toggle that you cannot verify is just a promise.

WebRTC is the browser technology behind in-page video calls. To connect two peers directly it needs to know your candidate IP addresses, so it asks a STUN server for them — and it does this from inside the browser using UDP, often skipping the proxy entirely. A script on any page can read those candidates through the RTCPeerConnection API without permission, and among them may sit your real local and public IP.

SOCKS5 and HTTP proxies set at the application level do not capture this traffic, which is why a proxied browser can still leak. Fixes: disable WebRTC where you do not need it (in Firefox set media.peerconnection.enabled to false; in Chromium use an extension that forces proxied UDP or disables non-proxied ICE), or run the browser inside a full-tunnel VPN so even WebRTC's UDP leaves through the tunnel. Modern browsers also mask the local address behind an mDNS .local hostname, which helps but does not always cover the public candidate.

A DNS leak happens when your device resolves hostnames through your ISP's resolver instead of through the tunnel. The page loads via the proxy, but the lookup that turned example.com into an IP went to your provider — so your ISP still sees every domain you visit. With proxies the cure is socks5h:// instead of socks5://, which asks the proxy to resolve remotely; with a VPN, DNS must be pushed inside the tunnel. Layering DNS over HTTPS or DNS over TLS hardens it further.

An IPv6 leak is the modern trap: your tunnel carries IPv4, but your OS still has native IPv6 connectivity, so any IPv6-capable site is reached directly, exposing your real v6 address. Either disable IPv6 while connected, or use a VPN that routes IPv6 too. See our DNS leak test guide and IPv6 proxies for the details.

Never assume; verify. Use the s4m privacy tools and a header-echo endpoint to confirm what a destination actually receives, and run a dedicated WebRTC/DNS/IPv6 leak test with your proxy or VPN active. Do it once for a browser profile and again whenever you change networks. For quick experiments the free proxy list is fine, but remember that a bare HTTP or SOCKS proxy protects only the traffic that goes through it — WebRTC and IPv6 are exactly the parts that do not. When leak-proofing across every app matters more than per-app control, a full-tunnel VPN is the more complete answer, and an authenticated proxy with socks5h handles the DNS half cleanly.