IP Address Check and Egress Detection

What This Information Means

Public IP: Where your request enters the internet

This is the address seen by our endpoint. With split tunneling enabled, domestic sites may connect directly while international sites may use a selected route. If this site matches a direct-connection rule, the result may still show your local network’s public IP. To confirm whether an app is using the expected route, check its rule matches and connection logs in your client.

Geolocation and ISP: Network data, not an exact location

The country and region come from IP geolocation data and may differ from a route name or the physical location of a data center. They can’t be used to determine someone’s exact address. The ISP identifies the provider or network associated with this IP; it may not be your local broadband provider. Data updates can lag, so a region name alone can’t tell you whether your connection is working properly.

Proxy detection: Based only on returned data

We show “Proxy detected” or “No proxy detected” only when the endpoint explicitly returns a proxy-detection field. If it doesn’t, we show “Temporarily unavailable.” No proxy detected doesn’t necessarily mean you’re connecting directly, and proxy detected doesn’t mean your privacy has been compromised. This result can’t replace checking your client’s rules.

DNS Leak Check

An IP lookup and a DNS check are different. DNS translates domain names into IP addresses, and DNS requests may take a different route even when your browser’s egress is as expected. This page checks egress details only; it doesn’t test DNS resolvers or mark an IP lookup as a successful DNS check.

1. Review your client’s DNS policy. Find the DNS or domain resolution settings and confirm that requests for international sites are handled by the client as expected. Available options depend on your client’s current interface.
2. Check your browser’s Secure DNS settings. The browser’s encrypted DNS may work independently of system settings. Note the current option, then compare it with your client’s documentation to avoid using different DNS routes in the browser and client.
3. Compare rules and connection logs. Visit the site you want to check, then review its matching rule, connection route, and any DNS logs available in the client. A changed public IP alone doesn’t prove that DNS requests took a different route.
4. Rule out caching. After changing rules, clear the DNS cache as directed by your system or client, then reconnect your browser. If the available logs don’t confirm the DNS route, leave the result as “Unknown.”

A conclusive DNS leak assessment requires a dedicated test that can observe where DNS requests originate. This page can’t do that. If you can’t confirm the route, submit a support ticket in the user dashboard with your platform, client settings, and steps to reproduce the issue.