How to Test VPN IPv6 Support and Leak Protection

You connect your VPN, open an IP-checking page, see a new address and feel finished. But that page may only have shown you the IPv4 side of your connection. If your network also hands out IPv6 addresses, a second, longer address may be quietly going out the old way, straight through your internet provider. A proper VPN IPv6 support test takes about ten minutes and tells you which of three things your setup does: carry IPv6 through the tunnel, block it, or leak it.

This article is a procedure, not a theory lesson. It walks through the baseline, the connected check, how to read the three possible outcomes, what to do when the result is bad, and how to repeat the test later. If you want the background on why leaks happen at all, read about IPv6 leaks and the difference between IPv4 and IPv6 first, then come back with a notebook open.

What you are actually testing

A "VPN IPv6 support" test sounds like one question, but it is really three separate ones, and mixing them up leads to wrong conclusions.

1. Does your own network have IPv6? If your home broadband, mobile data or cafe Wi-Fi hands your device only an IPv4 address, there is nothing to leak and the rest of the test is a formality.
2. Does the VPN carry IPv6 traffic through the tunnel? Some VPN services tunnel both address families. Others tunnel only IPv4 and either block or ignore IPv6.
3. If the VPN does not carry it, does your device stop IPv6 from escaping? This is the leak-protection part. A good setup either carries IPv6 inside the tunnel or switches it off while the VPN is connected.

Only the third question decides whether you are exposed. "Support" for IPv6 is nice to have, but "no leak" is the thing that matters for privacy. Many people are fully protected on an IPv4-only tunnel because their device simply does not use IPv6 while connected.

Why does it matter? An IPv6 address is assigned to your connection by your internet provider, often to your individual home or phone, and it is visible to every site that supports IPv6. If the VPN hides your IPv4 address but the browser reaches a site over IPv6, the site sees your provider's address instead. You get the look of protection without the substance. The IPv6 specification describes how addresses are formed, and it explains why a device can have several of them at once.

Before you start: set up a clean test

Good tests need controlled conditions. Spend two minutes on preparation.

• Pick two checker pages. Use one that reports IPv4 and IPv6 separately, and a second independent one. Different pages use different methods, and a disagreement is itself a clue.
• Use a fresh browser window. Close extra tabs, and if you use a browser extension that changes network behaviour, pause it for the test.
• Open a notes file. You will record four values: your IPv4 address, your IPv6 address if any, the DNS server shown, and the time.
• Know your network type. Write down whether you are on home broadband, mobile data or public Wi-Fi. IPv6 is far more common on mobile networks and newer broadband than on small office or hotel networks.
• Do not test on a captive portal. If you are still seeing a hotel sign-in screen, finish that first, because VPN behaviour before sign-in is unreliable.

If you have not tested a VPN before, the broader checklist in how to test a VPN covers speed and the kill switch too. This article deals only with the IPv6 piece.

Step 1: record the baseline without the VPN

Turn the VPN fully off. Do not just pause it, because some apps leave parts of the tunnel active. Load your first checker page and write down what it reports.

There are three common baselines.

What the checker shows	What it means	Next step
Only a short dotted address	Your network is IPv4-only	Continue, but a leak is unlikely
A dotted address and a long colon address	Dual stack: you have both	Full test needed
Only a long colon address	IPv6-only with translation	Rare; the test still applies, but ask your network operator how it works

Note the first part of any IPv6 address. Addresses from the same provider usually share the same opening groups, so that prefix becomes your "fingerprint of the provider". If you see the same prefix later while the VPN is on, you know the provider's address is leaking.

Also record the DNS server. Many checker pages show which resolver answered the test. At baseline this is usually your provider's resolver or a public one. Later, a VPN connection should normally change this, and you can compare. If DNS is the part that worries you, the guide to the DNS leak explains what to look for.

Step 2: connect and run the same check

Now connect the VPN, wait until the app says it is connected, and wait another ten seconds. That pause matters, because some devices keep old connections alive for a few seconds. Reload the same checker page and compare.

