How VPNs work, from app to server

A VPN can sound abstract until you follow one request. The useful part is understanding which organizations can see which pieces of information before and after the tunnel.

Before the tunnel: your device prepares a request

Imagine opening a news website. The browser needs to find the site's address, establish a connection, and request a page. HTTPS normally encrypts the page content in transit, but the network still handles routing information. A VPN app changes the route before the traffic leaves the device.

Step 1: the VPN app encrypts eligible traffic

After you select a server and connect, the VPN client and server agree on cryptographic keys through a VPN protocol. The client wraps eligible traffic in encrypted packets. Protocols differ in design and performance; NordVPN's current protocol guide describes NordLynx as its WireGuard-based default in most apps.

A kill switch is a related control, not part of the tunnel itself. Its role is to block selected traffic if the VPN connection drops, reducing the chance that an app silently returns to the ordinary route. Exact behavior can differ by platform and configuration, so it should be tested on the devices that matter.

Step 2: the local network carries encrypted packets

A Wi-Fi operator or internet provider can generally see a connection to a VPN service and the amount and timing of traffic. It should not be able to read the traffic inside the tunnel. That is the main boundary a consumer VPN adds.

Step 3: the VPN server forwards the request

The VPN server decrypts the outer tunnel and sends the request onward. The destination website sees the server's IP address. If the website uses HTTPS, the protected web session remains encrypted between the browser and website; the VPN does not need to read the page content to forward it.

Step 4: the website responds

The response returns through the VPN server and encrypted tunnel. The client unwraps it for the browser. The website can still use its normal controls: it can see a logged-in account, store cookies, run scripts, record actions, or block known VPN addresses. The tunnel is working even though those application-level facts remain visible.

DNS, split tunneling, and exceptions

Domain Name System requests translate names into network addresses. Well-configured VPN apps route DNS through the protected connection to avoid sending those lookups separately. Split tunneling deliberately excludes selected apps or destinations from the VPN. That can improve compatibility, but excluded traffic receives none of the tunnel's protection.

Device traffic outside the VPN client, operating-system services, local network discovery, and browser-specific technologies can create edge cases. That is why leak protection, platform documentation, and up-to-date apps are more useful than absolute marketing claims.

Why speed changes

Encryption takes processing time, and the VPN route may be longer than the direct route. A nearby, lightly loaded server with a modern protocol can keep the difference small; a distant or crowded server can add latency and reduce throughput. No responsible review can promise one speed figure for every reader.

A practical first setup

1. Install the app only from an official store or provider page.
2. Enable multi-factor authentication on the service account.
3. Choose a nearby server and the provider's recommended modern protocol.
4. Review kill-switch and auto-connect settings before using an untrusted network.
5. Check that everyday banking, work, streaming, and calling apps behave as expected.

If NordVPN is on your shortlist, our independent NordVPN review maps the current features to real use cases without claiming a universal speed score.