Tor Relay Family Management for Multi-Relay Operators

Tor's path selection algorithm uses several diversity constraints to prevent circuits from being vulnerable to correlation by a single observer. One constraint is family diversity: Tor will not use two relays in the same MyFamily group in the same circuit. If you run relays A, B, and C without MyFamily configuration, Tor might build a circuit A(guard)->B(middle)->C(exit), allowing your infrastructure to observe both entry and exit traffic for that circuit - catastrophic for user anonymity. Correct MyFamily configuration prevents this by informing Tor's path selection that these relays are controlled by the same operator, triggering the family exclusion rule.

Each relay must list all other relays you operate in its MyFamily line, and each of those relays must list all others. The configuration is fully qualified relay fingerprints separated by commas. Retrieve each relay's fingerprint from /var/lib/tor/fingerprint (the 40-character hex string). In each relay's torrc, add: MyFamily fingerprint1,fingerprint2,fingerprint3. Restart each relay after configuration. Verify MyFamily is advertised correctly by fetching the relay descriptor: curl https://onionoo.torproject.org/details?search=fingerprint and checking the family field in the JSON response. If any relay is missing from another relay's family declaration, path selection may still use them in the same circuit.

Beyond MyFamily, the Tor Project encourages operators to distribute relays across multiple autonomous systems (ASes) for network diversity. Using the same AS for all your relays reduces circuit diversity - Tor's path selection avoids using two relays from the same /16 subnet but not necessarily the same AS. When selecting hosting providers for additional relays, check the AS numbers at BGP.HE.net or similar tools and choose different providers in different ASes. Relays in diverse ASes provide stronger anonymity guarantees than multiple relays in the same AS, even with correct MyFamily configuration.

Multi-relay operators benefit from centralized monitoring across their relay family. Configure Prometheus with node_exporter on each relay server and Grafana for unified dashboard visibility. Track consensus weight across all family relays to identify underperforming members. Export Tor control port metrics from each relay to the central Prometheus instance. Set up cross-relay alerting: if one relay in the family goes down, ensure it does not affect the others (each should be independently managed, not dependent on shared infrastructure that could cause cascading failures). Monitor family bandwidth contribution as a whole and as individual relay percentages of total family bandwidth.

As relay family size grows, operational overhead increases proportionally. Automate relay deployment with configuration management tools (Ansible, Puppet, Salt). Maintain relay configuration in version control. Use templated torrc files with relay-specific variables (fingerprint, bandwidth, nickname) generated from configuration management. Automate MyFamily updates: when adding a new relay, the new relay's fingerprint must be added to all existing relay configurations. A management script that reads all current relay fingerprints and regenerates torrc files with updated MyFamily is essential for families of 5+ relays. Run automated configuration validation (tor --verify-config) in CI/CD pipelines before deploying configuration changes to production relays.