Meek Bridges and Domain Fronting for Tor: Complete Technical Guide
Meek is a Tor bridge transport that uses domain fronting through content delivery networks (CDNs) to disguise Tor traffic. The key insight: CDN providers like Microsoft Azure and Google have IP address ranges that censors cannot block without disrupting major business services. Meek routes Tor traffic through these CDN IPs by using legitimate domain names as the apparent destination. This makes meek extremely difficult to block without collateral damage to legitimate enterprise services. This guide explains how meek domain fronting works technically, why it is effective, and how to use meek bridges in Tor Browser.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Domain fronting exploits a property of CDN networks: the TLS SNI (Server Name Indication) field contains the apparent domain (used for routing decisions), while the HTTP Host header contains the actual destination. The CDN routes based on the TLS SNI but the actual request destination is in the Host header. With meek: the TLS connection establishes with SNI indicating a legitimate Microsoft or Google domain (like allowed.microsoft.com). The CDN sees a legitimate HTTPS connection and forwards it. Inside the TLS, the HTTP Host header requests the actual meek endpoint (ajbp6aaymqdj.azurefd.net or similar). The CDN forwards to the actual meek server. The meek server wraps Tor traffic in HTTP and proxies to the actual Tor bridge. A censor sees: HTTPS connections to Microsoft Azure or Google IP addresses with legitimate SNI domains - blocking these would block all Azure/Google traffic in the country.
Meek Transport Variants
Three meek variants exist: meek-azure: uses Microsoft Azure CDN as the fronting network. The SNI uses a Microsoft-owned domain, and the backend connects to a meek server running on Azure infrastructure. Effective in countries where Azure infrastructure is not fully blocked. meek-google: similar but uses Google's CDN and infrastructure. Effective where Google is not blocked (less useful in China). meek-amazon: uses Amazon CloudFront. Each variant uses different CDN infrastructure, providing different blocking resistance profiles. For users: Tor Browser includes meek-azure by default. meek-google and meek-amazon are available through additional configuration. meek bridges are pre-configured in Tor Browser - no manual bridge addresses needed. Access in Tor Browser: Settings -> Connection -> Use a Bridge -> select meek-azure (built-in) or enter the meek bridge line.
Performance Characteristics of Meek
Meek has higher latency than obfs4 or Snowflake due to the CDN routing overhead: typical meek latency is 200-500ms additional latency per hop compared to direct Tor connections. This makes meek slower than other bridge types for interactive browsing. However, meek is more reliable in environments where other transports have been blocked - it is a 'last resort' transport when nothing else works. Bandwidth is limited by the meek relay infrastructure rather than the user's connection. Meek is appropriate for: text browsing, email, messaging, and accessing information. Not suitable for: video streaming, large file downloads, or latency-sensitive applications. The meek relay infrastructure is maintained by the Tor Project and is a shared resource - heavy users should consider that their bandwidth impacts other users.
Changes in Domain Fronting Availability
Domain fronting has faced pushback from CDN providers: Google disabled domain fronting on Google Cloud in 2018 (after it was used by Signal in Iran, leading to a Google policy change). Amazon has implemented restrictions on domain fronting on CloudFront. Microsoft Azure has not disabled domain fronting as broadly as the other providers. The meek transport has adapted to these changes: meek-google's availability depends on specific Azure/Google configurations that enable fronting. When CDN providers change their fronting policies, meek variants may stop working temporarily until the Tor Project updates the meek infrastructure to use different fronting domains. The Tor Project maintains awareness of CDN policy changes and updates meek configurations accordingly.
When to Use Meek vs Other Bridge Types
Bridge selection priority for different environments: (1) Snowflake available and working: use Snowflake (lower latency, high capacity). (2) obfs4 bridges available and not blocked: use obfs4 (simple, effective, lower latency than meek). (3) WebTunnel bridges available: use WebTunnel (HTTPS-based, strong DPI resistance). (4) All above failing: try meek-azure (highest blocking resistance due to CDN fronting, accepts higher latency). Meek is the 'last resort' option with the highest blocking resistance and the highest latency. In practice, most users in heavily censored countries (China, Iran) find that Snowflake or WebTunnel bridges work reliably enough that meek is not needed for daily use. Meek serves as the fallback when other transports face temporary increased blocking.