How to Check If VPN Is Working
If you want to know how to check if vpn is working, record your public IP with Loqmi while disconnected, connect the VPN, and reload the page. A changed IP, ISP, and approximate location show that this browser is reaching the internet through a different exit; then check DNS, IPv6, WebRTC, and the kill switch because a “Connected” label alone does not prove every route or app is protected.
How to check if VPN is working
A personal privacy VPN should normally change the public address websites see. A company VPN may be deliberately split-tunnel: work systems use the tunnel while ordinary web traffic still uses your ISP. Define the expected result before treating an unchanged IP as a failure.
| VPN setup | Expected first result | If it does not happen |
|---|---|---|
| Personal full-tunnel VPN | Loqmi shows a different public IP and ISP. | Check connection status, exclusions, and the selected server. |
| Corporate or work VPN | Work resources load; your public IP may stay the same. | Ask whether the profile is split-tunnel before changing it. |
| Browser extension or proxy | Only that browser or configured app changes its route. | Do not assume other apps are covered. |
| VPN on a router | Clients using that router normally see the VPN exit. | Check for a device-level VPN, proxy, or bypass rule. |
Record a baseline, then recheck
- Disconnect the VPN completely. If another VPN, proxy, or privacy relay is active, turn it off for this comparison.
- Open Loqmi's IP checker and record the public IP, ISP, and approximate location. The city is only a database estimate.
- Connect to the VPN, wait for the app to report a stable connection, and reload the same Loqmi page in the same browser.
- Compare the full address, not just the country. A new IP and different network operator are strong evidence that this browser is using the VPN exit.
If the old IP remains, check split-tunnel exclusions and confirm that the intended profile is connected; saving a profile does not start its tunnel. A changed IP still proves only what this browser can reach, not what every app is doing.
Check DNS, IPv6, and WebRTC leaks
Loqmi verifies the public address seen by a web page, not every DNS query, IPv6 route, or browser peer-connection path. Use separate checks for those layers. Proton VPN's DNS leak guidance explains why a resolver can reveal the network handling lookups even when the visible IP changed.
- DNS: Run a reputable DNS leak test with the VPN on and compare it with the disconnected baseline. The result should not identify your home ISP's resolvers. A VPN provider's resolver or an explicitly documented third-party resolver can be normal; do not assume that every non-ISP resolver is a leak.
- IPv6: Use an IPv6-aware leak test. Your native ISP IPv6 address should be carried inside the VPN or blocked according to the provider's documented design. Do not copy an IPv6-disable command from a random guide; disabling IPv6 is not the same as tunneling it. See how IPv6 works on a router if the distinction is new.
- WebRTC: Run a WebRTC test in each browser you actually use. A private local-network address is not automatically a public IP leak, but your old ISP-facing public IP appearing while the VPN is on deserves investigation. ExpressVPN's leak-testing documentation describes IP, DNS, WebRTC, and network-transition testing.
Test the kill switch and split tunneling
A kill switch is a failure rule, not a connection badge. Enable it, save any work, and use a harmless page. With the VPN connected, briefly interrupt the underlying network or follow the provider's reconnect test. A strict kill switch should block new traffic until the tunnel returns. If browsing continues and Loqmi shows your old IP, review the setting.
Clicking Disconnect is not always a valid kill-switch test: some clients allow traffic after a user-initiated disconnect. Also inspect split tunneling. An excluded browser, app, or DNS service may bypass the VPN by design, so test the traffic you want covered. AMTSO's VPN testing guidance includes network changes, DNS, WebRTC, and IPv6 leak cases.
Check the VPN on Windows, macOS, Linux, Android, and iOS
Use the VPN app's controls when it installed the tunnel. Built-in profiles use the operating-system paths below; manufacturers and managed devices can vary.
Windows 11
Open Start > Settings > Network & internet > VPN, select the profile, and choose Connect or Disconnect. Microsoft also documents a VPN shield on the taskbar for a recognized connection. A provider app may show different controls, so use that app when it owns the profile. See Microsoft's current Windows instructions.
macOS
For a manual profile, use Apple menu > System Settings > Network > Action menu > Add VPN Configuration, then connect from the VPN status menu in the menu bar. If a provider app created the connection, connect there instead. Apple documents this path in its Mac VPN guide.
Linux and Ubuntu
In Ubuntu GNOME, open Activities > Network, select the + beside VPN, choose the connection type, and press Add. Connect from the top-bar system menu; Ubuntu shows a lock icon when connected. Other distributions, desktop environments, and vendor clients use different paths. See Ubuntu's VPN help.
Android
Open Settings > Network & internet > VPN, choose the profile, and connect. Android shows a VPN indicator when connected; if the menu is missing, search Settings for “VPN.” With an app-based VPN, the system page opens the app. Google notes that device makers can provide different menus in Android Help.
iOS
Connect and disconnect in the VPN provider's iPhone app. To inspect a managed or installed profile, open Settings > General > VPN & Device Management; do not remove a work or school profile just to test. iOS layouts and provider apps differ, so search Settings for “VPN” if needed. Apple's profile guidance explains the system path.
Use speed as a supporting check
A VPN can add route distance, encryption work, or congestion, increasing latency or reducing throughput without being broken. Run Loqmi's speed test with the VPN off and on, using the same device, browser, and network. Compare download, upload, and latency; see this VPN speed guide when speed is the symptom.
Troubleshoot by symptom
| Symptom | Likely cause | Safest next action |
|---|---|---|
| IP and ISP stay the same | Disconnected tunnel, excluded app, or intentional split tunneling | Reconnect and test the same browser; review exclusions and VPN scope. |
| IP changes but DNS shows the home ISP | Resolver bypass or browser-level DNS override | Enable provider DNS protection and follow its documented DNS settings. |
| Only WebRTC shows the old public IP | Browser path or extension behavior | Test another browser, remove unknown extensions, and ask the provider about WebRTC handling. |
| IPv4 changes but native IPv6 appears | IPv6 is not tunneled or blocked | Use the provider's IPv6 setting or support instructions; do not guess at MTU or firewall rules. |
| The city looks wrong | Approximate IP geolocation | Judge the IP and ISP first; IP location can be inaccurate. |
| Traffic returns during a drop | Kill switch disabled, permissive, or not covering that app | Enable the strictest documented mode and repeat the harmless reconnect test. |
Know what the check proves
A good result shows that one request used the VPN exit and the tested leak paths did not expose your baseline. It does not make you anonymous, erase cookies, change GPS or permissions, or prove every app uses the tunnel. Read how IP hiding works and what it cannot hide for the wider privacy picture.
Key takeaways
- Compare Loqmi before and after connecting, but treat an IP change as the first check, not the whole audit.
- Test DNS, IPv6, and WebRTC separately, and interpret private local addresses differently from an exposed public ISP address.
- Check split tunneling before calling an unchanged IP a leak; test the app and browser that matter to you.
- Use a safe network interruption to test a kill switch, and keep security controls enabled while troubleshooting.
- Use speed and city-level location only as supporting signals, not as proof that the tunnel protects every route.
Frequently asked questions
Can a VPN be working if my IP location is wrong?
Yes. IP geolocation databases often place a VPN exit in a nearby data center or a different city from the server name. Treat the city as approximate. The more useful checks are whether the public IP and ISP changed, whether DNS and IPv6 use the intended path, and whether the VPN app reports a stable connection.
Why does my IP stay the same when my VPN says connected?
The connection may be split-tunnel, the browser or app may be excluded, or the VPN may have connected only to a private work network. Check the VPN's routing and exclusion settings, then repeat the test in the same browser with the VPN fully connected. A corporate VPN may intentionally leave ordinary web traffic direct.
Should I disable IPv6 to test a VPN?
Do not disable IPv6 as your first move. A VPN should either carry IPv6 inside its tunnel or block it when the provider does not support it. Ask the provider for its documented IPv6 behavior; disabling IPv6 can disrupt other services and does not prove that the tunnel supports IPv6.
How often should I check my VPN?
Run a full check after installing the VPN, changing providers or protocols, updating the operating system, or changing networks. Repeat the IP and DNS checks when something looks unusual. Test the kill switch after enabling it and whenever the VPN app changes its network-protection settings.
Sources
- AMTSO VPN Testing Guidance Part 1
- Proton VPN: DNS leaks when using a VPN
- ExpressVPN: Leak Testing Tools
- Microsoft Support: Connect to a VPN in Windows
- Apple Support: Set up a VPN connection on Mac
- Android Help: Connect to a virtual private network (VPN) on Android
- Ubuntu Help: Connect to a VPN
- Apple Support: Install or remove configuration profiles on iPhone