Three Relays, but Not Three Random Relays

The Starting Point Is Not the Entire Internet

In the previous part of the series, the client obtained and verified the consensus: the signed map of the network jointly produced by the directory authorities. It also has the microdescriptors referenced by the consensus. Together, these documents provide a current list of relays and the information needed to evaluate them, including identities, flags, policies, parameters, and weights. A flag is a consensus label that indicates a relay’s eligibility or restriction.

That map does not contain a path assigned to the user. It contains candidates and rules. The client applies that information locally when it needs to build a new circuit.

A path, at this stage, is only an ordered sequence of relays selected in the client’s memory. No new connection to the selected relays has been opened yet.

When a New Circuit Is Needed, the Exit Must Be Compatible

A request does not always require a new circuit. Tor can attach the stream to an already open, compatible circuit, or use a circuit built in advance based on recently requested ports. When it must build a new one for pending or anticipated requests, it first chooses an exit capable of supporting them.

To leave the Tor network, the last relay must be willing to open the requested connection. Every potential exit publishes an exit policy: a set of rules that accepts or rejects combinations of addresses and ports.

Our example needs port 443, normally used by HTTPS. The client must therefore discard relays that cannot support that request. If it already has the destination’s IP address, it can compare the address and port with the policy. If it still has only the site’s name, it can choose an exit likely to support that port; name resolution will happen later.

The destination therefore imposes a constraint on the last position. If we chose the other relays first, we might reach the end and discover that no compatible exit completes that path. Tor starts with the component that has the most specific requirement.

The client does not necessarily choose the relay with the most bandwidth, nor does it draw every candidate with equal probability. It uses weighted random selection. Measured transport capacity and the coefficients published in the consensus—the bandwidth weights—change the probability of selection for that position.

The weight is not a vote of trust. It distributes traffic in a way that reflects capacity and the relative availability of the different roles.

The Guard Is Not Forgotten After Every Circuit

The guard occupies the first position and, in the standard model without bridges, is the only relay to which the client connects directly.

For precisely this reason, Tor does not treat the guard as a new independent draw from the whole network for every request. The client maintains a set of guards sampled from relays carrying the Guard flag, the label that makes them entry candidates. It applies bandwidth and weights, then keeps a small preferred group within this set: the primary guards. Whenever possible, it builds new circuits using one of these previously selected and still usable entries.

If a primary guard is unreachable or no longer eligible, the client can try another. This does not mean “one guard forever.” It means avoiding needless rotation for every new circuit.

The reason is structural: every new entry relay directly receives a connection from the client. Reducing guard churn limits how often the client exposes this relationship to new entries.

The Middle Must Be Compatible with the Other Two

The middle position remains. It too is chosen using weighted probabilities, but drawing any relay from the list is not enough.

For most standard paths, the client avoids using the same relay twice. It also applies constraints to avoid combining relays that declare themselves part of the same family, for example because the same operator manages them. It also avoids choosing multiple relays within the same network prefix—that is, within groups of IP addresses considered too close under the applicable rule.

These checks reduce clearly unfavorable paths. They do not prove that operators or infrastructure are truly independent: the client can apply only the available information and rules.

At this point the path is complete:

chosen guard → chosen middle → chosen exit

But the order in which the client made the decisions was:

exit → guard → middle

For now, the path exists only in the client. The exit was not contacted first. It has not been contacted at all.

Construction Starts with the Guard

To turn the chosen sequence into a circuit, the client must reach the first relay. It opens, or reuses, a channel to the guard.

A channel is an authenticated connection between two adjacent participants in the Tor network, typically protected by Transport Layer Security (TLS). Channel TLS protects that single link between neighbors. It is not the same as HTTPS between browser and site, and it does not replace the keys the client will establish with each relay in the circuit.

Over the channel, the client sends the guard a CREATE2 message. Guard and client complete a handshake: an exchange from which both derive the cryptographic material needed for the two directions of that segment. A position traversed at a relay is called a hop.

There is now a one-hop circuit:

client ⇄ guard

The Client Reaches the Middle Through the Guard

The client does not open a direct connection to the middle. Instead, it sends an EXTEND2 message through the partially built circuit.

The message tells the guard which relay should become the new endpoint. The guard opens, or reuses, a channel to that middle and forwards the creation request. The new handshake passes through the guard but establishes cryptographic material between the client and the middle.

The result is a two-hop circuit:

client ⇄ guard ⇄ middle

The guard must know the adjacent relay to which it should forward the extension. This does not give it a copy of the entire future path.

The Same Mechanism Adds the Exit

For the third hop, the client sends another EXTEND2. This time the message crosses the guard and middle. The middle, now the endpoint of the partial circuit, opens or reuses a channel to the exit and forwards the request.

The client thus completes a third, separate handshake:

client ⇄ guard ⇄ middle ⇄ exit

The circuit has grown one hop at a time. This property is called telescoping construction.

“Telescoping” does not mean that the client opens three direct network connections. The client’s direct connection ends at the guard. Subsequent links exist between adjacent relays; the circuit handshakes, however, let the client obtain distinct cryptographic material with the guard, middle, and exit.

Layered encryption will be applied using these already established relationships. Before the onion, then, there are three separate steps:

1. the consensus provides the candidates;
2. the client locally chooses a complete path;
3. the client builds that path from the first hop to the last.

Not Every Circuit Has an Exit to the Internet

So far we have followed a circuit for a normal website. Tor also builds internal circuits: the last relay remains inside the Tor network and need not provide an exit to the Internet. Onion services use internal circuits, but not every internal circuit serves an onion service; purpose, length, and constraints can vary.

One rule remains common: the client first decides which path satisfies the purpose, then builds it through adjacent relays.

The phrase “Tor chooses three random relays” therefore loses precision. Randomness operates within filtered pools, with weighted probabilities, persistent guard state, and constraints between relays. Construction instead follows the already chosen path and extends it from the guard to the last hop.

The circuit now exists. The next question is no longer which relays compose it, but what actually crosses those links when the browser opens one or more streams—that is, logical application flows.