How to Run an ExpressVPN DNS Leak Test and Fix What You Find

You connected to ExpressVPN, your IP changed, and you assumed your DNS queries were private. Then you ran a leak test and saw your ISP's resolver staring back at you. A DNS leak means your device is sending name-resolution requests outside the encrypted VPN tunnel — to your ISP, your router, or a public resolver you never chose. For ExpressVPN users this happens more often than the marketing suggests, and the fix depends entirely on which of six different root causes you are hitting.

What a DNS Leak Actually Means

Every website visit begins with a DNS query: your device asks a resolver to translate a domain name like example.com into an IP address. Inside a properly configured VPN, that request travels through the encrypted tunnel to ExpressVPN's own private resolvers. A leak is when the request escapes that tunnel — because the OS, browser, or router routes it somewhere else first. The resolver that answers can log every domain you look up, turning it into a real-time record of your browsing activity. Your VPN's masked IP address means nothing if DNS is leaking to your ISP.

Six Root Causes, Ranked by Frequency

1. Windows Smart Multi-Homed Name Resolution

The most common cause for Windows users is a feature called Smart Multi-Homed Name Resolution (SMHNR), shipped in Windows 8 and still active in Windows 11. It sends every DNS query to all available network interfaces simultaneously and uses whichever resolver responds first. Since your physical adapter's DNS — your ISP's resolver — is on the local network, it frequently wins the race against ExpressVPN's tunnel resolver. ExpressVPN's built-in DNS leak protection is supposed to suppress this, but it breaks down after Windows updates and on machines with multiple adapters such as Wi-Fi, Ethernet, and virtual adapters from VMware or Hyper-V, which all register as separate DNS interfaces.

2. IPv6 Traffic Bypassing the VPN Tunnel

ExpressVPN routes IPv4 traffic through its tunnel by default, but if your ISP provides native IPv6 and your device has an IPv6 address, DNS lookups over IPv6 travel over your ISP's stack, completely outside the VPN. As IPv6 adoption exceeds 45% of global web traffic in 2026, this leak vector is hitting more users than ever. ExpressVPN includes an IPv6 leak protection setting, but it is disabled by default on installations that upgraded from versions prior to v12 rather than performing a clean install.

3. Browser-Level DNS over HTTPS

Firefox defaults to Cloudflare's DoH resolver (1.1.1.1 over HTTPS). Chrome and Edge use a Secure DNS feature that falls back to Cloudflare or Google when the system resolver does not support DoH. Both bypass the operating system's DNS stack entirely — which means they also bypass ExpressVPN's DNS interception. You can have a perfectly clean OS-level DNS setup and still leak through the browser. This is the second most common source of the frustrating situation where the fix appears to work but the leak test still fails.

4. Split Tunneling Excluding the Wrong Apps

If you have configured ExpressVPN's split tunneling to exclude a browser or application from the VPN tunnel, that app's DNS also bypasses the VPN. This is technically working as designed — the app is not in the tunnel — but it produces identical privacy exposure to a true leak. Check your split-tunnel exclusion list before assuming you have a software bug.

5. Router or ISP Redirecting Port 53

Some ISPs and consumer routers use DNS hijacking: they intercept all outbound UDP and TCP traffic on port 53 and redirect it to their own resolvers, regardless of what your device is configured to use. If ExpressVPN's tunnel DNS uses standard port 53 and the router intercepts those packets, every lookup goes to your ISP. This is most common on ISP-supplied routers in the UK, Australia, and parts of Europe, and on home networks running parental-control firmware that forces a captive DNS.

6. Stale DNS Cache After VPN Connect

When ExpressVPN connects, it pushes new DNS settings to the OS. If the system does not flush the existing cache, in-flight queries continue to resolve via the pre-VPN resolver until cached entries expire. This produces intermittent leaks that appear to fix themselves — and that pass a leak test 30 seconds after connecting because the cache has aged out. If you only see leaks in the first couple of minutes after connecting, this is your cause.

How to Run the DNS Leak Test

Connect to ExpressVPN and select a server in a country different from your own. This makes it immediately obvious when a resolver belongs to your ISP versus ExpressVPN. Then follow these four steps:

