Define what you expect the VPN to change
Before testing, read the provider’s documentation for the server or mode you selected. Record the expected exit country, whether IPv4 and IPv6 are carried, which DNS resolvers should be used, and whether split tunneling excludes any apps. Without an expected design, an unfamiliar result cannot be classified reliably.
Choose one browser or test app and keep the underlying Wi-Fi or mobile network fixed. Browser secure DNS and Android Private DNS can affect the resolver path, so note those settings rather than changing them in the middle of the baseline.
Record a baseline without the VPN
- Disconnect the VPN
Wait for Android to report that the tunnel is no longer active. Keep the intended Wi-Fi or mobile network connected.
- Record public IPv4 and IPv6
Note each available address family, network organization, and approximate country.
- Run a fresh DNS test
Record every resolver organization and country shown, along with the app or browser used.
- Add the context
Write down the time, network type, Android Private DNS state, and any browser secure-DNS setting.
The baseline is not a “bad” state. It is the reference that lets you see which observed paths the VPN changes.
Continue with How DNS works—and what a DNS leak test really shows, compare it with Why is my IP location wrong?, or use IP Finder for Android for the next practical step.
Connect the VPN and repeat under the same conditions
- Connect the chosen VPN server
Wait until Android and the VPN app report the connection active.
- Rerun public-IP checks
Check IPv4 and IPv6 separately where possible; record unavailable families as well as changed values.
- Rerun the DNS test
Use the same browser or app and capture all resolver entries.
- Compare with documentation
Match the exit region, protocol coverage, resolver policy, and split-tunneling behavior promised by the provider.
The protocol details in this guide follow VPN developer guide and RFC 1034 — Domain Names: Concepts and Facilities; use those primary specifications when you need exact terminology or edge-case behavior.
How to interpret the comparison
| Observation | Supported conclusion | Question still open |
|---|---|---|
| Public IP changes to expected VPN network | The tested public path presented the VPN exit source | Whether every app and address family uses it |
| DNS changes to expected resolver | The test lookups reached expected resolver infrastructure | Whether every app uses identical DNS behavior |
| IP changes but DNS remains on baseline provider | Public and DNS observations followed different expected or unexpected paths | Private DNS, browser DNS, split tunneling, or VPN policy |
| One address family remains unchanged | That family needs separate investigation | Whether the VPN supports, blocks, or bypasses it |
A result can be technically consistent with an intentional configuration. For example, a split-tunneled browser may keep the baseline path while another app uses the tunnel. Label the app used before calling the overall VPN broken.
Troubleshoot an unexpected IP or DNS result
- Refresh or rerun the check after reconnecting; do not rely on a page loaded before the VPN connected.
- Check IPv4 and IPv6 separately. One family can follow a different path.
- Review app exclusions and split-tunneling rules in the VPN.
- Check Android Private DNS and the test browser’s secure-DNS setting.
- Try another VPN server while keeping the underlying network and test method fixed.
- Compare with the provider’s current documentation and status information.
- Send support the baseline, VPN result, time, device settings, and selected server if the mismatch persists.
What this check cannot certify
The comparison samples the public-IP and DNS behavior of the tools you ran. It does not inspect all device traffic, audit VPN cryptography, prove that every application follows the tunnel, detect every possible traffic leak, or establish anonymity. A provider can also operate expected infrastructure under names or locations that are not obvious in a third-party database.