How this article was prepared
VPNScout reviews official documentation and public security guidance, then checks material claims during editorial updates. We do not describe a product as hands-on tested unless the article includes the test conditions and results.
The quickest way to check whether a VPN is working is to record your public IP while disconnected, connect the full VPN app, and compare the address again. A different public IP is a useful first signal, but it does not prove that DNS, IPv6, WebRTC, every app, or reconnect behavior is protected. Use the six tests below together and interpret each result narrowly.
Start with our free VPN IP Change Checker. It saves your first result only in the current browser tab and compares it with a fresh reading after you connect. Do not post your real IP, raw connection logs, account details, or screenshots containing diagnostic identifiers publicly.
A VPN can pass one check and fail another. For example, the browser may show a VPN exit address while an excluded application uses the ordinary connection through split tunneling.
A useful test changes one variable at a time:
Do not disable firewall, antivirus, IPv6, or operating-system security controls simply to make a test pass. First identify which signal is unexpected, then follow the provider's current documentation.
Your public IP is the address an internet service sees for the tested request. It is different from a local address such as 192.168.x.x, 10.x.x.x, or 172.16.x.x through 172.31.x.x. Those private ranges can remain the same when a VPN connects.
Use the VPN IP checker in this order:
| Result | What it suggests | What it does not prove |
|---|---|---|
| Public IP changed | This browser request used a different public exit address | DNS, IPv6, WebRTC, other apps, or provider logging are safe |
| Public IP stayed the same | This browser may not be using the expected tunnel | The VPN protects nothing on the device |
| IP changed but location looks familiar | The tunnel may work; location data can be stale or approximate | GPS, cookies, or account location changed |
If the exact ISP-provided public address remains visible, follow our guide to a VPN connected but IP address not changing. Common causes include split tunneling, a browser-only extension, cached results, competing network software, or failed routing.
A network can support IPv4, IPv6, or both. One generic IP checker may return only the protocol used for that request, so a changed IPv4 result does not automatically describe IPv6 behavior.
Record both address families before connecting, then repeat while connected. Depending on the VPN and network, the expected result may be a VPN-routed IPv6 address or no reachable IPv6 result. The important warning is an original ISP-provided public IPv6 address remaining reachable when the provider says it should be routed or blocked.
Do not permanently disable IPv6 as the first fix. That can conceal the symptom and affect other network services. Update the VPN, try its recommended protocol, test another server, and read the provider's current IPv6 guidance.
DNS translates domain names into network addresses. A VPN normally intends to send DNS requests through resolvers chosen or protected by the VPN configuration, but the exact design varies by provider, operating system, browser, and custom DNS setting.
Run a reputable DNS test before and after connecting. Look at the resolver operator rather than expecting the DNS address to match the VPN exit IP. Content-delivery networks and resolver infrastructure can produce several addresses or nearby organizations.
An ISP-branded resolver appearing during the VPN test can be a warning, especially when the provider says its own DNS should be used. It is not conclusive on its own: secure DNS configured in the browser, an employer profile, antivirus filtering, a router, or a custom resolver can legitimately change the result.
If results are unexpected:
WebRTC helps browsers establish real-time audio, video, and peer-to-peer connections. Its ICE process can expose candidate address information to a web application. Modern browsers apply privacy protections, but behavior depends on browser, operating system, extension, and connection policy.
A WebRTC page may show:
Seeing a private 192.168.x.x or 10.x.x.x address is not the same as revealing the public IP assigned by your ISP. The strongest warning is the original public address appearing as a candidate after the VPN connects.
Do not disable WebRTC permanently without understanding the effect on calls, meetings, and browser applications. Update the browser and VPN, test the provider's browser protection where supported, and compare another maintained browser.
Split tunneling intentionally lets selected apps or websites bypass the VPN. A result outside the tunnel may therefore reflect the chosen configuration rather than a leak.
Test at least:
A browser extension normally protects only supported traffic inside that browser. It does not establish that games, email clients, streaming apps, or system services use the same route. For conflicting results, read why a VPN works in a browser but not in apps.
A VPN can work while the tunnel is stable but briefly expose traffic when the connection changes. Test failure behavior only after saving work because internet access may stop as designed.
Do not deliberately interrupt a connection during payments, work sessions, downloads, or other sensitive activity. A working kill switch can make the internet appear broken until the VPN reconnects. If the VPN repeatedly drops, use our Android disconnect guide or Wi-Fi versus mobile-data fixes.
A changed IP does not change GPS, browser location permission, nearby Wi-Fi information, a signed-in account, cookies, payment region, or saved preferences. IP geolocation databases can also be delayed or map a server to a nearby city.
If the VPN IP changed but Google still displays your usual area, follow why Google still shows your location with a VPN. Determine whether the location came from the internet address, device permission, or account history before changing unrelated settings.
For NordVPN, use the full official app and check its connected status first. NordVPN's support guidance recommends confirming the app and device connection indicators and running a DNS leak test. Then use this independent sequence:
NordVPN is our current top overall recommendation because it combines accessible apps, NordLynx, Auto-connect, and kill-switch controls across supported platforms. Features and behavior vary by operating system, plan, and app version, so use the current support documentation for your device.
A successful home test cannot prove:
Testing is evidence about the observed connection, not a complete security audit. A VPN also shifts part of the trust from the internet provider to the VPN operator. Review ownership, privacy terms, audit scope, app maintenance, and support history separately.
Compare your exact public IP before and after connecting, then check IPv6, DNS, WebRTC, split-tunneled apps, and reconnect behavior. A changed IP is the first test, not the final proof.
No. It shows that the tested request used a different public exit address. Other protocols, apps, or DNS settings may behave differently.
The browser may be excluded by split tunneling, you may be using only an extension, the result may be stale, another proxy may control the route, or the tunnel may have connected without routing traffic correctly.
Usually not. That is normally a private address used inside the local network. Check the public address visible to an internet service instead.
Yes. IP routing and DNS resolution are related but separate. Check both and interpret the resolver operator in the context of custom DNS, browser settings, and provider documentation.
A second reputable result can help identify a cached or service-specific error. Avoid entering personal information, downloading unknown software, or granting unnecessary browser permissions to a test page.
Begin with a controlled before-and-after public IP comparison, then test IPv6, DNS, WebRTC, app routing, and failure recovery. Treat each result as one piece of evidence. If the public address stays unchanged, diagnose routing and split tunneling; if only DNS or WebRTC looks unexpected, investigate that specific layer instead of weakening unrelated security controls.
