Scaling a Tor Relay from Entry Level to 1 Gbps Operation

Tor relays go through a well-documented ramp-up period before reaching their full traffic potential. In the first 3 to 4 days, the relay has zero consensus weight and receives no traffic. After initial measurement by bandwidth authorities (bwauths), the relay receives its first measured bandwidth and begins attracting circuits.

The ramp-up follows a rough pattern: minimal traffic for days 1 to 3, slow increase for days 4 to 14 as bwauths measure more samples, faster growth for weeks 3 to 8 as the relay accumulates stable flags and more bwauth measurements, and plateau at steady-state traffic level after 2 to 3 months. Some relays achieve full consensus weight within 3 weeks; others take longer depending on network conditions and measurement variance.

During the ramp-up period, avoid changing the relay's ORPort, fingerprint, or IP address. Each change triggers a re-evaluation period that can set the ramp-up back to zero. If migration to a new server is necessary, plan it carefully and maintain the same fingerprint (key) by copying the keys to the new server before the move.

The Tor network has dedicated bandwidth authority servers (bwauths) that measure relay bandwidth independently of self-reported values. The measured bandwidth from multiple bwauths is used to calculate consensus weight. A relay with high measured bandwidth and stable operation receives high consensus weight and attracts proportionally more traffic from the path selection algorithm.

Check your relay's current consensus weight and measured bandwidth at metrics.torproject.org/rs by searching for your relay's fingerprint. The difference between measured bandwidth and advertised bandwidth reveals whether your torrc bandwidth settings are accurate. Relays with inflated advertised bandwidth compared to measured bandwidth are penalized in path selection.

Verified that measured bandwidth closely tracks actual throughput by comparing bwauth measurements (visible in the relay's consensus entry) with actual traffic statistics from nyx. If measured bandwidth is consistently below your actual capability, ensure the relay's ORPort is reachable from the bwauth measurement servers and that no firewall rules are rate-limiting connections from specific IPs.

A single Tor process has practical throughput limits around 200 to 400 Mbps due to single-threaded cryptographic operations in the critical path. Achieving 1 Gbps aggregate requires running multiple Tor processes on the same server, each handling a portion of the total traffic and each independently measured by bwauths.

Configure multiple tor instances with separate configuration files and separate keys (different fingerprints). Each instance needs its own ORPort, HiddenServiceDir (or no hidden service), and data directory:

# Instance 1: /etc/tor/torrc-1
ORPort 9001
DataDirectory /var/lib/tor/instance1/
Nickname MyRelay1

# Instance 2: /etc/tor/torrc-2
ORPort 9002
DataDirectory /var/lib/tor/instance2/
Nickname MyRelay2

Each instance appears as a separate relay in the Tor consensus with its own fingerprint and measured bandwidth. The aggregate traffic across all instances can approach the physical port capacity. Network bandwidth (1 Gbps port) and CPU capacity (4+ vCPU) are the constraints; with proper kernel tuning, the instances together can sustain 800+ Mbps aggregate throughput.

See the advanced obfs4 tuning guide for detailed kernel parameter recommendations. For 1 Gbps relay operation, the most critical parameters beyond those are IRQ balancing for multi-NIC setups and CPU governor settings:

# Enable performance CPU governor
apt install cpufrequtils
cpufreq-set -g performance

For VPS with 1 Gbps uplinks, the hypervisor's virtual NIC driver is often the bottleneck rather than the network interface card itself. Contact the hosting provider to verify that the virtual NIC driver is the highest-performance option available for the hypervisor type. Paravirtualized drivers (virtio) significantly outperform emulated drivers (e1000) for high-throughput workloads.

Monitor the Tor relay's actual throughput over 24-hour periods with nyx. The maximum sustained throughput should stay below 90% of the port speed to avoid congestion affecting circuit latency. A relay consistently operating at 95%+ of capacity provides poor circuit performance even while sustaining high throughput numbers.