Work through this short checklist.

1. IPv4 changed? The dotted address should now be different from the baseline. If it is the same, the VPN is not carrying your traffic at all, and the problem is bigger than IPv6. Go to the help article on checking whether your VPN is working.
2. IPv6 line? Compare it with your baseline.
3. DNS line? Check whether the resolver changed.
4. Second checker agrees? Open the independent page and confirm the same picture.

Take a screenshot or copy the values into your notes. Do not rely on memory, because the addresses are long and look similar at a glance.

Step 3: read the three possible outcomes

After the connected check, your result falls into one of three groups. Only one is a problem.

Outcome A: IPv6 is carried by the VPN

The checker shows an IPv6 address that is different from your baseline and does not share your provider's prefix. This is a pass. Your VPN service tunnels both address families, so sites that use IPv6 see the VPN's address on that side too.

One more check helps here: make sure the IPv4 and IPv6 results both point to the same general provider or location. If IPv4 shows one place and IPv6 shows a different one, nothing is leaking, but some websites may behave oddly because the two addresses disagree.

Outcome B: IPv6 is blocked or disabled

The checker shows an IPv4 address from the VPN and no IPv6 address at all, or says IPv6 is unavailable. This is also a pass. Either the VPN app turns off IPv6 while connected, or the device has no route for it. Some pages may load slightly more slowly the first time while the browser gives up on IPv6 and tries IPv4, which is normal.

Outcome C: IPv6 leaks

The checker shows your provider's IPv6 address, the same prefix you recorded at baseline, while the IPv4 address belongs to the VPN. This is the failing result. The VPN is working for IPv4 but the device is still talking IPv6 directly. Anything that goes out over IPv6, which can include popular sites and apps, is not protected by the tunnel.

Outcome	IPv4 shown	IPv6 shown	Verdict
A: carried	VPN address	A different, non-provider address	Pass
B: blocked	VPN address	None	Pass
C: leaking	VPN address	Your provider's address	Fail
D: not connected	Your own address	Your own address	VPN not active

If you see Outcome D, stop and fix the connection first. A leak test is meaningless when the tunnel is down.

Step 4: add DNS and WebRTC to the same session

While the VPN is on, spend two more minutes on the neighbours of IPv6, because they often fail together.

• DNS. Run a DNS test page. The resolvers listed should not be the ones you wrote down at baseline. Remember that a DNS server can be reachable over IPv6 even when the IPv4 path is protected, so an IPv6 DNS leak is a real thing. The background in what DNS is helps if the terms are unfamiliar.
• WebRTC. Browsers can reveal local and public addresses through a feature built for video calls. Open a WebRTC test page and check that no IPv6 address belonging to your provider appears. See WebRTC leaks for details.
• A mixed test. Visit a site you know supports IPv6 and a site that does not. Both should load. If the IPv6 one fails while the VPN is on, you may have a blocked-IPv6 setup with a broken fallback.

Record results for each. A pattern like "IPv4 fine, IPv6 DNS leaks" tells you something very specific about where to look.

Step 5: fix an IPv6 leak

If you got Outcome C, do not panic. A leak is common, fixable, and usually limited to one device. Work from simplest to most involved.

1. Check the VPN app settings first. Look for an option that mentions IPv6, leak protection, or blocking non-tunnel traffic. Keep other settings at their defaults. If you do not see one, ask your VPN support how IPv6 is handled, and do not assume the answer.
2. Reconnect and retest. A fresh connection sometimes applies the protection that a sleeping device skipped.
3. Turn IPv6 off for the active network adapter. On Windows, this is a checkbox in the adapter properties. On macOS, you can set IPv6 to "Link-local only" for the network service. On Android and iPhone, there is rarely a simple switch, so use the router or choose a different network. The article on Windows VPN and IPv6 walks through the Windows steps.
4. Turn IPv6 off at the router. If your router has an IPv6 setting, disabling it covers every device in the home. Note the original setting before you change it.
5. Retest everything. Repeat Steps 1 to 4. A fix is only a fix when the checker shows Outcome A or B.

