Your VPN Is On but the App Still Knows Your Location

You turn the VPN on, open the app, and it still shows the city you are standing in. Nothing is broken. The app is reporting something it already knows rather than watching your traffic escape the tunnel. Two different questions are hiding in that result, and mixing them up sends people off to reinstall the client.

What the app actually received

A position on a screen can come from at least four places. A device location fix, an approximate city derived from your IP address, an address saved in your account, or something you typed into a form.

A device location fix is the one people mean when they say the app knows where they are. On a phone that is GPS, Wi-Fi scanning and cell data combined by the system; on a laptop it is usually a Wi-Fi database lookup. All of it arrives through a permission the app requested and you granted. The tunnel never enters into it.

Account data is the sneakier source. A delivery app that already stores your home address does not need a sensor to show it back to you.

Why the tunnel cannot cover this

A VPN replaces the address your traffic appears to come from. It does not touch the permission model, the sensors, or the account record on the server. Data the app collects locally and then uploads travels inside the encrypted connection, which is what the connection is for. The receiving server learns the payload because the app chose to send it.

Think about a name typed into a form. The tunnel hides the envelope, not the letter.

This is why an address check in a browser can disagree with an app. The browser reports the exit address; the app reports a sensor reading. Both are correct answers to different questions.

Permission, entitlement and what the platform allows

Apple's Mac location controls are a useful reference because they spell out where the number comes from: apps use Location Services, and the Mac estimates its position from nearby Wi-Fi. The same page notes that apps and websites can use other methods even when Location Services is switched off. That caveat is the whole story in one line.

On phones the split is similar. An app either holds a location permission or it does not, and the platform decides what it can read. A VPN client is not a permission manager and cannot revoke another app's grant.

Language, timezone and locale are weak signals on their own. They shift where a service guesses, not where you are.

What an actual leak looks like

Real leaks are worth separating out, because they have different symptoms: your real address surfacing in a page's own diagnostics, DNS queries resolving through your ISP, IPv6 traffic leaving outside the tunnel, or a split-tunnel rule that excludes the app you cared about. Those faults show a host you did not intend to contact, and they change when you switch the VPN off.

The tell is the direction of the surprise. A leak reveals who you are to a stranger, while an app submission reveals what the app already had.

Test the first case by comparing what a site reports for your address with what the VPN dashboard says about the connected session. Test the second by looking at what your account profile holds.

What to check in the next ten minutes

Open the app's permission entry and read the location setting. If it is allowed and you do not want the app to have a position, switch it to approximate or deny it, then reload the app so it stops using a cached fix. Then look at the saved address and the upload fields, because revoking a permission does not erase a value the server already holds. Finally, check the VPN client's split-tunnel list so you know which apps bypass the tunnel.

Do those three in order and the ambiguity usually collapses on its own.

If the position survives all of that and the VPN dashboard still shows a healthy session, you are looking at stored data rather than a leak. Changing your exit country will not move it. Deleting the saved value, or the account field that produced it, is the only step that will.