IP Leak Test: Make Your VPN Fail on Purpose
The VPN says Connected when Leo closes his laptop at home. It still says Connected after he wakes it on café Wi-Fi. For three seconds during that handoff, his ordinary IP address may tell a different story.
An IP leak test shouldn't begin with a green shield. It begins with a baseline, then tries to make the protected route fail in controlled ways.
The goal is simple: know which address should appear, force the awkward moments, and compare the result—not the icon.
A Baseline Gives the Test Meaning
Disconnect the VPN on a trusted network. Open a reputable IP-checking page and record the public IPv4 address, public IPv6 address if one exists, ISP name, and rough location. Keep the full addresses private; they are the identifiers you're testing.
Repeat the baseline in each browser you actually use. Browser extensions, privacy settings, and WebRTC handling can change the result even when the device and network stay put.
Now connect to a nearby VPN server, wait for the route to settle, and reload the tests in a fresh private window. The ordinary public IPv4 address should disappear. The connected result should show the VPN exit's address, not merely a different city label for the same address.
Geolocation databases are estimates. A VPN-owned address mapped to the wrong suburb isn't a leak; your normal address appearing is.
Four Clues Answer Four Different Questions
Don't flatten every result into “IP.” Each clue describes a different path.
- Public IPv4 is the common source address a destination sees. While protected, it should be the VPN exit's address.
- Public IPv6 is another globally routable address. It should use the provider's supported tunnel route or be unavailable while the VPN is active.
- WebRTC candidates are addresses a browser may expose while finding a real-time media path.
- DNS resolvers answer hostname lookups. A DNS result can expose the resolver path without revealing the same thing as a public-IP result.
The IETF's WebRTC IP-handling guidance specifically describes split-tunnel cases where candidate discovery can surface both a VPN public address and an ISP public address. That is why the exact browser matters.
Private addresses need context. The blocks defined in RFC 1918 are for private internets and have no global meaning. Seeing 192.168.x.x or 10.x.x.x can add local-network fingerprinting information, but it isn't the same event as exposing your public ISP address.
IPv6 Can't Be Graded by an IPv4 Result
Some networks give Leo both address families. If the VPN routes IPv4 but leaves IPv6 on the café interface, a site can receive a direct public IPv6 address beside the protected IPv4 one.
Test IPv6 before and after connecting. The protected state should match the provider's documentation: either a VPN-routed IPv6 address or no public IPv6 connectivity. “IPv4 changed” doesn't answer that question.
Temporarily disabling IPv6 can help isolate the fault. It is a diagnostic, not a durable substitute for supported routing or blocking; operating-system and network updates can restore interfaces later.
WebRTC Is a Browser Test, Not a VPN Verdict
Open the same WebRTC test in the browsers and profiles used for calls. Note the normal public address, the VPN public address, and any private candidates separately.
Don't disable WebRTC blindly. Video calls may depend on it, and browsers offer different privacy modes. A setting that suppresses non-proxied UDP candidates may solve the exposure without breaking the entire feature.
If only one browser exposes the ISP address, investigate that browser's extensions, proxy rules, and WebRTC policy before declaring the whole VPN broken. If every browser does, the device route deserves attention.
A fixed VPN gateway such as the GL.iNet Brume 2 can make the intended path consistent for devices that can't run a full client. In a home test, compare one device behind the gateway with another on the ordinary LAN. The hardware doesn't make leak testing optional.
- Sits on a wired network as a dedicated gateway for OpenVPN or WireGuard traffic
- Can run VPN client and server roles together for remote access and protected outbound browsing
- Has no Wi-Fi radio, making it best for pairing with an existing router or access point
Write down which port, SSID, or policy is protected, then label the ordinary comparison route too. Test both labels on purpose. Without that map, a clean test may only prove that you happened to join the right network once.
Split Tunneling Creates Expected Exposure
An excluded browser is supposed to show the normal public address. Its traffic leaves through the ordinary route, while a covered browser travels through the VPN and appears from the exit server.
Follow the observers. The device knows which rule chose each path. The café and ISP see direct connections from the excluded browser and an encrypted connection for covered traffic. The VPN operator handles only the covered side. Each destination sees the public IP of the path that reached it.
That isn't a leak if the rule was deliberate. The risk is forgetting the exception, excluding more than intended, or testing the wrong app and treating its normal address as surprising.
Break the Tunnel on Purpose
The steady state is the easy exam. Leave an IP-check page refreshing while you switch VPN servers, sleep and wake the device, move between Wi-Fi and cellular, restart the app, and briefly interrupt the network.
Watch for the baseline address during each gap. A kill switch should stop traffic until the protected route returns, but names don't guarantee behavior. Some modes engage only after a session starts; others block whenever the VPN is inactive.
Run the failure test after a reboot too. Persistent protection matters most before you remember to open the app.
If you regularly move several devices across hotel or café networks, a travel router such as the GL.iNet Beryl AX can create one controlled upstream handoff. Test its VPN policy, captive-portal behavior, and fallback path with the same skepticism.
A router can hide a network change from client devices, but it introduces another control plane. Check both sides: the router's upstream public address and the device's visible exit.
- Combines Wi-Fi 6 with a 2.5-gigabit WAN port in a compact travel-friendly body
- Runs OpenVPN and WireGuard profiles from compatible VPN providers across connected devices
- Adds WPA3, encrypted DNS, captive-portal support, and a configurable privacy switch
Fix the Leak You Actually Found
For a reconnect leak, enable the kill switch, update the app, and retest the exact handoff. Try another supported protocol because reconnection behavior can differ.
For an IPv6 leak, follow the provider's platform instructions for routing or blocking IPv6. For a browser-only leak, inspect WebRTC and proxy behavior. For an unexplained route, temporarily disable other VPNs, custom firewalls, security suites, and stale manual profiles one at a time.
Record the operating system, VPN app version, protocol, server, network type, and leak category before contacting support. Mask the ordinary IP in anything public.
A Clean Result Expires
Leo's clean test proves one device, one network, one software stack, and one moment. A major browser, VPN, router, or operating-system update can change routes and permissions.
Retest the baseline, connected state, and one forced failure after meaningful updates. The icon can tell you what the app believes. Only the route comparison tells you what the internet received.