Tor Pluggable Transports 2026: Full Protocol Comparison

obfs4 (obfuscation version 4) remains the most widely deployed pluggable transport. It transforms Tor traffic into random-looking byte streams that do not match any known protocol fingerprint. Strengths: highly effective against DPI-based blocking, well-documented, supported by all major Tor client applications, widely deployed (thousands of bridges), good performance overhead (lower than meek). Weaknesses: bridge IPs are a fixed attack surface (censors can block known bridge IPs), less effective against active probing (an adversary can probe the bridge IP on the obfs4 port and identify it as Tor). obfs4 is the best choice when: bridge IPs have not been enumerated by censors, censorship is DPI-based rather than IP-based, or when lower overhead is important (obfs4 adds less latency than Snowflake).

Snowflake routes Tor traffic through temporary WebRTC connections volunteered by Snowflake proxy operators (a browser extension). Strengths: uses WebRTC (same protocol as video calls), very difficult to block without collateral damage to legitimate video communication, extremely diverse IP pool (volunteer proxies, not fixed server IPs), domain fronting used for signaling channel makes it CDN-resistant. Weaknesses: higher latency than obfs4 (multiple hops through proxy), performance limited by volunteer proxy bandwidth, WebRTC is blocked in some network environments (corporate firewalls). Snowflake is the best choice when: IP-based blocking is comprehensive (obfs4 bridge IPs known and blocked), or when maximum IP diversity is needed (high-censorship environments like Russia/Iran).

WebTunnel disguises Tor traffic as legitimate HTTPS connections to a web server. The bridge appears to host a normal website; Tor traffic is encapsulated within HTTP/1.1 or HTTP/2 upgrade connections. Strengths: looks like standard HTTPS traffic to DPI, can be hosted on domains fronted by legitimate CDNs (Cloudflare, Fastly), resistant to active probing (the bridge IP looks like a normal web server). Weaknesses: newer protocol with less deployment than obfs4, CDN fronting may violate CDN terms of service, domain blocking is a different attack vector. WebTunnel is ideal when: environments where obfs4 is blocked but HTTPS to CDN-hosted sites is allowed (common in corporate/school networks), or when active probe resistance is important.

meek routes Tor traffic through major CDNs (Azure, Cloudflare) using domain fronting - the outer HTTPS header shows a CDN domain but the inner request routes to Tor infrastructure. Strengths: censors must block the entire CDN to block meek (causing massive collateral damage), very high blocking resistance. Weaknesses: slow (CDN routing adds significant latency), expensive (CDN bandwidth costs), performance-limited by CDN routing overhead. Azure meek may be blocked by targeting Azure IP ranges. Google meek no longer works. meek is best as a last resort when all other protocols are blocked - it is too slow for regular use but can establish connectivity in the most hostile environments.

Conjure (implemented in lox and other anti-censorship research): uses refraction networking, routing traffic through unblockable internet infrastructure (ISP-level refractors). Currently research stage, not widely deployed. Lyrebird (a Go implementation containing obfs4 and other transports): the library underlying obfs4proxy, also implements ScrambleSuit and other transports. HTTPT: similar to WebTunnel, HTTP/1.1 transport disguise. Snowflake v2: improved version of Snowflake with better probe resistance. The anti-censorship team at the Tor Project actively develops new protocols; following the anti-censorship mailing list or blog provides advance notice of new options.