A "connected" status only means a session was established with the VPN server, not that every byte of traffic is actually flowing through the encrypted tunnel. Depending on your operating system, DNS settings, or split tunneling rules, part of your traffic can bypass the VPN without any visible warning, and the only way to catch that is to run a few specific tests. Below we cover how encryption and the kill switch work in LiMP VPN, and exactly which checks reveal the real state of your connection.
This guide walks through a step-by-step VPN check: a 1-minute quick test, a detailed leak diagnosis for IP, DNS, WebRTC and IPv6, how to confirm encryption is actually happening, why a VPN can say "connected" and change nothing, and a speed test. At the end there's a checklist for what to do if a test turns up a problem.
Quick 1-Minute Check: Is Your VPN Actually Connected?
The fastest way to check a VPN is to compare two numbers: your IP address without the VPN and your IP address with it turned on. If they differ and the second address points to a server location rather than your own city, the basic protection is active.
- Look at the status in the appA "connected" badge and a running session timer are a first signal, not proof: the app is only reporting that a tunnel was established, not that all traffic is using it.
- Check your IP without the VPNand note the address and city, for example with the LiMP IP checker.
- Turn the VPN on and wait 10-15 secondsfor the connection to fully settle, then reload the same IP check page.
- Compare the resultThe address should switch to the VPN server's IP, and the location should switch to the server's country or city, not stay the same as before.
If the address does not change at all, the VPN is not actually connected, regardless of what the app shows. If it does change and you want to rule out hidden leaks, move on to the detailed tests below. The fastest way is the built-in "Is My VPN Working" tool, which checks IP, WebRTC and IPv6 on a single page.
Checking Your IP Address and Location
An IP check shows the address that websites see while you're connected through the VPN, and it must differ from your real ISP address. Three details are worth checking:
- Address type. You should see the VPN server's IP, which belongs to a hosting or data center provider, not your home ISP's address range.
- Country and city. The IP-based location should match the server location you picked in the app. A mismatched country usually means geolocation guessed wrong or the connection routed somewhere unexpected.
- Consistency across checks. Re-running the test a few minutes later should show the same or a different VPN server IP, but never your real address, even briefly.
One detail that's easy to miss: IPv4 and IPv6 show different addresses if both protocols are active on your device. An IP check that only looks at IPv4 can show a clean result while your IPv6 address is still leaking outside the tunnel (more on that below).
Testing for DNS Leaks
A DNS leak happens when the requests that translate domain names into addresses go straight to your ISP's DNS servers instead of through the VPN tunnel; in that case your provider can see which sites you visit even with the VPN on. To check this, run a dedicated test that lists the DNS resolvers actually handling your queries: the built-in DNS leak test does exactly that, showing the address, provider and country of every resolver.
How to read the result:
- Every resolver belongs to the VPN provider (or a configured DNS server inside the tunnel): no leak, DNS requests are going through the encrypted channel.
- At least one resolver belongs to your ISP: that's a leak. Part of your DNS traffic is bypassing the VPN, and your provider can reconstruct your browsing history from its query logs.
- Resolvers show different countries while only one VPN server is active: this usually means the device is querying several DNS servers in parallel, and some of those queries aren't protected.
A common cause is a cached DNS setting in the browser or operating system that didn't refresh after the VPN connected. The fix is simple: restart the browser once the VPN is on, and if the leak persists, check the DNS settings inside the VPN app itself: modern clients normally force all DNS traffic through the tunnel.
Testing for WebRTC Leaks
WebRTC is a browser technology for direct audio and video transfer between devices (video calls, live streaming), and it can expose your real IP address around the VPN because it sets up a direct connection instead of going through the system-level tunnel. This is one of the most common reasons someone feels protected while a site still sees their real address.
To check for a WebRTC leak, open a test page in the same browser where the VPN is active and look at which IP addresses it discovers. If your real ISP address shows up next to the VPN server's address, that's a WebRTC leak. The "Is My VPN Working" tool checks this alongside IP and IPv6 in one report; the browser privacy test separately shows how your browser fingerprint, including WebRTC handling, looks to a tracker.
Typical causes of a WebRTC leak and how to fix each one:
| Cause | What happens | Fix |
|---|---|---|
| The VPN doesn't intercept WebRTC traffic | The browser opens a peer-to-peer connection directly, skipping the tunnel | Turn on WebRTC leak protection in the VPN app's settings, if available |
| A browser extension conflicts with the VPN | An old VPN extension or ad blocker interferes with the system-level tunnel | Disable extra extensions and rely on the native VPN client instead of a browser extension |
| The browser is set to expose local IPs | Your public IP is hidden, but local device addresses are still visible | Check the browser's WebRTC settings or use a privacy-focused browser mode |
Testing for IPv6 Leaks (the One Most People Skip)
An IPv6 leak is the most underrated problem here, because many VPN clients only encrypt IPv4 traffic while the device's IPv6 address keeps traveling the network directly, if your ISP has it enabled. A site that supports IPv6 will then see your real address even while the IPv4 check looks perfectly clean.
Checking for this is easy: the "Is My VPN Working" test separately reports whether an IPv6 address is visible and whether it matches the VPN server. If the tool finds an active IPv6 address that doesn't belong to the VPN, that's a leak, and there are two ways to close it:
- Turn on IPv6 leak protection in the VPN app, if the option exists. Most modern clients simply block IPv6 traffic entirely when they can't route it through the tunnel.
- Disable IPv6 at the operating system or router level if the VPN app doesn't explicitly support it. The device will then rely only on IPv4, and the leak disappears technically.
Worth re-running this test not just at setup, but after major operating system updates: updates occasionally reset network settings and re-enable IPv6 without any visible notice.
How to Confirm Your Traffic Is Actually Encrypted
Changing your visible IP address isn't proof of encryption by itself: a proxy server does the same thing while traffic can still travel in plain text. Confirming encryption specifically requires other signals, not just the result of an IP check.
- The protocol shown in the app. Modern VPN clients display which protocol is active (WireGuard or OpenVPN). An app that honestly shows the active encryption protocol, rather than just "connected", is the first indirect sign.
- Behavior on open Wi-Fi. The most practical reference point is the Wi-Fi security check: with a properly configured VPN active, it shouldn't detect signs of HTTPS interception or DNS tampering on the network.
- No mixed-content warnings. If the browser or VPN client reports unencrypted connections while the VPN is active, that's a sign part of your traffic isn't going through the tunnel.
In practice, a modern protocol shown in the app (WireGuard or OpenVPN) together with IP/DNS/WebRTC/IPv6 checks all matching the expected server is enough confirmation for a typical user that traffic is genuinely encrypted, not just routed through a swapped address.
VPN Says "Connected" But Nothing Changed: Why
Most of the time the cause is that part of the traffic is routed around the tunnel on purpose, not that the VPN has failed outright. Here are three common scenarios.
- Split tunneling is excluding the app you're testing. If the VPN settings have certain apps or domains added as exceptions (split tunneling), their traffic is intentionally bypassing the tunnel: that's expected behavior, not a bug. Check the exceptions list if the IP won't change specifically inside one browser or app.
- An old network connection never reset. Apps that had already opened a connection before the VPN turned on sometimes keep using the old route until that connection is reopened. The fix is to restart the browser or app after connecting.
- The kill switch is off and the connection briefly dropped. A kill switch blocks internet access on the device whenever the connection to the VPN server drops, so traffic doesn't leak out in the open while the app reconnects. If it's off, a few seconds or minutes of traffic during a reconnect may have gone unprotected. Check that this option is enabled.
If the same issue keeps repeating on one particular network rather than as a one-off, it's worth digging into the network-specific causes. See what to do if a VPN isn't working on Wi-Fi.
Speed Test With a VPN: What's Normal
Slower speeds with a VPN turned on are expected, not a sign of a problem: encryption and the extra hop through a server inevitably add overhead. A 10-30% drop compared to your connection without a VPN is normal, assuming you picked a nearby server and a modern protocol like WireGuard.
How to run the test correctly:
- Measure speed without the VPN using a tool like the internet speed test and note download, upload and ping.
- Turn the VPN on, connect to a server, and repeat the same test under the same conditions, ideally the same device and network, with no other downloads running.
- Compare the results: a 10-30% drop is expected. A drop over 50%, or ping jumping several times higher, is a sign to check the server choice and protocol.
If speed drops more than that, first try a geographically closer server and the WireGuard protocol instead of OpenVPN: the difference between the two can be noticeable. If that doesn't help, the cause may not be the VPN at all but ISP throttling or a congested network, which is worth checking separately without the VPN at different times of day.
What to Do If Your VPN Check Shows a Problem
If one of the tests above found a leak or the VPN isn't behaving as expected, work through this order:
- Reconnect to the VPN serverThe single most common and simplest cause of a leak is a dropped session that didn't fully recover. Disconnect, wait a few seconds, and reconnect.
- Re-run the test after reconnectingIf the leak is gone, it was temporary. If it's still there, move to the next step.
- Turn on leak protection in the app's settingsOptions against DNS, WebRTC and IPv6 leaks are usually in the connection or security section of the VPN client. Enable everything available.
- Check and enable the kill switchso future connection drops don't leave traffic unprotected.
- Restart the browser and any appsthat were using the network before the VPN connected, so they reopen their connections over the new route.
- Update the VPN app to the latest versionDNS and WebRTC leaks are often fixed in client updates rather than operating system settings.
- Run the full set of tests againCheck IP, DNS, WebRTC and IPv6 once more with "Is My VPN Working" to confirm the problem is resolved on all four fronts, not just the one you first noticed.
If a leak keeps coming back after every one of these steps, that's a sign to look at the service itself: an outdated protocol, an overloaded server, or missing leak-protection settings in general. For how encryption connects to what your provider can actually see, see how a VPN protects you from ISP tracking.
How Often You Should Re-Check Your VPN
Checking a VPN isn't a one-time setup step. A few specific situations carry a meaningfully higher leak risk and deserve a quick re-check:
- After an operating system update. Major Windows, Android or macOS updates occasionally reset network settings, including IPv6 and routing behavior. A short re-check after installing an update closes this risk.
- After updating the VPN app itself. A new client version can change the default protocol or leak-protection settings; it's worth confirming once that behavior hasn't changed.
- When joining a new Wi-Fi network. Different networks handle DNS and routing differently; a new hotel, airport or office access point is a good reason for a quick one-minute check.
- While traveling, especially to another country. Switching countries changes the available servers and can trigger unfamiliar DNS behavior from the local provider; checking right after connecting on-site is worth the minute.
A full check across all these points takes a couple of minutes, and a quick IP check takes seconds, so making it a habit in the situations above costs almost nothing but meaningfully lowers the risk that your protection only exists on the app's screen and not in the actual traffic.
Bottom Line
Checking a VPN isn't a single number: it's a short sequence of tests, connection status, an IP comparison before and after, a check for DNS, WebRTC and IPv6 leaks, and a speed test if needed. A "connected" status on its own guarantees nothing, while the full set takes a couple of minutes and gives a clear answer about whether your traffic is actually protected. If you're looking for a VPN with clear leak-protection settings and a built-in kill switch, see LiMP VPN pricing.
