Check your public IP before connecting, then check again after connecting to a route. The result reflects the route used by this browser request; other apps may use different routes.
Enable JavaScript for an automatic lookup, or select “Check again.”
Fields that aren’t returned will show “Temporarily unavailable.” This page doesn’t automatically test for DNS leaks, and proxy detection alone can’t confirm whether a connection is working.
Use these results as troubleshooting clues, alongside your routing rules and actual browsing experience.
This is the source address seen by our service. Check your IP before and after connecting to a route and compare the results. If it changes, the route used for this request has changed. If it doesn’t, the connection may still be working: split-tunneling rules could be sending this site over your usual network.
IP locations usually come from databases, not device positioning. Database update schedules, address allocation and how the route is deployed can all affect the result. It doesn’t reveal a visitor’s actual location or, on its own, prove which region a service will show.
The ISP field may show the name of a carrier, data center or network operator—not necessarily your current internet provider. Seeing a data center network when using a remote route is normal. If the service doesn’t return a name, this page won’t fill one in.
This field shows the detection result explicitly returned by the service. “Not detected” doesn’t mean no proxy is in use, and “detected” doesn’t mean the connection is faulty. Database labels can be outdated or inaccurate. If no detection result is returned, the status won’t be shown as negative.
An IP lookup only shows the route used for web requests. DNS resolves domain names to addresses and may use a different route, so check it separately.
Check DNS interception, remote resolution and routing rules in your client settings. Then see whether your browser has custom Secure DNS enabled. To judge whether the results match your setup, first establish which requests should go through the client and which should use local DNS according to your rules.
For a closer check, use a trusted DNS test tool and note the resolver organizations and addresses shown before and after connecting. A resolver in a different region from your public IP doesn’t by itself indicate a leak. Public DNS services may route requests to nearby servers, and database records can affect the displayed location.
If DNS is expected to resolve remotely but you consistently see resolvers associated with your local network, check your client’s DNS rules, your browser’s Secure DNS settings and any conflicting network software. Save your changes, reconnect, clear the DNS cache as instructed by your client, and repeat the same test.
This page doesn’t send requests to external DNS testing services. Without a dedicated DNS route test, it can’t determine whether a leak has or hasn’t occurred.