Real Leak or Just Firefox's Secure DNS? Checking for VPN Leaks in Three Places

You run a quick VPN leak test and Cloudflare DNS pops up. Panic? Probably not. In most cases that line comes from Firefox’s Secure DNS, not a broken tunnel.

In the next five minutes, we’ll show you how to confirm, or dismiss, a real leak by checking three spots:

1. What the browser reveals 

2. What your device or VPN app actually covers 

3. What happens when the connection changes

It’s a calm, repeatable routine: digital self-care in action. For more ways to protect your online peace, see our guide to protecting your peace online.

The short answer: what counts as a VPN “leak”

A real leak happens only when a site can still see your home-network public IPv4 or IPv6 after the VPN is on. Everything else (unfamiliar DNS resolvers, odd map pins, or unusual time zones) is usually a harmless side effect.

Why the confusion? Most “VPN leak tests” spotlight DNS because it’s easy to display. Yet a DNS row merely tells you who answered, not how the query traveled. With DNS-over-HTTPS (RFC 8484) the browser may still call Cloudflare or Google even though the encrypted request rides safely inside the tunnel.

Think in three buckets:

• Tunnel leak: your regular public IP shows up in plain view. 

• Resolver choice: the browser deliberately talks to Cloudflare, Quad9, NextDNS, or another resolver you (or the browser) selected. 

• Tracking signal: time zone, language, cookies. Useful to advertisers, not proof of a leak.

Keep that model in mind; next, we’ll test what the browser itself can see.

Place 1: What the browser can see

First, capture a “before” snapshot with the VPN off, then an “after” snapshot with it on. Compare four details: public IPv4, IPv6, DNS resolver, and any public WebRTC candidate to see exactly what changed.

1. Establish a clean baseline

Open your browser without the VPN. Note the IP addresses and resolver name that appear. Next, connect the VPN and run the same quick check. TorGuard’s straightforward VPN leak test shows IP, DNS, and WebRTC in one view, so keep the tab open for later. Then compare the two results:

• If your ISP’s IPv4 disappears and a new address owned by the VPN appears, the tunnel covers IPv4. 

• If Cloudflare or Google replaces the ISP in the DNS row, hold judgment; the browser may be using Secure DNS. We will unpack that in a moment. 

• If your home-ISP IP or DNS shows up in both tests, that is a real leak.

Tip: Ignore minor geolocation quirks. City-level databases often map an IP to the center of a state or country rather than the router’s exact site.

2. Read each browser signal in its own light

Look at the four rows one by one. The public IP rows answer leak questions fastest.

Public IPv4. If this line now shows an address owned by your VPN or by the data-center network your VPN rents, you are covered on the protocol most sites still use. Your home-ISP name here is a confirmed leak.

IPv6. Some VPNs still tunnel only IPv4. When you see a home-ISP IPv6 next to a VPN IPv4, IPv6 is escaping. No IPv6 at all usually means the VPN or router disabled it deliberately.

WebRTC. Browsers expose extra candidates for calls. A private 192.168.x.x or .local hostname never leaves your network, according to WebRTC’s IP-handling guidance (see RFC 8828). A public home-ISP address, however, shows the browser is routing peer-to-peer traffic outside the tunnel.

DNS resolver. This line tells you who replied, not how the query traveled. Cloudflare, Google, Quad9, or NextDNS can appear even when the encrypted DNS rode safely inside the VPN. An ISP-branded resolver, by contrast, is a clear warning sign.

Work through the rows in this order and you will know whether to celebrate, tweak a setting, or dig deeper. Up next: why Firefox’s Secure DNS often explains that surprise Cloudflare entry.

3. Why Firefox may still show Cloudflare, even when the VPN works

Key point: If the public-IP row lists your VPN address, seeing “Cloudflare DNS” almost always means Firefox’s Secure DNS stayed enabled, not that the tunnel leaked.

Firefox offers four Secure DNS modes under Settings → Privacy & Security → DNS over HTTPS:

• Default: Enables DoH but automatically pauses it when Firefox detects a VPN, parental controls, or enterprise policy. 

• Increased: Keeps your chosen resolver active even through a VPN. 

• Max: Refuses to fall back to plain DNS; if DoH is blocked, Firefox shows a warning instead. 

• Off: Disables DoH entirely, reverting to your system or VPN's default DNS resolver.

Cloudflare is Firefox’s default resolver in the United States, so its name may appear on leak pages even though the encrypted query traveled inside the VPN tunnel.

Chrome handles Secure DNS differently. “Automatic” mode falls back to ordinary DNS when the resolver cannot be reached, but selecting a custom provider locks Chrome to that encrypted resolver, behavior similar to Firefox’s “Increased” mode.

Need proof? Temporarily toggle Secure DNS off, reload the leak test, and watch the DNS row. If your ISP resolver does not appear, the original Cloudflare entry was riding the VPN safely all along.

With the browser layer sorted, we can zoom out to what the VPN app and device settings reveal next.

Place 2: Device and app scope check

The first question to answer is what traffic your VPN is meant to protect. Not every product wraps the whole device.

1. Identify the VPN’s coverage

• Full-device app: installs at the OS level and routes nearly all traffic, unless you enable split tunneling. 

• Browser extension or proxy: guards only that browser’s tabs; email, cloud drives, and updates stay outside. 

• Firefox built-in VPN: hides Firefox traffic only, per Mozilla’s documentation. 

• Router VPN: covers every gadget on that Wi-Fi network, but not devices using mobile data or another hotspot. 

• Corporate or school VPN: frequently splits routes on purpose, sending work domains through the office while everything else goes directly to the internet.

Label your setup now. Once you know the tunnel’s true perimeter, odd results that fall outside it often make perfect sense, and you can focus on real misconfigurations in the next step.

