What Your VPN Provider Can See and What It Cannot
The exit sees addresses, timings and, unless Encrypted Client Hello is in use, the site name in the TLS handshake. Retention is a separate question.
Your tunnel keeps the local network out of your traffic. It does not remove the company at the other end, which handles every packet before it reaches the open internet. That position is both the business model and the privacy question. The useful question is therefore not whether the provider can see you, but what it sees, what it can name, and what it keeps.
Where the trust actually moves
Encryption runs from your device to the provider's server, and that outer leg is all your local network ever sees. The provider holds the other end of the leg, so it decrypts the tunnel and forwards your packets onward. Nothing about that is a flaw; it is the definition of the service you bought. Trust moved from the local operator to the exit operator rather than disappearing.
From that position it learns your source address, when you connected, roughly how much you transferred, and which destinations you contacted. None of that requires reading your messages, which is the point of separating categories. The interesting differences between providers concern what happens to those observations afterwards.
What the exit handles by necessity
Sort the categories by how reliably the exit can see them. None of the rows requires breaking encryption, and each has a different answer for whether it is avoidable at all.
| Category | Visible at the exit | Why |
|---|---|---|
| Your public address | Always | It is the address the tunnel arrives from |
| Connection times and volume | Always | Accounting data, not content |
| Destination IP addresses | Always | The exit has to route the packets |
| HTTPS hostname (SNI) | Normally, unless ECH is used | Sent in the clear in the TLS ClientHello |
| DNS names | Only if DNS is plaintext | DoH or DoT hides the query; plaintext is readable by the forwarder |
| Page paths and form contents | Not normally | Protected by the destination site's TLS session |
The fourth row is what most mental models miss. A modern browser puts the site name in the ClientHello, the first message of the TLS handshake, and that field is readable at the exit even when every DNS query is encrypted end to end. Unless Encrypted Client Hello is negotiated, the name travels in the clear beside the destination address. Encrypted DNS changes who sees the query, not who sees the name.
The same is true of certificates on older connections: TLS 1.3 encrypts the server certificate, while a TLS 1.2 handshake can expose the name to an observer that records the stream. Both are transport facts rather than provider policy.
What TLS does and does not cover
When a site serves HTTPS, your browser builds a TLS connection to that site's endpoint, not to the VPN server. The provider forwards encrypted records and learns the destination address, the timing and the approximate sizes. The site name rides in the ClientHello unless ECH is in play, and the page body stays encrypted either way. An unexpected root certificate changes that boundary, which is why certificate warnings deserve respect.
Plain HTTP has no such protection past the exit. The tunnel protects the leg to the provider, and after that the request travels exactly as it would have without a VPN. ECH does not repair that, because it protects the name rather than the content.
Retention is a separate question from visibility
An operator can process connection data in memory and keep nothing, or keep a subset and describe it accurately as not being browsing history. Read a no-logs claim by category rather than by slogan: connection records, timestamps, volume totals, destination data, account identifiers and support messages all count. A provider can honestly keep no browsing logs while holding the account record and the metadata needed to run the service. Visibility does not tell you which of those categories is stored.
An audit is evidence about the systems and the time window it covered, and open-source client code describes the client rather than the servers. Both are useful, and neither speaks for every storage system behind the exit. Ask for the scope of an audit, not for its badge.
Questions that separate providers
Ask what is retained, for how long, and who can retrieve it. Ask who operates the exit, because a directory listing, an app developer and the person running a particular server can be three different parties. Ask how DNS is handled and whether ECH is supported on the paths you use, since a plaintext ClientHello names the site even without a DNS query. Ask what happens on a legal request, and read the answer as a description of capability rather than intent.
The EFF's guide to choosing a VPN is a reasonable checklist for those questions, and it is a framework rather than a verdict on any service. A marketing page is not a retention policy. None of this makes a VPN useless; it changes who you have to trust, and for what.