What Your ISP Still Sees When Torrenting Through a VPN

Walk the questions in order: what the access network can observe, what leaves the tunnel without it, what the name lookup reveals, and what peers and trackers learn regardless. Each answer is independent of the others, and a VPN only fully addresses the first. The fourth is where most expectations quietly fail, because no tunnel removes an account name.

Start by deciding which observer worries you, because the answer changes with the observer.

One Connection Replaces Many

With the client genuinely inside the tunnel, the access network sees one sustained encrypted connection to a single VPN address. Volume, timing and the fact that a VPN is in use remain visible; tracker hostnames, peer addresses and file names do not. That is a real improvement, and a narrower one than the marketing suggests. The operator of the tunnel sits in the middle and sees more than the access network does.

A no-logs statement describes retention policy rather than technical visibility. Those are different claims, and only the first is something a provider can promise.

The Leak Comes From the Binding, Not the Tunnel

BitTorrent makes a stream of short-lived TCP and UDP connections to peers, trackers, DHT nodes and local discovery. Bind the client to the physical adapter, or restart it once the tunnel has dropped, and the resulting traffic is precisely what the tunnel existed to conceal. Firewall rules are a weaker control than they appear: a rule matching only the default route, only IPv4, or only new connections leaves paths open. Binding the client to the tunnel interface and verifying that binding is the stronger pattern.

Verify by stopping the tunnel on purpose and watching whether transfers halt. If they continue, the client was never inside. Repeat after a client restart and after a laptop wake, since those are when bindings are usually lost.

DNS Names the Site Without Touching the Transfer

Should name lookups still go to the local resolver, the query itself announces the site while the transfer stays encrypted. Moving resolution into the tunnel, or encrypting it, closes that gap. Neither does anything for a client whose packets are leaving outside the tunnel. Check which resolver is in use and which interface the query leaves from; the two checks answer different questions.

A name that resolves through the tunnel and a transfer that respects the binding are separate properties, and either can fail alone.

The Swarm and the Tracker See Different Things

Address exchange is part of the protocol, so peers record whatever they see. Connecting from the exit gives them the exit; connecting directly gives them the home address. DHT and peer exchange spread that observation further, and a later session without the tunnel can link the same client port and version. The tracker may know more still: a passkey in the announce URL identifies the account regardless of which exit the packets came from.

Encryption covers a different axis again. HTTPS protects a request from the exit onward; plain HTTP exposes the request line to every network along the path, which is why one protocol can be shaped while another is not.

Answer the four questions with evidence, not with an icon. The icon only tells you that a tunnel exists.