Pluggable transports and bridges

Summary

A bridge is a Tor relay whose address is not listed in the public relay directory. It supplies an alternative entry point when known Tor relays are blocked. A pluggable transport changes how the connection to Tor looks on the network, making protocol-based detection harder. An unlisted address alone does not provide that disguise.

The Tor Browser manual leads to the current unblocking guide, which documents obfs4, meek, Snowflake and WebTunnel. They address different blocking conditions; none is a universal answer.

How it works

The transport carries the connection into Tor while Tor provides the onward circuit. The relay guide distinguishes a bridge at the entry from an exit relay connecting to the destination.

The Snowflake project explains its WebRTC design. The WebTunnel operator guide documents the website, certificate and reverse-proxy setup. Looking like a common protocol raises the difficulty of selective blocking; it does not prevent a censor blocking the endpoint or the surrounding service.

Conjure is experimental here. Tor's Conjure testing announcement describes refraction networking: participating network infrastructure turns otherwise unused IP addresses into proxy endpoints. A later Tor developer response says the bridge is for testing and expected to fail. Treat it as research to follow, not a fallback to promise to people who need access.

Getting and using bridges

1. Install Tor Browser while you can reach the official download channel. In its connection settings, try a built-in transport appropriate to your network.
2. If you need additional bridges, request them inside Tor Browser or through Tor's bridge distributor. The getting-bridges guide lists the supported distribution methods.
3. Copy the complete bridge line, not just the IP address, into the bridge settings. Follow the desktop or Android instructions for your client.
4. If it fails, try another bridge or transport. Preserve a working configuration privately and keep an alternative; avoid publishing the bridge details you depend on.

For ordinary browsing precautions after connecting, continue with Using Tor Safely.

Trust model / threat model

Bridges change the entry to the Tor circuit. They are not exits and do not replace the rest of Tor's design. Their address is absent from the public relay directory, not guaranteed secret from anyone who receives or discovers it. Tor's own relay guide documents that bridges can be detected and blocked.

Transport disguise should not be read as a guarantee that Tor use is undetectable. Choose based on the connection you can actually establish. A VPN such as WireGuard or a proxy such as Outline has a different trust model from a Tor circuit; transport encryption alone does not make them interchangeable.

Readiness

Usable for the transports documented in Tor Browser. obfs4, Snowflake, meek and WebTunnel have user-facing connection instructions. Which one works depends on local filtering. Conjure is described separately because its documented testing status is a different readiness level.

Limits

• An unpublished bridge can be learned and blocked. Transport disguise does not solve every form of address blocking.
• Bridges and transports can slow connections. Reachability and performance need local testing, with attention to the risks of measurement described in OONI.
• The Snowflake browser extension helps other people connect. To use Snowflake for your own access, select it in a supported Tor application; installing the extension does not unblock your own browsing.
• These are internet transports. Pair them with shutdown preparedness for loss of connectivity and with the server guide if you want to contribute capacity.

Primary sources

• Tor Browser manual: circumvention and current unblocking guide.
• Getting bridges, using bridges and bridge distribution.
• Types of Tor relays.
• Snowflake and WebTunnel setup.
• Conjure testing announcement and developer guidance on experimental status.

Also in Anonymity Networks