Free VPN Test guide ยท Published 2026-10-05
How to test a free VPN
Use the same checks for a free VPN and a paid subscription. Start with your ordinary connection, compare the VPN-facing address, then examine the separate browser and DNS routes. No single green badge can verify every part of a tunnel.
Start the free VPN testPublic IP and WebRTC checks are available here. Active DNS and IPv6-only route checks are temporarily unavailable.
1. Record your ordinary connection
Disconnect the VPN and open the VPN test. Note the public IPv4 address, available IPv6 address and network organization. Keep these results in your own notes; the site does not store a permanent before-and-after profile.
Use the same browser and network for both parts of the comparison. Moving from Wi-Fi to mobile data can change the address even without a VPN, so a network change makes the result harder to interpret.
2. Connect the VPN and reload
Open the provider's app, choose the available server and wait for its connected status. Reload the test page. A full tunnel normally changes the public address or network owner, but a nearby VPN server can leave the country estimate unchanged.
If the address stays the same, check split tunneling, browser exclusions and whether you installed a browser proxy extension rather than a full VPN client. Changing the server and testing again can help distinguish a route problem from an unavailable exit.
3. Check WebRTC candidates
Run the WebRTC test with the VPN connected. A public candidate that matches your ordinary ISP address deserves investigation. Private LAN addresses and temporary .local names are different signals and are not automatically public IP leaks.
Some browsers suppress candidates or expose only the protected address. No candidate result does not prove that every installed application uses the VPN. This check describes what the browser exposes in this test.
4. Test IPv6 and DNS separately
Run the IPv6 test against our IPv6-only endpoint. If it is reachable, compare the observed address and network with the expected VPN route. If it cannot be reached, IPv6 may be absent, blocked by the VPN or affected by a connection problem.
Run the DNS leak test before and after connecting as well. It reports the recursive resolver addresses that ask our authoritative service for fresh hostnames. An ISP resolver appearing only after connection may deserve investigation; a public resolver alone cannot prove a leak.
5. Interpret detection evidence carefully
A known relay-list match supports the VPN detection result. Missing evidence can mean that the provider's exit is new, private or outside the available inventories. Detection coverage and successful routing are separate questions.
Repeat the checks after changing devices, sleep, an app update or a network change. For claims about encryption, logging and kill-switch behavior, use the provider's documentation and suitable device-level tests; a web page cannot independently inspect the whole tunnel.