ipleak.net

Connect to your VPN, open ipleak.net, and look at the DNS detection section. If any DNS server listed there belongs to your ISP or your local network instead of your VPN provider, your system is leaking DNS queries. The fix is to force DNS through the VPN tunnel — usually in the VPN client's settings, sometimes in your OS network settings — then re-run the check to confirm only VPN DNS appears.

This applies to any setup where you expect DNS to travel inside a VPN or proxy tunnel: VPN users, Tor users, and anyone testing a privacy tool. It does not apply if you are not using a tunnel — then seeing your ISP's DNS is normal.

What the mydns check actually shows

The DNS detection area on ipleak.net resolves a set of random hostnames through your system's configured resolvers and displays which DNS servers answered. The page states the logic plainly: "If you are now connected to a VPN and between the detected DNS you see your ISP DNS, then your system is leaking DNS requests."

Two things to note before you trust a result:

• JavaScript must be enabled. The page shows "JavaScript required" placeholders for the DNS, WebRTC, and torrent sections until scripts run. A blank or "Pending, please wait" result means the check has not completed, not that you are clean.
• The check reflects your resolver, not your traffic. It tells you which DNS servers your system used for these lookups. It does not prove every query goes the same way, but a leak here is a strong signal.

Step-by-step: run the check

1. Disconnect the VPN first, then reconnect it. A stale tunnel can leave old resolver settings in place. Reconnecting forces the client to reapply its DNS configuration.
2. Open ipleak.net in a browser and allow JavaScript.
3. Wait for the DNS detection section to move from "Pending, please wait" to a list of DNS servers.
4. Read the list. Compare each entry against:
   • Your VPN provider's published DNS server addresses.
   • Your ISP's DNS servers (often visible in your router's admin page or your OS network settings).
   • Your local router address (commonly 192.168.1.1 or similar) — a local resolver forwarding to the ISP is still a leak.
5. Check the IP address details block on the same page. If the IP, ISP, and country shown match your VPN, the tunnel itself is working; a DNS leak alongside a correct IP means only the resolver path is broken.

If you see only your VPN's DNS servers, you are done. If you see ISP or local DNS, continue below.

Deciding whether it matters for you

The page's own framing is worth keeping in mind: this is the kind of information every site you visit, plus its advertisers and embedded widgets, can collect. DNS is one channel among several.

Common causes of a DNS leak

• VPN client DNS setting not applied. Some clients have a separate "use provider DNS" or "DNS leak protection" toggle that is off by default.
• Manual DNS set in the OS. If you once set 8.8.8.8 or a similar public resolver in your network adapter, it can override what the VPN pushes.
• IPv6 bypassing the tunnel. Many VPNs tunnel IPv4 only. If your ISP hands out IPv6 and your system prefers it, DNS can go out over IPv6 outside the tunnel. The related question on IPv6 leaks covers this path in detail.
• WebRTC exposing requests. WebRTC uses STUN to discover your public IP and can reveal addresses the tunnel should hide. The page notes that if you are connected to a VPN and still see your ISP IP, your system is leaking WebRTC requests.
• Split tunneling. If the VPN client is configured to route only some apps through the tunnel, the excluded apps use the system resolver.

Fixes by platform

VPN client settings (try first)

Look for options named "DNS leak protection," "Use VPN DNS," "Block outside DNS," or similar. Enable them, reconnect, and re-test. This is the least invasive fix and covers most cases.

Windows

1. Open Settings → Network & Internet → your adapter → Edit DNS server assignment.
2. Set it to Automatic (DHCP) so the VPN can push its resolver, or enter your VPN provider's DNS addresses manually.
3. If IPv6 is the leak path, disable IPv6 on the adapter or set the VPN to handle it.

macOS

1. Open System Settings → Network → your active service → Details → DNS.
2. Remove any manually added DNS servers so the VPN's settings take effect.
3. Check Advanced → TCP/IP for IPv6 configuration if leaks persist.

Firefox (WebRTC)

The page gives the exact steps: type about:config in the address bar, search for media.peerconnection.enabled, and double-click to set it to false. This disables WebRTC entirely, which stops the STUN-based IP discovery but also breaks WebRTC-dependent apps like browser video calls.

