How to Check If Your VPN Is Actually Working

Load an IP-check page with the VPN off and note the address and location it reports. Connect the VPN, then reload the same page. If the address is different and the location now matches the server you chose, your traffic is going through the tunnel. That is the whole basic test, it takes under a minute, and it settles most worries about whether a VPN is on.

What that check actually proves

It proves one specific thing: the connection your browser made to that page left through the VPN server, and the page saw the server’s address instead of yours. That is the core job, and confirming it is worth the minute.

It does not prove much beyond that. It says nothing about the other apps on your Mac, some of which can be configured to bypass the tunnel. It says nothing about what happens when the connection drops. And it says nothing about the name lookups that precede every connection, which travel by a different route and can leak while the address check looks perfect.

One caveat on the location itself. The city an IP-check page reports comes from a geolocation database, and those are frequently wrong or out of date for VPN server addresses. Seeing the wrong city is not a failure. The signal you care about is that the address is not yours.

DNS, the leak that hides behind a working tunnel

DNS is the lookup that turns a name like example.com into the numeric address your Mac actually connects to, and every connection starts with one. A VPN is meant to carry those lookups inside the tunnel and answer them with its own resolvers. The catch is that DNS is handled by a different part of your system configuration than the tunnel, so the two can disagree: your traffic rides the VPN while your lookups still go straight to your internet provider. The site you visit sees the VPN’s address, and your provider still ends up with a tidy list of every domain you asked for.

To check, use a DNS leak test site. It triggers a set of lookups and reports which resolvers answered them. If the resolvers listed belong to your internet provider, the names usually make that obvious, and you have a leak worth fixing in your VPN app’s settings. If they belong to the VPN, that part is working. Worth retesting after you switch servers or wake the Mac from sleep, because those are the moments the setting tends to slip.

WebRTC and the browser’s own idea of your address

Browsers include a real-time communication feature, WebRTC, that powers video calls and other direct connections between two people. To find the shortest path between the participants, it asks the operating system which addresses the device has, and it can pass those to the page. On some setups that includes your real public address, even with the tunnel up. Nothing is broken when this happens; a browser feature is doing exactly what it was designed to do, in a way that happens to route around your VPN.

The same test pages that report your IP usually report a WebRTC address on a separate line. If the main line shows the VPN server while the WebRTC line shows your real address, that is the leak. Check it in each browser you actually use, since the behavior is per-browser rather than system-wide.

The reassuring part is that this gap has narrowed. Current browsers mask local addresses by default, and VPN apps built for desktop generally block the exposure themselves. A quick look is still the only way to know which side of that your setup falls on.

The kill-switch test

A kill switch blocks your traffic whenever the tunnel goes down, so that a brief drop does not quietly push your activity onto your normal connection. Untested, it is a claim on a settings screen. Tested, it is a feature.

Start a large download, then force the tunnel to drop while it runs: quit the VPN app, flip its toggle off, or turn Wi-Fi off for a few seconds and back on. Then watch the transfer. With a working kill switch the download stalls or fails within a moment, and everything else stops loading too, which is the behavior you want even though it looks like a broken internet connection. If the download keeps moving at full speed while the VPN is disconnected, there is no protection during that window and your traffic is going out in the open. Run this with a file you do not mind losing, and note how long the app takes to reconnect afterward, because that gap is the part you live with.

A slower connection is not a broken VPN

Some speed loss is built into the design. Your traffic gets encrypted and takes a detour through another server, and both of those cost time, so a lower number on a speed test is the expected outcome rather than a symptom. If the drop is large and repeatable, that is a tuning problem with its own causes, covered in why your VPN is slow, not a reason to doubt the tunnel.

Two other things people misread as failures are actually confirmations. Sites that suddenly show you extra verification steps, and services that refuse to load, are recognizing the VPN server’s address, which means the address change worked. So does a site that starts showing you content for another country.

What none of these tests can tell you

Every check here confirms the plumbing: traffic leaves through the server, lookups stay inside the tunnel, the browser is not talking around it, the connection fails closed. None of them tell you what the VPN provider does with the traffic it now carries, and no test on your Mac can. That part rests on who runs the service and what they keep, which is the trade a VPN makes rather than a bug in it. The honest boundaries of the whole tool are worth reading about separately in what a VPN actually hides.

Run the IP check whenever you want reassurance, and the DNS, WebRTC, and kill-switch checks once on a new setup or after changing anything. Four verifications, one afternoon, and you stop guessing.