How Tor Enters a Network That Blocks Tor
A client tries to connect to a public Tor relay. The censor reads the same public directory and blocks that IP address.
The client switches to a bridge whose address does not appear in the complete public list. The connection starts. The censor did not know the IP address, but recognizes the characteristics of Tor traffic and blocks that too.
The client then adds a pluggable transport to the link to the bridge. The observable traffic changes shape; the server-side pluggable transport (PT) component later removes the transformation and delivers the flow to the bridge’s Tor process.
This escalation separates the two tools:
public relay → IP blocked → bridge → traffic recognized → pluggable transport
Layered encryption cannot solve the first block. If the client cannot reach the first relay, the circuit does not yet exist.
First: What the Censor Can Do
Here, a network censor means an actor that can observe or block connections between the client and the Internet. We do not automatically grant it global visibility or control of Tor relays.
The censor can use addresses, blocking the IP addresses of public relays, or traffic characteristics, trying to recognize the protocol even at an unknown IP address. Hiding an address and changing the appearance of traffic are separate problems.
The Consensus Cannot Hide Public Relays
The consensus is the signed map through which clients learn which public relays are available. A relay is a server participating in the Tor network. The guard is the first relay in an ordinary circuit and directly receives the client’s connection.
The public nature of the consensus is not an accidental mistake. The client must be able to verify the map and choose paths without relying on a central server to assign its route.
But a guard listed in the public directory can also be enumerated. When blocking uses that list, Tor needs an entry point distributed in a different way.
A Bridge Is a Less Enumerable First Hop
A bridge is a Tor relay used as an entry point, but its coordinates are not distributed as part of the complete relay list in the public consensus.
The client obtains the bridge address through a separate mechanism. The intended invariant is that the censor cannot immediately derive the complete set of bridges by reading the public directory.
This does not make the bridge invisible. A censor can discover individual addresses, obtain them through distribution channels, or identify them in other ways. The goal is to make complete, immediate enumeration harder—not to guarantee eternal secrecy.
The Bridge Takes the Public Guard’s Place
When Tor is configured to use bridges—the option is called UseBridges—the configured bridges replace public guards as candidates for the entry position. Tor separately retains the state of bridges already sampled and confirmed instead of choosing a new one for every circuit. The chosen bridge thus becomes the first hop and performs the role of a normal public entry guard.
It does not replace the directory authorities that sign the consensus. It does not replace the middle. It does not replace the exit of an Internet-bound circuit or the rendezvous point of an onion circuit.
It changes the entry.
From the bridge onward, the client extends the circuit toward the other relays using normal telescoping construction: it negotiates the first segment, then adds one relay at a time without opening direct connections to more distant hops.
An Unknown IP Address Can Still Carry Recognizable Traffic
Suppose the censor does not yet know the bridge’s address. It can still observe the connection between client and bridge and try to classify it.
If the link exposes recognizable characteristics and the censor decides to block them, having an address outside the public list is not enough.
This is where the pluggable transport enters. It is a modular component that changes how traffic is carried between client and bridge. Two compatible helpers, one on the client side and one on the bridge side, transform the first link and then deliver the flow to the Tor protocol.
The transport is not a new circuit. It is a wrapper or transformation of the entry link.
The Transport Ends on the Bridge’s Server Side
The geometry is the most important part.
The pluggable transport covers the client-to-bridge segment. The server-side PT component removes the transformation and forwards the flow to the bridge’s Tor entry interface, called the ORPort or Extended ORPort. From there, the normal Tor protocol continues.
The middle, exit, rendezvous point, relay cells, and per-hop transformations are not replaced by the transport. Drawing it around the entire circuit would suggest a second end-to-end anonymity system that does not exist.
Bridges and transports also answer different questions:
- the bridge tries to avoid blocking based on enumerating public relays;
- the transport tries to change observable characteristics of the first link;
- the Tor circuit separates origin and destination through successive relays.
These functions can work together, but they are not synonyms.
The Censor Can Adapt
The specification defines a modular interface. The ability to evade recognition, however, depends on the transport and the specific adversary.
A censor can adapt: discover a bridge, recognize a transformation, or interfere with the channel used to obtain new coordinates.
When one of these conditions changes, the client may need another bridge or entry mechanism. Censorship resistance is therefore a dynamic contest among distribution, observation, and blocking.
After Entry, Tor Remains Tor
The bridge adds no magical anonymity to the path, and the transport does not automatically encrypt every subsequent layer. Their job is to make the first connection possible when ordinary entry is blocked.
Once that link is available, the verified directory, path selection, telescoping construction, circuits, cells, and streams all return.
The point is not to circumvent censorship instead of Tor. It is to reach Tor so that Tor can begin to work.
Technical Sources
Tor Specifications: Glossary (“bridge”); Server descriptor purposes (bridge purpose and UseBridges); Guard state instances (separate bridge state); Pluggable Transport — Introduction (helpers and interface); PT configuration environment (ORPort and Extended ORPort); Extended ORPort (handoff from the PT to the bridge’s Tor process). Tor Project: Design of a blocking-resistant anonymity system (IP blocking and bridge distribution). Consulted August 14, 2026; effectiveness depends on the specific adversary.