Why is Tor so slow? Relays, load, attacks and what to avoid

Why it feels slow, in the Tor Project’s words

The Tor Project’s support page on speed, which carries no date, opens with a short answer. Tor Browser may feel slower than other browsers because traffic is routed through relays around the world, and performance depends on network load, latency and ongoing defenses against attacks. That is three causes in one sentence, and the rest of the page fills in the first two. It says the Tor network has over a million daily users and just over 6000 relays to carry their traffic, and that the load on each server can sometimes cause latency. The page gives no date for these counts, so we report them as the text read on 6 November 2026 and set them against no other count.

The page then says that, by design, your traffic bounces through volunteers’ servers in various parts of the world, and that some bottlenecks and network latency will always be present. The Tor Project’s FAQ, which we read as an archived copy from 2019, makes the same point more bluntly. It says Tor is “never going to be blazing fast” and that you should not expect university-style bandwidth through it. The same FAQ says the network was quite small compared to the number of people trying to use it, and that many of those people did not understand, or did not care, that Tor could not handle file-sharing traffic load at that time.

The support page closes in the other direction. It says Tor is much faster than it used to be and that you may not actually notice any change in speed from other browsers. The pages we read do not say how much slower Tor is than an ordinary browser. The Tor Metrics site has a Performance page, which says it uses two tools, Torperf and OnionPerf, to fetch files of different sizes over Tor and time the download. Its graph shows file sizes of 50 KiB, 1 MiB and 5 MiB, from a public server or an onion server, as a range from the first to the third quartile with the median highlighted. The graph is an image, the text we read held no values, and so we give none.

Three relays, six for onion services

Tails has a page titled “Why is Tor slow?” that starts with the circuit; our page on onion routing explains the three-relay circuit itself. Tor provides anonymity by building circuits with three relays, it says. So instead of connecting directly to the destination server, a connection is made between each relay of the circuit, and this takes more time. It adds that Tor tries to build circuits with relays in different countries, which makes the connection travel more and appear slower. The page carries no date.

Whonix, a separate project, has a wiki page with the same title and almost the same wording. Its license note names Amnesia as a copyright holder of the page alongside Encrypted Support LLC, so the two read as one explanation more than as two. Whonix adds two things. For ordinary sites it describes the three-relay circuit as a way of building anonymity, and for onion services it says a six-relay arrangement is used, with three relays picked by the user and three picked by the onion service. It also says that building circuits from relays in different geographical locations necessarily makes connections travel further and slows down the fetching of resources. We read the copy of the Whonix page whose license line gives the years 2014 to 2025. Our page on onion services covers what the address is and how a visit works.

The relays are the second reason both pages give. They are run by volunteers in a decentralized way, so the relays are not of the same quality: some are big and fast, others smaller and slower. As a whole, both pages say, the network could be faster if it had more capacity, and you can add capacity by running a relay yourself or by helping existing relays. A footnote on the Whonix page adds a caution drawn from economics: increased supply will lead to more users arriving to fill the void. That is Whonix’s footnote and not a measurement.

Where the circuit starts matters too. The Tor Project’s support page on managing identities says the first node, the guard or entry node, is selected automatically and randomly, and that it changes only after 2 to 3 months, unlike the other nodes, which change with every new domain. A 2018 post by mikeperry on the Tor Project’s blog says that when you have a good path through the network, Tor performs very well, but that choosing an overloaded guard node or a bad circuit can make performance poor. Our page on exit nodes covers the last relay in the circuit.

Load, misuse and attacks

Tails and Whonix both have a section on misuse. Some people misuse the Tor network, sometimes on purpose and sometimes through lack of knowledge. Tor is sometimes used to conduct DDoS attacks, they say, and by doing this the Tor relays are the ones that suffer from the attack instead of the intended target. They also say that some people use peer-to-peer software through Tor, which is bad for the network. Whonix goes further: it says peer-to-peer software such as BitTorrent slows down the network for all users, and a footnote says a large file downloaded through BitTorrent can translate to several hours of browsing for a regular Tor Browser user.

The Tor Project’s own pages say the same about torrents, with a second reason. Its support page on torrents says using torrent clients over Tor is unsafe and not recommended, because most torrent clients reveal your real IP address to peers, and because the traffic puts unnecessary load, and potential legal issues, on volunteer exit relay operators. A support page on staying anonymous says torrent applications have been observed to make direct connections even when told to use Tor, and that doing so slows down the entire Tor network for everyone else. A 2009 post on the Tor Project’s blog already counted a handful of users overloading the network as one of the causes of slowness.

Attacks are a separate cause, and the one with the most recent date. On 7 February 2023 a post by isabela on the Tor Project’s blog, about why Tor was slow at that moment, said that for at least 7 months several different types of ongoing denial of service attacks had affected the Tor network. At some points the attacks were severe enough that users could not load pages or access onion services. The post says the methods and targets of the attacks had changed over time, and that it is not possible to determine with certainty who is conducting them or what they intend. It also says the project was adding two members to its Network team to work on onion services development.

The support page on speed points readers to that post and says the project has introduced a Proof-of-Work Defense for onion services to help mitigate some of these attacks. We did not read the page on that defense. Whonix also links to the 2023 post, as the first factor in its list. The pages we read do not say whether attacks are the main cause of slowness today, and they do not give a date when the attacks ended.

The research view, 2009 to 2023

