By Rachel Foster — Education & Career Reporter

What you'll learn: an updated, practical 30‑minute audit you can run today (Aug 2026) to verify whether your VPN delivers on three things that matter for most users: network‑level privacy (IP/ASN hiding), correct DNS and IPv6 handling, and sane provider practices (telemetry, logging and accountability).

Who this is for: VPN services enthusiasts and technical consumers who spend limited time and money on privacy tools and want a fast, verifiable ROI on those investments. If you use a VPN daily for privacy or sensitive work, this checklist helps you catch the common gaps marketing glosses over.

Why this matters now: the networking landscape in 2026 has shifted in ways that change what a basic leak looks like. IPv6 deployment has continued to grow on mobile networks and home ISPs; encrypted DNS (DoH/DoT/DoQ) and ECH (encrypted client hello) are more widely supported in browsers and resolvers; and VPN clients themselves have become more feature‑rich (multi‑protocol fallbacks, per‑app VPNs, stealth/obfuscation modes). That complexity improves privacy in many scenarios but also opens fresh escape routes. A focused 30‑minute audit keeps the ROI on your subscription clear: you know what’s protected — and what is not.

Prerequisites and context (what you need before you start)

  • Time: 30 minutes for the baseline audit; 60–90 minutes if you test router‑based VPNs, additional devices, or run packet captures.
  • Devices/OS: test the device and OS you actually use (Windows 10/11, macOS Ventura+ / Sonoma, Android 12+, iOS 16+). Repeat on each OS that matters to you.
  • VPN app and subscription: the client or router configuration you normally use. If you use per‑app VPNs or split tunneling, test those scenarios explicitly.
  • Browsers: one primary (Chromium‑based or Firefox) and a second to cross‑check. Browser DoH/DoQ settings vary and are a common source of leakage.
  • Optional advanced tools: Little Snitch (macOS) or GlassWire (Windows) for app network monitoring; Wireshark/tcpdump for packet captures if you investigate deeper.

Brief definitions: IP address (public IPv4/IPv6 seen by websites); ASN (autonomous system number used to confirm which network is showing); DNS (resolver translating hostnames); DoH/DoT/DoQ (encrypted DNS transports); WebRTC (browser API that can expose addresses); ECH (encrypted client hello, which hides SNI from passive observers); VPN protocol (WireGuard, OpenVPN, IKEv2, or vendor variants).

Step 1: Establish your “before VPN” baseline (3 minutes)

  1. Disconnect from your VPN and any tethered or secondary networks.
  2. Open a trusted IP/DNS checker and record these values (use the same site before and after): ipleak.net, ipinfo.io, or browserleaks.com are still suitable. Record:
    • Your public IPv4 and any public IPv6
    • Your reported ISP name and location
    • The ASN shown (this helps distinguish database errors from true leaks)

Why: you need a clear reference. If the VPN does not change these values, it’s not delivering basic network hiding.

Step 2: Connect to the VPN and verify the basics (5 minutes)

  1. Connect to a server you actually use (test one nearby and, time permitting, one remote).
  2. On the same IP/DNS checker, confirm:
    • Your public IP changed
    • Your ISP attribution no longer shows your home ISP
    • Your ASN now corresponds to the VPN provider or a hosting ASN the provider documents
  3. If values look unchanged, stop and troubleshoot. Common causes: client not connected, split tunneling active, or per‑app VPN rules.

Why: ASN and ISP strings are stronger indicators than city geolocation databases, which are often inaccurate.

Step 3: Run DNS and encrypted DNS checks (7 minutes)

Encrypted DNS transports and resolver selection have become a larger factor in real‑world leaks. Browsers now frequently prefer DoH/DoQ, which can bypass the system resolver and — in some setups — the VPN tunnel.

  1. With the VPN connected, run a DNS leak test (ipleak.net or dnsleaktest.com). Check the resolver list for ownership and location.
  2. Ask:
    • Do any resolvers belong to your home ISP?
    • Are resolvers the VPN’s infrastructure or an explicit third‑party resolver you chose?
    • Is the browser using DoH/DoQ to a resolver that would be reachable without the VPN?
  3. Inspect browser DoH/DoQ settings:
    • Firefox: Preferences → General → Network Settings → DNS over HTTPS (which provider is selected).
    • Chromium: Settings → Security → Use secure DNS (check provider and whether it’s set to “automatic”).
  4. If your browser’s DoH provider is outside the tunnel and you want strict tunneling, either configure the browser to use the VPN’s resolver (if offered) or disable browser DoH so DNS flows through the system resolver inside the tunnel.

