How VPNs Work: Encryption, Servers and IPs Explained

When you type a website address, your device first performs a DNS lookup: it asks a directory service to turn a domain such as example.com into a numeric IP address. By default, that request often goes to your ISP or the operator of the network you are using.

Your browser then connects to the destination. HTTPS encrypts page contents, passwords and form data in transit, but the network can still observe connection metadata. Depending on DNS and TLS configuration, it may infer or see the domain, timing, data volume and destination IP. The website sees the public IP assigned to your connection and can estimate a location from it.

1. The handshake: your device and the VPN server authenticate and establish short-lived session keys over the open network.
2. Traffic is encrypted: modern protocols use established ciphers such as AES-256 or ChaCha20-Poly1305. The local network sees encrypted traffic to a VPN server, not the destinations carried inside.
3. The server forwards the request: it decrypts the tunnel packet and sends the request onward using the server’s public IP rather than yours.
4. The response returns: the website replies to the VPN server, which encrypts the response and sends it back through the tunnel for your device to decrypt.

The trust shift

After connection, your ISP still knows your real IP and that you connected to a VPN, but it no longer sees the destinations carried inside a correctly configured tunnel. The website sees the VPN server IP. The VPN provider can see your incoming IP and destinations at the forwarding point, although HTTPS still protects page contents from the provider.

A VPN does not remove the trusted party; it changes that party. This is why ownership, independent no-logs assurance and transparent policies matter more than grand claims about “military-grade” protection.

Your public IP is the return address for the connection. It normally provides an approximate location—not a street address or personal name—but it is a persistent signal that services can use to connect activity.

With a VPN, websites see the exit server’s IP. Most subscribers share that exit address with many other users. Sharing helps activity blend together, but it also explains more CAPTCHAs: everyone shares the address reputation.

A dedicated IP is a paid alternative used only by one account. It reduces shared-reputation problems and can support allowlists, but a unique address is also easier to associate consistently with one subscriber. Neither choice is automatically more private in every threat model.

IPv6 needs attention too. If a device sends IPv6 traffic outside a tunnel that handles only IPv4, the real network address can leak. Reputable apps route or block IPv6 appropriately, and the practical verification is a leak test.

A DNS leak occurs when the tunnel carries the main connection but the device continues asking the local resolver which IP belongs to each domain. The ISP may then retain a useful list of destinations even though the page traffic is encrypted.

Proper VPN apps send DNS queries through the tunnel to resolvers controlled or selected by the provider. A leak test should show resolvers associated with the VPN, not the home ISP, hotel or café network.

Some apps also block ads, trackers and known malicious domains at the DNS layer. That is useful filtering, but it is not a replacement for browser security, software updates or careful phishing checks.

Practical rule: keep the app on its modern default unless the network refuses to connect. On a restrictive network, switch to the provider’s obfuscated or stealth option.

A kill switch is a firewall rule. The device blocks internet traffic that is not using the VPN interface. If the tunnel drops during sleep, a network change or unstable Wi-Fi, traffic stops instead of silently falling back to the open connection.

Test it after installation: connect the VPN, interrupt Wi-Fi and re-enable it. The device should have no usable internet during the gap, then recover through the tunnel.

• Anonymity: visibility shifts from the ISP to the provider. For a stronger anonymity design, the relevant tool is Tor.
• Logged-in activity: a service knows what its account does regardless of the IP address.
• Cookies and browser fingerprints: changing IP does not clear stored identifiers or change the browser’s distinctive characteristics.
• Phishing and malware: DNS filtering can stop known bad domains, not a new convincing page or an already infected device.
• Guaranteed streaming access: platforms detect VPN traffic and what works changes frequently.
• Legal permission: a tunnel does not change local law, and VPN use is regulated in some destinations.

Choosing a VPN means choosing who handles the visibility moved away from the local network. That is why independent evidence and a clear business model are essential.

There is no shame in deciding you do not need one. A VPN is a tool for specific network and privacy problems, not a general safety blanket.

We separated protocol mechanics from provider marketing, checked claims against current Provider Hub evidence and used the diagrams as explanations—not proof of product performance. No speed result, price or provider interface is presented as first-party testing.

Next, see guide to choosing a VPN, return to the VPN Guides hub, browse VPN Basics guides, or apply the model to safer public Wi-Fi and the best VPNs for travel.