Browser connection path check

Public IP and geolocation

After connecting to a route, check which public IP your browser is actually using. This shows network details for this request only; it doesn’t show how traffic from every app on your device is routed.

Current check results

Same-origin lookup

Waiting to check. JavaScript is required to retrieve your current network information.

Public IP
Temporarily unavailable
Country / region
Temporarily unavailable
Internet service provider (ISP)
Temporarily unavailable
Proxy detected
Temporarily unavailable

Run another check after switching routes or changing proxy mode. Results reflect the browser’s connection path when the request was sent.

What these results mean

Public IP: where the request comes from

The public IP is the address identified when this request reaches the lookup service. Record the result before connecting to a route, then connect to your chosen route and check again. If the address changes, this browser request is using a different exit. If it doesn’t, check whether this page is set to connect directly and whether your browser is using the expected proxy settings.

Geolocation and ISP: clues from databases

Country, region, and ISP information comes from IP geolocation databases and may be out of date. It doesn’t establish your device’s physical location, and may not match the route name exactly. The ISP may identify the data center or network provider at the exit point, rather than your local internet provider.

Proxy detection: not a connection test

Proxy detection relies on flags returned by the lookup service. “No proxy detected” doesn’t mean the request wasn’t sent through a proxy; “Proxy detected” doesn’t identify the route in use. If the service returns no clear flag, this page shows “Temporarily unavailable” rather than inferring a result from your IP or location.

DNS leak check

A changed public IP doesn’t mean DNS lookups are taking the same route. A DNS leak occurs when domain lookups that should use the expected network path are sent through another resolver path. This page’s GeoIP lookup can’t inspect all DNS requests made by your system, so it can’t confirm that you’ve “passed a DNS leak test.”

  1. Check your client’s DNS mode. Open the network settings in your client and check whether it handles DNS and how its routing rules are configured. System proxy and tunnel modes may cover different traffic; the connection icon alone isn’t enough to tell.
  2. Check your browser’s secure DNS settings. Your browser may choose an encrypted DNS service independently of your system or client settings. Note the current settings before making changes, and follow your client’s instructions. Changing several settings at once can make troubleshooting harder.
  3. Check actual DNS requests. Use your system’s network diagnostic tools or a diagnostic view provided by your client to see which resolver handles requests for the target domain. The DNS settings listed by your system show its configuration, not necessarily the path an app actually uses.
  4. Consider your routing rules. A domain routed directly may be expected to use a local resolver. Investigate further only if a domain that should use a route is still resolved through an unexpected path. A resolver’s location alone isn’t evidence of a leak.

For help, describe your platform, client mode, target app, and the issue in a support ticket. Before sharing a screenshot, hide your subscription link and account credentials.