The Tor Project’s own explanations change with the year, and we set them out as a sequence without saying which one is right now. On 13 March 2009 a post signed arma said the reasons the network is slow had been written up, with what could be done about each. Part of it, the post says, comes down to design flaws, some of it is that a handful of users are overloading the network, and there is simply not enough capacity to go around. It names six categories of problems and links a PDF with the detail, described in a later edit as a 25-page document. We did not read the PDF, so we cannot list the six.

Whonix gives a list of its own, in a table headed “Tor Throughput Factors”, and credits it to research by Roger Dingledine and Steven Murdoch. The factors are the overhead of downloading directory information for users on low bandwidth, excessive load from some users, the way Tor’s congestion control mixes bulk and browsing traffic, inefficient handling of connection failures and variable latency, a path selection that does not spread load well, and a total capacity it calls insufficient for the demand. One of its footnotes cites the 2009 PDF, and another says the research is dated, so some of these issues may have been fully or partly mitigated by now.

The 2018 post on open research topics, signed mikeperry and dated 23 July 2018, takes a different line on capacity. It says Tor’s network performance is one of the largest barriers to its adoption. Adding more relays will raise average-case performance, it says, but will not solve the core problem, which is performance variance. Even with lots of added capacity, variance would stay very high. The bulk of the variance, the post says, comes from two classes of solvable problems: a lack of congestion control, with related fairness issues, and load balancing. It adds that fixed flow-control window sizes put an upper bound on the throughput of client traffic.

On 4 May 2022 another post signed mikeperry announced Tor 0.4.7.7, the first stable release with support for congestion control. It explains that Tor had no end-to-end congestion control and instead used a fixed window of 1000 cells of 512 bytes on a circuit. In the early days, it says, windows that large caused long delays, with users waiting up to a minute for a page to load. Around 2015, once spare network capacity had grown, the fixed window became a speed limit, and lower-latency circuits had higher throughput than high-latency ones. Congestion control, the post says, will remove that limit and cut latency by shortening queues at relays.

The 2022 post also says users see the benefit only when the exit relay or onion service they use has upgraded to the 0.4.7 series, and that Tor Browser Stable with congestion control was expected on 31 May 2022. We did not check whether that release followed. The post says the network was roughly 25% utilized, so throughput might be very high at first for the few users on fast circuits. Its evidence is a simulation: in the Shadow Simulator, with clients placed in Germany and Hong Kong, the post says the speed limit of the 0.4.6 series was clearly gone. The pages we read do not say how much faster Tor became in practice.

What helps, and what the Tor Project says to avoid

The support page names one way to improve the speed of the network itself: run your own relay, or encourage others to do so. The support page puts it as a way to help improve the speed of the network. For a single page that will not load, the support page on managing identities describes the “New Tor circuit for this site” option. It says the option is useful if the exit relay you are using is unable to connect to the website you require, or is not loading it properly. Selecting it reloads the active tab over a new circuit, and the other open tabs from the same site use the new circuit once they are reloaded. It does not clear any private information or unlink your activity. The page does not describe the option as a speed fix, and it does not say how often to use it.

A separate support page says how long a circuit is kept. Tor reuses the same circuit for new TCP streams for 10 minutes as long as the circuit is working fine, and if the circuit fails Tor switches to a new one immediately. A single long-lived stream stays on its circuit, the page says, because rotating streams would give an attacker with a partial view of the network many chances to link you to your destination. The 2022 post adds that users of Tor 0.4.7 and above get faster performance when they use exits or onion services that have upgraded. The support page on speed does not tell readers to update.

Whonix gives a view for its own users. It says that any sudden drop in network speed is almost certainly related to a misconfiguration around a VPN or proxy, to anomalies in the Tor network, or to entry guards that are malicious, overloaded, under attack or misconfigured. It describes a test with a second Whonix-Gateway that has a different set of guards, and strongly discourages using that test setup for anything but testing, because adversaries might try to induce a user to switch guards.

The Tor Project’s pages advise against four things a reader chasing speed might be tempted to try; none of those pages presents them as speed advice, and only the torrent text mentions slowing the network. On a VPN, its support page says that in practice combining it with Tor can reduce anonymity or break Tor’s protections if not configured correctly, and that it generally does not recommend it unless you are an advanced user; our page on Tor or a VPN sets out the longer comparison. On add-ons, it says Tor Browser includes NoScript, that installing other plugins or add-ons is strongly discouraged because they can harm your privacy, weaken security and make you easier to track, and that the Tor Project does not give support for those setups. On torrents, see the section on load and misuse above. On choosing relays by hand, the 2019 FAQ explains the EntryNodes and ExitNodes settings in the torrc file and then says “We recommend you do not use these.” It says you get the best security Tor can provide when you leave route selection to Tor. For readers on networks that block Tor, our page on bridges and censorship is the place to go.

What we could not read

Each statement on this page is traced to the sources listed below, and the quotations were matched word for word against them. We did not open community threads, guides from companies that sell VPNs or Quora answers, and the statements here are traced only to the sources listed below. We did not read the 2009 PDF, the page on the Proof-of-Work Defense or Tails’ page on managing the circuits of Tor, and the values behind the Tor Metrics graph are not in the text we read. The FAQ copy is the archived 2019 version, and each date is given where we use it.

The sources also differ on what is old and what is new. The Tor Project’s support page, the Tails page and the Whonix page carry no date for their statements apart from the Whonix license line. Tails is described in its own footer as made by the Tor Project, but it is a separate site, and Whonix is a separate project too. We therefore name the page behind each claim.