How to Check If Your VPN Is Working With an IP Lookup

A VPN opens an encrypted tunnel from your device to one of the provider's servers and sends your traffic through it. When it works, every website sees the exit server's public address, ISP and location instead of yours, your DNS lookups travel inside the tunnel, and both your IPv4 and your IPv6 traffic are covered. Each of those is a separate promise that can fail on its own, which is why checking a VPN is a sequence of small tests rather than one glance at a map.

Before connecting to a VPN, check your public IP and note the country, city, and ISP. Note the IPv6 address as well if your connection has one; the guide to checking your own IP address covers the command-line ways to see both. This is the baseline everything else is compared against.

Connect the VPN and run the lookup again. A working VPN should usually show the VPN provider or exit network instead of your normal home, office, or mobile ISP. The address must differ from the baseline, and the ISP or organization should be the VPN provider or a hosting company.

If your normal ISP still appears, the tunnel is not carrying this traffic. The usual causes are a browser extension that proxies only that browser, split tunneling that excludes the app you tested with, or a connection that reported success but never came up.

The country should be the one you selected. Country is the level at which geolocation is reliable, so a mismatch here is meaningful: either you connected to a different server than you intended, or the provider's address for that server is registered elsewhere.

VPN city labels and IP geolocation databases can disagree. A server marketed as one city may appear in a nearby metro or at a hosting provider location.

There are three ordinary reasons. Databases map an exit address to the network that registered it or the facility that hosts it, which may be a different city from the server's label. Providers move and announce address space faster than databases update, so a recently added server can carry a stale location for weeks. And some servers are 'virtual locations': the machine sits in one country while its addresses are registered and geolocated to another, a practice providers use for countries where they will not run hardware.

If location matters to you, test several servers from the same provider and pick the one the databases agree on. But the test of a working VPN is not the city. Focus on whether your original public IP and ISP are hidden, not whether every database agrees on the exact city. The accuracy guide and the guide to wrong lookup locations explain how far city results can be trusted for any address.

Many connections are dual-stack, carrying an IPv4 and an IPv6 address at the same time. A VPN that tunnels only IPv4 leaves the IPv6 path untouched, so a website that supports IPv6 connects to you over it and sees your real address while an IPv4-only site sees the VPN. Check the IPv6 lookup with the VPN connected: it should show the provider's IPv6 address or none at all. Your own IPv6 address from the baseline is a leak.

The fix is a client that tunnels IPv6 or blocks it while connected; failing that, disable IPv6 on the device. The IPv4 versus IPv6 guide explains why the IPv6 address identifies your device more precisely than a shared IPv4 address does.

An IP leak happens when a website sees your real public IP instead of the VPN, proxy, or protected network address you expected. If your real IP appears, websites can often estimate your country, region, ISP, and connection type. That is what steps 3 and 6 test.

A DNS leak is different. Before your browser connects to a site, it asks a DNS resolver for the site's address, and the resolver learns which sites you visit. A DNS leak happens when those lookups go outside the tunnel, typically to your ISP's resolver, while the web traffic itself goes through the VPN: the website sees the VPN address and looks protected, while another network path still sees your browsing intent. RFC 9076 describes this exposure in general terms: the resolver, and anyone able to observe the path to it, can see the names you resolve.

Test them separately. A DNS leak test reports which resolver networks answered your queries; with the VPN connected, they should belong to the VPN provider, not your ISP. Encrypted DNS over TLS (RFC 7858) or HTTPS (RFC 8484) hides your queries from the ISP and the local network, but it does not hide your public IP from websites, and a VPN does not protect DNS unless the client routes it through the tunnel. The two protections answer different questions.

Browsers use WebRTC for calls and peer-to-peer connections, and to set those up they gather the addresses your device can be reached at. Older implementations exposed local and public addresses to any page that asked, which let a website learn your real address while a VPN was active. RFC 8828 sets out the requirements browsers now follow to limit that exposure, and current browsers by default reveal only the address of the route your traffic actually uses and hide local addresses behind generated names. A browser WebRTC leak test shows what yours gives up; if it still exposes your real address, use the VPN client's browser protection or the browser setting that disables WebRTC.

A kill switch blocks all traffic when the tunnel drops, so that your device does not silently fall back to the bare connection. Test it deliberately: with the VPN connected, switch Wi-Fi off and on or end the VPN process, then run the lookup immediately. The right result is no connection at all until the tunnel is back; the wrong result is your real address appearing for the seconds before the client reconnects. Test the wake-from-sleep case too, since that is when tunnels most often come back later than the network does.

The VPN is working when all of the following hold: the public IP differs from the baseline; the ISP is the VPN provider or a hosting network, not your own ISP; the country is the one you chose; the IPv6 lookup shows the provider's address or nothing; the DNS test shows only the provider's resolvers; WebRTC does not expose the baseline address; and traffic stops when the tunnel drops.

A wrong city on its own is not a failure. Your real address showing on any of the checks is. Hiding your address is also not the same as hiding that you use a VPN: websites can recognize exit addresses from known ranges, hosting ASNs and reputation data. The VPN and proxy checker shows what a site sees when it looks at your exit, and the VPN detection checklist describes those signals from the site's side.