Before/after evidence is incomplete
Capture both a baseline and a current snapshot so the checker can compare your IP, ASN, ISP, and location context.
Many users connect a VPN, see a different IP, and assume everything is fine. That is a good first check, but DNS leaks, WebRTC behavior, or route inconsistencies can still expose useful information. This wizard helps you verify the full picture.
Capture a baseline before connecting your VPN, then capture your current network after connecting to compare IP, ASN, and provider changes. Snapshots are stored only in your browser.
Capture before connecting your VPN.
Capture after connecting your VPN.
This is one automatic signal inside the workflow. It does not replace DNS, WebRTC, or IPv6 checks, but it helps you see whether the current route looks like a VPN/proxy exit right now.
Complete the steps below to verify whether your VPN is actually protecting your traffic.
Finish the checklist after connecting a VPN. A good provider should change your visible IP and avoid DNS, WebRTC, and IPv6 leaks.
Use the before/after compare plus the leak-test results together. A working VPN should tell one consistent story across all of them.
Capture both a baseline and a current snapshot so the checker can compare your IP, ASN, ISP, and location context.
Follow the highest-signal fixes first instead of retesting random settings. That is the fastest way to find the real failure point.
Open the homepage checker before connecting your VPN and note your IP, ISP, and ASN. This is your comparison baseline.
Enable your VPN and choose the server/location you want to test. Wait until the client shows connected status.
Run the homepage checker again. Your public IP should usually change after the VPN connects.
Run the DNS leak test workflow and decide whether it passed, failed, or needs more review.
Run the WebRTC leak test to check browser-level IP exposure via STUN/WebRTC behavior.
If your network uses IPv6, check whether your VPN still exposes native IPv6 routing after it connects.
Use Proxy Check as an extra signal. Unexpected results are not always failure, but they can indicate a setup issue.
Compare the ASN before and after connecting. A provider/ASN change is a strong sign your routing changed.
A truly working VPN passes all five of these checks, not just the first one. Most users stop at step one and miss real leaks.
The wizard above walks you through each of these steps automatically. If any step fails, the fix guides below explain exactly what to do.
Your VPN is working properly when the public IP changes, the ASN no longer points to your normal ISP, DNS resolvers follow the VPN route, WebRTC does not expose the original network, and IPv6 does not bypass the tunnel. If only the app status says "connected," you do not have enough evidence yet.
If the VPN is connected but the IP is not changed, start with the public IP and ASN checks first. If the IP changes but privacy still looks wrong, run the DNS, WebRTC, and IPv6 checks next.
Mixed VPN results are common because a VPN connection is not one single signal. Your public IP can change while DNS still leaks. DNS can look clean while WebRTC exposes a browser-level path. IPv4 can be protected while IPv6 still exits through the original ISP. The safest way to interpret a VPN test is to separate the result into layers: public IP, network owner, DNS resolver path, browser exposure, and IPv6 behavior.
If the public IP changes but the ASN still looks suspicious, look at the type of network instead of only the provider name. Some VPN providers use leased hosting networks, CDN-adjacent infrastructure, or residential proxy partners. That can make the ASN name different from the VPN brand. The important question is whether the ASN no longer belongs to your home or mobile ISP and whether the result matches the server location you selected.
If DNS fails but IP passes, your browsing can still reveal useful history to the resolver. This often happens when browser DNS-over-HTTPS is enabled, when split tunneling excludes the browser, or when the operating system keeps a custom resolver after the VPN connects. Fix DNS before treating the setup as private, because domain lookups can expose the sites and services you use even when the destination sees the VPN IP.
If WebRTC or IPv6 fails while the other checks pass, the issue is usually configuration rather than the entire VPN being broken. Disable WebRTC exposure in the browser or use a browser profile with stricter privacy defaults. For IPv6, either choose a VPN that tunnels IPv6 properly or disable IPv6 on that network until the provider supports it. Re-run the same sequence after every fix so you can confirm the weak layer is gone.
The wizard combines live before/after snapshot comparison with a guided verification workflow: public IP checks, DNS leak review, WebRTC leak review, IPv6 leak review, proxy/VPN detection signals, and optional ASN comparison. It stores only your step selections and captured snapshots in local browser storage so you can continue later.
It still depends on dedicated leak-test pages for DNS, WebRTC, and IPv6, but the point of this page is to turn those separate checks into one repeatable VPN verification path instead of a loose collection of tools.
When those signals tell the same story, your VPN setup is usually working as intended. If one path still points back to your normal network, treat that as a fix-first issue instead of assuming the app status is enough.
If your VPN connects but your IP does not change, start with VPN connected but IP not changing.
If your IP, DNS, or WebRTC results still show your ISP, your VPN is not protecting you. A trusted provider passes every leak test by default.