How a VPN Works, in Just Enough Detail to Travel With One
A VPN puts an encrypted connection between your device and a server you chose, and sends everything through it. The practical consequence is that three parties now hold three different views of your traffic: the network you are physically sitting on, the provider operating that server, and the service you are trying to reach. Knowing which of the three sees what is enough to predict almost everything a tunnel will and will not do for you.
This post stays at that level on purpose. Deeper mechanism is a different subject, and this site is not the place for it.
The three views
The network under you — hotel, café, airline, carrier, office — can tell that your device has a persistent encrypted connection to one outside address, and roughly how much data moves through it and when. It cannot tell which services you are using. Before the tunnel comes up it sees everything ordinary; after, it sees a stream it cannot open.
The provider sees both ends, because passing your traffic along is the function you are paying for. This is structural. Any promise about what it does with that position is a promise, and how much such promises are worth is discussed in what a no-logs VPN policy means.
The service at the far end sees a request arriving from the provider’s server. It does not see your address, and therefore does not see your address’s country. It may well work out where you are anyway, from signals that never entered the tunnel — the subject of what a VPN does not change about your location.
Every claim you will read about VPNs can be checked against those three views. If a claimed benefit does not follow from moving visibility between those parties, it is probably not a VPN feature.
Two consequences that matter when the network keeps changing
Your gatekeeper changes. Normally the network you joined decides what you can reach: it resolves names, it may filter, it may inspect. With a tunnel up, it carries a stream to one destination and its filtering has much less to act on. This is why the same site can be unreachable on hotel Wi-Fi and fine through a tunnel — the party that was refusing you is no longer in a position to refuse.
Your apparent origin changes. You now arrive at services from the exit server’s country, so anything decided from your address is decided from there. That is a smaller change than it sounds, because address is only one input; the hierarchy is in how a website decides which country you are in.
The ordering problem
A tunnel has to be established before it can protect anything, and establishing it requires working internet access. Those two facts collide on exactly the networks travellers use most.
A guest network that wants you to sign in has to intercept your early requests to show you its sign-in page. A VPN set to connect automatically prevents that interception, so the page never appears and the tunnel cannot reach its server either — a deadlock that looks like a broken app and is actually two systems both trying to go first. The sequence that resolves it is in why hotel and airport Wi-Fi breaks your VPN.
The same ordering explains the gap when you land, change networks, or come out of standby: for a moment your device is on a new network with no tunnel, and whatever it does automatically in that moment happens in the open.
Where the traffic physically goes
Your traffic no longer takes the shortest path to its destination. It goes to the exit server first, then onward. If the server is far from both you and the service, you have added a detour to every request in the session.
This is the mechanism behind most complaints about VPN speed, and it is also why the fix is usually a nearer exit rather than a different provider. The choice-by-task version of that decision is in which VPN server country to connect to, and the honest accounting of what the detour costs is in does a VPN slow you down.
It also means the label on a server location is a claim about where the machine is, and labels are not always literal — see virtual vs physical server locations.
What the model predicts
Take a problem and ask which of the three parties owns it:
- “The café network blocks this site.” The network under you. A tunnel removes it from the decision. Likely fixed.
- “This service says it is unavailable in my region.” The service, from your address. Possibly fixed by a different exit country.
- “This service says my account’s region does not include this.” The service, from your account. Not fixed by anything network-level.
- “My bank locked me out.” The service, reacting to an unfamiliar origin. A tunnel can cause this as easily as cure it — see why your bank locks you out abroad.
- “I do not want the hotel to know what I read.” The network under you. Fixed, once the tunnel is up.
- “I want no one at all to know.” Includes the provider. Not fixed, by design.
That last one is the honest limit of the arrangement. You have not removed a watcher; you have replaced several casual ones with a single deliberate one you selected.
Where this site stops
Handshakes, key exchange, protocol comparisons, and the details of how traffic is wrapped are all real subjects and none of them change the three-party picture above. If your goal is to travel competently with a VPN, the shape is sufficient, and the time is better spent on which exit country suits the task and how the tool behaves on networks you do not control.
Bottom line
Your device builds an encrypted path to a server you chose; the network under you loses visibility, the service at the far end sees the server, and the provider sees both. Ask which of those three owns your problem, and you will know whether a tunnel is the answer before you start changing settings.