VPN Split Tunneling Test: Check Your Routing Setup

Split Tunneling Routing Test

Test the egress IP and routing policy used for different network destinations to evaluate if split tunneling rules are working.

Website Egress IP IP Geolocation ISP Status / Latency

Understanding split tunneling and route leaks

What split tunneling is, how it leaks, and how to read the result of this test.

Split tunneling means only part of your traffic goes through the VPN or proxy while the rest goes out directly. It is often deliberate, because routing local or streaming traffic outside the tunnel is faster. The leak happens when the split is not where you think it is. A rule written for one domain may not cover the addresses that domain resolves to. A rule written for IPv4 may leave IPv6 completely outside the tunnel. This test opens connections to several independent endpoints at once and compares the exit address each of them sees, which reveals splits that a single-endpoint check cannot.

Because they were routed differently. If two endpoints report two different addresses, part of your traffic left the tunnel. Common causes are proxy rules that match on hostname rather than destination address, load balancing on the proxy side that assigns several exits to one session, and dual stack setups where IPv4 is tunneled but IPv6 is not. Multiple exits within the same address family are not automatically a problem, but they do mean an observer can correlate your session across more than one address, which reduces anonymity rather than improving it.

It does on many setups. A large number of VPN and proxy configurations only capture IPv4 routes, and any site reachable over IPv6 is then contacted directly from your real address while everything else appears to come from the tunnel. Because modern operating systems prefer IPv6 when it is available, this can quietly send the majority of your browsing outside the tunnel. This test probes IPv4 and IPv6 endpoints separately, so if the two families report different exits you will see it immediately.

Route by destination address rather than by hostname wherever your client allows it, since hostname rules are evaluated before resolution and miss anything reached by address. Make sure the tunnel captures IPv6 as well as IPv4, or disable IPv6 entirely if your exit does not support it. Enable the kill switch or lockdown mode your client offers, so traffic is dropped rather than sent in the clear when the tunnel is down. After changing anything, run this test again: rules that look correct in a configuration file frequently behave differently once the operating system route table is involved.

No. Deliberately keeping local network traffic, printers or a streaming service outside the tunnel is reasonable and often improves performance. The risk is a split you did not intend, or one broader than you believe. The useful question is not whether traffic is split, but whether the specific traffic you care about is inside the tunnel. This test answers that by showing you exactly which endpoints saw which exit address, rather than reporting a single overall verdict.