CourtVPN

How Does a VPN Work?

Your device opens an encrypted connection to a server operated by the VPN provider, and sends all its internet traffic through that connection. The server forwards the traffic on to its real destination and sends responses back the same way. That’s it. Every capability and every limitation follows from this one arrangement.

Worth understanding properly, because once you can picture the path, most VPN marketing claims become straightforward to check.

The path, step by step

Without a VPN, your traffic goes: device → local network → ISP → destination. The local network and the ISP both see which destination you’re contacting.

With a VPN:

  1. Your device establishes an encrypted tunnel to the VPN server. This involves verifying the server’s identity and negotiating keys — the same general shape as any secure connection.
  2. Your traffic is encapsulated. Each outgoing packet is wrapped inside another packet addressed to the VPN server. The original destination is inside the encrypted payload.
  3. The wrapped traffic travels through your local network and ISP. They can see that you’re talking to the VPN server, how much data is moving, and when. They cannot see what’s inside.
  4. The VPN server unwraps it and forwards the original request to its real destination, using its own IP address as the source.
  5. The destination replies to the VPN server, which wraps the response and sends it back through the tunnel.

Two immediate consequences:

  • Your ISP sees only “encrypted traffic to a VPN server.” It knows you’re using a VPN and how much data, not where you’re going.
  • The destination sees the VPN server’s address, not yours.

And one more, which is the whole trust question: the VPN server sees both ends. It has to — it’s doing the forwarding. This is structural, not a flaw in any particular provider.

What the encryption does and doesn’t cover

The tunnel protects traffic between your device and the VPN server. Beyond that point, your traffic continues under whatever protection it had originally.

So: a request to an HTTPS site is encrypted end-to-end anyway, and the VPN adds a second layer over the first leg. A request to a site without HTTPS travels protected to the VPN server and then unprotected onward. A VPN does not make an insecure site secure — it just changes who can see the insecure part.

Since the overwhelming majority of the web now uses HTTPS by default, the VPN’s contribution is mostly about hiding metadata — which sites, when, how much — from the local network and ISP, rather than protecting content that was already protected.

Protocols

The protocol is the set of rules for building and running the tunnel. As of writing, the ones you’ll commonly see named:

  • WireGuard — modern, notably compact codebase, generally fast. Widely adopted, sometimes with provider-specific modifications to handle address assignment.
  • OpenVPN — long-established, highly configurable, extensively reviewed. Runs over either TCP or UDP, which matters on restrictive networks.
  • IKEv2/IPsec — handles network changes well, so it’s common on mobile where you move between Wi-Fi and cellular.
  • Proprietary or obfuscated protocols — usually variants designed to make VPN traffic harder to identify and block on networks that filter it.

Two honest points about protocol choice. First, for most users the difference is performance and connection stability rather than a meaningful security difference — all the mainstream options are considered sound as of writing. Second, this area changes, so treat any specific claim about a protocol as current rather than permanent.

DNS, which is where it often goes wrong

Before connecting to a site, your device looks up its address via DNS. If that lookup goes to your ISP’s resolver instead of through the tunnel, your ISP learns every domain you visit — regardless of the encrypted tunnel carrying the actual traffic.

This is a DNS leak, and it defeats a large part of the point. A correctly configured VPN routes DNS through the tunnel to its own resolver. It’s covered properly in VPN leaks and kill switches, which is the practical companion to this post.

Server location and its effects

The server you choose determines the IP address destinations see, and therefore your apparent location. It also determines your traffic’s physical path — a server far away means longer round trips, which is the main reason a VPN can feel slow.

Provider marketing emphasises server counts and country lists. What actually affects your experience is whether there’s a well-provisioned server reasonably near you, and whether it’s congested. Those aren’t things a country count tells you, and they’re not things we can measure — which is part of why this site doesn’t rank providers.

What this means practically

Because the arrangement is simple, the honest evaluation criteria are too:

  1. Does the tunnel actually carry everything, including DNS, including at startup, including when the connection drops?
  2. Does the provider deserve the position it occupies? It can see both ends by design.
  3. Is there a server close enough to you to keep latency tolerable?

Everything else — protocol lists, server counts, marketing about military-grade encryption — is secondary to those three. The first is a leak question; the second is a claims question; the third you can only assess by trying it.

how-it-worksprotocols