Maximizing Tor Relay Consensus Weight

The Tor bandwidth authority (bwauth) measures relay bandwidth by building circuits through each relay and timing data transfers. The measurement process: the bwauth establishes a circuit through the relay being measured, transfers a known amount of data, and records the observed throughput. This measured bandwidth (not the configured BandwidthRate) is reported to the directory authorities. The directory authorities combine measurements from multiple bandwidth authorities and compute a consensus bandwidth figure. The consensus weight is derived from this measured bandwidth relative to all other relays' measured bandwidths. A relay that measures at 100 Mbit/s when the median relay measures at 10 Mbit/s gets a higher proportion of circuits. Key insight: your configured BandwidthRate is a ceiling - if your bandwidth measures lower than your configuration, the consensus weight reflects the measurement, not the configuration.

Tor relay flags affect which circuits use the relay: Running: relay is currently reachable and in the consensus. Required for any circuit assignment. Valid: relay has a valid descriptor and is running correctly. Fast: relay has sufficient bandwidth for fast circuits (above the median of measured relays). Guards are primarily selected from Fast relays. Stable: relay has sufficient uptime for long-duration circuits (hidden services, downloads). HSDir: relay is eligible to store hidden service descriptors. Guard: relay is eligible for use as a circuit entry guard (requires Fast + Stable + sufficient uptime and bandwidth). Exit: relay is eligible as a circuit exit (requires ExitPolicy not set to reject all). To maximize circuit assignment: aim for Fast, Stable, and ideally Guard flags. Guard flag relays are preferentially used as circuit entry points - carrying a higher proportion of traffic than non-guard relays.

Beyond bandwidth, network position affects relay utility. Diverse relay families: each relay family (set of relays operated by the same operator, grouped via MyFamily directive) is limited in how many relays a circuit can use. If all your relays are in one family: each relay is effectively competing with the others for circuits. Multiple families (operated by different people, or configured without MyFamily) have no such limit. IPv6 support: relays supporting IPv6 (ORPort [::]:9001) are usable in more circuit configurations and may receive higher weighting as IPv6 adoption grows. Geographic diversity: the Tor network attempts to build circuits through geographically diverse relays. A relay in a geography not well-represented in the network (Southeast Asia, Africa, South America) may get higher proportional weighting than its bandwidth alone would suggest.

To ensure your relay measures at its full capacity: (1) ensure the VPS has actual available bandwidth matching your configuration - a $19.99 VPS on a shared network host may not have guaranteed bandwidth; test with iperf3 to verify actual throughput, (2) configure BandwidthRate to match actual sustained available bandwidth (not the port speed) to prevent the relay from advertising more than it can deliver, (3) ensure low CPU usage on the relay - if the relay's CPU is saturated with other processes, Tor cannot process cells fast enough to measure at full bandwidth, (4) ensure good network latency to major relay clusters - the bwauth builds circuits through your relay and measures end-to-end throughput; high latency increases measurement variability, (5) maintain high uptime - the measurement system averages multiple measurements over time; relays with more measurement samples have more stable consensus weight.

Track your relay's consensus weight and flag history on Tor Metrics (metrics.torproject.org). Key metrics to monitor: consensus weight history (should grow as the relay establishes a track record), flag history (should show stable Running and Fast, ideally Stable and Guard over time), bandwidth measurement history (the raw measurements from bwauths), and circuit assignment rate (visible in Tor's MetricsPort data as tor_circuit_opened_total). New relays have a limited consensus weight during their first 68 days (the Tor network applies conservative weighting to new relays to prevent Sybil attacks). After 68 days: consensus weight reflects measured performance more directly. Plan on a 2-3 month period before a new relay reaches its maximum potential consensus weight.