Answer and scope

A VPN (Virtual Private Network) works by creating an encrypted “tunnel” between your device and a VPN server. Once that tunnel is up, your traffic is sent to the server through the tunnel, and the server forwards that traffic onward to the destination you requested. To outside observers on your local network (for example, a Wi‑Fi hotspot) and between you and the VPN server, the contents are protected by encryption, and the apparent source is the VPN server.

Core explanation: how a VPN connection is established

When you turn a VPN on, two things must happen: a secure connection must be negotiated, and traffic must be routed through the tunnel.

First, your device and the VPN server perform a handshake to agree on secure session settings (such as encryption and integrity protections) before any sensitive data is sent. After the secure channel is established, the tunnel encrypts your traffic while it travels from your device to the VPN server.

Second, the VPN client modifies routing for your device so that eligible network traffic goes into the tunnel instead of leaving directly via your normal network path. In practice, this means your device can still use the internet normally, but the path changes: you effectively reach the destination via the VPN server rather than directly.

A useful mental model is:

  • Your device talks to the VPN server over an encrypted tunnel.
  • The VPN server talks to the internet destinations on your behalf.
  • Return traffic comes back through the tunnel to your device.

What the VPN changes—and what it doesn’t

A VPN can reduce certain kinds of exposure, but it does not erase all information or eliminate every risk.

What a VPN commonly helps with:

  • Protecting traffic contents from being read by someone who can observe your local network traffic.
  • Reducing the usefulness of network-level observation between you and the VPN server (your destination requests are not visible in the same way as without encryption).
  • Making the public-facing IP address seen by many websites appear to be the VPN server’s address.

What a VPN does not automatically guarantee:

  • Complete anonymity: websites, apps, and account systems may still identify you via logins, cookies, device fingerprints, or other data.
  • Safety from malicious content: encryption doesn’t prevent you from visiting harmful sites if you choose to.
  • Protection when the VPN is not actually in use: if the tunnel is down, traffic may leak depending on your device settings and client behavior.

Differences and limits you should expect

The details depend on configuration and on how your device handles DNS and routing.

  1. DNS behavior matters If DNS requests are not sent through the VPN tunnel (or if DNS settings are inconsistent), a third party may still learn which domain names you are trying to resolve. Some VPN setups aim to ensure DNS queries follow the tunnel; others may require you to configure it.

  2. Routing scope can vary Some VPN configurations send all traffic through the tunnel; others route only selected traffic. If split-tunneling is enabled, some connections may bypass the VPN.

  3. Reliability trade-offs Encryption and rerouting can add overhead. This can increase latency or reduce throughput compared with a direct connection, especially if the VPN server is far away or heavily loaded.

  4. Trust assumptions remain Even with strong encryption, the VPN operator becomes part of the path. The VPN server must be trusted to forward traffic correctly and to protect your data at the server side. How much you can trust that is a separate question from how the VPN works technically.

Practical use: checks you can do to confirm expected behavior

You can validate that your VPN is behaving as you intend with a few non-invasive checks.

  • Check the apparent IP change: while the VPN is connected, compare the public IP address shown by a reputable “what is my IP” style page with what you saw when disconnected. If it doesn’t change, the tunnel may not be routing correctly.

  • Verify DNS handling: test domain resolution while connected and ensure your client is using the intended DNS path (for example, by checking DNS leak tests made for that purpose). Results can vary by client and operating system.

  • Confirm the tunnel is actually up: disconnect/reconnect and watch whether connectivity fails immediately when the tunnel drops (depending on how your client is configured). If you continue to have full connectivity when the VPN appears disconnected, some traffic may be bypassing.

  • Inspect client settings related to routing: look for options like “use VPN for all traffic” vs “split tunneling,” and ensure the choice matches your goal.

  • Use a fresh session when testing privacy expectations: log out of accounts or use a new browser profile before comparing what websites see, because cookies and logins can persist across tests.

Related concepts: why “encrypted tunnel” isn’t the whole story

A VPN is one layer of protection. Network encryption addresses what can be observed in transit, but it doesn’t replace endpoint security (updates, malware protection), account security (strong passwords, multi-factor authentication), or application-level privacy controls. So when evaluating a VPN, it helps to separate:

  • Transport security (the tunnel encryption and integrity).
  • Routing behavior (what goes through the tunnel).
  • Identification surfaces (how websites and apps still recognize you).
  • Operational security (how settings, leaks, and reliability affect outcomes).