Chrome

The page's excerpt on Chrome is cut off, so treat the Firefox method as the documented example and check Chrome's current WebRTC handling separately if you need it.

Verify the fix

1. Reconnect the VPN.
2. Reload ipleak.net and let the DNS detection finish.
3. Confirm the DNS list contains only your VPN provider's servers — no ISP entries, no local router address.
4. Check the IP block still shows your VPN's IP and ISP.
5. If you disabled WebRTC, confirm the WebRTC section no longer reports your ISP IP.

If the leak persists after all of the above, the tunnel itself may not be capturing DNS — try a different VPN protocol (for example, switch between OpenVPN and WireGuard if your client offers both) and re-test.

Quick reference

• Check: ipleak.net → DNS detection section, JavaScript on, VPN connected.
• Leak signal: ISP DNS or local DNS appears in the list.
• First fix: enable DNS leak protection in the VPN client.
• Second fix: clear manual DNS in OS network settings.
• Third fix: disable IPv6 or WebRTC if either is the bypass path.
• Confirm: re-run the check and see only VPN DNS.

An IPv6 leak happens when your real IPv6 address reaches websites even though you are connected to a VPN. To check for one, open a leak-test page such as ipleak.net while the VPN is on and look at the IP addresses it reports: if you see your ISP's address instead of your VPN's, your system is leaking. To fix it, either block IPv6 in the browser or operating system, or use a VPN client that filters IPv6 traffic itself. The steps below cover detection, the differences between leak types, and the fixes.

Check for an IPv6 leak

1. Connect to your VPN and confirm the client shows an active connection.
2. Open ipleak.net in a browser. The page lists the IP addresses it can see, and it separates browser-default addresses from WebRTC-detected ones.
3. Compare what you see with your expectations:
   • Only the VPN's IP address appears → no leak.
   • Your ISP's IP address appears, especially an IPv6 address → you have a leak.
   • The page shows "JavaScript required" for a section → enable JavaScript, since the IP, WebRTC, DNS, and torrent checks all depend on it.

The site's own guidance states the test plainly: if you are connected to a VPN and you see your ISP IP, your system is leaking. The same logic applies to the DNS section — if your ISP's DNS servers show up among the detected resolvers, DNS requests are leaking.

Read the results correctly

• IP address section — shows the addresses the site can see directly. An IPv6 address belonging to your ISP here is the core IPv6 leak signal.
• WebRTC detection — WebRTC implements STUN (Session Traversal Utilities for NAT), a protocol that discovers the public IP address. If you are on a VPN and this section still shows your ISP IP, WebRTC requests are leaking.
• DNS detection — lists the DNS resolvers your queries reach. ISP DNS servers appearing here means DNS leaks, which is a separate problem from an IPv6 leak even though both expose your real network.
• Torrent address detection — a separate check for whether your torrent client exposes your real address.

IPv6 leak vs. DNS leak vs. WebRTC leak

These three are often confused because they all reveal information you wanted hidden, but they fail differently and need different fixes.

Because IPv6 and DNS leaks can share a root cause — a system that prefers IPv6 and bypasses the VPN tunnel — fixing IPv6 handling often resolves both, but you should re-test each section separately.

Fix an IPv6 leak

Browser-level fixes

The ipleak.net page documents the WebRTC fix for two browsers, which is useful because WebRTC is a common leak channel:

• Mozilla Firefox: type about:config in the address bar, scroll to media.peerconnection.enabled, and double-click it to set it to false.
• Google Chrome: the page begins describing a Chrome option but the excerpt cuts off, so treat the Firefox method as the documented example and check Chrome's current privacy settings for the equivalent control.

Disabling WebRTC stops the STUN-based IP discovery, but it does not by itself stop an IPv6 address from being used for normal connections. For that, block IPv6 at the browser or system level.

Operating-system level

Turning off IPv6 on the network adapter prevents the OS from using IPv6 at all, which removes the address a leak test could detect. The exact menu path differs by OS and version, so verify the current location for your system rather than following a fixed path. The trade-off: some services and local networks rely on IPv6, so disabling it can break connectivity in those environments.

