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.
If your VPN says connected but your public IP address does not change, first make sure you are checking the public internet address from an app or browser that is actually routed through the VPN. The most common causes are comparing a local Wi-Fi address instead of a public IP, split tunneling excluding the browser, using a browser extension while testing another app, a cached result, an IPv6 or WebRTC exposure, or a VPN tunnel that connected without routing traffic correctly.
A working full-device VPN normally makes websites see the VPN server's public address instead of the public address assigned by your internet provider. If the VPN stays connected but pages will not load, use our VPN connected but no internet guide. Follow the checks below in order. Do not publish screenshots containing your real public IP, account details, or diagnostic identifiers.
Phones and computers commonly have several IP addresses at the same time. Only the public internet address should change when ordinary traffic is routed through a commercial VPN.
| Address or signal | Should it change when the VPN connects? |
|---|---|
| Public IPv4 shown by a website | Normally yes |
| Public IPv6 shown by a website | Normally yes or be unavailable, depending on the provider's IPv6 handling |
| Local Wi-Fi address such as 192.168.x.x | Usually no |
| Router gateway address | No |
| Bluetooth or local-device address | No |
| GPS location reported by the phone | No |
| Account country stored by a website | No |
| DNS resolver | It should normally use the VPN's intended resolver, but this is separate from the visible public IP |
A local address identifies your device only inside the current home, office, or hotspot network. It is not the address websites see. Do not use the Wi-Fi details page in Android, iPhone, Windows, or macOS as the main VPN test.
Use this controlled sequence:
If the exact public IPv4 still belongs to your normal internet provider, the browser traffic probably did not enter the tunnel. If the address changed but the city did not, the VPN may still be working: IP-location databases can be imprecise, delayed, or map a server to a nearby location.
Addresses beginning with common private ranges such as 192.168.x.x, 10.x.x.x, or 172.16.x.x through 172.31.x.x are normally used inside local networks. A VPN does not need to replace that address. It creates a virtual network route and changes the public exit address seen by internet services.
Split tunneling lets selected applications bypass the VPN. If Chrome, Firefox, Edge, Safari, or the IP-checking application is excluded, it will continue showing the internet provider's address even while other apps use the tunnel.
This can also explain conflicting results: one browser shows the VPN address while another app shows the ISP address. Review both the VPN application's split-tunneling list and any website exclusions configured in a browser extension.
A VPN browser extension can protect or proxy traffic from that browser, but it does not necessarily route every application on the device. Testing in another browser, game, email app, or system command may therefore show the regular address.
Use the provider's full desktop or mobile application when you need device-wide routing. If you intentionally use only an extension, run the IP check inside the protected browser and confirm that the test domain is not excluded.
A search result, browser tab, network widget, or website session can continue displaying an earlier address. Hard-refresh the page, open a private window, and compare a second checker. Disconnecting and reconnecting without reloading the page is not a reliable test.
A device can have both IPv4 and IPv6 connectivity. If the VPN changes IPv4 but an IP test still shows an ISP-provided IPv6 address, IPv6 traffic may not be handled as expected by that provider or configuration.
Do not permanently disable IPv6 as a first response. Update the VPN, test another protocol, and check the provider's current IPv6 documentation. Disabling network components can break local or internet connectivity and may hide the symptom instead of fixing the routing problem.
Browsers use WebRTC for real-time audio, video, and peer-to-peer communication. Depending on the browser, operating system, and VPN, a WebRTC test may expose address information that an ordinary public-IP page does not show.
Interpret WebRTC results carefully. A private local address is not the same as exposing the public address assigned by your ISP. The important warning is when the test reveals the same public internet address you recorded before connecting.
The VPN application may authenticate successfully while a route, virtual adapter, firewall, or network service fails to send traffic through the tunnel. This is more likely when every browser shows the ISP address even after split tunneling is disabled.
Two VPN clients, a corporate profile, antivirus web protection, an ad-blocking VPN, a manual proxy, or a privacy browser can create competing routes. The status shown by one app does not prove that it controls the traffic being tested.
Websites can estimate location using more than an IP address. GPS permission, Wi-Fi positioning, browser location access, cookies, account history, payment region, and saved preferences can continue identifying the usual area after the public IP changes.
A website displaying your home city does not by itself prove an IP leak. Check the exact public address first, then review the site's location permissions and account settings. If Google is the only service showing the old area, use our guide to why Google still shows your location with a VPN. For broader privacy context, see what your internet provider can see when you use a VPN.
Disconnect the VPN and record the public address, then connect to a server in an obviously different region. Open a private window and use two current IP checks. Compare:
Do not rely only on the map pin. IP geolocation is an estimate, and databases do not all update at the same time.
Open the VPN application's settings and find Split tunneling, Bypass VPN, Excluded apps, or Allowlist. Confirm that the browser used for testing is routed through the VPN.
On Android and Windows, split tunneling is commonly application-based. Browser extensions may instead exclude individual websites or domains. Remove the test website from any exclusion list, reconnect, and reload it.
If disabling split tunneling changes the public address, add exclusions back one at a time. Remember that an excluded application uses the ordinary connection and can reveal the ISP address by design.
Check whether the installed product is a browser extension or a full operating-system application.
Pause the extension, connect the full app, and repeat the test in a private browser window. If you prefer the extension, test only inside that browser and understand that other applications can keep using the normal public IP.
Disconnect and choose a specific server rather than reconnecting automatically to the same location. Test two or three nearby servers and one clearly different country.
If only one server reproduces the problem, report that server or location to the provider. If every server shows the same ISP address, investigate local routing, split tunneling, and software conflicts instead of repeatedly changing countries.
Connecting twice to the same VPN location does not guarantee a different VPN address each time. Providers may assign an address from a server pool, and reconnecting can return the same VPN exit address. The important comparison is between the pre-VPN ISP address and the address shown while connected.
Avoid modified VPN applications or unofficial premium APKs. They can change routing, remove security controls, or collect credentials.
Start with Automatic or the provider's recommended protocol. If the public IP still does not change, test each maintained protocol available in the app.
Changing protocol forces the application to build the tunnel using a different networking method and can bypass a problem with a virtual adapter, restrictive network, or route. Do not select an obsolete manual protocol merely because it connects.
These tests answer different questions:
| Test | What it tells you |
|---|---|
| Public IPv4 check | Which IPv4 address the website sees |
| Public IPv6 check | Whether the website can reach you over IPv6 and which address it sees |
| DNS leak test | Which resolver handles domain lookups |
| WebRTC test | Which candidate addresses the browser may expose for real-time connections |
A DNS resolver from the ISP is a privacy concern worth investigating, but it does not automatically mean the public-IP checker must show the ISP's public address. Likewise, a private WebRTC address is not proof that the public ISP address leaked.
Run one test at a time, save the provider and address type privately, and compare the results with the VPN's documentation. If an ISP public IPv6 or WebRTC address appears, switch protocol, update the app, and contact the VPN provider with the exact test conditions.
For diagnosis, disconnect other VPN clients and review:
Do not remove managed work or school profiles without authorization. If temporarily disabling one product resolves the routing problem, update both applications and follow their official compatibility guidance rather than leaving protection disabled permanently.
If the public address changed but a website still displays the old city or country:
A VPN changes network routing; it does not rewrite GPS, account, billing, or cookie information. Do not falsify account details or use a VPN to evade rules you are required to follow.
Use the provider's Reset VPN profile or Restore defaults option when available. Otherwise:
A complete operating-system network reset is more disruptive and should come later. It may remove saved Wi-Fi networks, Bluetooth pairings, VPN profiles, and mobile configuration.
A different VPN IP after reconnecting is usually normal. Providers commonly assign exit addresses from a shared pool, so changing servers, reconnecting later, or balancing users across infrastructure can produce a different address. You may also receive the same address again; neither result alone proves that the tunnel failed.
Compare the connected address with the public ISP address recorded before the VPN started. The important result is that protected traffic uses a VPN exit address—not whether every VPN session receives a unique address. If the new address belongs to the VPN but a website still displays the old city, investigate geolocation, cookies, account settings, and device location separately.
Open the VPN app's split-tunneling settings and confirm the browser is not excluded. Android can run only one active VPN service for a user at a time, so ad blockers or firewalls implemented as VPNs can compete with the commercial VPN. Check both IPv4 and IPv6 after reconnecting.
Review Settings > General > VPN & Device Management for old profiles you recognize. Disable Private Relay only as a controlled compatibility test if it is active and relevant to the browser being tested, then restore it afterward if you use it. Check whether Safari or the website has location permission before treating an old city label as an IP failure.
Review the VPN's split-tunneling list, Windows proxy settings, other VPN adapters, and security software. Test using the full VPN application rather than only a browser extension. Restart after changing or reinstalling the virtual network adapter through the provider's supported process.
Check System Settings > Network > VPN & Filters for multiple VPNs, content filters, or old profiles. Confirm whether the test browser is using an extension with its own server. Do not delete an employer-managed filter without permission.
Use this sequence for NordVPN:
NordVPN documents split tunneling on Windows, Android, and Android TV, and its browser extension provides domain-level exclusions. Those features are useful, but an excluded browser or website will intentionally use the ordinary public address.
A consistent result should look like this:
No single website proves total anonymity or verifies a provider's entire infrastructure. These checks confirm common routing and exposure problems on the tested device and network.
Contact the provider when the exact ISP public address remains visible after:
Include the device model, operating-system version, VPN app version, connection protocol, server location, whether IPv4 or IPv6 is affected, and steps that reproduce the result. Mask most of your real IP in screenshots and send diagnostics only through the provider's official support channel.
A full VPN connection should normally change the public internet address seen by traffic routed through the tunnel. It does not need to change the device's local Wi-Fi address, GPS location, or account country.
You may be checking a local address, testing an app excluded through split tunneling, using only a browser extension, viewing a cached result, or experiencing an IPv6, WebRTC, routing, or software-conflict problem.
The VPN server may be nearby, the geolocation database may be inaccurate, or the website may use GPS, cookies, account history, or saved preferences. Compare the exact address and network owner rather than relying only on a city label.
Yes, by design, for applications or websites you intentionally exclude. Their traffic bypasses the VPN and uses the normal internet connection. Review exclusions whenever privacy from the local network or ISP is the priority.
Not necessarily. DNS and public-IP tests measure different parts of the connection. A device can show the VPN exit IP while sending DNS requests to an unintended resolver, so investigate both results separately.
WebRTC can expose address information depending on the browser and network configuration. Focus on whether it reveals the same public ISP address recorded before connection; a private local address alone is not the same thing.
The browsers may have different extensions, proxy settings, split-tunneling rules, cached pages, or domain exclusions. Test each in a private window and review both app-level and extension-level settings.
Not necessarily. A provider can assign the same exit address again, especially when you reconnect to the same server or location. The key test is whether the connected address differs from the ordinary ISP address.
No. Signing in, cookies, browser storage, GPS permission, and device characteristics can identify you even when the VPN changes your public IP. A VPN improves network privacy but does not make you anonymous.
When a VPN says connected but the IP address does not change, verify the public address rather than the local Wi-Fi address, then check split tunneling, browser-extension scope, cached results, IPv6, WebRTC, servers, protocols, and competing network software. Test the exact address before and after connecting, not only the displayed city.
A correctly routed full-device VPN should replace the public ISP address for traffic inside its tunnel. If the same ISP address remains visible across multiple browsers, servers, and protocols after exclusions are disabled, stop relying on the connection for privacy-sensitive activity and contact the provider with controlled test results.
