The instinct that more layers means more anonymity - route a VPN into Tor, chain a second VPN, add hops - misunderstands what Tor actually defends against. Tor is strong against an observer who sees only part of your path and useless against one who can watch both ends at once, and no amount of extra encryption changes that, because the attack does not read your traffic. It matches its shape. This is the one weakness Tor's own designers state plainly, and it is worth understanding before you trust any onion-routed or multi-hop setup.
//What Tor Actually Promises
Tor routes your traffic through three relays - a guard, a middle, and an exit - with a separate layer of encryption for each hop, so no single relay knows both who you are and where you are going. Against a local or partial observer, that works: your ISP sees an encrypted connection to a guard and cannot tell where it leads; the site sees a connection from an exit and cannot tell where it came from. That is the threat Tor is built for, and it defeats it well.
The Tor Project states the limit just as plainly: the design does not protect against a global passive adversary who can watch traffic going into and out of the network and correlate the two sides. That is not a bug to be patched; it is a known, accepted boundary of the low-latency design.
//Why Encryption Does Not Help Here
A correlation (or confirmation) attack does not try to decrypt anything. It compares the timing and volume of traffic entering the network near you with the timing and volume leaving it near the destination. Those patterns - the rhythm of requests, the sizes of bursts - pass through all three encryption layers unchanged, because encryption hides content, not shape. An adversary positioned at both ends lines up the two streams and matches them. The academic work makes the point bluntly: the RAPTOR analysis (USENIX Security 2015) showed this timing correlation works even when the communication is encrypted, needing to see only one direction of traffic at each end, and reported very high accuracy in controlled experiments.
//The Myth of the Rotating Path
A common belief is that Tor makes you a moving target by rebuilding your whole path every ten minutes. It does not. Tor reuses a circuit for new streams for about ten minutes (the MaxCircuitDirtiness default of 600 seconds), and a long-lived stream stays on its circuit the whole time - but only the middle and exit rotate. Your entry guard is deliberately kept for months. The guard design exists precisely because rotating the first hop would be worse: the more different guards you use over time, the more chances an attacker who runs guards has to eventually become yours. A small, stable guard set is the defence, not a weakness. So the first hop - the one closest to you - is the opposite of a moving target, by design.
//Why a VPN Does Not Rescue It
Adding a VPN in front of Tor is the usual proposed fix, and against the both-ends attack it does nothing. It changes who sees the entry side: your ISP no longer sees that you use Tor, and the guard sees the VPN's address instead of yours. But the VPN provider now sees both your real IP and that you are using Tor - you have relocated that trust, the same pattern as in what a VPN actually hides - and an adversary watching both ends still correlates the timing regardless of whether a VPN sits in the chain. The Tor Project does not recommend combining the two unless you understand exactly what each is doing, because a careless setup more often reduces anonymity than adds it. More hops are the same story: an adversary already at both ends does not care how many encrypted relays sit between them.
//So What Does Help?
Not more layers. What actually resists traffic correlation is higher-latency, batching, or cover-traffic designs - mix networks that deliberately reorder and delay messages so the timing fingerprint no longer lines up - which is a fundamentally different trade-off from Tor's low-latency browsing. For most people the honest takeaway is narrower and more useful: Tor is excellent against the partial observers that make up almost every real threat, it is not magic against a global-scale timing adversary, and stacking VPNs on top buys reassurance rather than protection. Know which adversary you are actually facing - the same lesson as the threat-model picker.
//Sourcing and Framing
The both-ends / global-passive-adversary limitation and the "correlating the information on both sides" wording are from the Tor Project's own writing and the original Tor design paper. The timing-correlation-survives-encryption result and the one-direction-per-end detail are from the RAPTOR paper (Sun et al., USENIX Security 2015); its accuracy figures come from controlled experiments and are cited as demonstrated feasibility, not real-world base rates. The circuit-rotation behaviour (MaxCircuitDirtiness ~600s for new streams, long streams pinned) is from Tor's support documentation, and the stable-guard design and its rationale are from Tor's guard specification and proposals - with the caveat that the exact guard count and lifetime are version-dependent (a small set, lifetimes measured in months). The VPN stance is the Tor Project's FAQ. The interpretation is the site's recurring one: layering relocates or hides who sees you, it does not defeat an adversary who already sees both ends.