meek Bridge Server Configuration for Domain Fronting Tor Traffic

Domain fronting exploits a quirk in how major CDN providers route HTTPS traffic. The TLS SNI (Server Name Indication) field, which is visible to network observers because it is sent before the TLS handshake completes, contains a legitimate domain such as ajax.aspnetcdn.com for Azure. The actual HTTP request inside the TLS tunnel uses a different Host header pointing to the meek-azure endpoint. The CDN sees the Host header and routes internally; the censor only sees the SNI, which belongs to a major cloud provider they cannot block.

The meek bridge server runs a special relay that the Azure or Amazon endpoint forwards traffic to. This server decrypts the HTTPS and passes the Tor circuit data to the Tor process. From the perspective of the user's ISP or national firewall, the entire session looks like the user visiting Microsoft or Amazon infrastructure, which is essentially impossible to block at scale without disrupting enormous amounts of legitimate enterprise traffic.

Cloud providers have been inconsistent about whether they explicitly block domain fronting for Tor traffic, but the current meek-azure and meek-amazon endpoints remain operational in most environments as of 2026. The transport is slower than obfs4 due to the additional HTTPS overhead but significantly more robust against blocking in environments with very aggressive censorship.

The meek server runs as a Go binary alongside the tor process. Install the meek-server from source or the Tor Project package repository. The server configuration requires a TLS certificate for the fronted domain. In practice, most operators use meek-azure or meek-amazon as the fronting CDN, not a self-hosted front end.

For operators who want to run a fully self-hosted meek-like setup, the Tor Project provides meek-server source code at git.torproject.org. The server component listens on a port forwarded by your CDN proxy and hands off decrypted streams to the local Tor process via the ExtORPort interface. The complete setup requires CDN account configuration in addition to server software, making it more complex than obfs4.

Most bridge operators who want meek support simply configure their torrc to enable meek as an additional transport alongside obfs4, letting the Tor Project's own meek infrastructure handle the CDN side. This is the recommended approach for new operators. The self-hosted meek server is an advanced configuration needed only by organizations that want full control over all components.

A single VPS can host both obfs4 and meek transports simultaneously, offering clients a fallback when one transport is blocked. Configure torrc with multiple ServerTransportPlugin lines:

BridgeRelay 1
ORPort 9001
ExtORPort auto
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:443
ServerTransportPlugin meek exec /usr/bin/meek-server
ServerTransportListenAddr meek 0.0.0.0:8443
PublishServerDescriptor bridge
ContactInfo your-contact-info

Each transport advertises its own bridge line with different port numbers and plugin-specific parameters. Clients who receive a bridge line for your server can try both transports and fall back to whichever works in their censored environment. This dual-transport approach effectively doubles the usefulness of a single VPS investment without doubling hardware costs.

meek bridge IPs are more persistent than obfs4 bridge IPs because the censorship blocking mechanism is fundamentally different. Rather than blocking your IP directly, censors must block the CDN endpoint used for domain fronting. This makes meek bridges longer-lived in practice, but the operational security considerations remain the same.

Use a pseudonymous email for the ContactInfo field in torrc. Do not reuse this email for other purposes. Pay for the VPS with Bitcoin or Monero and use a fresh payment address for each invoice. Keep the bridge IP separate from any other hosting you control personally to prevent cross-correlation through BGP routing history or email header analysis.

Run the tor process as the debian-tor user with minimal system privileges. Enable systemd security features in the service unit. Consider full disk encryption for the VPS if your data center supports encrypted volume provisioning. These measures ensure that even if an adversary gains physical or logical access to the server, they cannot reconstruct your personal identity from the server state.