Tor Bridges: What They Are, and Which Transport to Actually Try First

What a bridge actually is

An ordinary Tor relay is listed in a public directory anyone can download — which is fine for most users, but means a censor can simply block every address on that list. A bridge is a relay deliberately left off the public list, with its address distributed instead through channels like the Tor Project's own bridge site, email, or Telegram, specifically so a censor can't block it by downloading the same directory everyone else uses.^{Tor Project} Using a bridge in combination with a pluggable transport — software that disguises what your connection looks like at the network level — is what actually gets you through a censor that's blocking based on traffic patterns rather than just IP addresses; used alone, a bridge with no transport can still be identified and blocked if the censor is inspecting traffic content rather than only the destination address.

The four pluggable transports, and what each imitates

obfs4

Makes your Tor traffic look like random noise rather than a recognizable protocol, and specifically resists a censor's attempt to find obfs4 bridges by scanning the internet for them. Needs a bridge address to connect to.^{Tor Project}

meek

Disguises your connection as ordinary traffic to a major cloud provider or CDN, so a censor watching for Tor specifically sees what looks like a visit to a large, popular service instead.^{Tor Project}

Snowflake

Routes your connection through volunteer-run proxies in a way designed to resemble a video or voice call rather than a Tor connection, and doesn't require you to obtain a bridge address at all — it works differently from the address-based transports.^{Tor Project}

WebTunnel

The newest of the four, masking your Tor connection so it appears to be an ordinary HTTPS website visit.^{Tor Project} Tor's mobile Tor VPN Beta specifically prioritized adding WebTunnel support because it measurably improved reliability for users in heavily censored regions.^{Tor Project blog, 9 Sept 2026}

All four are implemented by a single program, Lyrebird, bundled with Tor Browser and the Tor Expert Bundle, so you're not installing separate software for each — the choice is which one you configure, not which one you download.^{Tor Project}

An actual decision order, not "try them all"

Tor Project's own official advice is to try obfs4, WebTunnel, Snowflake, or meek and see what works^{Tor Project} — accurate, and not much help if you're offline and want a starting point rather than a menu. A reasonable order, based on what each transport is built for: start with Snowflake, since it requires no bridge address to obtain in the first place and is designed for exactly the situation of a user who can't easily reach the usual channels for getting bridge addresses. If Snowflake is itself blocked or too slow, try obfs4 next, since it's the most mature and widely deployed transport and resists straightforward scanning. If both fail, WebTunnel and meek disguise traffic as ordinary web browsing rather than relying on randomness, which can succeed against censorship specifically targeting "traffic that looks encrypted but unrecognizable" rather than targeting known Tor infrastructure directly. None of this is guaranteed in any specific country — censorship techniques vary by region and change over time, which is exactly why Tor Project won't commit to one universal answer either.

How to actually get bridges in Tor Browser

On first launch, choosing "Configure Connection" rather than "Connect" surfaces Connection Assist, which can automatically select a working transport based on your detected region without you needing to know anything about the options above in advance.^{Tor Project} If you're already running Tor Browser and need to switch, the built-in bridge menu sits under Settings → Connection → Bridges, where you can select any of the four built-in transports directly without leaving the browser.^{Tor Project} If none of the built-in options connect, Tor Project distributes bridge addresses through its own bridges website, by email request, and via a Telegram bot — three independent channels specifically so a censor blocking one doesn't cut off all of them at once.^{Tor Project}

Browser bridges versus editing a config file

Everything above uses Tor Browser's own built-in menus, and that's the right layer for almost every reader of this page. Tor's official documentation on configuring pluggable transports for "little-t tor" — the standalone network daemon, run without the browser at all, via a hand-edited torrc configuration file — is a genuinely different and more technical task, aimed at server operators and advanced users running Tor as a background service rather than someone who just wants Tor Browser to connect.^{Tor Project} If a guide starts by asking you to locate and edit a torrc file, it's answering the daemon question, not the "my browser won't connect" question this page addresses — the built-in Settings → Connection → Bridges menu inside Tor Browser itself is the equivalent, no config file required.

Why bridges slow the connection down

Using a bridge and a pluggable transport together adds real overhead compared to connecting directly to a public relay: obfuscation transports spend extra effort disguising traffic patterns, and Snowflake's proxy-hopping design in particular routes through an additional volunteer machine before ever reaching the Tor network proper.^{Tor Project} That's a real trade-off, not a bug — the entire purpose of a transport is to spend some performance disguising what your connection looks like, and a censored connection that's slower but working beats a fast connection that's blocked outright.

Telling a dead bridge from a blocked one

From the outside, both look identical: the connection simply fails. A bridge can stop working because its operator took it offline, entirely unrelated to censorship — bridges are volunteer-run and come and go. A bridge can also be blocked specifically once a censor identifies its address, which happens more often the longer a specific bridge address has been in circulation and the more widely it's been shared. The practical difference doesn't change what you do next either way: request a fresh bridge rather than troubleshooting the old one indefinitely, since there's no reliable way to diagnose which cause applies from your side of a failed connection, and a bridge that's been blocked will not come back by retrying it.

Why nothing here is region-specific, and why that's a real gap

Every official transport description above is written the same way regardless of where you're connecting from, even though censorship techniques are inherently regional — what blocks Tor in one country may do nothing in another, and a technique that worked reliably last year can stop working after a censor upgrades its own detection. Tor Project's own Connection Assist feature is the closest thing to a regional answer, since it selects based on your detected location rather than asking you to guess, but it's still working from a general model of what's currently effective by region rather than publishing country-specific guidance directly — largely because publishing exactly which transport defeats a specific censor's exact detection method would hand that censor a roadmap for blocking it next. If Connection Assist doesn't get you online, the ordered list above is a reasonable starting point, but persistent regional failures are best addressed through Tor Project's own current bridge-request channels rather than a static guide, since what works shifts over time in exactly the regions where it matters most.