A word of caution: turning off IPv6 is a workaround, not a moral victory. A small number of websites and services work better over IPv6, and as networks migrate, IPv6-only services will become more common. For most people today, the trade-off is small. Write down what you changed so you can reverse it.

Scenarios: three people, three results

Nina, a student at home. Nina's broadband provider gives her dual stack. At baseline her checker showed both addresses. With the VPN on, the IPv4 address changed but a long address with her provider's prefix remained. That is Outcome C. She disabled IPv6 on her laptop's Wi-Fi adapter, reconnected, and the checker now shows only the VPN's IPv4 address. Outcome B, and she noted the change in her file.

Arun, a remote worker on a hotel network. Arun's baseline showed only an IPv4 address, because the hotel network does not offer IPv6. His connected test showed a new IPv4 address and no IPv6. There was nothing to leak. He recorded that the result applies only to this network, and planned to retest at home.

Mei, a traveller on mobile data. Mei's mobile network is IPv6-heavy. At baseline she saw a long address and a translated IPv4 address. Once the VPN was on, both lines changed to addresses unrelated to her mobile operator. Outcome A. She still ran the DNS check and found one resolver that matched her operator, which she reported to the VPN support team rather than guessing.

The point of each story is that the procedure, not the app name, tells you what is true on your network today.

Limits, common mistakes and retesting

Be honest about what you have proved. A passing browser test means that your browser reached the checker through the tunnel. It does not guarantee that every app and system service does the same.

• Apps can use different paths. A chat app, game or operating-system service may try IPv6 directly when the browser does not.
• Networks change. Moving from Wi-Fi to mobile data can change the baseline and the result.
• Sleep and wake cycles matter. A device waking from sleep can briefly use the unprotected path before the VPN reconnects. A kill switch helps here, and the kill switch guide explains how.
• Checkers are not perfect. Pages can cache, or report a router's address. Two pages are better than one.
• Tests are not proof of anonymity. Passing proves the IP path is tidy. Accounts, cookies and browser fingerprints still identify you, as the article on tracking with a VPN explains.

For extra confidence, you can run a command-line lookup of your public address over each address family, or use a packet monitor to see which interface carries traffic. That goes beyond what most people need, but the principle is the same: compare the baseline with the connected state.

Common mistakes in an IPv6 test

• Testing only once, on one network, and treating it as permanent.
• Skipping the baseline and then not knowing what "your own address" looks like.
• Comparing only the IPv4 line and ignoring the long address under it.
• Looking at a page that shows a single address and assuming it is the only one.
• Disabling IPv6 and forgetting to retest, so a different leak goes unnoticed.
• Testing while a browser extension or second VPN is also active, so the result mixes two tools.
• Assuming the result transfers to your phone because it passed on your laptop.
• Confusing a slow first page load after blocking IPv6 with a broken VPN.

When and how often to retest

Put a reminder in your calendar and test again in these situations.

1. After the first install of any VPN app.
2. After a major operating system update, which can reset adapter settings.
3. When you move to a new network, such as a new home, office or phone SIM.
4. After a VPN app update that mentions network or leak settings.
5. After changing your router, or when your provider switches you to a new connection type.
6. When something feels off, such as unexpected location prompts or sites showing your real region.

A short routine works: baseline, connect, compare, DNS, done. Keep your notes file so that next time you can compare against last time's values instead of starting from zero.

Summary

A VPN IPv6 support test is a simple comparison. Record your address with the VPN off, connect, record it again, and read the result: IPv6 carried by the VPN or IPv6 blocked is a pass, while your provider's IPv6 address showing up is a leak. Add DNS and WebRTC checks to the same session, fix any leak by using the VPN app setting, a device-level IPv6 switch or a router change, and repeat the test after updates and network changes. The test proves only what it measured, so treat it as one good habit rather than a guarantee.

If you are choosing a VPN and want a simple prepaid pass to test these steps with, the pricing page shows the current options, and the download page lists the free app for each device.