Tor Relay Family Configuration: Running Multiple Relays Correctly

Tor's path selection algorithm uses three relays for most circuits: guard (entry), middle, and exit. For anonymity, these three should ideally be operated by different entities - if any two are controlled by the same adversary and they are the guard and exit, traffic correlation attacks become trivial. The MyFamily directive allows relay operators to declare all their relays as belonging to the same family, causing Tor clients to never use two relays from the same family in the same circuit. Without this declaration, an operator running 50 relays might have their guard and exit chosen for the same circuit, compromising the privacy of users whose traffic passes through both.

MyFamily is configured in each relay's torrc file. The value is a comma-separated list of fingerprints (preceded by $) of all relays in the family. Every relay must list all other relays in its MyFamily. For example, a three-relay family: MyFamily $FINGERPRINT1,$FINGERPRINT2,$FINGERPRINT3. Get each relay's fingerprint from its var/lib/tor/fingerprint file. All relays must be listed in all others' MyFamily - a partial declaration (relay A lists B but B doesn't list A) is detected by directory authorities and reduces trust in both relays. For large families (10+ relays), maintaining this configuration manually is error-prone - use configuration management (Ansible, Puppet) to generate the list automatically from a central relay inventory.

The ContactInfo field in torrc is displayed on relay search portals (Relay Search at metrics.torproject.org) and is visible to the entire Tor network. It serves the important function of allowing the Tor Project and other operators to contact you about relay issues, abuse complaints, or security vulnerabilities. Best practice is to provide an email address that is monitored for relay-related communications. Use a dedicated email address for relay operations (not your personal primary email) to avoid spam. Some operators use a hashed email (hashed using the email2 convention) to prevent crawlers from harvesting it: ContactInfo 0x someone AT example DOT com.

New relays start with no flags and earn them over time through consistent performance. The Guard flag requires high bandwidth (top 25th percentile) and high uptime (95%+). The Exit flag is granted to relays with non-trivial exit policies. The Stable flag requires consistent uptime above the network median. The HSDir flag enables hidden service directory service. Flag acquisition takes days to weeks depending on relay performance. Monitor your relay's flags at metrics.torproject.org/rs. A relay stuck at low bandwidth utilization after weeks may indicate misconfiguration or insufficient bandwidth - check BandwidthRate settings and network connectivity.

Exit relays route other users' traffic to the clearnet and receive abuse complaints for that traffic. Expect to receive DMCA notices, abuse emails from ISPs, and occasionally law enforcement inquiries. Hosting providers that are Tor-friendly (and are willing to forward rather than act on these complaints) are essential for exit relay operation. Keep a prepared response explaining Tor exit relay operation (templates available at Tor Project community resources). Some jurisdictions have established that exit relay operators are not liable for traffic they route. Document all abuse complaints and your responses for legal protection. For exit relays in Romania and Iceland, both jurisdictions have been historically accommodating for responsible exit relay operation.