1. Use an independent test site. ExpressVPN hosts a test at expressvpn.com/dns-leak-test, but it is not neutral. Use a third-party tool for a second opinion to rule out any self-reporting bias in the results.
2. Read the resolver organization field. Every result should show ExpressVPN or EXPRESSVPN BV in the ISP or organization column. Any result showing your ISP name, Cloudflare, Google, or a private RFC 1918 IP address is a confirmed leak.
3. Run the extended test. Basic tests fire one or two queries. Extended mode fires 20 to 40 sequential queries and reliably catches intermittent leaks that a single-query test misses. SMHNR leaks on Windows almost always appear in extended mode but pass basic tests.
4. Test with all browsers closed, then open. Close every browser, run the test from a terminal or fresh private window, then re-run it with your main browser open. This isolates browser DoH leaks from OS-level leaks so you know which fix to apply.

CLI Verification: dig, nslookup, and resolvectl

Leak test websites give a visual answer, but command-line tools tell you exactly which resolver answered and from where. Run these after connecting to ExpressVPN:

On Windows, if nslookup shows your router's LAN IP as the server, DNS is being handled by the router before it reaches the VPN tunnel — a strong indicator of either SMHNR or router-level DNS hijacking. Both require different fixes.

Platform-by-Platform Fixes

Windows 10 and 11

Step 1 — Verify built-in protection is on. Open ExpressVPN, click the hamburger menu, go to Options → General and confirm DNS Leak Protection is enabled. In v12 and later this is on by default. If it is already on and you are still leaking, proceed.

Step 2 — Disable SMHNR via Group Policy (Pro and Enterprise editions only):

Step 2 alternative — Home edition (no Group Policy editor):

Step 3 — Null out DNS on physical adapters. Settings → Network & Internet → Change adapter options → right-click your Wi-Fi or Ethernet adapter → Properties → Internet Protocol Version 4 (TCP/IPv4) → Use the following DNS servers → enter 0.0.0.0 for Preferred DNS, leave Alternate blank. When ExpressVPN is active, this forces Windows to use only the VPN adapter's pushed DNS.

Step 4 — Disable IPv6 on physical adapters. In the same Properties dialog, uncheck Internet Protocol Version 6 (TCP/IPv6). Reconnect ExpressVPN and re-run the extended leak test.

macOS (Sequoia and Sonoma)

ExpressVPN for macOS injects DNS settings via the Network Extension framework. If the app's own protection is not catching the leak:

1. System Settings → Network → select your Wi-Fi or Ethernet interface → Details → DNS tab → remove all listed DNS server addresses → add 0.0.0.0. Click OK, then Apply.
2. Flush the DNS cache after reconnecting ExpressVPN:

Safari uses the system resolver exclusively, so once the OS DNS is clean, Safari follows automatically. Firefox and Chrome require the separate browser-level fix below.

Linux (systemd-resolved Systems)

For distributions using a plain /etc/resolv.conf not symlinked to systemd-resolved, ExpressVPN's app should overwrite it on connect. If it does not, the file may have an immutable flag set. Check with lsattr /etc/resolv.conf and remove it with sudo chattr -i /etc/resolv.conf, then reconnect the VPN.

iOS 17 and Later

Go to Settings → Wi-Fi → tap the (i) next to your active network → Configure DNS → Manual → remove all existing entries and leave the list empty. ExpressVPN's app pushes its own DNS when the Lightway tunnel activates. Also confirm inside the ExpressVPN app under Settings → DNS Leak Protection → On.

Android 12 and Later

Android's Private DNS setting (DNS over TLS) routes queries outside the VPN tunnel. Go to Settings → Network & Internet → Private DNS → set it to Off while ExpressVPN is active. If a work profile or MDM policy enforces a Private DNS hostname, that policy supersedes the VPN's DNS and you will need IT to adjust it centrally.

Fixing Browser-Level DoH Leaks

After sealing the OS, test each browser independently. Use the DNS Lookup tool to verify whether specific domains resolve through ExpressVPN's resolvers after applying these browser changes — look for the resolver IP in the query answer section.

Firefox: Open about:preferences → General → scroll to Network Settings → click Settings → uncheck Enable DNS over HTTPS. Alternatively open about:config, search for network.trr.mode, and set it to 0 (disabled) or 5 (explicitly off, ignores any OS DoH settings).

Chrome, Edge, and Brave: Settings → Privacy and security → Security → Use secure DNS → turn it Off. In Chrome this toggle is in the Advanced section. If your organization deploys Chrome via Group Policy, the setting may be managed centrally and needs to be adjusted by IT.

