VPN & Online Security

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 setupExpected first resultIf it does not happen
Personal full-tunnel VPNLoqmi shows a different public IP and ISP.Check connection status, exclusions, and the selected server.
Corporate or work VPNWork resources load; your public IP may stay the same.Ask whether the profile is split-tunnel before changing it.
Browser extension or proxyOnly that browser or configured app changes its route.Do not assume other apps are covered.
VPN on a routerClients using that router normally see the VPN exit.Check for a device-level VPN, proxy, or bypass rule.

Record a baseline, then recheck

  1. Disconnect the VPN completely. If another VPN, proxy, or privacy relay is active, turn it off for this comparison.
  2. Open Loqmi's IP checker and record the public IP, ISP, and approximate location. The city is only a database estimate.
  3. Connect to the VPN, wait for the app to report a stable connection, and reload the same Loqmi page in the same browser.
  4. 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.
Do not “fix” a leak by weakening protection first. Keep encryption and firewall controls enabled. Review the provider's leak-protection settings, browser DNS settings, split-tunnel rules, and support guidance before changing system networking.

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.

Fast self-test: If Loqmi changes your IP but speed falls, test the leak paths before changing security settings.

Troubleshoot by symptom

SymptomLikely causeSafest next action
IP and ISP stay the sameDisconnected tunnel, excluded app, or intentional split tunnelingReconnect and test the same browser; review exclusions and VPN scope.
IP changes but DNS shows the home ISPResolver bypass or browser-level DNS overrideEnable provider DNS protection and follow its documented DNS settings.
Only WebRTC shows the old public IPBrowser path or extension behaviorTest another browser, remove unknown extensions, and ask the provider about WebRTC handling.
IPv4 changes but native IPv6 appearsIPv6 is not tunneled or blockedUse the provider's IPv6 setting or support instructions; do not guess at MTU or firewall rules.
The city looks wrongApproximate IP geolocationJudge the IP and ISP first; IP location can be inaccurate.
Traffic returns during a dropKill switch disabled, permissive, or not covering that appEnable 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

Related articles