Snowflake and meek — Pluggable Transports Compared

When the goal is simply to reach the Tor network from a hostile network, the distinction between “Snowflake” and “meek” often gets blurred in forum threads. Both are pluggable transports designed to obscure the fact that you are connecting to Tor, but they achieve this through fundamentally different architectures. Understanding the difference is not just an academic exercise; it dictates which tool will actually work in a given censorship environment, and which one might get you flagged by a sophisticated adversary.

The Core Architectural Split: Peer-to-Peer vs. Domain Fronting

The most critical difference is that Snowflake is a peer-to-peer (P2P) system, while meek relies on a technique called domain fronting. They are not interchangeable solutions; they are responses to different censorship models.

Snowflake works by routing your traffic through a series of short-lived proxies operated by volunteers. These proxies are not centralized servers. Instead, they are mundane internet users running a browser extension, a stand-alone app, or simply keeping a browser tab open with the embedded code. The system uses WebRTC to allow your browser to communicate directly with these proxy browsers. The “broker” is the central coordination point that introduces clients to available proxies, but the actual data relay happens directly between you and the volunteer’s machine.

Meek, on the other hand, is a domain fronting transport. It conceals your Tor connection by making it look like you are talking to a massive, legitimate web service (like Microsoft’s Azure or, historically, Google and Amazon). You connect to that service’s domain, but the request is actually routed to Tor’s relays hidden behind the same cloud infrastructure. A censor monitoring traffic sees a connection to a well-known CDN or cloud provider, not to a known Tor relay.

Snowflake: The Pros and Cons of Ephemeral Proxies

Snowflake’s strength lies in its massive, decentralized pool of IP addresses. As of 2024, the system boasted roughly 140,000 unique IP addresses concurrently. By the first half of 2026, the broker was recording an average of 146,000 unique volunteer proxy IP addresses per day. This sheer volume makes blocking the transport a whack-a-mole game for censors.

If a censor tries to block Snowflake, they face a logistical nightmare. Russian censors, for example, have attempted to fingerprint the browsers of Snowflake hosts and block them, or they have installed Tor themselves and blocked all IP addresses offered as Snowflake servers. However, these techniques are only effective when the number of proxies is small. With hundreds of thousands of ephemeral proxies, the blocklist becomes unmanageable and risks collateral damage.

Despite the resiliency, there are trade-offs. The quality of the connection is variable. Because you are routing through a volunteer’s home internet connection, you are subject to their bandwidth, latency, and the stability of their connection. While hosting a Snowflake proxy does not appear to appreciably slow down a volunteer’s own browsing, the relay experience for the client can be less consistent than a dedicated server connection.

The barrier to entry for volunteers is intentionally low. You do not need a dedicated IP address or to configure port forwarding. Installing a browser extension is sufficient in most cases. This ease of use is key to building the massive volunteer network. The recent launch of Snowflake Volunteer, a dedicated Android app, is an attempt to expand the pool further, particularly by capturing mobile users who had previously used Orbot’s “Kindness Mode.” The Tor Project has been transparent about the need for volunteers to consider their data limits and battery usage, and the app allows them to restrict activity to Wi-Fi and charging periods.

Meek: The Power and Vulnerability of Big Tech

Meek’s approach is elegant in its simplicity. It hides your traffic in plain sight by mimicking a connection to a major cloud provider. The censor sees an HTTPS connection to Azure (or a similar domain) and must decide whether to block the entire cloud service to stop the Tor traffic routed through it. This is a high-cost action, as it would disrupt access to hundreds of thousands of other legitimate websites and services hosted on the same platform.

This strategy is highly effective against nation-state censors who rely on IP and SNI-based blocking. It is a form of “collateral damage” defense-the censor cannot block the fronted domain without causing massive disruption to their own citizens’ access to the broader internet.

