Public IP and Network Check

Public IP: the address this site sees

Your public IP is the address used by this request when it reached this site. It is not your device’s address on the local network. Check again after switching routes; if the address changes, this browser request is using a different exit. If it stays the same, first check that your client is connected and that this site is not set to bypass the proxy in your routing rules.

Location and ISP: address records, not device location

Location comes from an IP address database and may differ from the actual exit location. It does not indicate your device’s physical location. The ISP field shows a network provider or organization listed in the database. It may refer to a data center, upstream carrier or address holder, and may not match the name of your client.

Proxy detection: an indicator, not a usability verdict

“Proxy detected” means the interface classified this address as a proxy exit. “No proxy detected” only means it was not identified as one. Neither result guarantees that an AI tool or streaming service will work. Services may also consider account region, sign-in status and their own risk controls. If the detection field is missing, this page will not infer a result.

This page checks only requests made by the current browser. Command-line tools, IDE extensions and other apps may use different proxy settings. IPv4 and IPv6 may also take different routes. A single result cannot verify the connection path for every app.

DNS translates domain names into IP addresses. If lookup requests expected to be handled by your client are still sent through a local network resolver, DNS and browsing traffic may take different routes. This page does not run a DNS leak test and will not label your connection “passed” or “leak-free” based on your public IP.

1. Confirm the expected route. Check whether your client is using app-level proxying, a system proxy or a mode that routes all system traffic. An app-level proxy may cover only configured apps, so it does not confirm that system DNS is routed through the client.
2. Check your DNS settings. Review your client’s DNS configuration, system network settings and whether your browser has enabled Secure DNS separately. A browser using its own resolver may behave differently from the system settings. Understand the current rules before changing them.
3. Use a dedicated DNS test and compare results. To verify your setup, choose a DNS leak test tool you trust and test both before and after disconnecting from and connecting to a route. Check the resolver’s network, the expected routing and the test’s guidance—not just the displayed location.
4. Troubleshoot differences one setting at a time. Check routing rules, app-specific proxies and IPv6 settings. Change one setting, then test again to make it easier to identify the cause. On managed work devices, follow your organization’s network configuration requirements.

A resolver appearing in another region does not necessarily mean there is a leak; seeing one in the expected region does not prove that every request followed the expected route. Public DNS services may use nearby or distributed endpoints, so check the client’s rules and the test tool’s guidance.

For help checking client settings, see the Getting Started Guide. For differences between browsers, APIs and development environments when using AI tools, see the AI Tools Guide.