DNS, IP and WebRTC Leaks: How to Test Your VPN and Fix Every Leak

A VPN is only as private as its weakest connection. If your real IP address, your DNS lookups or a WebRTC request slips out around the encrypted tunnel, the websites you visit and the network you are sitting on can still see who and where you are, even though the VPN app proudly shows "Connected".

The good news is that leaks are easy to test for and, in almost every case, easy to fix. This guide explains the leak types, how to test and read the results, and how to close the gaps on every major platform and browser.

What is a VPN leak?

With a working VPN, every packet is encrypted and sent to the VPN server, which forwards it using its own IP address. Websites see the server's address and your provider sees only an encrypted stream. You can see how this works in our guide to why you should use a VPN.

A leak is any situation where some of that traffic, or information about it, bypasses the tunnel. Leaks rarely mean the encryption has been broken; the operating system, browser or network simply sends something by a different route. Typical causes include:

• The operating system using the DNS server supplied by your router or ISP instead of the VPN's DNS.
• The VPN handling IPv4 only while the network also offers IPv6.
• The browser using WebRTC to gather local and public addresses for real-time communication.
• The VPN connection dropping for a few seconds and apps continuing to send data over the normal connection.
• Split tunnelling rules that exclude an app or website you assumed was protected.

Why leaks matter

Your IP address reveals your approximate location and internet provider; DNS queries reveal every domain you visit, even over HTTPS. If you use a VPN to protect yourself on public Wi-Fi, to keep your browsing away from your ISP, or to reach content in another region, a leak quietly undoes most of the benefit.

The four leak types explained

IP address leaks

An IP leak is the most obvious failure: a website sees your real public IP address instead of the VPN server's. It usually happens when the tunnel has not fully come up, has dropped, or an app is excluded by split tunnelling.

DNS leaks

Before your device can connect to example.com, it must ask a DNS resolver for that name's IP address. If those questions go to your ISP's resolver instead of through the VPN, your ISP or the Wi-Fi operator can log the sites you visit. On Windows in particular, the system may send queries through several network adapters at once and use whichever answers first, which is a classic source of DNS leaks.

WebRTC leaks

WebRTC is a browser technology used for video calls, voice chat and peer-to-peer file transfer. To set up a direct connection, the browser gathers "ICE candidates", which are the addresses at which it might be reachable, and a web page's JavaScript can read them. Modern browsers hide your local network address behind a random mDNS name by default, but in some configurations a page can still learn a public address that did not come through the VPN, particularly if the VPN is set up as a browser proxy rather than a system-wide tunnel.

IPv6 leaks

Many ISPs now give customers both an IPv4 and an IPv6 address. If a VPN tunnels only IPv4, the operating system will happily send traffic to IPv6-capable websites over your normal connection, fully exposing your real IPv6 address. A good VPN client either tunnels IPv6 too or blocks it while connected.

How to test for leaks, step by step

A leak test is only meaningful if you know what "normal" looks like, so always start with a baseline.

Step 1: Record your baseline

1. Disconnect from the VPN completely.
2. Open our What Is My IP tool and note your public IP address, the location and the provider name shown.
3. Run the WebRTC leak test on the same page and note any addresses it lists.
4. If you have IPv6, note whether an IPv6 address is detected.

Step 2: Connect and test again

1. Connect to a VPN server, ideally in a different country from your own so the difference is easy to spot.
2. Reload the What Is My IP page (a hard refresh with Ctrl+F5 or Cmd+Shift+R avoids cached results).
3. Confirm the IP address and location now belong to the VPN server, not to you.
4. Run the WebRTC test again. Your real public IP from step 1 must not appear anywhere in the results.
5. Use an extended DNS leak test (these work by making your device resolve unique random hostnames and recording which resolvers ask for them). The resolvers listed should belong to the VPN provider, not to your ISP.

Step 3: Stress the connection

A connection that passes a test when everything is stable can still leak during transitions. Repeat the checks after:

• Switching from Wi-Fi to mobile data or to another Wi-Fi network.
• Putting the device to sleep and waking it up.
• Switching VPN servers or protocols.
• Deliberately interrupting the connection with the kill switch enabled, to confirm nothing loads while the tunnel is down.

How to interpret your results

Test pages show a lot of data, and not all of it is a problem.

Results that are fine

• The IP shown is the VPN server's and the location matches the server you chose. This is exactly what you want.
• WebRTC shows a random string ending in .local. That is an mDNS placeholder, which browsers use specifically to hide your local address.
• WebRTC shows only the VPN server's IP, or a private address such as 10.x.x.x belonging to the VPN's virtual adapter. Private ranges (10.x, 172.16-31.x, 192.168.x) are not routable on the internet and do not identify you.
• DNS servers belong to the VPN provider or to a public resolver used by the VPN server, located near that server.

Results that indicate a leak

• Your baseline public IP (IPv4 or IPv6) appears anywhere while connected.
• The DNS test lists your ISP's resolvers, or resolvers in your home country when you are connected to a server abroad.
• An IPv6 address appears that matches your baseline, while the IPv4 address is the VPN's.
• Pages load normally for a few seconds after the VPN drops, with the kill switch supposedly enabled.

The kill switch: your safety net

Even a well-configured VPN will occasionally disconnect: a Wi-Fi hand-off, a sleeping laptop, a server restart. Without protection, apps silently fall back to the normal connection. A kill switch blocks all internet traffic unless it goes through the tunnel.

There are two broad kinds:

• System-level (firewall) kill switch: rules in the operating system firewall allow traffic only through the VPN interface and to the VPN server itself. This is the most robust approach because it works even if the VPN app crashes.
• App-level kill switch: the VPN app closes or blocks selected applications when the connection drops. This is useful for specific programs but offers less complete protection.

