Privacy & Leaks

Good news: your DNS resolver country matches your public IP country, which is what we would expect for a normal, unproxied home connection. Nothing to do right now. If you later start using a VPN, come back and re-run this test -- if the numbers stop matching, that means the VPN is protecting your web traffic but leaking your DNS lookups, which is worth fixing in the VPN client settings.

This card flagged a mismatch. To fix: (1) In your VPN client, look for a setting called "Use VPN DNS" or "Block IPv6 / DNS outside tunnel" and turn it on. (2) In your browser, enable Secure DNS (DoH) pointed at a resolver you trust -- Cloudflare 1.1.1.1, Quad9 9.9.9.9, or your VPN provider's resolver. (3) Re-run this test to confirm the fix. (4) If you are on a corporate or campus network you cannot control, assume DNS is being logged and use Tor Browser for anything sensitive rather than fighting the network.

Your browser only exposed the public IP that websites already see anyway -- no LAN addresses, no VPN-bypassed real IP. That is the correct outcome for a browser that is either not on a VPN or is on a VPN with WebRTC leak protection enabled. Nothing to do. If you later put this browser behind a VPN, re-run this test: if a second IP suddenly appears, WebRTC is bypassing the tunnel and you should turn on the setting listed in the leak-fix guidance below.

An extra IP was found. Fix by browser: (a) Brave -- Settings > Shields > WebRTC IP handling policy > "Disable Non-Proxied UDP". (b) Firefox -- about:config, set media.peerconnection.enabled to false (this will break Meet/Discord in-browser; use the desktop apps instead). (c) Chrome/Edge -- install the "WebRTC Network Limiter" extension from Google and set it to "Use my proxy server". (d) Safari on iOS/macOS -- already only exposes the public interface, no action needed. Re-run this test after applying the fix and confirm the extra IP disappears.

A VPN or hosting provider is answering for your IP, which usually means your intended privacy setup is working. Verify the other privacy cards on this page also agree: the DNS Leak card should not show a country mismatch, and the WebRTC Leak card should not show extra IPs. If those two also come back clean, your VPN is fully protecting you. If not, the VPN is only partly protecting you and you should adjust the VPN client settings to force DNS and WebRTC through the tunnel.

Residential is a normal, neutral result for a home connection. There is nothing to fix. Some things to know: (a) if you WANT to appear residential for streaming or banking (many sites treat datacenter IPs as suspicious), you are already there. (b) if you WANT to appear private for research or journalism, you should turn on a reputable VPN -- pick a provider with a diskless / no-logs audit (Mullvad, IVPN, Proton) and pair it with Tor Browser for the highest-risk sessions. (c) if you thought you had a VPN running, this card is telling you it is either off or leaking -- check the VPN client and re-run this test.

You have dual-stack IPv4+IPv6 working, which is what modern ISPs aim for. Peer-to-peer apps and games will pick the best path automatically. Two things worth checking: (1) if you use a VPN, confirm the VPN also carries IPv6 -- many do not, and will silently break IPv6 sites unless the VPN client disables IPv6 on the OS. (2) IPv6 addresses are more unique per device than shared IPv4 NAT, so if cross-site tracking matters to you, prefer a browser that rotates or randomizes IPv6 (Firefox with privacy.resistFingerprinting, or Tor Browser).

IPv4-only is still normal for many US home ISPs. To get IPv6: (1) call your ISP and ask whether IPv6 is provisioned on your account -- most US cable/fiber ISPs support it but do not turn it on by default. (2) If yes, log into your router and enable IPv6 in WAN settings (usually "Automatic" or "DHCPv6"). (3) Reboot the router and re-test. If your ISP does not offer IPv6, you can tunnel it via Hurricane Electric (tunnelbroker.net, free) but expect a small latency penalty. If you are on a VPN, check whether the VPN carries IPv6 -- many do not.

Consistent timezone + residential IP is the most privacy-neutral outcome: less likely to trigger anti-fraud captchas, and no unusual signal for fingerprinters to key on. There is nothing to do. If you later start using a VPN and want to appear to be in the VPN exit country, you would need to either match your OS timezone to the exit country (heavy-handed -- breaks your calendar) or use a per-site timezone-spoofer extension (Chameleon on Firefox, similar on Chrome).

There is a real mismatch: your browser says one timezone, your IP suggests another. If you are NOT using a VPN, your OS clock is probably stuck on an old timezone -- go to system Date & Time settings and either enable "Set timezone automatically" or set it to your actual location. If you ARE using a VPN and you want to look consistent, either (a) set your OS timezone to match the VPN exit country, or (b) install a browser extension like Chameleon (Firefox) that overrides the JS Intl API. Do NOT change your OS timezone just for privacy -- it will make every calendar event and every timestamp in your logs wrong. Note: if you legitimately travel and your OS auto-updates timezone while your VPN stays pinned to home, this mismatch is expected and safe to ignore.

Whether "consistent" is desirable depends on your goal. If you are trying to blend in with normal residential traffic (streaming, banking, day-to-day browsing), consistent timezone + residential IP is exactly what you want -- less likely to trigger anti-fraud captchas. If you are trying to look anonymous or run a persona in a different country, consistent is actually working against you: you are announcing your true region even if the IP is spoofed. There is nothing to fix unless one of those two goals applies -- then either leave it (blend in), or install a browser extension like Chameleon (Firefox) or a similar timezone-spoofer to override the JS Intl API on a per-site basis. Do NOT change your OS timezone just for privacy: it will make every calendar event and every timestamp in your logs wrong.