Why do clients use a small number of persistent guards instead of random selection?

If clients chose guards randomly for each circuit, an adversary controlling 10% of relays would have a 10% chance of being selected as guard for each circuit - over many circuits, they would likely be selected at least once. With persistent guards, a client's probability of having an adversarial guard is fixed at 10% (chosen once) and does not increase with circuit count. This persistent selection strategy protects against adversaries who try to increase their probability of being selected by creating many short-term circuits.

Does having the Guard flag affect my relay's contribution to non-Guard circuits?

Yes. Guard relays are eligible for the guard position in circuits but can also serve as middle relays. In practice, Guard-flagged relays carry more total traffic because they are selected for both positions. The Guard flag increases a relay's circuit selection probability beyond just guard-position circuits. Non-Guard relays (fast but unstable, or low-bandwidth) serve only as middle relays.

How long does it take to earn the Guard flag for a new relay?

Typically 8-12 days after initial deployment. The first 3-5 days involve the new relay flag delay (Tor does not use completely new relays). Days 5-8: relay appears in consensus and bandwidth authorities measure it. Days 8-12: if bandwidth meets median and stability is high, the Guard flag is assigned in the next consensus that evaluates flags. Monitor relay status at metrics.torproject.org with your relay fingerprint.

Can I configure my relay to refuse non-guard-position use?

No. Relay operators cannot specify which position their relay serves in circuits. Tor's circuit selection algorithm determines this. You can influence your relay's characteristics (bandwidth, stability, exit policy) but not the circuit position assignments. GuardFraction in torrc is a setting for clients specifying fraction of traffic over guards, not a relay setting.

What is a 'bridge guard' and is it different from a regular guard?

In Tor, 'guard' in the context of client circuits refers to the entry node (first hop). Bridges can also serve as entry nodes (and are preferred by censored users over public guards). A bridge that operates reliably can be a 'bridge guard' in a practical sense - a bridge assigned to specific users as their entry point. Bridges do not have the same 'Guard' flag as public relays because they are not in the public relay directory. The Guard flag concept applies only to publicly listed relays.

Earning and Maintaining the Tor Guard Flag: Configuration Guide

The Guard flag is assigned to Tor relays that have demonstrated sufficient stability and bandwidth to serve as the entry point (guard relay) for Tor client circuits. Guard relays are the first hop in a 3-hop Tor circuit: they see the client's real IP address but not the destination. For this reason, Tor clients use a small number of guard relays consistently over time (rather than selecting randomly for each circuit) - this reduces the probability that a client's guard is a malicious relay controlled by an adversary. Running a relay that earns and maintains the Guard flag provides particularly valuable contribution to the Tor network's security model.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Guard Flag Requirements

The Guard flag is assigned by Tor's directory authorities based on: bandwidth requirement (measured bandwidth at least the median of all relays, currently approximately 2 Mbit/s), stability requirement (weighted fractional uptime must exceed a threshold, typically 98% or more), long-term consensus presence (relay must appear in many recent consensuses without gaps). New relays must operate for approximately 8 days before being considered for the Guard flag (the guard-time-delay). Relays that meet requirements consistently earn the Guard flag automatically. Operators do not request or configure the Guard flag - it is assigned by directory authorities. The Guard flag is separate from the HSDir flag (also uptime-based) and the Exit flag (based on exit policy).

Stability Metrics That Affect Guard Flag

Two stability metrics determine Guard flag eligibility: MTBF (Mean Time Between Failures): how often does the relay go offline? Calculated as a weighted average where recent restarts count more than old ones. A relay with 0 restarts in 30 days has perfect MTBF. Weighted Fractional Uptime (WFU): what fraction of recent consensus windows did the relay appear in? Each 1-hour consensus window counts - a relay that is online for 23 of 24 hours has 95.8% WFU for that day. For the Guard flag, WFU must consistently be above the threshold (approximately 98%). Improve stability: use a reliable VPS provider, set up systemd auto-restart (Restart=on-failure), configure unattended-upgrades for OS updates (to avoid security patch downtime exceeding the restart), and monitor the relay with external uptime checks.

Bandwidth Requirements for Guard Flag

The bandwidth requirement for Guard flag is dynamic: set at the median measured bandwidth of all relays in the current consensus. As the Tor network grows, the median bandwidth increases. In 2026, the median is approximately 2-5 Mbit/s sustained. To ensure your relay meets the bandwidth requirement with margin: set RelayBandwidthRate and RelayBandwidthBurst at least 20% above the current median. Monitor your relay's measured bandwidth (vs your configured rate) on Tor Metrics. Measured bandwidth is what the bandwidth authority (bwauth) observes, not your configured rate. If measured bandwidth is significantly below configured rate, investigate: network interface saturation, CPU overload (AES-NI not active), or VPS provider throttling. Measured bandwidth must be above the median for the Guard flag.

Long-Term Guard Relay Operation

Guard relays are used by clients for months at a time - Tor clients rotate guards infrequently to minimize the probability of being assigned a malicious guard. This long-term use creates value: clients who have selected your relay as their guard benefit from its security properties for the duration of that guard period. Implications for operators: Guard relays have higher sustained traffic than non-Guard relays because they are used consistently by assigned clients. Expect higher and more consistent bandwidth usage after earning the Guard flag. Plan VPS bandwidth allocation with Guard-level traffic in mind. Guard relays also have additional attack value to adversaries - they can see which clients use them as guards. This is a documented threat (guard discovery) but the Tor network's vanguard system (which adds a pre-guard layer for hidden services) mitigates some of this exposure.

Losing the Guard Flag and Recovery

The Guard flag can be lost if: measured bandwidth drops below the median (relay is overloaded or network connection degrades), WFU drops below threshold (relay has significant downtime), or the relay goes offline entirely for a significant period. Recovering the Guard flag after loss: address the underlying cause (upgrade bandwidth, fix stability issues), then wait for the relay to re-establish consensus presence with good stability metrics. Recovery typically takes 2-4 weeks of consistent stable operation. To minimize Guard flag loss: configure monitoring that alerts within 5 minutes of Tor process failure, use a VPS provider with strong uptime SLAs (99.9% or better), and schedule maintenance windows to minimize total downtime duration.

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Iceland VPS I