Do Son 
A browser reports a different public IP after a VPN connects. That observation is useful, but it is often asked to support a much larger claim: that the device’s entire connection is private and every application is following the intended route.
The gap is a testing problem. A public-IP result describes the request that reached the checking service. Wider claims require defined coverage, separate observations and a record of the conditions under which each check was made.
Define the claim before choosing the test
There are several possible questions: is this browser request exiting through the VPN, are other applications included, which DNS resolver is handling queries and what happens when the connection fails?
These are related, but not interchangeable. A changed address does not answer all of them. Neither does a green connection indicator.
Start by recording the device, operating-system version, client version and relevant routing settings. Note browser-specific connection tools and any exclusions. Without that context, two apparently conflicting results may simply describe different traffic paths.
For a VPN client, the provider’s documented scope is the starting expectation. The test should examine that expectation, not invent a universal requirement and then assume the software either meets or fails it.
Separate address families and application paths
Where the environment supports both IPv4 and IPv6, a result obtained through one address family should not be treated as a check of the other. Record which path the test service exercised and use an appropriate separate check when needed.
The same discipline applies across applications. A browser extension, system client and application-specific proxy can coexist, producing different routes. Testing the browser demonstrates something about the browser request; it does not establish how a separate synchronisation client or meeting application connects.
Use harmless requests on a device and environment you are authorised to test. Keep unrelated tools and settings stable. A comparison made after several simultaneous changes loses much of its diagnostic value.
If a browser check succeeds while another application fails, investigate the routing and access conditions for that application. The discrepancy may concern an exclusion, a service policy or another part of the setup rather than the basic tunnel state.
Resolver identity needs interpretation
DNS translates names into the addresses used for connections. A DNS test may show resolver information, but an unfamiliar resolver name is not automatically proof that a query escaped the intended route.
Browsers and operating systems can use different DNS arrangements. DNS over HTTPS, for example, sends DNS queries over HTTPS. The resolver selected by a browser can therefore differ from the provider’s default arrangement without the name alone explaining how the traffic travelled.
Record the browser’s secure-DNS setting, system configuration and expected client behaviour. Then interpret the result against that record. A third-party resolver is a fact to investigate; whether it represents a configuration problem depends on the intended route and policy.
Avoid combining resolver location, ownership and transport into one conclusion. A test page may estimate a location or identify an operator without establishing every property of the connection.
Failure behaviour is a separate test case
An established tunnel and a failed tunnel create different conditions. If the client offers traffic-blocking behaviour during a disconnect, confirm the documented scope and settings before checking it.
Use a controlled, non-sensitive session. Observe whether the relevant application stops communicating, reconnects or resumes through another allowed route. Preserve the sequence and any automatic recovery behaviour. Do not perform the experiment while an important transfer is running and then infer the result from the final file status.
A free VPN can support an initial evaluation of the controls available on a particular platform. Check those controls directly. A free plan lacking a premium option should not be tested as though that option were enabled, and results from one platform should not automatically be applied to another.
Report observations at the level they support
A useful record might say that an IPv4 browser request used a particular exit address, while a separate DNS check showed a named resolver under stated secure-DNS settings. A broader assertion of complete anonymity would not follow from those observations.
Keep account identity outside the routing claim as well. A service can associate activity with a signed-in account even when the request travels through the intended VPN route. That is not, by itself, a tunnel leak.
Repeat only the affected checks when a setting or client version changes. The aim is a reproducible understanding of coverage and behaviour, not a collection of reassuring badges. A changed IP is a good first observation. A sound assessment says exactly which claim that observation supports and what remains untested.