Why: DoH/DoQ encrypt DNS but can move resolution outside the tunnel depending on browser and OS policies. Verify both system and browser resolvers to be sure.

Step 4: Check IPv6 handling (5 minutes)

  1. With VPN connected, visit an IPv6 test (test-ipv6.com or your IP checker showing IPv6).
  2. Desired outcomes:
    • Best: IPv6 address shown is associated with the VPN provider/ASN (tunneled).
    • Acceptable: IPv6 is blocked/disabled on the client while on the VPN (no public IPv6 visible).
    • Bad: IPv6 shows your ISP‑assigned address while VPN is active (an IPv6 leak).
  3. If you see an IPv6 leak:
    • Enable the VPN app’s IPv6 leak protection if available.
    • If the app lacks controls, temporarily disable IPv6 at the OS level or switch to a provider that documents IPv6 tunneling or robust blocking.

Why: IPv6 usage continues to rise, particularly on mobile networks and modern home gateways; a single IPv6 leak can negate the rest of your protections.

Step 5: Check WebRTC, browser APIs and SNI exposure (5 minutes)

  1. With VPN connected, run a WebRTC test (browserleaks.com/webrtc) and check for any public IPs tied to your ISP.
  2. Also consider SNI visibility: ECH adoption has increased, but not every site or resolver uses it. A VPN protects routing — it does not change how applications reveal hostnames if the client or resolver leaks them.
  3. If a public ISP IP appears in WebRTC:
    • Test across browsers; Firefox often has stricter defaults for WebRTC than some Chromium builds.
    • Consider browser settings or extensions that restrict WebRTC; be aware these can break real‑time apps
    • For repeated, high‑risk use, prefer browsers and configurations you’ve tested and can control centrally

Why: browser APIs and encrypted handshake features (ECH) are evolving. Test the actual browsers you use for sensitive tasks, not hypothetical defaults.

Step 6: Confirm protocol, QUIC/HTTP3 behaviour, and fallback risks (4 minutes)

  1. Open your VPN client’s connection details and note the active protocol (WireGuard and its variants are widespread; OpenVPN and IKEv2 remain in use). Check whether the client is using QUIC/HTTP3 for control or data channels — some providers now support QUIC for performance and stealth.
  2. Confirm automatic fallback behavior. Does the client silently switch from WireGuard to OpenVPN or TCP? Silent fallbacks can change detectability and leak risk.
  3. Decide whether automatic fallbacks are acceptable for your threat model. If you require predictable behavior, disable silent fallbacks and handle protocol switches manually.

Why: protocol choices affect performance, detectability on restrictive networks, and how the client handles outages. Understand what your client will do during a handshake failure.

Step 7: Test the kill switch and multi‑network failover (7 minutes)

  1. Enable the VPN app’s kill switch / network lock. On routers, locate the equivalent (not all consumer routers implement strict kills).
  2. Start continuous network activity (ping, a large download, or a page that refreshes).
  3. Induce a failover:
    • Disable Wi‑Fi briefly, or
    • Switch from Wi‑Fi to mobile tethering, or
    • Force the VPN client to change servers.
  4. Observe whether traffic stops entirely until the VPN reconnects. A temporary return to your ISP IP indicates the kill switch did not block leakage.

Why: disconnects are the most common time leaks happen. A strict kill switch sacrifices availability for safety — decide which trade‑off is right for your work.

Step 8: Audit the provider side — logs, telemetry, audits and accountability (10 minutes)

Technical controls matter, but provider practices determine what happens when legal or operational pressure arrives. Marketing slogans like “no logs” are common; treat them as starting points, not guarantees.

8.1 Read the privacy policy for three concrete items

  1. Connection metadata: do they log timestamps, source IPs, assigned VPN IPs, or session durations? If so, how long are these retained?
  2. App telemetry: what telemetry, crash reporting or analytics does the app collect? Are third‑party SDKs listed? Can you opt out from the app or store privacy controls?
  3. Jurisdiction & disclosure: where is the company incorporated, and what is their stated legal disclosure and data‑sharing policy?

Practical test: search the policy for explicit retention windows and named subprocessors (payment processors and crash‑report vendors can create metadata trails).