2. Settings that quietly open side doors

Even a full-device VPN can be undone by a single switch elsewhere on your system. Check these five spots before you blame the tunnel:

• Split tunneling: many VPN apps let selected programs skip the tunnel for speed. Make sure your browser, call app, or game is not on that exclusion list. 

• Custom DNS: a router, security suite, or old network tweak may point your device at the ISP’s resolver. If the VPN does not override it, leak tests will show the ISP name. 

• IPv6 handling: some providers still block IPv6 by design. When your computer prefers native IPv6, traffic can leak unless the app supports or disables it explicitly. 

• Kill switch: without a kill switch, your real IP appears during reconnects. Confirm the switch is on and stays on after updates; independent tests show this is where many apps fail. 

• Extension conflicts: ad blockers, privacy add-ons, or a second VPN extension can rewrite proxy rules mid-session. Disable extras one by one until results stabilize.

After each tweak, run the leak test again. One clean check per change is faster, and clearer, than a dozen random refreshes. With device-level variables checked, we will move on to what happens when the connection itself drops or switches.

Place 3: Watch the connection when it changes

Key idea: Leaks often appear during brief drop-and-reconnect moments, not while everything is calm. AMTSO’s 2025 VPN-testing guidelines stress checking server switches, Wi-Fi hops, and sleep-wake cycles for this reason.

1. Why a single “all-green” page can still hide a leak

When the tunnel drops, your operating system sees an open network and your apps resume traffic over the direct link. Unless a kill switch blocks it, your real IP and DNS resolver can flash out for a few seconds. A later browser test looks clean because the exposure has already passed.

The fix is to move from one-time snapshot tests to motion tests that watch the connection while it changes.

2. A two-minute motion test

1. Open a leak-test page and start a low-stakes video stream so you notice any interruption. 

2. While the VPN is connected, switch to another VPN server or jump from home Wi-Fi to a mobile hotspot. 

3. Watch for three signs: 

   1. The stream pauses, meaning the kill switch is blocking traffic until the tunnel returns. 

   2. The leak-test page flashes your home IP or ISP DNS, proof of a transition leak. 

   3. Nothing changes, showing your tunnel stayed intact.

Repeat once after closing and reopening the laptop lid. The check takes less time than refilling a mug but reveals issues a static all-green page can miss.

Diagnosis matrix: real leak or harmless mismatch?

Use the left column to spot what the leak-test page shows, the middle explains what it really means, and the right lists your next step.

Treat the matrix like a triage card: find the symptom, apply the fix, then move on without endless tab refreshing.

Fix the route without losing useful protections

Fastest wins first:

1. Update everything. Out-of-date VPN apps, browsers, or operating systems can miss leak-patching bug fixes. Run all three updaters, reconnect, retest. 

2. Switch servers. Crowded nodes may drop packets or mishandle IPv6; many providers suggest a quick hop to a second server in the same country before changing settings. 

3. Check split tunneling. If your browser sits on the exclusion list, remove it and retest. 

4. Toggle DNS and IPv6 options. In your VPN’s advanced pane, try “Use VPN DNS” or “Block IPv6,” one switch at a time so you know what solved the issue.

Drastic only if necessary: 

• Turning off Secure DNS hides the symptom but reduces privacy on public Wi-Fi. 

• Disabling IPv6 can hurt speed on modern fiber links. 

• Blocking WebRTC may break calls and screen sharing.

If a documented leak still appears, especially during transitions, gather redacted screenshots and step-by-step notes, then contact support. No clear answer? Consider a provider that is transparent about its methods.

A calmer VPN-checking routine

Key idea: Test on day one, then only when something material changes.

• Full baseline: right after you install a new VPN or switch providers. 

• Event retest: after a major OS or VPN app update, a new device, a new router, or when you join unfamiliar Wi-Fi. 

• Quick snapshot: before a genuinely sensitive session, just to confirm the public IP row.

Archive one sanitized screenshot set per quarter (date plus server name in the file title, never the raw IP). That single folder proves you checked and saves you from constant page refreshes.

For more habit-building tips, see our guide to building healthier digital habits. A steady routine beats constant vigilance.

Frequently asked questions

Does seeing “Cloudflare DNS” mean my VPN leaked?

Not in most cases. Firefox Secure DNS uses Cloudflare by default in the United States, and the encrypted request still travels through the VPN as long as the public-IP row shows the VPN address.

Should I turn Secure DNS off when a VPN is running?

Only for troubleshooting. In Default mode Firefox pauses Secure DNS when it detects most VPNs. Higher modes keep it on to hide DNS from local networks. Turning it off removes one layer of privacy without improving an intact tunnel.

Why do two leak-test sites disagree?

Tools query different domains and classify IP owners in different ways. Compare the actual IP addresses first, treating alert colors as secondary.

Will disabling WebRTC stop every WebRTC leak?

It stops the browser from offering extra address candidates, but it can break calls and screen sharing. A safer approach is a browser setting or extension that limits WebRTC to the VPN interface (see RFC 8828).

Does a clean leak test guarantee anonymity?

No. A leak test measures routing only. It says nothing about cookies, account log-ins, tracking scripts, or whether the provider logs traffic.

How often should I run these checks? 

• After initial setup or whenever you change VPNs 

• After a major OS, browser, or VPN-app update 

• Before a genuinely sensitive session

Consistent routine beats constant refreshing.

Conclusion

Seeing Cloudflare DNS on a leak-test page does not mean your VPN failed. Run the three checks (browser view, device or app scope, and transition test) and you will know within minutes whether any real traffic escaped the tunnel.

Keep your VPN, browser, and OS updated, retest only after material changes, and then close the diagnostics tab. An informed routine beats constant vigilance, and that steady habit is the healthiest privacy choice of all.