Can my ISP see my VPN traffic? What stays visible in 2026

Short answer: your ISP cannot read what travels inside the tunnel, but it still sees that a tunnel exists, which address it goes to, when it is open and how many bytes move through it. Most setups also put a hostname in the outer handshake. That is a large reduction in what is visible, not a disappearance, and the gap between those two is where most of the confusion lives.

What your ISP sees without a tunnel

Start from the baseline, because everything after this is a subtraction from it. With no tunnel your provider is on the path for every packet and can record:

• Every destination IP address and port you contact, with timestamps.
• DNS queries, if resolution goes to the resolver handed out over DHCP - a plaintext list of hostnames.
• The server_name field of most TLS handshakes, which names the site even when DNS is encrypted. Encrypted Client Hello is the exception, and it is still far from universal.
• Byte counts, packet sizes and timing per connection, which separates a video call from a file download without reading either.
• The contents of anything still running without TLS - firmware and update checks on older devices, plain-text mail protocols on old clients, a good deal of local network chatter.

What the tunnel actually hides

Once the client is up and routing everything, the packets leaving your machine are addressed to one host: your VPN server. What used to be a list of destinations collapses into a single flow. Assuming nothing bypasses the tunnel - a condition covered further down - your provider no longer sees:

• Which sites and services you reach. Their addresses appear only on the far side of the tunnel.
• Hostnames of those sites, whether they would have leaked through DNS or through the TLS handshake.
• URLs, paths, headers, request bodies, uploaded files, message contents.
• The identity of the protocols you run inside. Not perfectly - sizes and timing still suggest what kind of traffic it is - but nothing carries a label any more.

The far end of the tunnel stays visible

Your provider sees the destination IP of the tunnel itself, and that address carries information. It resolves to an autonomous system, and hosting ASNs look nothing like residential or CDN ranges. A long-lived connection from a home line to a single machine in a datacenter is a recognizable pattern on its own.

For commercial services this is sharper: their address ranges are tracked by IP-intelligence vendors, which is how streaming platforms and banks recognize them. A private server is not on those lists, but it is also one address with one subscriber talking to it, which is distinctive in a different way.

There is a smaller detail people miss. If your profile points at a hostname rather than a literal IP, the client has to resolve that name before the tunnel exists, using whatever resolver the system is on at that moment. That query is outside the tunnel by necessity, and it names your endpoint.

The honest formulation: a tunnel hides what goes through it, not the fact that you are using one. Any claim beyond that deserves skepticism.

Timing, volume and shape stay in the clear

Encryption protects contents, not the envelope. Your provider still records when the connection opens and closes, how many bytes go each way, in what bursts, with what packet sizes. No VPN protocol removes that, because the packets have to exist to be sent.

What it reveals is coarse but not nothing. A steady low-rate flow in both directions for half an hour looks like a call. A one-directional burst of several gigabytes looks like a download. A trickle at 3am looks like a device syncing rather than a person working. Nobody learns which site you opened from this, but activity patterns and hours are readable.

The defense against traffic analysis is padding and cover traffic, and mainstream tunnels deliberately do very little of either, because constant filler costs bandwidth and battery. If your threat model includes an adversary correlating flows over long periods, a commodity VPN is not the tool for it.

The outer handshake: SNI and fingerprints

A TLS client puts the requested hostname in the ClientHello, in cleartext, before the session is encrypted. Encrypted Client Hello does not delete that field: it moves the real name into an encrypted inner ClientHello and leaves the provider's public name outside, and it needs an ECHConfig published in a DNS HTTPS record plus support on both ends. Xray and sing-box both expose ECH settings now, it is not on by default, and it changes nothing about the destination address. Inside a tunnel none of this matters for the sites you visit - those handshakes are wrapped. The tunnel's own handshake is on the outside, and what it puts in that field depends on your setup.

• VLESS or Trojan over plain TLS with your own domain - the handshake carries that domain in cleartext. If the domain is used for nothing else, it becomes a stable label on your traffic, and a certificate transparency lookup ties it back to whoever registered it.
• VLESS Reality - the handshake is aimed at a real third-party site and carries that site's name, so there is no domain of yours to log. The weak point is elsewhere: your line sends a ClientHello for that name with no DNS query for it beforehand, and to an IP that the name does not resolve to. See how Reality works.
• Hysteria2 and other QUIC transports - the ClientHello sits in a CRYPTO frame inside the QUIC Initial packet, whose protection keys are derived from a version-specific salt published in RFC 9001. Any observer can decrypt it and read the name. QUIC is not a way to hide SNI; the Salamander-style obfuscation that stops the packets parsing as QUIC at all is a separate feature.
• WireGuard - no TLS, so no SNI, and that is not invisibility. The Noise handshake is a 148-byte initiation and a 92-byte response, each starting with a fixed message-type byte. A length-and-first-byte rule matches it.
• OpenVPN - it does have a TLS handshake, inside its own framing. With tls-auth the ClientHello is readable there; with tls-crypt the control channel is encrypted under a static key and it is not. The opcode framing and the ACK pattern identify the protocol either way.

