Short answer: A website will always show some public IP address. The real question is whether it shows the VPN exit IP you expect or your original ISP, office, home router, or mobile carrier IP after the VPN says it is connected.
This confusion causes many false alarms. A VPN endpoint being visible is normal. Your real network still showing after connection is a setup problem that can come from split tunneling, proxy settings, failed tunnel state, IPv6, DNS, or WebRTC.
Problem
- A visible public IP is never itself the problem. Every request needs a source address; the question is whose it is.
- Network owner and ASN answer that question. The city label does not, and disagrees often enough to mislead.
- This reads the browser you run it in, which is exactly the layer a split-tunnel rule can exclude.
Run the test
Start with VPN Leak Test. Keep the same browser and network when comparing before and after.
- Open What Is My IP with the VPN disconnected and note network owner, ASN, country, and IP version.
- Connect the VPN to a known server location.
- Run VPN Leak Test and compare visible IP, DNS, WebRTC, IPv6, and browser/session signals.
- If the browser still shows your ISP or carrier, check split tunneling, proxy extensions, VPN kill switch, and reconnect state.
- Use Safe Copy after the retest so you can compare before and after without sharing raw IP details.
How to read the VPN Connected But IP Still Shows result
| Result | Usually means | What to do next |
|---|---|---|
| IP changes to VPN provider | The basic browser route likely changed. | Check DNS/WebRTC/IPv6 before calling it fully clean. |
| IP stays on real ISP/carrier | The browser may not be using the VPN tunnel. | Review split tunneling, proxy settings, captive portal, and VPN reconnect state. |
| VPN city looks wrong | IP geolocation can be approximate or stale. | Compare network owner and ASN, not city alone. |
| DNS differs from VPN | Resolver path may be separate from page IP. | Run DNS Leak Test and review Secure DNS or VPN DNS settings. |
| WebRTC or IPv6 exposes another route | The page IP and browser/network candidates can differ. | Run focused WebRTC and IPv6 checks. |
Most common fixes
- Turn off split tunneling for the browser you are testing.
- Disable browser proxy extensions for the test.
- Reconnect the VPN and wait for the route to settle before retesting.
- Enable DNS leak protection and kill switch if your provider offers them.
- Retest in another browser if only one profile behaves strangely.
What to do after the result
The most common reason this question gets asked is a misreading, so settle that first: a visible IP is not a failure. Every request needs a public source address, and after a successful connection that address should be the VPN's. Compare network owner and ASN against your provider's server list. If they match, the setup is working, and a city label that looks wrong is a geolocation database being approximate rather than a routing problem.
If the owner really is still your ISP, work down the causes by how quickly each can be ruled out rather than by how likely it feels. Browser proxy extensions and split-tunnel rules are the two that most often exclude a single browser while everything else is tunnelled, and both are visible in a settings pane in under a minute. A tunnel that reports connected but has not finished re-establishing after a network change gives the same reading and clears on reconnect, so retest once before changing any setting at all.
Frequently asked questions
Should my IP disappear when VPN is connected?
No. Websites still need a public endpoint. The question is whether that endpoint is the VPN server or your original network.
Can split tunneling cause this?
Yes. If the browser is excluded from the tunnel, it can keep using the normal ISP route.
Why does the VPN location look different from the city I selected?
IP geolocation databases are approximate and can lag behind provider routing. Check network owner and ASN too.
Limits and methodology
MyIPScan checks show observable browser and network signals for the current session. Results can change with browser profile, app route, VPN server, router, OS, carrier, DNS, and time. See the methodology and editorial policy.