Every VPN review site lists the same five features: no-logs policy, military-grade encryption, kill switch, DNS leak protection, and a map showing dozens of server locations. The marketing is identical because the product category has converged on a checklist. What you cannot see from a review site is whether any of those claims actually hold when you put the service under scrutiny. Independent audits occasionally surface discrepancies, and connection metadata quietly accumulates in jurisdictions that claim not to log. Most buyers have no way to verify a VPN’s behavior before committing to a year of subscriptions. You read the reviews, you pick the highest-rated option, and you trust that the marketing language matches the technical reality.
This post gives you a browser-based evaluation workflow that tests actual behavior rather than marketing claims. You will learn what to test, how to test it, and what the results mean in practical terms. By the end, you will be able to confirm whether a VPN does what its marketing claims before you enter any payment details. The tools are free, they run entirely in your browser, and they require no software installation or account creation.
Why “No-Logs” Claims Need Independent Verification
A no-logs policy is a promise made entirely on the provider’s terms. The VPN company writes the policy, enforces it internally, and answers to nobody beyond an optional third-party audit. Most providers have never published an independent audit report. When they do, the audit scope is often narrow: connection timestamps might be excluded from the audit, or the methodology might not cover the specific data types that matter for privacy. A provider can truthfully claim “we do not log browsing activity” while still retaining connection timestamps, bandwidth totals, and crash diagnostics that tie your activity to a specific account. The marketing language is carefully crafted to sound absolute while the actual data retention practices remain undisclosed. This gap between claim and practice is where most privacy evaluations fail.
Jurisdiction adds a layer of legal context but does not guarantee technical behavior. A VPN headquartered in Panama faces different legal exposure than one operating under US or UK jurisdiction, yet jurisdiction alone does not change what the software does on your machine. A provider in a privacy-friendly jurisdiction can still collect metadata, route traffic through third-party servers, or maintain session logs that connect your activity to your account. The gap between legal positioning and software behavior is where privacy claims usually break down. CapyToolkit’s privacy-first approach means every tool runs client-side with zero server-side processing, so you can verify behavior directly rather than relying on marketing language. When evaluating a VPN, treat jurisdiction as a secondary factor. The primary question is whether independent evidence supports the logging claims, because no amount of favorable corporate registration changes what the client sends to the server.
Testing for IP and DNS Leaks in Your Browser
WebRTC leaks are the most common and invisible leak type in a VPN connection. Even when the VPN tunnel is active, your browser’s WebRTC implementation can reveal your ISP-assigned public IP to any site that asks. The leak happens because WebRTC bypasses the operating system’s routing table and uses its own ICE candidate gathering process. According to the ICE protocol specification, ICE queries STUN servers to discover connectivity paths, returning your real public IP regardless of what the VPN does with normal TCP traffic. A VPN that blocks WebRTC avoids this leak but breaks video calls and screen sharing.1
STUN servers help WebRTC peers discover their public IP address and port mapping, and the STUN protocol specification defines this as a core function.2 This contact cannot be suppressed without disabling WebRTC. DNS queries face a similar problem: if the VPN fails to route UDP port 53 correctly, your domain lookups continue hitting your ISP’s resolver. A kill switch that only blocks TCP leaves both WebRTC and DNS traffic unrestricted. To verify this boundary, measure whether WebRTC traffic reaches the remote peer inside the VPN tunnel or bypasses it entirely using CapyToolkit’s P2P Network Tester.
To catch these silent exposures before they compromise your browsing session, you must isolate how each distinct protocol behaves when the VPN tunnel is active. WebRTC, DNS, and the kill switch each interact with the VPN differently, and a failure in any one of them exposes your real IP or your browsing history regardless of how well the other components perform. Testing each vector independently is the only way to confirm the tunnel actually covers all your traffic.
What WebRTC leaks reveal about your real IP
Your browser’s WebRTC implementation gathers ICE candidates from three sources: local interfaces, STUN servers, and TURN relay servers. The server-reflexive candidate from STUN reveals your ISP-assigned public IP, which is the value a VPN should hide. When WebRTC runs without the VPN, this candidate shows your real IP. With the VPN active, it should show the exit node’s IP.
WebRTC does not consult the operating system’s VPN routing table. It maintains its own network stack inside the browser, connecting directly to STUN servers without system-level routing configuration. Every VPN must explicitly configure the browser’s WebRTC stack to route through the VPN interface, but not every provider implements this correctly. Consequently, you must verify how your specific VPN client handles WebRTC routing rather than assuming the tunnel covers all traffic types.
How to verify DNS routing with a browser-based URL parser
A browser-based URL parser cannot directly inspect DNS resolution results, because standard browser sandboxes completely isolate client-side JavaScript from the DNS query stack. The native URL API performs string manipulation only. It has zero access to the physical IP addresses that a domain resolves to. Consequently, verifying DNS routing requires a server-side component that can observe which resolver addresses receive your query.
The practical approach is to use a DNS leak test service that queries highly randomized subdomains from authoritative nameservers it controls. When you run the test through your VPN, the service logs which recursive resolver addresses receive the request. If those responses come from your ISP’s address block instead of the VPN’s DNS servers, your domain lookups are leaking in plain sight despite the tunnel appearing active. Running these checks without installing browser extensions keeps the test clean and verifiable. CapyToolkit’s browser-based tools that run entirely on your machine handle any URL construction or inspection locally without transmitting data to external servers.
How NAT Type Affects VPN Performance and Bypass
NAT type determines whether your VPN can establish optimal peer-to-peer connections. When a VPN routes all traffic through its gateway, it changes your apparent NAT classification. A VPN that preserves port forwarding or flattens your NAT improves P2P connectivity for video calls, gaming, and file sharing. A VPN that preserves a strict NAT or introduces symmetric NAT degrades exactly those use cases.
The only way to know which behavior your provider delivers is to test it. CapyToolkit’s check your NAT type for gaming and video calls identifies your NAT classification before and after connecting. Run it without the VPN active to establish your baseline, then again with the VPN connected. If your classification changes to a stricter type, the VPN is degrading P2P connectivity. Use the check your WebRTC ICE candidate type in the browser to see whether connections use direct host candidates, server-reflexive candidates through the VPN, or relay candidates routed through a TURN server. A shift from host to relay candidates confirms the VPN is interfering with direct peer discovery. While standard NAT translations alter your routing paths, certain restrictive configurations break connection paths entirely. Specifically, symmetric NAT introduces severe barriers to direct peer communication.
Symmetric NAT blocks direct peer connections
Symmetric NAT assigns a different port mapping for each destination address, which prevents WebRTC from establishing direct peer connections.3 When your traffic passes through a VPN that applies symmetric NAT at its edge, your browser cannot create a direct connection path to the remote peer. Instead, the connection routes through a relay server, adding latency that a speed test never shows. For real-time applications like video calls or competitive gaming, relay routing introduces perceptible lag that no amount of server-side bandwidth can fix. The symmetric NAT and WebRTC interaction explains why this classification blocks direct connections and what conditions force traffic through relay servers.
Your ISP’s NAT type is the baseline. A full cone or restricted cone NAT allows direct peer connections. A symmetric NAT forces every outbound connection through a different port mapping. When you connect to a VPN, the provider’s gateway becomes your new NAT boundary. If that gateway operates symmetric NAT, your apparent classification stays the same or gets worse. If the provider uses full cone NAT or implements port forwarding, your classification improves. Testing both states reveals what the provider actually does.
Verifying Encryption and Tunnel Integrity
Not all VPNs encrypt all traffic, and the exclusions are rarely advertised. Some providers exempt WebRTC traffic, multicast packets, or specific UDP ports from the tunnel to improve call quality. The result is a parallel unencrypted path that bypasses the tunnel entirely. Checking whether all traffic flows through the tunnel requires looking at multiple signals at once.
The first signal is certificate inspection. When you connect to a VPN, your browser establishes a TLS session to the tunnel endpoint. Inspect that certificate and verify the hostname and organization match the provider’s claimed infrastructure. A certificate that a generic cloud hosting platform issues signals that your traffic passes through infrastructure outside the provider’s direct control.
The second signal is hash verification of the VPN client binary. Unofficial distribution channels have delivered modified VPN clients with injected telemetry or altered routing rules. After downloading the client, verify its SHA-256 hash against the value published on the provider’s official website. If the hashes do not match, the binary you installed is not what the provider shipped. CapyToolkit’s Hash Generator computes SHA-256, SHA-512, SHA-1, and MD5 hashes entirely in your browser, so the verification happens without uploading the file to any server.
The third signal is the encryption cipher suite. A VPN product shipping in 2026 should negotiate AES-256-GCM or ChaCha20-Poly1305 for data encryption.4 Deprecated ciphers like RC4, Blowfish, or DES signal either neglect or intentional backward compatibility with legacy systems that have known vulnerabilities. According to NIST’s cryptographic algorithm transition guidance, AES-GCM is approved for current cryptographic use. The IETF separately deprecated RC4 in RFC 7465, and modern systems now prefer ChaCha20-Poly1305 as a fast, secure alternative. Deprecated ciphers like RC4, Blowfish, or DES in a modern VPN product signal either neglect or intentional backward compatibility with legacy systems that have known vulnerabilities. Inspect the cipher suite your VPN negotiates using your browser’s developer tools. If the negotiated cipher falls outside the current standard, that is a red flag worth investigating further.5
- Verify the VPN client binary hash matches the published
SHA-256checksum before installing - Inspect the
TLScertificate to confirm the tunnel endpoint belongs to the provider’s infrastructure - Confirm the negotiated cipher suite uses
AES-256-GCMorChaCha20-Poly1305 - Run an external
DNSleak test to verify whether your recursive queries route through the provider’sDNSservers instead of your ISP’s resolvers - Check whether the kill switch blocks both
TCPandUDPtraffic, not justTCP - Re-run these checks after every VPN client update to catch silent configuration changes
Evaluating VPN Provider Transparency
Independent audits are the only verifiable proof of no-logs claims. A provider that publishes audit reports from a recognized firm on a regular schedule is making a claim that can be checked. A provider that references an audit from three years ago without subsequent updates may have changed its infrastructure or logging behavior since then. Read the audit scope carefully: connection timestamps, connection endpoints, and bandwidth data are often excluded from audit scope even when the report confirms “no activity logs.” Knowing what the audit did not cover is as important as knowing what it did. A provider that audits for absence of activity logs but does not audit timestamp retention is making a narrower claim than the marketing suggests.
By offering open-source clients, providers let you verify exactly what the software does with your traffic. When you rely on a proprietary client, it can route traffic outside the tunnel, inject scripts into browser sessions, or collect device telemetry without your knowledge. Publishing client code to a public repository simplifies auditability. Because you do not need cryptography expertise to benefit from this transparency, companies that invest in open-source code build greater trust with the privacy community. Beyond the underlying client codebase, operational signals like active warrant canaries and legal jurisdictions reveal how a provider defends user data under real-world pressure. A warrant canary is a published statement that the provider has not received any secret government subpoenas or gag orders. When a provider removes or fails to update its warrant canary, that silence is itself a signal that something changed.6 Track the canary publication date alongside the jurisdiction: a provider in a Five Eyes country with a stale canary presents a different risk profile than a provider in Switzerland with a recently updated canary. Neither jurisdiction guarantees privacy, but both provide context for how the provider responds to external pressure.
A Browser-Based VPN Evaluation Workflow
The practical evaluation sequence starts with baseline measurements taken before the VPN is active. Run a discover your public IP address without the VPN connected to record your public IP, NAT classification, and ICE candidate type. This baseline is your reference point. Without it, you have no way to detect whether the VPN changed your apparent IP, altered your NAT behavior, or introduced relay routing. Most people skip this step and test only the connected state, which misses the changes the VPN actually made.
After connecting to the VPN, re-run the STUN server test and NAT type check to confirm your public IP has changed to the VPN exit node. Compare the post-connection ICE candidate type against your baseline. A shift from host to srflx or relay candidates indicates the VPN is adding NAT traversal layers that affect WebRTC connectivity. If the diagnose WebRTC ICE connection failures test fails after connecting, investigate whether the provider blocks WebRTC entirely or whether your NAT configuration conflicts with the VPN’s tunnel settings. A complete WebRTC block is a privacy feature from the provider’s perspective, but it breaks video calls and screen sharing.
Pre-connection baseline measurements
The baseline session records three values: your public IP address as seen by external STUN servers, your NAT type classification, and your WebRTC ICE candidate type. STUN discovers your public IP and port mapping; the P2P Tester’s additional analysis classifies your NAT behavior from the patterns in those responses. Record all three before activating the VPN. The public IP is the most straightforward comparison: after connecting, the IP reported by the STUN server should match the VPN exit node’s IP, not your ISP-assigned address. The NAT type tells you whether the VPN improves or degrades your peer-to-peer connectivity.
Skipping the baseline is the most common mistake in VPN evaluation. Without a before-and-after comparison, you cannot distinguish between a VPN that genuinely protects your privacy and one that happens to pass a leak test on a day when your network configuration accidentally masks the problem. The baseline eliminates guesswork by giving you a concrete reference point for every measurement you take after connecting.
Post-connection leak and routing verification
After connecting to the VPN, run the same three measurements again. While the public IP must now show your VPN exit node, your apparent NAT type should either improve or remain steady. To assess your direct peer performance, monitor the resulting WebRTC candidate type to ensure your traffic does not force relay routing through an intermediate TURN server. If any of these values regress after connecting, the VPN is actively degrading your network behavior in ways that speed tests do not capture.
Re-run these checks after every client update, especially if the provider announces infrastructure changes. A VPN that passed all checks on installation can fail silently after an update, and ongoing monitoring is the only way to catch regressions before they compromise your privacy. CapyToolkit’s network tools run entirely in your browser with zero uploads, so you can re-run the full evaluation sequence without worrying about data leaving your machine.
Making the Final Call
Weight each criterion against your actual threat model. A journalist sourcing stories from jurisdictions with aggressive surveillance laws needs verified no-logs claims, strong legal jurisdiction, and an open-source client they can audit. Someone who wants to access geo-restricted streaming content needs reliable server locations and consistent performance, but the privacy stakes are different. A developer testing P2P applications needs NAT traversal that preserves direct peer connections, which rules out VPNs that force relay routing. No single VPN excels at every use case, which is why testing before subscribing matters more than any review site’s star rating.
The browser-based evaluation workflow outlined here takes about twenty minutes to execute. That twenty minutes tells you more about a VPN’s actual behavior than a hundred review articles that only test speed and server count. Prioritize independent audits for trust, open-source client for verification, jurisdiction for legal protection, and browser-based leak tests for ongoing confirmation. If a provider cannot satisfy those criteria, the marketing claims are just marketing. Browser-based tools that process everything locally give you the ability to verify behavior rather than trust claims, and that verification step is what separates a VPN that protects your privacy from one that just says it does.
- 1.
Nasser Mohammed Al-Fannah, “One Leak Will Sink A Ship: WebRTC IP Address Leaks,” arxiv.org, September 2017. https://arxiv.org/abs/1709.05395
- 2.
Cloudflare, “How WebRTC works,” cloudflare.com, accessed July 2026. https://www.cloudflare.com/learning/video/how-webrtc-works/
- 3.
Cloudflare, “What is a TURN server?,” cloudflare.com, accessed July 2026. https://www.cloudflare.com/learning/video-streaming/turn-server/
- 4.
OpenVPN, “Data-Channel Encryption Cipher Negotiation on Access Server,” openvpn.net, accessed July 2026. https://openvpn.net/as-docs/data-channel-encryption-cipher.html
- 5.
Mozilla, “Deprecating the RC4 Cipher,” blog.mozilla.org, September 2015. https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/
- 6.
Kurt Opsahl, “Warrant Canary Frequently Asked Questions,” eff.org, April 2014. https://www.eff.org/deeplinks/2014/04/warrant-canary-faq
