What Your Internet Provider Still Sees While the Tunnel Is Up
A VPN stops your internet provider from seeing which sites and services you reach. It does not make you invisible to it. Your provider still sees that a connection exists, which single address it goes to, roughly what protocol it is, when it started and stopped, and how much data crossed the line in each direction — and separately from anything on the wire, it still holds the subscriber records that tie your line to you. Those are two different kinds of visibility and they need to be taken apart.
What genuinely stops being visible
Without a tunnel, the network carrying your traffic is positioned to observe a per-destination picture: each hostname your device looks up, each address it opens a connection to, and how much it exchanges with each one. That is the raw material of anything worth calling tracking, and a tunnel removes it.
With the tunnel up, all of that collapses into a single flow to a single address. The destinations are inside the encrypted payload. Your provider can no longer build a list of the services you use, and cannot distinguish reading the news from streaming video except by inference about volume and timing.
That is a real and substantial change. It is worth having, and it is narrower than “they cannot see anything”.
The one address that stays in view
The tunnel is a conspicuous object rather than a hiding place, and the conspicuous part is an address.
Your traffic now leaves as one long-lived flow to one destination, and that destination is the exit server. Any address on the internet can be looked up against the registry that allocated it, which returns the organisation holding the range and the network it is announced from — the procedure in what an ASN and reverse DNS tell you. If the range belongs to a hosting company, that is a fact about your connection your provider can establish as easily as you can. Nothing about a tunnel conceals which network you are tunnelling to.
Alongside it sit the coarse facts that come with carrying any flow: when the session began and ended, and roughly how much crossed the line each way. Inside your own network the traffic also still originates from one particular device with its own local address before it reaches the router, which is a separate question from what leaves the router.
A fair summary is that the tunnel converts a per-destination record into a single destination plus a rough total. It does not produce silence.
The records that exist regardless of traffic
This is the part usually left out, and it is the reason “stop ISP tracking” is the wrong shape as a goal.
Your provider assigned your public address, and it knows which subscriber had it and when. If you are behind carrier-grade translation, it also holds the mapping between your session and the shared public address it was multiplexed onto. It knows your account details because you pay it. It knows your service address, your equipment, and your line’s activity pattern. On a mobile network it also has location data derived from the cells you attach to.
None of that touches the contents of your traffic, and none of it is affected by a tunnel. Anyone whose actual concern is the relationship between their identity and their connection should understand that this layer is untouched.
It is also worth separating three things that “tracking” runs together: whether the provider can observe something, whether it records it, and whether it uses records commercially. Encryption addresses only the first, and only for traffic contents.
Where encrypted DNS fits, and where it stops
Encrypted name resolution is often recommended in the same breath, and it solves a genuinely different problem. Without it, your lookups go to whichever resolver your device was handed — usually your provider’s, as covered in who runs your DNS resolver — in a form that network can read. Encrypting them removes that view.
Two limits are worth knowing. First, encrypted lookups are not needed for privacy from the access network once everything is inside a tunnel, because the lookups are in the tunnel too; the comparison is set out in DNS over HTTPS vs a VPN. Second, encrypted DNS on its own does not hide destinations, because the hostname is commonly announced in the clear anyway, in the server-name field that each new connection opens with.
The combination that actually matters is that the tunnel carries your lookups as well as your traffic, and that nothing falls back to the network’s resolver when the client is fussy. That second part fails often enough to be worth testing rather than assuming.
The moments before the tunnel is up
There is a gap nobody advertises. Joining a network, waking from sleep, or moving between Wi-Fi and mobile data all leave a short window where the interface is up and the tunnel is not. Background services do not wait politely, so lookups and connections can leave in the open during those seconds.
You cannot eliminate this. You can shrink it by having the client start with the system, by knowing what it does on a drop, and by testing that behaviour deliberately rather than trusting the setting’s name.
Trading one observer for another
The honest framing is not that observation was removed but that it was moved. What your provider can no longer see, the tunnel operator now can, because the exit machine handles both your address and your destinations by necessity. Whether that is an improvement depends entirely on which party you would rather have in that position, and on what the operator keeps — which is why the retention language deserves close reading, as set out in what a no-logs VPN claim covers.
Checking your own side
Two things are worth verifying rather than believing. Confirm your lookups are resolving through the tunnel rather than escaping to the resolver your network handed you. And confirm what happens when the connection drops, by dropping it on purpose while something is downloading. Those two checks cover most of the distance between what a client claims and what it does.