VPN-client level

Many VPN clients include an IPv6 leak-protection or "block IPv6" setting that drops IPv6 traffic outside the tunnel instead of disabling it system-wide. This is usually the cleaner option because it keeps IPv6 available for non-VPN use while preventing leaks. Check your client's settings for a leak-protection or IPv6-blocking toggle.

Verify the fix

1. Reconnect the VPN.
2. Reload ipleak.net with JavaScript enabled.
3. Confirm the IP address section shows only the VPN's address and no ISP IPv6 address.
4. Check the WebRTC and DNS sections again — they should also show VPN-side values, not your ISP's.
5. If any section still shows your ISP, repeat the corresponding fix and re-test.

Common snags

• JavaScript disabled — every detection section on ipleak.net needs it; without it you only see partial results.
• Testing without the VPN connected — the test will show your real address by design, which is not a leak.
• Fixing one leak and assuming the others are gone — IPv6, DNS, and WebRTC are independent; verify each.
• Disabling IPv6 system-wide — effective, but it can break IPv6-only services, so prefer a VPN-level block where available.

A DNS leak happens when your device sends domain-name lookups to a DNS server outside your VPN tunnel — usually your ISP's resolver — so the sites you visit can still be logged even while your traffic is encrypted. You can check for one in seconds with a browser-based detector such as ipleak.net: connect your VPN, load the page, and look at the "DNS detection" result. If the detected DNS servers belong to your ISP or your real location rather than your VPN provider, you have a leak. This matters most when your reason for using a VPN is hiding what you visit, not just who you are.

What a DNS leak actually is

Every time you open a site, your device first asks a DNS resolver to translate the domain name (example.com) into an IP address. That query travels separately from your normal web traffic. A VPN is supposed to route both through its encrypted tunnel. A leak means the DNS query escapes the tunnel and goes to a resolver your VPN was meant to replace.

The practical consequence: your VPN provider sees an encrypted stream, but your ISP (or another resolver) still sees a list of the domains you requested. Your IP address may be hidden while your browsing destinations are not.

How to test for a DNS leak

ipleak.net runs the check in your browser and reports several things at once.

1. Connect your VPN first. The test is only meaningful while the VPN is active — that's the state you're trying to verify.
2. Open the detection page and wait. The DNS section shows "Pending, please wait" until results arrive; it requires JavaScript, so a script blocker will leave it blank.
3. Read the DNS results. The page states the rule directly: "If you are now connected to a VPN and between the detected DNS you see your ISP DNS, then your system is leaking DNS requests."
4. Compare against your real ISP. You need to know your ISP's DNS or its name to judge the result. If the listed resolvers match your VPN provider or a location you don't recognize as your own, the tunnel is holding.
5. Check the other panels too. The same page reports your IP addresses, WebRTC detection, and torrent address detection, so you can see whether the leak is DNS-specific or part of a broader exposure.

A clean result shows only your VPN's DNS servers. A leak shows your ISP's servers, your home country, or both.

Common causes

• VPN not set to route DNS. Some clients tunnel traffic but leave DNS to the operating system, which keeps using the ISP resolver.
• OS-level DNS overriding the VPN. Manually configured DNS on your adapter, or a router handing out its own resolver, can bypass the tunnel.
• IPv6 left uncovered. Many VPNs handle IPv4 only; if IPv6 is enabled, queries can slip out over it. ipleak.net lists IPv6 leak detection as a separate check for this reason.
• WebRTC exposure. WebRTC uses STUN to discover your public IP address. As the site notes, if you're on a VPN and still see your ISP IP, "your system is leaking WebRTC requests." This is an IP leak rather than a DNS leak, but it defeats the same goal.
• Split tunneling or a dropped tunnel. If only some apps use the VPN, or the tunnel drops without a kill switch, DNS can revert to the ISP.

How to fix it

