# Why Tor Chooses Random Paths: Speed, Guards and the Cost of a “Fastest Route”

> Tor draws relays at random, weighted by bandwidth, and keeps a few long-lived guards. Why picking the fastest route can reveal where a user is, from the research.

FireAI Security & Research Team (HisnLabs) · Published 2026-10-08
Canonical: https://hisnlabs.com/en/blog/tor-path-selection-speed-anonymity

Tor is often described as slow, and a natural idea is to make it choose the fastest relays, as a satellite navigation app chooses the fastest road. This note explains, from the Tor specifications, the Tor Project’s own account of congestion control and the research literature on relay selection from 2007 to 2013, why Tor’s path choice is random by design, which part of Tor’s slowness was actually removed in 2022, and why a path chosen for speed can tell an observer something about where its user is. The central point is that in an anonymity network, a predictable choice is itself information.

## Background

A Tor circuit passes through three relays: a guard, which is the only relay that sees the user’s IP address, a middle relay, and an exit, which makes the connection to the destination. The rules for choosing them are public. The path specification states: “For all circuits, we weight node selection according to router bandwidth.” It adds constraints that separate the relays of one path: “We do not choose the same router twice for the same path”, “We do not choose any router in the same family as another in the same path”, and “We do not choose more than one router in a given network range, which defaults to /16 for IPv4 and /32 for IPv6” [[1]](https://spec.torproject.org/path-spec/path-selection-constraints.html). Within those rules the choice is a random draw, with faster relays drawn more often in proportion to their bandwidth, not a search for the single best path.

## Findings

### Guards: a few entry relays, kept for a long time

The guard specification gives the reason for keeping the first hop stable. “If users chose their entries and exits uniformly at random from the list of servers every time they build a circuit, then an adversary who had (k/N) of the network would deanonymize F=(k/N)^2 of all circuits… and after a given user had built C circuits, the attacker would see them at least once with probability 1-(1-F)^C. With large C, the attacker would get a sample of every user’s traffic with probability 1.” Hence: “Tor clients choose a small number of guard nodes (e.g. 3). These guard nodes are the only nodes that the client will connect to directly. If they are not compromised, the user’s paths are not compromised” [[2]](https://spec.torproject.org/guard-spec/index.html). Changing guards often, for instance to chase a faster one, works against this rule: every new guard is a new chance to pick one that an adversary runs.

### Tor already discards its slowest circuits

Tor does not ignore speed. “Since version 0.2.2.8-alpha, Tor clients attempt to learn when to give up on circuits based on network conditions”: the client models its own circuit build times and sets the timeout at the 0.8 quantile, so that, in the specification’s words, “the Tor client will accept the fastest” 80 per cent “of the total number of paths on the network” [[3]](https://spec.torproject.org/path-spec/learning-timeouts.html). The slowest fifth of paths is abandoned, but the choice among the rest stays random.

### Much of the old speed limit was congestion control, fixed in 2022

Tor Proposal 324, created on 2 July 2020, located a major cause of slowness outside path selection: “Lack of congestion control is the reason why Tor has an inherent speed limit of about 500KB/sec for downloads and uploads via Exits, and even slower for onion services” [[4]](https://spec.torproject.org/proposals/324-rtt-congestion-control.html). On 4 May 2022 the Tor Project announced Tor 0.4.7.7, “the first stable Tor release with support for congestion control”, which “will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays”; of its simulations it reported that “the speed limit from 0.4.6 Tor is clearly gone” [[5]](https://blog.torproject.org/congestion-contrl-047/). The improvement came without making paths less random. The proposal also records its own cost: “Vastly reduced queue delay and predictable amounts of congestion on the Tor network may make certain forms of traffic analysis easier”, and stable round-trip times “may make geographical inference attacks easier” [[4]](https://spec.torproject.org/proposals/324-rtt-congestion-control.html).

### Selecting for performance concentrates traffic

Wacek, Tan, Bauer and Sherr, at NDSS 2013, compared relay selection strategies proposed in the literature on models of the live Tor network, measuring performance and the Shannon entropy and Gini coefficient of the relays chosen in the entry and exit positions [[6]](https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/empirical-evaluation-relay-selection-tor/). They found “a strong correlation between better performance and a more selective relay selection strategy, confirming that within the context of anonymity systems, performance is a commodity that requires a trade-off with anonymity.” In their simulation the entropy of Tor’s default bandwidth-weighted selection was 7.68, against 9.65 for uniformly random selection and 5.95 for the most performance-biased Snader-Borisov setting. Not every speed-up costs the same: the congestion-aware strategy “impressively shows high performance while giving up less anonymity than Tor”, and the authors concluded that it “has little anonymity impact” [[6]](https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/empirical-evaluation-relay-selection-tor/).

### Location-aware routing ties the path to the user’s place

LASTor, presented at the IEEE Symposium on Security and Privacy in 2012, chooses relays by their inferred geographic location to cut latency, and reports a 25 per cent lower median latency than the default client. Its authors state the cost directly: “the preference for low latency paths reduces the entropy of path selection”, which is why they made the trade-off tunable [[7]](https://www.freehaven.net/anonbib/cache/oakland2012-lastor.pdf). Two of its design points show how location leaks into the path. Paths close to the straight line between client and destination are preferred, so “if an adversary wishes to ensure that a relay under his control is on the chosen path between S and D, then the adversary can choose a location that is close to the direct line between S and D and setup a large number of relays at that location.” And LASTor picks its entry guards from relay clusters ordered “based on their distance from the client” [[7]](https://www.freehaven.net/anonbib/cache/oakland2012-lastor.pdf), so a guard set chosen this way depends, by construction, on where the client is.

### Latency itself is a location signal

Timing alone already reveals something. Hopper, Vasserman and Chan-Tin describe an attack that “allows a malicious website to gain several bits of information about a client each time he visits the site”; in their survey of nearly 14 000 servers, the round-trip time between an unknown host and a random Internet host “yields roughly 3.5 bits of information about the network location of the unknown host” [[8]](https://www.freehaven.net/anonbib/cache/tissec-latency-leak.pdf). Geddes, Jansen and Hopper, at PETS 2013, studied performance changes to Tor and showed that a new class of induced throttling attacks “can drastically reduce the set of probable entry guards on a circuit, in many cases uniquely identifying the entry guard” [[9]](https://www.robgjansen.com/publications/howlow-pets2013.pdf). A routing rule that makes paths faster by making them more regular, or more dependent on distance, gives such measurements more to work with.

| Approach | What it changes | Anonymity cost reported | Source |
| --- | --- | --- | --- |
| Bandwidth-weighted random draw (Tor’s default) | Faster relays drawn more often | Entropy 7.68 against 9.65 for uniform selection, in simulation | path-spec; Wacek et al. |
| Circuit build timeout | Slowest paths abandoned at the 0.8 quantile | Not separately quantified in the sources | path-spec |
| Congestion control (Tor 0.4.7) | Removes the per-stream speed limit | May ease traffic analysis and geographical inference | Proposal 324; Tor blog |
| Congestion-aware selection | Avoids congested circuits | “Little anonymity impact” in emulation | Wacek et al. |
| Location-aware selection (LASTor) | Paths and guards chosen by geography | Lower entropy; guards depend on the client’s location | Akhoondi et al. |
| Strongly performance-biased selection | Traffic concentrated on the fastest relays | Entropy 5.95, the lowest measured | Wacek et al. |

*Ways to make Tor faster, and what each one costs*

> TorAi’s Fast routes keep Tor’s own guard and Tor’s weighted random draw, with no location term, and only make relays that were slow for you less likely. It is off by default. [Download FireAI for Mac](https://hisnlabs.com/fireai/en/download)

## Implications for Mac users

For someone using Tor on a Mac, three consequences follow. First, slowness on a particular circuit is often the luck of the draw, and the remedy built into Tor is a new circuit, not a smarter choice. Second, most of the structural speed limit was removed by congestion control in 2022 without touching path randomness, so the remaining gains from cleverer path selection are smaller than the idea suggests. Third, any tool that promises a “fastest route” should be asked what it uses to rank paths: a rule that depends on geography, on the destination or on a stable set of preferred relays makes its users’ paths both more predictable and different from everyone else’s, which is the opposite of what an anonymity network needs.

## Recommendations

1. Keep your tor client current; congestion control arrived in Tor 0.4.7, released in May 2022.
2. When one circuit is slow, request a new circuit rather than changing settings that narrow relay choice.
3. Do not pin exit or entry relays, or restrict countries, for speed; every restriction shrinks the set of paths you can take.
4. Treat any “fastest route” feature as a trade-off and read what it ranks paths by; avoid ones that use geography or a fixed list of favoured relays.
5. Leave guard selection to tor; frequent guard changes increase the chance of meeting a hostile one.
6. Expect large downloads and video to remain slower over Tor than over a direct connection.

## Relevance to TorAi

TorAi is a HisnLabs app for macOS; version 0.1.1 is available. It has an optional setting, Fast routes, off by default, described in the app as “Paths stay close to Tor’s own choice, but slightly less random.” What it does: TorAi plans circuits itself, within tor’s path rules (families, the /16 rule, relay flags, the user’s country settings), always through the guard tor chose, and with tor’s own bandwidth-weighted random draw. The only change is that relays that were measured slow or failing on this Mac are drawn less often; nothing is ever given a bonus, and the draw never simply takes the cheapest path. An earlier design priced paths by geographic distance; it was removed before release for the reason given above, that it would let an observer who knows the rule narrow down where the user is. A test in TorAi’s code fails if, over 10 000 simulated plans, the entropy of the middle or exit relays falls below 95 per cent of tor’s own. With Fast routes on, an option called Live traffic moves new connections to a fresh route through the same guard when a relay stays jammed for 3 seconds. TorAi’s timing results are reported plainly on its page: Fast routes are “not measurably faster yet in our tests”. What it does not do: it does not choose or change guards, it does not use the user’s or the destination’s location, it is turned off by the Safer and Safest security levels, and it does not measure how distinguishable a Fast-routes user is to an observer who knows the rule over time, which remains an open question. Live traffic also changes circuits more often than tor would. Details are on the [TorAi page](https://hisnlabs.com/torai/en).

> TorAi 0.1.1 routes the Mac apps you choose through Tor, each on its own circuit, and leaves path choice to tor unless you turn Fast routes on. 17-day free demo. [Download FireAI for Mac](https://hisnlabs.com/fireai/en/download)

> **Note:** TorAi is not affiliated with or endorsed by The Tor Project. Tor is a trademark of The Tor Project, Inc.

## Limitations

The studies cited were run on simulated or emulated networks, or on earlier versions of Tor (Wacek et al. used tor 0.2.2.33 and models of 50 and 1 524 relays), and their figures should not be read as measurements of today’s network. Entropy and the Gini coefficient compare strategies; the authors themselves warn that they “should not be taken as direct indicators of the strength of a particular anonymity technique” [[6]](https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/empirical-evaluation-relay-selection-tor/). Proposal 324 leaves open whether its side-channel risks are serious. LASTor was evaluated as a research client, not deployed in Tor. TorAi’s behaviour is described from its release notes and HisnLabs’s own tests, not from an independent audit; its constants were chosen rather than measured, and HisnLabs makes TorAi, which readers should weigh. Further reading: the FireAI University lesson [how Tor works and what it protects](https://hisnlabs.com/en/university/malware-and-the-hidden-internet/how-tor-works-and-what-it-protects), and the posts [what Tor hides and what it does not](https://hisnlabs.com/en/blog/what-tor-hides-and-what-it-does-not) and [Relay Authority](https://hisnlabs.com/en/blog/relay-authority-tor-relay-reputation-score).

## How FireAI and HisnLabs fit in

FireAI does not choose Tor paths; it shows each connection your Mac’s apps make, including connections to Tor guard relays, and lets you decide which ones go through.

FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its FireAI Pilot feature) on real traffic patterns, all without any of it leaving your Mac.

You can read the technical decisions behind it, or try FireAI for 17 days, at [FireAI, by HisnLabs](https://hisnlabs.com/fireai/en/download).

## Sources

- [Tor specifications: path selection constraints (path-spec)](https://spec.torproject.org/path-spec/path-selection-constraints.html)
- [Tor specifications: Tor Guard Specification, introduction and motivation (guard-spec)](https://spec.torproject.org/guard-spec/index.html)
- [Tor specifications: learning when to give up on circuit construction (path-spec)](https://spec.torproject.org/path-spec/learning-timeouts.html)
- [Perry, Tor Proposal 324: RTT-based Congestion Control for Tor, created 2 July 2020](https://spec.torproject.org/proposals/324-rtt-congestion-control.html)
- [The Tor Project blog: Congestion Control Arrives in Tor 0.4.7-stable!, 4 May 2022](https://blog.torproject.org/congestion-contrl-047/)
- [Wacek, Tan, Bauer and Sherr, “An Empirical Evaluation of Relay Selection in Tor”, NDSS 2013](https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/empirical-evaluation-relay-selection-tor/)
- [Akhoondi, Yu and Madhyastha, “LASTor: A Low-Latency AS-Aware Tor Client”, IEEE Symposium on Security and Privacy, May 2012](https://www.freehaven.net/anonbib/cache/oakland2012-lastor.pdf)
- [Hopper, Vasserman and Chan-Tin, “How Much Anonymity does Network Latency Leak?”, ACM Transactions on Information and System Security](https://www.freehaven.net/anonbib/cache/tissec-latency-leak.pdf)
- [Geddes, Jansen and Hopper, “How Low Can You Go: Balancing Performance with Anonymity in Tor”, PETS 2013](https://www.robgjansen.com/publications/howlow-pets2013.pdf)
- [HisnLabs: TorAi product page](https://hisnlabs.com/torai/en)