Tor bridges obfs4
Tor bridges obfs4 disguise your connection when your ISP or network blocks listed Tor relays — your traffic reaches an unlisted entry point instead of a public relay.
Normal Tor traffic has a recognizable fingerprint. Your internet provider sees encrypted packets heading to IP addresses on a public list of Tor relays. In countries that block Tor — and on corporate or university networks that filter it — that signature is enough to drop the connection before a circuit forms. Bridges solve this by giving you an entry point that is not on any public directory.
The Tor Project defines bridges as "Tor relays that are not listed in the public Tor directory." Your ISP sees traffic to an unremarkable server, not a known relay. From there, the connection works like any other Tor session — three hops, encrypted end to end. Below: when you need a bridge, which transport to pick, and how to configure obfs4 or Snowflake in Tor Browser. For installation and security settings, see the Tor Browser setup guide.
What your ISP sees without a bridge
Without a bridge, the first hop in your Tor circuit is a public relay. Anyone — your ISP, your employer's network admin, a government filter — can download the list of relay IP addresses and block them. The block does not need to decrypt anything. It just refuses connections to those IPs.
What the ISP cannot see, even without a bridge, is what you do inside Tor. The traffic is encrypted from your machine to the first relay. Your provider knows you reached Tor. It does not know which .onion sites you loaded or what data passed through. A bridge addresses the first part — the visible connection to Tor itself — not the second.
Some users confuse this with anonymity from their ISP. A bridge hides the fact that you are using Tor. It does not make you anonymous to the destination site; that is what the three-hop circuit does. Both layers matter, but they solve different problems.
obfs4 versus Snowflake — which transport to use
Tor Browser offers several bridge transports. Two cover almost every real-world scenario: obfs4 and Snowflake.
| Transport | How it disguises traffic | Best for | Downside |
|---|---|---|---|
| obfs4 | Random-looking encrypted bytes; no TLS handshake pattern | ISP blocking known Tor relays; most censorship | Bridge addresses can be blocked if discovered |
| Snowflake | WebRTC connection through a temporary volunteer proxy in the browser | When obfs4 bridges are blocked or unavailable | Depends on volunteer proxies; can be slower |
| meek | Tunnels through a CDN domain (e.g. Microsoft Azure) | Heavy state-level blocking | Slow; fewer bridges available |
Start with obfs4. It is the default recommendation from the Tor Project for users who cannot connect directly. The traffic does not look like Tor and does not look like standard HTTPS either — it looks like noise. That is enough to pass most DPI (deep packet inspection) filters.
Switch to Snowflake if obfs4 fails. Snowflake routes your connection through a short-lived proxy run by a volunteer — often someone who left a browser tab open. The traffic resembles a WebRTC video call, which is difficult to block without breaking legitimate services. The tradeoff is speed and reliability: you are depending on whoever is volunteering right now.
meek is worth knowing about but rarely needed unless you are in a country with aggressive Tor blocking and both obfs4 and Snowflake have failed. Most readers of this guide will never need it.
Requesting a bridge through Moat
The easiest way to get a working bridge is through Moat — the built-in bridge request system in Tor Browser. Moat talks to the Tor Project's bridge distribution service and returns an address configured for your chosen transport.
Moat may ask you to solve a CAPTCHA or complete a small proof-of-work puzzle. This prevents bridge addresses from being harvested by censors in bulk. If the request fails, wait a few minutes and try again — bridge distribution rate-limits aggressive requests.
Manual bridge configuration
Sometimes you need to enter a bridge address manually — a friend shared one, you received it through an out-of-band channel, or Moat is unreachable from your network.
A bridge line looks like this:
obfs4 192.0.2.113:443 4FB9… cert=7BF… iat-mode=0
In Tor Browser: Settings > Connection > Use a bridge > Provide a bridge I know. Paste the entire line and save. The format matters — include the transport type (obfs4), the IP and port, the node ID, and the cert string exactly as provided.
Bridge addresses distributed through email, Telegram, or the Tor Project's BridgeDB website are intended for manual entry. Treat them like credentials: do not post them publicly, because published bridges get blocked faster.
Bridges are not a VPN replacement
People often reach for a VPN when Tor fails to connect. That solves a different problem and introduces a different trust model.
A VPN encrypts traffic between you and the VPN provider's server. The provider sees everything — including that you connected to Tor, if you then use Tor through the VPN. You are trusting a company with your connection metadata, and VPN providers respond to legal requests. Several high-profile cases have shown that "no logs" policies are not always true.
A bridge encrypts traffic between you and an unlisted Tor relay. No company sits in the middle. The bridge operator sees that someone connected, but not who you are or where you go after the first hop. For hiding Tor usage from your ISP, a bridge does the job without adding a trusted third party.
The one scenario where VPN-plus-Tor gets discussed: using Tor over VPN so your ISP sees VPN traffic instead of Tor traffic. This can work, but you are trading ISP visibility for VPN provider visibility. Unless you have a specific reason to trust a particular VPN more than your ISP, bridges are the simpler and more aligned choice. The OPSEC guide covers network isolation in broader terms.
When bridges fail and what to try next
Bridges are not magic. They can be discovered and blocked, especially if the same bridge address is shared widely. When a bridge stops working, the symptoms look like a normal Tor connection failure — Tor Browser spins on "Connecting" and never completes.