Verify a Split Tunnel Works: One IP Result Is Not a Test

A single browser page that reports an IP address proves almost nothing about a split tunnel. A visible address can be the right one for the wrong reason, and an excluded flow is never exercised by it. Write the expected result down before you test: which application or destination should use the tunnel, which should stay direct, and what should stop when the tunnel fails. Without that plan, any plausible number looks like success.

The myth: an address lookup proves coverage

The IP check answers one question: what the outside world sees from one application at one moment. It says nothing about an internal prefix, a second browser profile or a name that should resolve privately. It also says nothing about failure, which is the half of a split-tunnel design that breaks in production.

An address page also cannot show the route, the resolver or the failure policy. Treat it as one observation, not a verdict.

Exercise an included flow and an excluded one

Send a harmless request from the application that should be included, or to the prefix you expect to route through the tunnel, and log the source, destination, address family and observed path. Do the same for a flow that should stay direct. The excluded side is the one people skip, and it is the only evidence that the split is deliberate rather than accidental. A helper process can carry a separate policy identity, so test in the process that owns the socket.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

That is why a test run in the wrong application can show the opposite of what the design intends. Write the four fields down for both sides before drawing any conclusion.

Add DNS and the failure case

Query the system resolver and the resolver the app uses, then compare those answers with the exit address the site reports. The two layers can disagree by design, and one browser lookup does not exercise the operating system policy. A shell makes the comparison repeatable: Break the tunnel on purpose, then make a request the browser has not cached; a page served from cache tells you nothing about which way the fallback went. Record what actually happened rather than what the design predicted.

curl -s https://ifconfig.me
nslookup intranet.example

A split tunnel that fails closed and one that fails open look identical until you break the tunnel deliberately. Record which behaviour you observed, not which one you expected.

Repeat after the state changes

Repeat the same observations after a reconnect, a network switch and a relevant application update. A stored exclusion can keep pointing at a path or an application identity that no longer exists, and the design quietly stops matching its documentation. Those three events are where split tunnels drift, and each one is cheap to retest. A test that only runs once at deployment describes a configuration that no longer exists.

If a result differs, find the rule owner and the processing stage before changing several settings at once. Changing five things and observing one result is not a diagnosis, it is a new configuration.

What the result should establish

Tie the observations to the policy and client version you actually tested. The goal is to show that this deployment matches the coverage it claims, not that every future application will be private. That is a narrower claim, and it is the one you can actually support with evidence. Write the claim, the version and the four-field results into the change record.

Then the next reviewer can tell whether the design changed or the test did. A split tunnel is verified when both sides, the resolver split and the failure behaviour match what you wrote down at the start. One IP result verifies none of them.