• Enable DNS handling in your VPN client. Turn on any setting that forces DNS through the tunnel, and enable a kill switch so queries can't fall back when the connection drops.
• Set the VPN's DNS explicitly. Point your device at the resolver your VPN provides rather than "automatic."
• Disable IPv6 if your VPN doesn't support it, or confirm it does before leaving it on.
• Turn off WebRTC if you don't need it. The page gives the Firefox method: type about:config in the address bar, find media.peerconnection.enabled, and double-click to set it to false. Chrome requires an extension for the same effect.
• Re-test after every change. Fixes that look correct in settings still fail in practice; the detection page is the confirmation step.

When a DNS leak is a real risk — and when it isn't

It's a genuine problem if your threat model includes your ISP or network operator seeing which sites you visit — for example, circumventing local censorship or keeping browsing private from an employer's network. It matters less if you only use a VPN to hide your IP from the sites themselves, since those sites already know which domain you asked for.

Two caveats worth keeping in mind. First, a leak exposes destinations, not the content of encrypted traffic — HTTPS still protects what you send and receive. Second, seeing an unfamiliar DNS server isn't automatically a leak; VPN providers often route DNS through third-party resolvers, so identify the server before assuming the worst. The reliable test is the one the page states: on a VPN, your ISP's DNS should not appear.

Connect to your VPN, open a WebRTC detection page such as ipleak.net, and look at the "WebRTC detection" result. If it shows your ISP's IP address instead of your VPN's IP, your browser is leaking your real address through WebRTC and you should turn WebRTC off or restrict it. If the result matches your VPN IP, there is nothing to fix.

What a WebRTC leak actually is

WebRTC (Web Real-Time Communication) is the browser feature behind in-page video calls and peer-to-peer data transfer. To connect two devices directly, it uses a protocol called STUN (Session Traversal Utilities for NAT), which discovers the public IP address your device is reachable at.

That discovery happens independently of your normal browsing traffic. So even when your web traffic is routed through a VPN, WebRTC can still ask a STUN server for your public address and hand back the one your ISP assigned you. The detection page then displays that address, which is why a leak looks like "my VPN is on but the site sees my real IP."

Check for a WebRTC leak

1. Connect to your VPN and confirm it is actually active.
2. Open a leak-test page such as ipleak.net in the browser you normally use.
3. Find the WebRTC detection section. The page notes that if you are connected to a VPN and you see your ISP IP there, your system is leaking WebRTC requests.
4. Compare the WebRTC address with the IP shown in the page's IP address details. If they differ and the WebRTC one belongs to your ISP, you have a leak.

Some pages require JavaScript to run the detection, so allow scripts on the test page or the result will stay blank.

Fix it in Firefox

Firefox exposes WebRTC through a preference you can flip:

1. Type about:config in the address bar and accept the warning.
2. Search for media.peerconnection.enabled.
3. Double-click it to set the value to false.
4. Reload the leak-test page and check the WebRTC section again.

With the preference off, WebRTC is disabled entirely, so sites that rely on it for calls or peer-to-peer features will stop working. That is the trade-off: you close the leak, but you also lose WebRTC functionality in that browser.

Fix it in Chrome and Chromium-based browsers

Chrome does not offer the same simple on/off preference. The practical options are:

• Install an extension that blocks or spoofs WebRTC requests, then re-test.
• Use enterprise policy settings to restrict WebRTC behavior if you manage the machine.
• Use a separate browser profile or browser for WebRTC-dependent services, keeping your main browsing profile protected.

After any change, reload the detection page and confirm the WebRTC result no longer shows your ISP address.

Don't confuse WebRTC leaks with DNS or IPv6 leaks

These are three separate mechanisms and each has its own check on the same page:

The page's own guidance is parallel for each: if you are on a VPN and the detected value is your ISP's, that channel is leaking. Fixing WebRTC will not fix a DNS leak, and vice versa, so test each one after making changes.

Verify and know the limits

Re-run the WebRTC check after every change and confirm the detected address matches your VPN. Keep in mind that disabling WebRTC in one browser does not affect other browsers or apps on the same machine, and that a leak test only reflects the browser and network state at the moment you run it. If you switch VPN servers or reconnect, test again.

