Your current IP and network.

What these results mean

Public IP: the source of this request

Your public IP is the source address seen by our API for this request. Check it before and after connecting to a route: if it changes, the IP used to reach this API has changed. If it hasn’t, first check that your client is connected and that its rules aren’t sending requests to our site over your local network. This result alone doesn’t show that your entire connection is unavailable.

Location and ISP: clues from IP registration data

The country or region is based on IP geolocation data. ISP usually refers to the network provider or organization associated with the address. Neither indicates your device’s live location, and neither is guaranteed to match a route’s name exactly. Database updates, IP reassignment and network routing can all affect what you see.

Proxy detection: an indicator, not a verdict

This page displays “Proxy detected” or “No proxy detected” only when the API explicitly returns a result. No proxy detected doesn’t mean you aren’t using one, and proxy detected doesn’t mean your connection has a problem. This check can’t verify encryption strength or privacy, or determine whether a streaming service or AI tool allows access.

DNS leak check

DNS translates domain names into network addresses. A web request using the expected public IP doesn’t necessarily mean DNS lookups followed the same route. A DNS leak generally means lookup requests are handled by a resolver outside the expected path, which may reveal the domains you look up to that service.

1. Note your baseline before connecting. Check your system’s current DNS settings and whether your browser has Secure DNS enabled separately. You can note your public IP for comparison after connecting; this page doesn’t save past results.
2. Check your client after connecting. Review its DNS, routing rules and traffic interception settings. If it provides DNS logs, check the path used to handle domain lookups. Setting names and locations vary by client version.
3. Compare browser and system settings. Browser-specific Secure DNS, system DNS settings and other network tools may use different paths. Don’t assume where lookup requests go based only on the resolver’s name in your settings.
4. Use observed DNS requests to assess the result. A complete test requires observing which resolver receives actual DNS requests; your public IP alone can’t establish this. If you use a dedicated DNS testing tool, read its privacy policy first and compare the results with your expected DNS path, not just the displayed location.

Seeing your local ISP in DNS results is worth investigating, but it isn’t conclusive on its own. A resolver’s registered location can differ from the location of your web traffic’s public IP without indicating a leak. After changing settings, disconnect and reconnect, revisit the service you’re testing, and check what happens.

For help with client settings, read the Getting Started Guide. If your connection isn’t behaving as expected, visit the Support Center or describe your platform, selected route and symptoms in a support ticket.