Snowflake Proxy Hosting on VPS - WebRTC Censorship Circumvention

obfs4 bridges use a fixed IP that users must know in advance. When censors block that IP, the bridge is dead until a new one is distributed. Snowflake proxies are ephemeral from the client perspective: the Snowflake broker matches Tor clients with available proxies dynamically, so clients never know or need a specific proxy IP in advance. Censoring Snowflake requires blocking the broker endpoint itself, which is behind domain fronting on major cloud providers.

The cost of this architecture is throughput. WebRTC adds overhead compared to raw TCP, and TURN relay adds another hop when direct WebRTC is unavailable. Snowflake is excellent for users who need to get online at all, not for users who need sustained high-bandwidth connections. A dedicated VPS proxy operates as a standalone rather than browser-based instance, giving it much higher sustained throughput and uptime than the typical volunteer browser extension.

Operators who want to serve both latency-sensitive and high-throughput users should run both obfs4 and Snowflake in parallel on separate infrastructure. The resource requirements for a Snowflake standalone proxy are modest: 1 vCPU and 512 MB RAM is sufficient for dozens of concurrent WebRTC sessions.

The Snowflake standalone proxy is a Go binary distributed by the Tor Project. Install Go 1.21 or later from the official Go distribution if your package manager ships an older version:

wget https://go.dev/dl/go1.21.6.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.21.6.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

Then build the standalone proxy:

git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git
cd snowflake/proxy
go build -o /usr/local/bin/snowflake-proxy .

Verify the build with snowflake-proxy --version. Create a systemd service unit for automatic startup and restart on failure. The proxy requires no special privileges and should run as a dedicated non-root user for security. Configuration is done entirely via command line flags; no configuration file is needed for basic operation.

Create /etc/systemd/system/snowflake-proxy.service with the following content:

[Unit]
Description=Snowflake Tor Proxy
After=network.target

[Service]
User=snowflake
Group=snowflake
ExecStart=/usr/local/bin/snowflake-proxy -broker https://snowflake-broker.torproject.net -relay wss://snowflake.bamsoftware.com/ -log /var/log/snowflake/proxy.log
Restart=always
RestartSec=10
ProtectSystem=strict
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Create the snowflake user and log directory, reload systemd, and enable the service:

useradd -r -s /bin/false snowflake
mkdir -p /var/log/snowflake && chown snowflake:snowflake /var/log/snowflake
systemctl daemon-reload && systemctl enable --now snowflake-proxy

Watch the log file for lines indicating successful connections to the broker and to clients. A healthy proxy shows periodic "Relayed X bytes" messages and counts of successful and failed client connections.

The default Linux kernel parameters are not optimized for hundreds of concurrent WebRTC sessions. Apply these sysctl adjustments to /etc/sysctl.d/99-snowflake.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

Apply with sysctl --system. BBR congestion control significantly improves throughput on high-latency paths that WebRTC typically traverses. These optimizations allow a single VPS instance to comfortably handle 200 to 500 concurrent Snowflake sessions depending on session bandwidth.

For even higher capacity, run multiple proxy processes on different ports. The Snowflake broker distributes load across all registered proxies automatically, so running three processes on a 3 vCPU VPS triples effective capacity. Use separate systemd instances or a process manager like supervisord to manage multiple proxy processes independently.

The Snowflake project tracks proxy contributions and publishes anonymized statistics. Your proxy's contribution appears in aggregate Snowflake capacity reports without identifying your specific server. Watch /var/log/snowflake/proxy.log for session counts, bytes relayed, and error rates. Typical metrics for a healthy proxy on a 100 Mbps uplink include 30 to 80 concurrent sessions and 50 to 200 GB of traffic relayed per month.

Set up log rotation with logrotate to prevent the log file from consuming excessive disk space. A daily rotation with 7 days retention is appropriate for most operators. The proxy itself has no built-in dashboard, but the log data can be fed into a lightweight monitoring tool like Prometheus with a custom log parser for alerting on error rate spikes or session count drops.