The weakness of meek lies in its dependency on a few large CDNs. The history here is crucial: Amazon Web Services and Google Cloud no longer support meek. This is not a network failure but a political and legal one-these providers received pressure or decided the risk of being used for censorship circumvention was too high. This left Microsoft’s Azure as a primary option, putting all of meek’s eggs in one basket. If Azure were to also withdraw support, the transport would need to scramble for a new front. There is also the fallback option of using a free Cloudflare domain for fronting, but that introduces a different set of variables and potential bottlenecks.

Traffic Analysis and Fingerprinting

For a privacy-conscious user, the critical question is not just “can I connect?” but “what does my connection look like?”

Snowflake attempts to disguise its traffic to resemble a video call. This is a clever countermeasure against deep packet inspection (DPI), which might otherwise flag the traffic as “unknown UDP” or “Tor-like.” The traffic type is inherently ephemeral and connection-oriented, much like a WebRTC call, which makes it harder for a passive observer to identify it as a circumvention tool.

However, the P2P nature introduces a metadata vulnerability. In a Snowflake connection, the client connects directly to a proxy. While the content is encrypted, the censor can see that a specific user is connecting to a specific IP address that is also connected to other random users. To the censor, this is a pattern. If they have already identified an IP as a Snowflake proxy, they can observe all clients connecting to it. This is why the system’s resilience is tied entirely to the diversity of the proxy pool. If a censor blocks 90% of known proxies, the remaining 10% become a honeypot for monitoring.

Meek, in contrast, relies on domain fronting. This technique is strong against connection metadata analysis because the censor sees a connection to a major CDN. The censor can see the IP address and the SNI (Server Name Indication) for the fronted domain-it appears as a standard HTTPS connection to a legitimate service. The content is hidden inside, and the actual destination is obscured. The theoretical weakness is that while the censor cannot see where the traffic is going, they can see a massive volume of data flowing to a single CDN at odd hours. This may trigger alarms, but blocking the CDN outright has the disruptive side effects previously mentioned.

Historical Context and Availability

The lineage of these tools is worth noting. Snowflake was originated by a developer known as Serene, inspired by the earlier “Flash proxy” system. It was released in 2016 and became a browser extension in 2019. By February 2023, a stand-alone Rust-based version called “Snowstorm” was in development, funded by the Open Tech Fund. Meek has been part of the Tor repertoire longer, utilizing domain fronting techniques that were also used by Signal and Telegram to bypass blocks in restrictive countries like Egypt and Russia.

For the average user, availability is a deciding factor. Snowflake is bundled with Tor Browser and Onion Browser, making it a one-click option for users. Meek is also available as a built-in transport in Tor Browser, though its options are more limited now that it relies primarily on Azure.

Which One for Which Scenario?

Speaking practically, the choice comes down to your threat model and the nature of the censorship.

• If you suspect the censor relies on a DPI blacklist-that is, they are specifically blocking known Tor relay IPs and common proxy signatures-Snowflake is the superior choice. The sheer number of proxies ensures that a significant portion of your connection attempts will succeed, and the video-call mimicry obfuscates the traffic’s true nature.
• If the censor is aggressive and blocks entire chunks of the internet-for instance, blocking all IPs that are not part of a “whitelist” of domestic websites-meek might be your only option. Because it uses domain fronting to hide your traffic in a connection to a popular cloud service, it is virtually indistinguishable from normal web traffic to a passive observer. It can bypass IP-based whitelists because the destination IP is that of the cloud provider, which is not blocked.

There is no “winner” here. Snowflake offers resilience through decentralization but is vulnerable to active fingerprinting of its proxy pool. Meek offers stealth through centralization but is fragile because it depends on the continued goodwill of a single cloud provider. The Tor Project maintains both because they address different censorship regimes. A researcher or a user in a high-risk environment should be familiar with how to switch between them and understand what each transport makes visible to the network observer. Your OPSEC should reflect the reality of the transport’s design, not just the security of the encrypted tunnel it provides.