The name is only half of what the outer handshake gives away. The cipher list, the extension order and their contents form a fingerprint - JA3, or the newer JA4 - and a Go TLS stack does not produce the same one as Chrome. That is why Xray and sing-box ship uTLS: the client copies a browser's ClientHello. It works, and it also means the fingerprint has to stay plausible for the traffic it sits on.

DNS and IPv6: where traffic goes around the tunnel

Most of what people describe as a VPN failing to hide things is not the VPN at all - it is traffic that never entered the tunnel. Four common cases:

• DNS outside the tunnel. If the client does not take over resolution, queries keep going to the provider's resolver on UDP 53. That hands back a list of the hostnames you visit, which is most of what the tunnel was hiding.
• IPv6. A tunnel that routes only IPv4 on a line with working IPv6 lets dual-stack destinations be reached directly. Large sites are dual-stack, so this is not an edge case. Either route IPv6 through the tunnel or disable it on the interface.
• Split tunneling. Per-app or per-route exclusions do exactly what they say: everything excluded is visible in the clear. That is a choice rather than a bug, but people forget what they excluded.
• Gaps at connect and reconnect. Between link-up and tunnel-up, and during every reconnect after a network change, traffic takes the default route. Without a kill switch those windows are visible, and background apps are noisy right after a network change.

WebRTC is the leak people expect in this list, and it belongs in a different one. It exposes local and public addresses to the web page you are on, not to your provider, which already knows both. It matters for what a site can tell about you, not for what your ISP logs.

There is also low-level chatter that stays local regardless: DHCP, ARP, mDNS, captive portal probes and often NTP. It says little about you, but it is why a capture on your router never looks completely empty.

The observer moves rather than disappearing

Everything the ISP stops seeing, someone else starts seeing. The VPN server terminates your traffic, so its operator now holds the position your provider used to hold. With a commercial service you are trusting a policy you cannot verify. With a self-hosted server you are trusting the hosting company and its upstream, and the server address is tied to whatever you paid with.

What either party has to retain is a matter of local law and varies sharply. In Russia, telecom operators and registered internet services fall under the retention obligations introduced by the 2016 package commonly called the Yarovaya law. In the EU, blanket data retention has been struck down repeatedly by the Court of Justice, and what remains is national and narrower. Do not assume a rule you read about one country applies to another, and do not treat a tunnel as a way around a legal obligation - it is not one.

How to check what your own connection shows

1. 1Capture on the outside, not the inside. Run tcpdump -n -i <wan-if> on the router or on whatever Linux box is your gateway. A second laptop on the same switch will not see your traffic unless it is on a mirrored port. Whatever appears in that capture is what your provider sees.
2. 2Confirm non-tunnel destinations are absent. Filter your server out with tcpdump -n not host <server-ip>. What remains should be local chatter and nothing else.
3. 3Check DNS specifically. Look for UDP 53 and DoT on 853 in that capture. DoH on 443 looks like ordinary HTTPS, so for that one check which resolver the client is actually configured to use rather than trusting the capture.
4. 4Check IPv6. Run curl -6 https://ifconfig.co with the tunnel up. Your home address in the answer means IPv6 is bypassing the tunnel; a connection error means there is no IPv6 route at all, which is also a pass.
5. 5Test the reconnect window. Disable Wi-Fi, enable it again, and watch the first few seconds of the capture. That is where a missing kill switch shows.
6. 6Read your own handshake. Open the start of a new tunnel connection in Wireshark and look at the server_name field - for QUIC it decrypts the Initial packet for you. Whatever is there is what gets logged upstream.

Run this once per setup rather than once per week. The results change when you switch clients, upgrade an OS, or move to a network with different IPv6 behavior.

Common questions

The summary worth keeping: a tunnel turns a detailed log of your destinations into a single flow to one address, while timing, volume and the fact of use stay readable. That is a meaningful change on a hostile network and a poor substitute for anonymity. Which transport suits your line is a separate question, covered in VLESS Reality vs Hysteria2.