Snowflake Proxy Deployment: Helping Censored Tor Users Through WebRTC

Snowflake uses a broker architecture with three components: the Snowflake proxy (the helper, operated by volunteers), the broker (a centralized service matching users with proxies), and the Snowflake server (a relay in the Tor network that proxies connect to). A censored user's Tor Browser signals to the broker (through a domain-fronted HTTPS request that is hard to block) that they need a proxy. The broker matches them with an available volunteer proxy. The user and proxy establish a WebRTC connection (the same protocol used for Zoom or Google Meet calls), and traffic flows through this connection to the Snowflake server relay and into the Tor network. WebRTC traffic is extremely difficult to block without disrupting all real-time communication apps.

The simplest way to run a Snowflake proxy is through the Firefox or Chrome browser extension. Install the Snowflake extension from the Firefox or Chrome extension store. Enable it from the extension popup. While your browser is open and you have internet connectivity, you are serving as a Snowflake proxy for censored users. The extension handles all technical details. Traffic flows through your browser's WebRTC stack, meaning your IP address acts as the proxy entry point. Bandwidth usage is typically 50-200 MB/day on an active browser. No configuration is required. This is the recommended approach for non-technical users who want to contribute.

For higher capacity and 24/7 operation, run the standalone Snowflake proxy daemon on a VPS. Install Go (Snowflake is written in Go), clone the Snowflake repository, and build the proxy binary. Run with: ./proxy -capacity N (where N is the maximum simultaneous users to serve). A VPS proxy runs continuously, serving many users simultaneously, making it more valuable than a browser extension that runs only when the browser is open. Resource requirements are modest: 1 vCPU and 512MB RAM is sufficient for small capacity. Bandwidth is the main resource: each served user uses approximately 5-20 Mbps while connected. A Romania VPS Mini can comfortably serve 10-20 simultaneous Snowflake users.

The effectiveness of Snowflake depends on proxy diversity - having proxies in many different IP ranges (consumer ISPs, cloud providers, universities) makes it harder for censors to block them all. Cloud provider IP ranges (known AWS, GCP, Azure ranges) can be blocked by censors without disrupting consumer internet. If a censor blocks all known cloud IP ranges, cloud-hosted Snowflake proxies become less effective. Browser extension proxies (on consumer ISP connections) are harder to block because censors cannot block consumer ISP IP ranges without also blocking normal user traffic. Contributing both types (VPS for capacity, browser extension for IP diversity) strengthens the overall network.

The standalone Snowflake proxy provides metrics accessible at localhost:9999/metrics in Prometheus format. Key metrics: snowflake_proxy_current_nat_type (your NAT type - symmetric NAT reduces proxy effectiveness), snowflake_proxy_connections_total (total connections served), snowflake_proxy_traffic_bytes_total (total bytes proxied). If your NAT type is 'symmetric,' WebRTC connections may be difficult to establish and your proxy may serve fewer users. Provider-side solutions: request a specific public IP from your VPS provider, configure UPnP or port forwarding to improve NAT traversal. Monitor bandwidth usage to avoid exceeding hosting plan limits.