PD-Proxy Premium includes a kill switch and private DNS in the desktop and mobile apps, and our Wi-Fi Protection feature can connect automatically when you join an untrusted network, so the tunnel is up before your apps start talking.

How to fix leaks on each platform

Start with the basics in your VPN app: enable the kill switch, enable the provider's DNS (sometimes called "private DNS" or "DNS leak protection"), and enable IPv6 protection if offered. Then check the platform-specific settings below.

Windows

• In the VPN app, turn on the kill switch and DNS leak protection, and use WireGuard or OpenVPN rather than older protocols.
• Open Settings > Network & internet, select your Wi-Fi or Ethernet adapter and check the DNS server assignment. If you have manually set an ISP or third-party DNS there, the VPN app normally overrides it while connected, but remove it if tests show leaks.
• Uninstall old VPN clients and leftover virtual adapters.
• If IPv6 leaks persist and your VPN app has no IPv6 protection, you can untick Internet Protocol Version 6 (TCP/IPv6) in the adapter properties (Control Panel > Network Connections) as a last resort.

macOS

• Enable the kill switch and DNS protection in the VPN app, and allow its network extension or VPN configuration when macOS asks.
• Check System Settings > Network > Wi-Fi > Details > DNS for manually added servers.
• Look under System Settings > Network and General > Login Items & Extensions for other VPN, proxy or filtering apps that may compete for DNS and routing, and remove the ones you do not use.

Linux

• Many distributions use systemd-resolved. Run resolvectl status while connected and confirm the VPN interface carries the DNS server and a routing domain of ~. so that all queries go through it.
• With WireGuard's wg-quick, set DNS = in the configuration so it installs the tunnel's resolver; with OpenVPN, use the update-resolv-conf or update-systemd-resolved scripts.
• For a kill switch, use firewall rules (nftables, iptables or ufw) that allow outbound traffic only on the tunnel interface and to the VPN server's address.
• Check ip -6 addr and ip -6 route to see whether IPv6 traffic has a route outside the tunnel.

Android

• Go to Settings > Network & internet > VPN (the path varies slightly by manufacturer), tap the gear next to your VPN app and enable Always-on VPN and Block connections without VPN. This is Android's built-in, system-level kill switch.
• Check Private DNS in the network settings. If it is set to a specific provider hostname, DNS queries may go to that provider instead of through the VPN's DNS; "Automatic" or "Off" usually lets the VPN manage DNS. Test to confirm.
• Some manufacturers add aggressive battery optimisation that can stop VPN apps in the background; exempt your VPN app.

iOS and iPadOS

• Use the VPN app's "connect on demand" or auto-connect option, which relies on Apple's VPN On Demand rules to bring the tunnel up automatically.
• Check Settings > General > VPN & Device Management for leftover VPN or DNS profiles from other apps and remove them.
• Be aware that iOS may keep some existing connections open, and some Apple services may communicate outside the tunnel, when a VPN connects. Connecting before you open sensitive apps, and keeping auto-connect on, reduces the window.

For a deeper look at phone-specific settings, read our mobile VPN and smartphone privacy guide.

Fixing WebRTC and DNS leaks in browsers

The single most effective fix for WebRTC leaks is to use a real, system-wide VPN tunnel rather than a browser-only proxy. When all traffic leaves through the VPN interface, WebRTC can only discover the VPN's address. If you still see leaks, adjust the browser itself:

Firefox

Type about:config in the address bar, accept the warning and set media.peerconnection.enabled to false. This disables WebRTC entirely, so video calls in the browser will stop working. For a gentler approach, keep it enabled and rely on the system-wide VPN.

Chrome, Edge and other Chromium browsers

There is no simple built-in switch to disable WebRTC, though recent versions hide local addresses using mDNS by default. If you need more control, a reputable extension that restricts WebRTC's IP-handling policy can help; Safari users are normally covered by its restrictive defaults plus a system-wide VPN.

Browser DNS over HTTPS

Firefox, Chrome and Edge can send DNS queries over HTTPS to a chosen resolver. This encrypts lookups, but it also means the browser may bypass the VPN's DNS. When a VPN is active, it is usually best to let the VPN handle DNS so all apps behave the same way. Test with both settings and keep the one that shows only the VPN's resolvers.

Leak-proofing checklist

Frequently asked questions

Is a DNS leak dangerous if websites use HTTPS?

Yes, to a degree. HTTPS encrypts page content, but a DNS leak still reveals which domains you visit to whoever operates the resolver, typically your ISP or the local network. That list alone can be very revealing, so it is worth fixing.

Why does the leak test show a location in a different city from my VPN server?

IP geolocation databases are compiled by third parties and are not always precise. As long as the IP address belongs to the VPN server and none of your baseline addresses appear, a slightly different city is not a leak. You can compare with the locations listed on our servers page.

Does a WebRTC leak mean my VPN is broken?

Not necessarily. It usually means the browser is revealing an address the VPN does not control, most often with browser-only proxies or excluded apps. Using a system-wide VPN and adjusting browser settings as described above usually resolves it.

Should I disable IPv6 completely?

Only if your VPN cannot tunnel or block IPv6 and tests show a leak. Disabling IPv6 can occasionally cause issues on IPv6-only networks, so prefer a VPN client that handles IPv6 protection for you.

Conclusion

Leaks are one of the few ways a VPN can fail without you noticing, which is why testing matters. Record a baseline, compare it with your connected results, and fix anything that shows up with a kill switch, VPN-provided DNS, IPv6 protection and sensible browser settings. If you want these protections built in, PD-Proxy Premium includes a kill switch and private DNS on every supported platform, and you can check the result any time on our IP and WebRTC test page.