Public IP and Network Test

What these results mean

Public IP: the address websites see

Your public IP is the address used when this request reaches our site, not your device’s private address on your home network. If your browser traffic goes through the selected route, the result will usually show that route’s exit address. With split tunneling, this page may still use your local network. If the address hasn’t changed, check that your client is connected and that its current rules include your browser, then run the test again.

Location and ISP: network ownership in databases

Location results come from IP geolocation data, not your device’s location services. Database updates, address allocation, and how the exit is deployed can all affect what you see. The ISP may be the data center or network provider used by the exit, rather than your local internet provider. Websites may use different geolocation databases, so they may not identify the location the same way this page does.

Proxy detection: an indicator, not a connection verdict

This page shows “Proxy detected” or “No proxy detected” only when the service explicitly returns a proxy status. “No proxy detected” does not prove that your connection isn’t using a proxy or confirm your privacy status. If the status field is missing, the page shows “Temporarily unavailable” instead of treating it as a negative result.

DNS Leak Check

DNS translates domain names into addresses that devices can connect to. Browser traffic and DNS lookups may take different routes, so checking your public IP alone can’t confirm whether DNS requests follow the expected path. This page doesn’t actively test DNS, so it won’t automatically report that there are no leaks.

1. Confirm which traffic should use the route

   Check the client’s current connection mode: does it handle only selected apps and domains, or route all device traffic? Requests that go direct under your rules can coexist with requests sent through the route. First identify which requests should use it so you have a clear basis for comparison.

2. Check your system and client DNS settings

   Check which DNS server your system uses and whether your client offers DNS interception or remote resolution. Follow the client’s documentation to confirm that the relevant features are working. If your device is managed by your workplace or school, follow its network policies before changing settings.

3. Check your browser’s Secure DNS

   Your browser may use encrypted DNS independently of your system settings. Check the Secure DNS option in your browser’s privacy or security settings and confirm that it matches your client’s DNS policy. Don’t judge a leak solely by the resolver’s name or location; consider the route the request was supposed to take.

4. Use DNS records to verify the route

   If your client provides connection logs, open the domain you’re checking and review its DNS and connection records. Before doing so, check how long logs are kept, especially if they may contain sensitive information. For further verification, use a domain you control and review its DNS query logs to see where requests originate. Only conclude that traffic took an unexpected route when you have evidence from actual DNS queries.

If your public IP has changed but a service still reports the wrong region, check your routing and DNS settings first, then reconnect. Switching regions repeatedly can make the issue harder to diagnose and may trigger account security checks.