Tor Bridges: obfs4, Snowflake, WebTunnel
If Tor is blocked or flagged, a bridge hides the first hop. This guide compares obfs4, Snowflake, WebTunnel and meek, and how to get bridges officially.
A public Tor relay is easy to find and easy to block. Censors copy the published list, firewalls watch for the TLS handshake, and some networks probe anything that looks like a guard. A bridge is an unpublished entry, and a pluggable transport wraps the traffic so it no longer looks like Tor. That is all a bridge does: it gets you onto the network. It does not add a hop, and it does not hide you from the rest of the circuit.
How censors find and block Tor
Most blocks start with the public consensus. Every client downloads a signed list of relays. Anyone else can download the same list and drop those IP addresses. That is cheap and it works until users switch to unpublished entries.
Deep packet inspection is the next layer. Tor's handshake has historically been distinctive even when the destination IP is unknown. Some censors also run active probes: they connect to a suspected host and check whether it answers like a Tor daemon. If it does, they add it to the block list. That is why a "secret" IP is not enough on its own — the protocol still has to look ordinary.
Connection Assist in current Tor Browser tries built-in transports automatically when a normal bootstrap fails. If that still stalls, you pick a transport to match the network you are on. The Tor Browser research guide covers what the browser itself does; this page is about the first hop only.
What a bridge is — and is not
A bridge is a guard that is not published in the consensus. Your ISP or local firewall sees a connection to that host instead of a known Tor IP. The bridge operator sees your IP, the same way a normal entry guard would. The bridge does not see the destination. The rest of the circuit is unchanged: middle relay, then exit or onion service.
Bridges do not protect you from a compromised browser, reused accounts, or a seized laptop. They also do not hide Tor use from a global passive observer who can watch both ends of a circuit. If slowness is the problem rather than a block, start with why Tor is slow before adding a transport.
The four transports you will actually meet
| Transport | What the local network sees | Typical use |
|---|---|---|
| obfs4 | Random-looking bytes on an unpublished host | Default pick; many networks, including Russian ISPs |
| Snowflake | A short-lived WebRTC session to a volunteer browser | When IPs are scanned and blocked quickly |
| WebTunnel | HTTPS to a normal-looking website | When the censor allows the web but blocks Tor and obfs4 |
| meek | HTTPS to a major cloud front (domain fronting) | Last resort; slow and capacity-limited |
obfs4 looks like noise. The handshake is designed so a scanner cannot confirm that the host is Tor unless it already has the bridge line. That is why sharing a working obfs4 address in a public chat burns it.
Snowflake uses volunteer browsers as short-lived proxies. The client reaches a broker, then a WebRTC peer. Volunteers come and go, so a block list of Snowflake IPs goes stale. The trade-off is reliability: a volunteer tab can close mid-session.
WebTunnel presents as ordinary HTTPS to a website that happens to terminate a Tor entry. A censor who blocks "unknown encrypted protocols" but leaves HTTPS open often lets it through. The Tor Project has recommended it first in some Chinese networks.
meek hides inside the TLS of a large cloud provider. Blocking it means blocking a popular domain, which many censors will not do. The path is expensive and slow; treat it as a fallback, not a daily driver.
Pick by situation
- Home ISP that flags Tor but does not inspect payloads: try built-in obfs4 first.
- School, hotel or office firewall with a Tor category: obfs4, then WebTunnel.
- Country-scale IP blocks plus active probing (Russia is the usual example): obfs4 or WebTunnel; skip public relays entirely.
- Aggressive DPI that classifies obfs4 as "unknown protocol" (parts of China, some mobile networks): WebTunnel, then Snowflake, then meek.
- You only need to hide Tor use from a local admin, and the network is otherwise open: any bridge works; obfs4 is enough.
These are heuristics from Tor Project support pages, not guarantees. Censors change rules. If one transport bootstraps and then dies, switch; do not keep retrying a burned bridge.
Usage spikes after shutdowns are visible in Tor metrics. Iran's repeated disruptions — including the 2026 nationwide cuts documented by independent connectivity monitors — show up as collapsed user counts, then a recovery on bridges. Russia has blocked public relays for years; most remaining clients there arrive through transports.
How to get bridges without burning them
Use official Tor Project channels only:
- Tor Browser's own "Request bridges" flow (solves a CAPTCHA, writes the lines into settings).
- The bridges portal on torproject.org.
- Email to the Project's bridges address from a Gmail or Riseup account.
- The Project's Telegram bot, if Telegram itself is reachable.
Never paste a working bridge line into a public forum, a screenshot, or a "free VPN" site. Once it is public, scanners add it to the block list. Do not download "bridge packs" from random GitHub gists or Telegram channels unrelated to the Tor Project — those lists are either exhausted or hostile.
Built-in bridges ship with the browser. They are convenient and also well known; a determined national firewall may already block them. Requested bridges are the ones worth trying next.
What a working bridge still leaves exposed
Your local network learns that you opened an encrypted session to a specific host, or to a Snowflake volunteer, or to a website that fronts WebTunnel. A bridge operator who logs can record your IP and connection times. The guard and exit visibility matrix still applies after you are on the network.
A bridge also does not fix a poisoned download. Get Tor Browser from the official site and verify the signature before you rely on any circumvention feature. Common setup errors — adding a VPN in the wrong order, lowering the security slider to "make it faster" — are covered in common Tor mistakes and Tor over VPN.
Frequently Asked Questions
Do I need a bridge in the US or UK?
Usually no. Public relays are reachable on most consumer ISPs. A bridge is useful if a workplace or campus firewall blocks the Tor category, or if you want the local network not to see a known Tor IP. It does not change your anonymity set on the far side.
Which transport is "best"?
There is no single best transport. obfs4 is the right first try on many networks. WebTunnel and Snowflake exist because some censors learned to spot or probe obfs4. meek is the remaining option when the others fail. Try the built-in list, then request fresh bridges.
Can the bridge operator read my traffic?
No. The bridge only sees the encrypted Tor cells you send it, plus your IP. It cannot read the destination or the page content. It is an unpublished guard, not a decrypting proxy.
Does a bridge make Tor slower?
Often yes, because you add obfuscation and sometimes a volunteer or a cloud detour. If the circuit bootstraps and then crawls, the cause may be the transport, a loaded guard, or the three-hop design itself. Diagnose with the slowness guide before stacking more tools.