Tor Guard Relay Configuration Guide

The Guard flag is assigned by Tor's directory authorities to relays that meet uptime and bandwidth thresholds. Current requirements: relay must have the Fast flag (minimum consensus bandwidth above the median), the Stable flag (median weighted time between address changes > 7 days and weighted fraction of time online > certain threshold), and have been running for at least 68 days (varied by network conditions). Guard flag assignment is automatic - you cannot request it but can ensure your relay meets the requirements. Monitor flag assignment at metrics.torproject.org - look for G in the relay flags column. New relays typically take 8-12 weeks of stable, high-uptime operation before receiving the Guard flag.

Guard relay stability is critical because clients persist guard assignments for months - an unreliable guard forces frequent guard rotation, which degrades the privacy properties guards are meant to provide. Target 99%+ uptime on guard relays. Set up systemd service with automatic restart: Restart=on-failure in the tor.service unit. Configure UnattendedUpgrades on Debian/Ubuntu for automatic security patching with tor daemon auto-restart. Monitor uptime with Prometheus node_exporter and alert on Tor service failures. For planned maintenance (kernel updates, hardware changes), schedule during off-peak hours and limit downtime to under 4 hours. Extended downtime causes clients to select replacement guards, reducing your relay's selection probability.

To configure a guard-only relay (no exit capability), set ExitRelay 0 and ExitPolicy reject *:* in torrc. This ensures Tor never uses your relay as an exit and you will not receive abuse complaints about exit traffic. Guard-only configuration is the lowest-risk relay type to operate because your server's IP does not appear in destination server logs. Set ORPort to 443 for maximum reachability - some networks block non-standard ports but rarely block 443. Configure DirPort to allow directory mirroring (optional but beneficial for the network). Set ContactInfo to a valid email or Tor community contact for Tor team communication about operational issues.

Guard relay performance directly impacts the quality of circuits that use your relay. Configure RelayBandwidthRate to 80% of your available sustained throughput. For a 100 Mbit/s server, set RelayBandwidthRate 80 MBytes and RelayBandwidthBurst 100 MBytes. Monitor actual bandwidth usage with vnstat and compare against the consensus weight assigned by bandwidth authorities. If consensus weight is significantly below your configured BandwidthRate, the bandwidth authorities are measuring lower throughput than you expect - check for network bottlenecks (shared uplink contention, ISP throttling) with iperf3 tests from multiple locations. For guard relays, latency matters as much as throughput - prefer VPS providers with low-latency network connections over high-bandwidth providers with poor latency.

If you operate multiple Tor relays, all must be listed in MyFamily in each relay's torrc, and each relay must list all others. The format is MyFamily relay_fingerprint1,relay_fingerprint2 where fingerprints are the hex fingerprints from /var/lib/tor/fingerprint. Incorrect or incomplete MyFamily configuration means your relays may be selected for the same circuit, reducing circuit diversity and weakening anonymity for users of those circuits. For guard relays specifically, MyFamily prevents two of your guard-eligible relays from both appearing in a client's guard set, which would concentrate a client's entry traffic through your infrastructure. Configure MyFamily correctly before your relays receive the Guard flag.