One request answers one routing question
An IP-checking page reports the source address seen by a particular endpoint. When that address matches your VPN’s expected egress, you have useful evidence about that request. You have not yet established how every application, protocol and address family on the device is routed.
That distinction becomes important with browser-only proxies and split-tunnel VPNs. A proxy extension may handle ordinary web traffic while another application uses the underlying connection. A split tunnel may intentionally exclude work services or local resources. Neither behaviour can be understood from one number shown on a webpage.
Start with the public IP check, and write down what you expected before running it. The meaningful comparison is between an observed route and a documented configuration, not between a green icon and a red one.
WebRTC adds a different observation
WebRTC gathers connection candidates to help peers find a usable path. A STUN request can reveal a server-reflexive mapping that differs from the source address of an HTTP request. That can be relevant when a browser proxy handles one traffic type but not another.
A host candidate ending in .local is generally an mDNS-masked candidate, not a public IP. A server-reflexive candidate describes an observed mapping. A relay candidate depends on TURN infrastructure that an application configures. Treating all three as the same kind of “leaked address” hides the technical distinction you need for troubleshooting.
The WebRTC test records the candidate types and addresses it observes. It also records whether the observation window ended before gathering completed. No candidates can result from privacy settings, disabled APIs, blocked traffic or an unreachable STUN service. It is not automatically proof of complete protection.
DNS requires its own question
A public DNS record explorer answers what its chosen resolver knows about a name. It does not by itself tell you which resolver your operating system normally uses or whether your VPN carries those DNS queries. Those are different measurements that need a suitable DNS-route test or local network inspection.
Browser DNS-over-HTTPS settings can also differ from operating-system resolver settings. Enterprise policy, local split-horizon names and VPN clients can influence resolution. If an internal hostname stops working after a VPN change, the public record for that name may have little relevance to the private resolver view the application expects.
| Observation | Useful conclusion | Still unknown |
|---|---|---|
| HTTP public IP | Source address seen by that endpoint | Other applications and protocols |
| WebRTC candidate | A route candidate exposed during ICE gathering | All possible future connection paths |
| Public DNS answer | One resolver’s response to a name | Your device’s complete DNS routing policy |
Keep the comparison controlled
Connect the intended VPN endpoint and wait for the application to report its settled state. Run the HTTP and WebRTC observations close together, then save the reports. If a result is unexpected, review the VPN’s excluded applications, browser proxy configuration and address-family support before making changes.
Change one setting and repeat. Reconnecting a mobile network or switching endpoints between checks can create a legitimate address difference that looks like an inconsistency. If you are evaluating a kill switch, a controlled local test should consider what happens during disconnection and reconnection; a static webpage observation cannot cover that lifecycle.
Keep legitimate functionality in view. Blocking WebRTC entirely can disable calls and collaborative applications. A configuration that hides one signal while silently breaking your work is not automatically the right choice. Use documented controls that match the actual routing requirement.
Write a precise finding
Prefer a finding such as “the HTTP request used the expected exit address, while the STUN mapping used another public address” to “the VPN is unsafe.” The precise version identifies the behaviour that an administrator or provider can investigate. Add the date, browser version and relevant settings, and avoid posting unnecessary network identifiers publicly.
For the underlying terminology, the ICE specification and MDN’s WebRTC connectivity guide explain why candidate discovery exists. Understanding the mechanism makes a test result more actionable than a general promise of invisibility.
Create a route matrix before testing
List the traffic you expect the VPN to carry: ordinary browser requests, browser real-time connections, DNS resolution and any separate applications involved in your work. Mark intentional exclusions. A split tunnel is not automatically a failure; the question is whether the observed traffic follows the policy you selected.
Record whether the product is a full-device VPN, a browser proxy or an application-specific tunnel. Similar interface labels can conceal different scope. Include the chosen exit region and address-family support. This prevents an IPv4-only expectation from being mistaken for a complete statement about IPv6 traffic.
Use one network connection throughout the first test. Moving from Wi-Fi to mobile data can change the underlying route while the VPN reconnects. Capture the time of each observation so an address difference can be associated with a transition rather than treated as simultaneous contradictory evidence.
Inspect connection transitions deliberately
A static check while the VPN is settled does not exercise disconnection behaviour. For a controlled kill-switch test on your own device, define which harmless request should stop when the tunnel is unavailable. Keep unrelated sensitive applications closed so the experiment does not expose real work while you investigate the route.
Observe both the failure and recovery stages. An application may retain an existing connection, fail closed, reconnect outside the tunnel or wait for the tunnel to return. Record the actual result rather than assuming every product implements the same lifecycle. The VPN client's status icon is useful context but is not a packet-path measurement.
If you need stronger evidence, inspect the local routing table, resolver configuration and traffic through appropriate authorised operating-system tools. A webpage cannot see every packet from another process. Keep that deeper test separate from the browser checks and document which observation supports each conclusion.
Compare IPv4 and IPv6 as separate paths
A device can have both address families active, and a service may be reachable through either. A single public-IP endpoint may exercise only one family. Review the VPN's documented handling and use suitable family-specific observations when your requirement covers both.
Do not identify a public IPv6 address as a MAC address or a person's identity. Address construction and privacy behaviour vary. The important routing question is whether traffic using that address family follows the intended path, not whether its text looks unfamiliar compared with a dotted IPv4 value.
If an application fails only after enabling the VPN, inspect DNS answers and route availability together. A name can resolve to an address the tunnel cannot reach. Removing IPv6 globally may conceal the cause; a targeted configuration repair is easier to maintain when the intended network supports both families.
Write a report the provider can reproduce
Include product version, operating system, browser, connection type, selected endpoint, intentional exclusions and the exact check that differed. Provide timestamps and redacted address relationships, such as expected exit versus underlying connection, when full addresses are unnecessary. Keep the original evidence privately if support needs a secure follow-up.
Describe whether the issue occurs only during reconnect, only in one browser or only for one address family. These distinctions point to different owners and code paths. A broad statement that the VPN leaks gives support less to work with than a reproducible mismatch tied to a specific operation.
Frequently asked questions
Does a matching public IP prove every application uses the VPN?
It proves only the observed request used that source address at the endpoint. Other applications, protocols or address families can follow different routes. Compare the product's scope and exclusions with measurements appropriate to each traffic type you actually need to protect.
Is a private WebRTC candidate a public leak?
A private address or mDNS-masked host candidate is different from a public server-reflexive mapping. Read the candidate type and scope before drawing a conclusion. The practical question is what route information the browser exposed and whether it conflicts with your intended configuration.
Does the DNS explorer test my VPN's DNS routing?
No. It reports answers from the resolver used by the site's DNS service. Your device may use another resolver, browser encrypted-DNS setting or private VPN DNS path. Investigate those through an appropriate local or route-specific test rather than treating a public record answer as a leak test.
Why can the VPN exit address change?
Providers can use pools, reconnect to another server or route different destinations through different infrastructure. Mobile network changes can also trigger reconnection. Compare the observed change with the provider's documented behaviour and your selected policy before assuming the address is outside the tunnel.
Can blocking WebRTC solve every routing concern?
It affects a browser feature and can break calls, but it does not configure every application or DNS path. Identify the traffic that violates your requirement and apply the appropriate supported control. A blocked browser test is not evidence about unrelated processes on the device.
What if the test returns no candidates?
Record whether gathering completed and whether an error or timeout occurred. Privacy policy, unavailable APIs and unreachable STUN infrastructure can all affect the result. No observed candidate is a limited outcome, not proof that all future network paths are constrained.
When is the investigation complete?
The measured traffic should follow the documented route matrix in both settled and relevant transition states, while required applications remain usable. Preserve unresolved scope limits explicitly. A collection of consistent observations is more useful than a single universal safe label.