Connect to your VPN, open ipleak.net, and compare what it shows against what you expect. If any field still shows your ISP's IP address or DNS servers, you have a leak. The page tests four things at once: your public IP addresses (including WebRTC-discovered ones), your DNS resolvers, your torrent-visible address, and your geolocation. This guide walks through reading each result and fixing the common causes.

What ipleak.net actually checks

The page runs several independent detections, and each one can fail separately:

• IP addresses — your public IPv4/IPv6 as seen by the server, plus a WebRTC detection that can reveal a second address your browser exposes.
• DNS detection — the recursive resolvers your queries reach. It lists each one it observes.
• Torrent address detection — a magnet-style check that reports the IP your BitTorrent client would announce.
• Geolocation — browser-based location (requires permission) and IP-based location with an accuracy radius.

The page's own guidance is the key to reading results: if you are connected to a VPN and you see your ISP IP, your system is leaking WebRTC requests; and if between the detected DNS you see your ISP DNS, your system is leaking DNS requests.

Step 1: Establish a baseline before connecting the VPN

1. Disconnect the VPN.
2. Load ipleak.net and note your IP, ISP, and the DNS servers listed.
3. This is your "leak signature" — the values that should disappear once the VPN is on.

Without a baseline you can't tell whether a result is your real ISP or your VPN provider's own infrastructure.

Step 2: Re-test with the VPN connected

1. Connect the VPN and confirm the client reports an active tunnel.
2. Reload ipleak.net (hard-refresh to avoid cached JavaScript).
3. Check each section against the table below.

If every row is clean, you're done. If not, fix the matching section below.

Fixing a DNS leak

A DNS leak means your queries bypass the VPN tunnel and reach your ISP's resolver. The page notes this is common because systems can send DNS queries outside the tunnel even when other traffic is routed through it.

Check these in order:

1. VPN client DNS handling — most clients have a setting to force all DNS through the tunnel (often labeled "DNS leak protection" or "use VPN DNS"). Enable it.
2. System DNS settings — on Windows, check the adapter's DNS servers; on macOS, check Network settings. If they point to your router or ISP, the VPN may not be overriding them.
3. Browser encrypted DNS (DoH) — if your browser uses its own DNS-over-HTTPS resolver, it can bypass the VPN's DNS. Either disable secure DNS in the browser or point it at a resolver you trust.
4. IPv6 — if your VPN only tunnels IPv4, IPv6 DNS queries can leak. Disable IPv6 on the adapter or confirm the VPN handles it.

Re-run the DNS detection after each change until only VPN resolvers appear.

Fixing a WebRTC leak

WebRTC uses STUN (Session Traversal Utilities for NAT) to discover your public IP address — which is exactly why it can expose you even behind a VPN. The page gives a direct fix for Firefox:

• Firefox: type about:config in the address bar, search for media.peerconnection.enabled, and double-click to set it to false.

For Chrome and Chromium-based browsers, the page points to extensions or policy-based restrictions rather than a built-in toggle. Practical options:

• Install a WebRTC-blocking extension and verify it actually blocks the detection.
• Use enterprise policy (WebRtcIPHandlingPolicy) if you manage the browser.
• Or simply use a browser profile where WebRTC is disabled for sensitive sessions.

After changing anything, reload ipleak.net and confirm the WebRTC section no longer shows your ISP address.

Checking your torrent client

The torrent detection works by having you add a test torrent and reporting the IP your client announces to peers. If that IP is your real one, your BitTorrent traffic is bypassing the VPN.

Common causes:

• The client was already running before the VPN connected — restart it after connecting.
• The client is bound to the wrong network interface. Most clients let you bind to the VPN adapter specifically; do that.
• IPv6 traffic escaping an IPv4-only tunnel.

Re-test after each fix; the torrent section should report the VPN IP.

Verifying the fix

Once all sections are clean, do one final pass:

1. Disconnect and reconnect the VPN.
2. Hard-refresh ipleak.net.
3. Confirm IP, WebRTC, DNS, and torrent all show VPN values.
4. Optionally repeat after a reboot, since some leaks only appear on a fresh network stack.

If a leak returns after reboot, the cause is usually a system-level DNS or IPv6 setting rather than the VPN client itself.