IP ADDRESS
Public IP
Loading
NETWORK DIAGNOSTIC / GEOIP
Reads the public details for the current network request to verify whether the route has changed, the location matches expectations, and the ISP information is different.
CURRENT CONNECTION
IP ADDRESS
Loading
LOCATION
Loading
NETWORK
Loading
PROXY SIGNAL
Loading
Results are provided by this site's same-origin GeoIP API.
Each field only shows where the current network request exits. To determine whether the connection is behaving as expected, review the public IP, location, ISP, and client status together.
Your public IP is the network address visible to the destination website. After switching routes, refresh this page. If the address changes, the current request is using a new exit point. If it stays the same, check that the client is connected and that browser traffic is covered by the active routing rules.
Location data comes from an IP address database and does not represent the device's actual location. It is mainly used to verify the region associated with the exit route. Database updates can lag, so city-level details may differ from the data center listing; when the country or region matches, it is generally the more reliable basis for a basic check.
The ISP field identifies the network organization associated with the exit address. Comparing it before and after connecting can help confirm whether requests are still leaving through the original network. Some databases show a carrier, data center, or autonomous system name; differences in naming do not directly indicate a connection problem.
Proxy detection depends on the data returned by the GeoIP API. “Not detected” only means the current database provided no proxy signal and is not a complete assessment of the connection method. “Not provided” means the API did not return this field; the page does not infer a result.
DNS CHECKLIST
This page's GeoIP lookup checks only the exit point of the web request and does not generate a list of DNS resolvers. A DNS check must also cover the client route, system resolver settings, and any separate DNS configuration within the application.
After connecting to the target route, refresh this page and first confirm that the public IP matches the selected region. If web traffic is still using the original exit point, resolve the connection or split-routing issue before checking DNS.
Check whether the operating system's current DNS configuration is managed by the client. If resolvers from another network interface remain active, disconnect unnecessary connections, reconnect the route, and check again.
Some browsers and applications allow a separate secure DNS setting. This may bypass the system resolver path. Compare the app settings with the current client mode to avoid having the system and application use different DNS channels.
After changing settings, disconnect the current connection, reconnect, and refresh this page. If the public IP details look right but DNS still behaves unexpectedly, switch routes or restart the client to rule out the effects of an old connection or cached state.