Tor Relay Bandwidth Scaling to Multi-Gigabit

Achieving sustained gigabit throughput requires hardware that matches the network connection speed. For a 1 Gbit/s relay, a modern server with 4+ CPU cores at 3+ GHz handles the asymmetric crypto workload. Tor's AES-128-CTR cipher for relay-to-relay encryption is hardware-accelerated on CPUs with AES-NI, available on virtually all modern Intel and AMD server processors. For 10 Gbit/s relays, use servers with 16+ cores and network interface cards with multi-queue support and RSS (Receive Side Scaling) to distribute packet processing across cores. RAM requirements scale with the number of simultaneous circuits - budget 64-128 GB for 10 Gbit/s operation.

A single Tor process cannot effectively utilize more than 8-10 CPU cores due to internal locking. For 10 Gbit/s targets with 24+ core servers, run multiple Tor relay instances, each bound to different ports and IP addresses. Each instance appears as a separate relay in the consensus with its own fingerprint and bandwidth measurement. Configure each instance in separate DataDirectory paths (/var/lib/tor0, /var/lib/tor1, etc.) with corresponding torrc files. Use a systemd template service tor@.service to manage multiple instances. Assign each instance to a CPU core subset using CPUAffinity in the systemd unit file.

The bandwidth authorities measure relay capacity using scanners that open test circuits and transfer data. A relay's consensus bandwidth weight is the median of measurements from these scanners. To maximize consensus weight: ensure your relay is reachable from all bandwidth scanners by not firewalling their IPs, maintain stable uptime (95%+ over 30 days), and actually sustain the bandwidth you advertise. Throttling below your configured rate causes measurements to underreport capacity. Monitor your relay's consensus weight history at metrics.torproject.org. Weight changes slowly - a new relay or one with recent instability takes 4-8 weeks to accumulate accurate measurements.

At multi-gigabit scale, OS connection limits become the primary bottleneck. Increase the maximum file descriptors: echo DefaultLimitNOFILE=1048576 to /etc/systemd/system.conf and set LimitNOFILE=1048576 in the Tor systemd service unit. Increase the connection tracking table for conntrack-based firewalls with net.netfilter.nf_conntrack_max=2000000. Disable iptables conntrack for Tor's ORPort traffic if you do not need stateful firewall tracking for relay-to-relay connections, using -j NOTRACK in the PREROUTING chain. Monitor kernel connection table usage with cat /proc/net/nf_conntrack_stat to detect exhaustion.

Track relay performance through the Tor control port and Nyx dashboard. Export metrics to Prometheus using the torctl2prometheus exporter. Key scaling indicators: when your relay consistently sustains BandwidthRate for 8+ hours per day, increase BandwidthRate by 25%. When CPU usage exceeds 70% on all cores during peak hours, consider splitting into multiple instances or upgrading hardware. When MaxMemInQueues is frequently triggered (visible in Tor logs as 'exceeded memory queue limit'), increase RAM or add a second relay instance. Monitor Tor's consensus weight weekly - steady growth over 4-8 weeks followed by plateau indicates you have reached the network's measured capacity for your relay.