See the public address, location, ISP, and proxy indicators your browser presents when visiting websites. Run the lookup again after switching routes to confirm that your public IP changed with the connection.
Each result answers only one question. Compare the public IP, location, ISP, and selected route together to determine whether the current connection is behaving as expected.
Web services typically use your public IP to determine which network and region your connection comes from. After switching QEvpn routes, a corresponding change in the public IP and location indicates that browser traffic is using the new exit. Some websites cache location data; if content does not change immediately, reopen the page or clear that site’s session data.
Country and region data comes from a GeoIP database, not your device’s precise location. Different data sources may update at different times, so city or region names can occasionally be inaccurate. When troubleshooting a connection, first check whether the country and region broadly match the selected route.
The ISP field may show a carrier, data center, or network organization. It helps distinguish traffic still using the local network from traffic reaching websites through the selected route’s exit network, but the name itself says nothing about speed.
Some GeoIP data labels data centers, hosting networks, or known proxy exits as related network types. Websites may use their own detection rules, so the result here may not exactly match a target site’s assessment. If a service is unavailable, continue troubleshooting by checking the route region, split-routing rules, and the service’s own regional policies.
A public IP lookup can show where web requests leave the network, but it cannot directly list the DNS resolution path used by your device. Checking for DNS leaks requires reviewing the client’s DNS settings, split-routing rules, and connection logs together.
Open the current client’s network or DNS settings and confirm that domain resolution is handled by the tunnel or a remote resolver. If custom rules are in use, check that they are not still sending the target domain to the local network for resolution.
After visiting the site you want to check, review the client’s connection logs or request history. DNS requests for the target domain and the subsequent connection should use the expected route rather than accidentally matching a local direct-connection rule.
Run this lookup again and verify the exit region. If the exit has changed but the DNS service still clearly corresponds to the original network, check the system DNS cache, client split routing, and the browser’s secure DNS settings.