8.2 Look for independent, verifiable transparency signals

  • Full third‑party audit reports (not just summaries) from a reputable auditor, with clear scope and dates.
  • Server infrastructure transparency: published server images, RAM‑only/ephemeral server claims with technical writeups or audited procedures.
  • Transparency reports, warrant canaries, or court records that indicate how the provider responds to legal requests.

Red flags: a marketing blog post labeled “audit” with no downloadable report, or audits that only cover a single internal module.

8.3 Check app telemetry practically

  • Review app store privacy labels and the app’s own settings for analytics, crash reporting and diagnostics.
  • If you need low linkability, disable nonessential analytics in the app and prefer providers that allow strict opt‑outs or publish precise telemetry schemas.
  • For hands‑on verification, run a local network monitor (Little Snitch, Windows Firewall logging, or a lab capture) to see where the client connects when idle or during updates.

Why: telemetry and background connections are a metadata channel. Minimizing unnecessary telemetry preserves the privacy value of the service.

Common mistakes that make audits misleading

  • Testing only one server or one network: repeat on a local and a distant server and on home and mobile networks.
  • Ignoring browser DoH/DoQ settings: browser‑driven DNS can bypass the VPN even when system DNS is correct.
  • Assuming local IPs are public leaks: focus on public IPs and ASNs; local addresses are usually non‑routable and expected.
  • Trusting marketing alone: “no logs” needs concrete language, retention windows, and preferably independent verification.
  • Forgetting router vs client differences: router VPNs and client apps often handle DNS, IPv6 and kills differently — test devices behind the router.
  • Overlooking app telemetry: crash reporters and analytics SDKs are often the easiest link to real identities.

Pro tips (for enthusiasts who want a tighter setup)

  • Keep two browser profiles: one for identity‑linked activity (banking, shopping) and another for VPN‑focused browsing. A VPN hides network location, not cookies or fingerprints.
  • Prefer documented server practices: providers that publish technical server configurations, use RAM‑only servers, and have repeatable audits reduce forensic risk—verify via reports, not slogans.
  • Limit split tunneling: use it only when necessary and document which apps are excluded. Treat split tunneling as a managed exception.
  • Consider payment metadata: billing creates a link. If minimal linkage matters, weigh prepaid or privacy‑preserving payment options against legal and operational trade‑offs.
  • Automate quarterly checks: set reminders to rerun this audit after OS updates, VPN client upgrades, or quarterly to preserve the ROI of your privacy investment.
  • Use network monitors for certainty: Little Snitch (macOS), GlassWire (Windows) or a short tcpdump capture can confirm whether background telemetry escapes the tunnel.

FAQ

Will this audit make me anonymous?

No. A VPN only protects network‑level metadata (IP/ASN and some DNS visibility). It does not hide account logins, cookies, browser fingerprinting, or application‑level telemetry. Treat a VPN as one layer in a broader privacy strategy.

Do encrypted DNS transports (DoH/DoT/DoQ) eliminate DNS leaks?

Not automatically. Encrypted DNS hides the contents of DNS queries but can be configured by browsers or the OS to use a resolver outside your VPN. Verify both system and browser DNS settings and select resolvers reachable only through the VPN if you require strict tunneling.

Should I disable IPv6 system‑wide to be safe?

Disabling IPv6 is an effective temporary mitigation if your VPN does not handle IPv6. However, this is a blunt instrument: IPv6 can improve performance and some services rely on it. Prefer a provider that documents IPv6 tunneling or reliable blocking. If you disable IPv6, re‑test services that depend on it.

How often should I rerun this audit?

Re‑run after major OS updates, VPN client upgrades, router replacements, or if you change networks. Quarterly is a reasonable cadence for most users; run checks immediately before and after high‑risk sessions if you depend on the VPN for sensitive work.

My VPN’s audit report looks good — can I trust it?

Use an audit as evidence, not proof. Read the audit scope, methodology and dates. Prefer full reports from reputable auditors that cover server architecture, client binaries and key management. If the report is a superficial summary or lacks an independent auditor’s name and methodology, treat claims cautiously.

Bottom line: in 30 minutes you can verify the controls that yield the most practical privacy: IP/ASN changes, system and browser DNS behavior, IPv6 handling, WebRTC exposure, kill‑switch enforcement, protocol and fallback behavior, and whether provider practices match their marketing. Run this checklist on the devices and networks you actually use, and repeat it after major changes. That small time investment protects the larger one you’ve already made in the service.