Public IP and Network Check

Public IP: The Address Websites See

Your public IP is the address our site identified when it received this request. It isn’t your device’s address on a local network. Check before and after connecting to a route: if the address changes, your route to our site has changed. If it stays the same, check your client’s connection status and routing rules.

If our site is set to connect directly, this page may still show your local network’s public IP even when your client is connected. Check the client’s routing mode and run the check again; an unchanged address alone doesn’t mean the entire connection has failed.

Country, Region, and ISP: Approximate Attribution, Not Exact Location

Country and region are based on IP geolocation databases and may differ from the route name, your device’s actual location, or how a platform identifies your connection. ISP refers to the network provider or organization associated with the address in the database. On a hosted network, it may show a data center rather than your current access provider.

There can be a delay between an address change and database updates. These fields can help you check your exit route, but they don’t prove that an address is dedicated, residential, or eligible for access to a particular platform.

Proxy Detection: An Indicator, Not a Verdict

This page shows “Proxy detected” or “No proxy detected” only when the endpoint explicitly returns a proxy detection field. If no field is provided, it shows “Temporarily unavailable” rather than inferring a result from the IP, ISP name, or location.

“No proxy detected” doesn’t mean you aren’t using a proxy or that your privacy protection is fully effective. “Proxy detected” doesn’t mean your connection is faulty, either. Websites may use different detection methods.

DNS translates website domain names into network addresses. If your requests go through a proxy but domain lookups still use an unexpected local route, the DNS provider on that route may be able to see those lookups. Whether this is a leak depends on your intended routing and actual configuration—not just the DNS provider’s listed location.

1. Start by identifying the intended route. Decide whether the proxy should cover your browser, specific apps, or all system traffic. With a browser-only proxy, other apps and system DNS may use different routes.
2. Check your client’s DNS and routing settings. See whether the client handles DNS, how it routes different domains, and whether DNS falls back to the system resolver if the connection has issues. Option names vary by client; check the documentation for your current version.
3. Check your browser’s Secure DNS settings. A browser may use its own encrypted DNS resolver. Check it alongside system and client DNS settings to avoid conflicting configurations. Encrypted DNS alone doesn’t prove that requests go through a proxy.
4. Compare the actual DNS routes. Check your system DNS configuration, the client’s local diagnostic logs, and tools with DNS testing features. A standard domain lookup command can help show DNS results, but it can’t establish the browser’s complete request route on its own.
5. Verify again after making changes. Reconnect the client, clear the DNS cache as directed by your system or browser, then check your exit route and DNS again. Before sharing diagnostic information, remove account details, subscription links, and other credentials.

For connection help, see the getting started guide. If you’re still unsure, describe your platform, connection mode, and what’s happening in a support ticket. Don’t share your password or full subscription link.