See where this browser request is coming from. After switching routes, run the check again to compare your public IP and location. To confirm streaming library access, check directly on the streaming platform.
The check hasn’t finished. Results reflect only the connection used for this browser request.
This tool looks up your public connection details. It doesn’t run an automatic DNS leak test or check traffic from every app.
Check your public connection first, then assess the route. IP geolocation, proxy status, and streaming library availability are separate things.
This is the source address seen by our API, not your device’s address on the local network. After connecting to VPNHill, note the result, switch to your intended route, and run the check again. If the address hasn’t changed, confirm the client is connected and that your routing rules send requests to this site through that route.
The location comes from the IP database used by our API; it may not match your device’s actual location. Database updates can lag, and platforms may use different databases. A result showing your intended region doesn’t confirm that Netflix or Disney+ has made its regional library available.
This shows the network provider or organization returned by our API. It may be an access provider or a hosting network. The provider name alone can’t confirm whether an address is residential, a residential broadband IP, or a particular route type. Check route labels and real-world access as well.
Proxy status reflects only the result explicitly returned by our API. No proxy detected doesn’t mean every platform will reach the same conclusion, and a proxy detected result doesn’t mean a service will necessarily be unavailable. If the API doesn’t return this field, this page says “Temporarily unavailable” rather than guessing based on your location.
Your public IP shows where a request exits the network; DNS resolution shows which service looks up a domain name. Checking your IP alone can’t confirm that DNS requests follow the expected route.
When you can easily switch networks, note your current connection details and check which DNS servers are configured in your system settings. If Secure DNS is enabled in your browser, note that too. Configured addresses show what’s intended, but don’t prove where DNS requests actually go.
Connect to your intended route, then check the client’s DNS handling, routing mode, and related rules using its documentation. Switching routes alone may leave DNS requests taking an unexpected path. If you’re unsure what an option does, keep the recommended settings and follow Quick Start to review the connection steps.
Your browser’s Secure DNS settings may differ from your system settings. If both the client and browser manage DNS, the result may differ from what you expect. Check that settings are consistent. Encrypted DNS protects DNS traffic in transit, but doesn’t guarantee that requests use your selected route.
If you use a tool that checks DNS, read its privacy policy first, then compare the DNS providers it detects with your client logs and settings. A DNS provider’s location differing from your exit location doesn’t necessarily indicate a leak. What matters is whether requests use the expected route and reach the intended DNS provider.
This page doesn’t send extra DNS test requests or mark DNS as “passed” just because your public IP has changed. Without evidence of the DNS resolution path, the result should remain unconfirmed.
The check requests connection details from our API only and doesn’t fall back to public third-party lookup services. This page doesn’t save query history. The copy button copies only the IP retrieved for the current check and doesn’t write to your clipboard automatically.
Before sharing a screenshot, consider hiding your full IP address. It may reveal your current network exit. When troubleshooting in a public setting, share only what’s necessary.