The reason browser DoH bypasses OS-level DNS is architectural, not accidental. The IETF RFC 8484 specification documents exactly how DNS-over-HTTPS negotiation works and why it deliberately sidesteps the system resolver stack — useful context when explaining the issue to a skeptical colleague or client.

Confirming the Fix Worked

Do not call it fixed until all four of these pass:

1. Full disconnect and reconnect. Do not resume the existing session — fully disconnect ExpressVPN, flush your DNS cache, then reconnect from scratch to force fresh DNS settings to push to the OS.
2. Extended leak test from two independent tools. Both must show only ExpressVPN in the resolver organization column with no ISP or third-party entries.
3. CLI verification. The SERVER line in dig output and the Server field in nslookup must show ExpressVPN's resolver address, not your router's LAN IP or your ISP's resolver.
4. Test with each browser open. Close and reopen each browser, then rerun the leak test. Browser DoH leaks only appear with the browser running, not from a cold terminal test.

If every resolver organization field shows ExpressVPN — and only ExpressVPN — across both extended web tests and CLI queries, the leak is sealed.

Preventing Leaks Going Forward

• Enable auto-connect on startup. The window between device boot and VPN connect is a genuine leak window. ExpressVPN's Connect on Startup setting closes it before the first browser query fires.
• Enable Network Lock (kill switch). On Windows and macOS this is Network Lock under Options in the ExpressVPN app. On mobile it is Block Internet When VPN Disconnects. This halts all traffic — including DNS — during reconnects and unexpected drops.
• Audit split-tunnel exclusions quarterly. Every app in the exclusion list is a potential DNS leak vector. Review the list whenever your network or app setup changes.
• Recheck after Windows feature updates. Major updates such as 23H2 and 24H2 are known to reset Group Policy settings including the SMHNR disable. Run gpresult /h report.html after each major update and open it in a browser to verify the policy survived.
• Disable IPv6 on physical adapters permanently unless you have a specific operational need for it. IPv6 leak risk consistently outweighs the marginal benefit for most VPN users on consumer networks.

Common Misdiagnoses

WebRTC leaks are not DNS leaks. If the leak test shows your real IP address alongside your VPN IP, that is a WebRTC leak — a completely separate issue handled by disabling WebRTC in the browser or installing a dedicated browser extension. The DNS fixes above have no effect on WebRTC.

Cloudflare in results is not always a leak. If you have deliberately configured Cloudflare's DoH endpoint in your browser and the VPN is not intercepting DoH, Cloudflare will appear in results. That is a browser configuration issue, not an OS-level DNS leak. Apply the browser fix described above rather than chasing an OS problem that does not exist.

Leak test CDN results can mislead. Some leak test sites are served via CDN. The resolver they detect may be the CDN's edge node rather than your actual DNS server. When results look inconsistent across tools, run the CLI verification commands — they query directly and bypass CDN caching entirely.

Intermittent early leaks after connect. If leaks only appear in the first 60 to 90 seconds after connecting and then clear up, the stale DNS cache is the cause, not a persistent misconfiguration. Flush the cache immediately after every VPN connect using the commands in the CLI section above, then wait 90 seconds before testing.

2026 Context: IPv6, DoT, and What Has Changed

IPv6 crossed 45% of global web traffic in late 2025. If your home connection is dual-stack and ExpressVPN's IPv6 leak protection is not active, your browser may prefer IPv6 AAAA records for major domains and resolve them entirely outside the tunnel. In the ExpressVPN app navigate to Options → Advanced and enable IPv6 Leak Protection. Verify it is working by checking whether your leak test lists any IPv6 addresses belonging to your ISP — there should be none.

DNS over TLS (DoT) is now the default on Android 12 and later, and newer home router firmware from ASUS, Ubiquiti UniFi, and others automatically advertises DoT support. ExpressVPN intercepts DNS at the OS level on port 53 UDP and TCP — it does not intercept port 853 (DoT). If your device uses DoT natively and the VPN does not tunnel port 853, those queries bypass the VPN entirely regardless of how cleanly configured the rest of your setup is. Disabling Private DNS on Android as described in the platform section above is the correct resolution for this specific case.

DNSSEC does not create or prevent DNS leaks on its own, but ExpressVPN's resolvers do support DNSSEC validation. If you want to confirm that DNS responses are authenticated before and after connecting to the VPN, check for the AD (Authenticated Data) flag in the query output: