When a new relay stays online but doesn’t receive Guard or Fast, it can feel like an invisible failure. Usually, it isn’t. Tor relay flags come from the signed network consensus, and your server cannot enable them with a line in torrc.
For a new relay operator, this distinction prevents wasted troubleshooting. These labels help Tor clients choose relays that are reachable, stable, fast enough, or safe for a certain role. Time-based eligibility can take days or longer, so the sections ahead focus on what the labels mean and which operational checks matter.
Key Takeaways
- Tor relay flags come from the signed network consensus, not from settings in
torrc. Running,Valid,Fast, andStablereflect reachability, accepted software, measured capacity, and long-term reliability.Guard,Exit,HSDir, andMiddleOnlydescribe relay roles with different eligibility rules and operational responsibilities.- New relays may need days or longer to receive time-based flags, so check reachability, firewall rules, NAT, logs, and uptime before changing configuration.
- Choose a relay role deliberately, protect the server, and treat consensus flags as network observations rather than safety certifications.
How Flags Appear in the Consensus
Tor relay flags are assigned through the official flag assignment rules, which explain how authorities choose each relay’s flags. Relays publish descriptors, directory authorities test reachability and relay behavior, and authorities vote before publishing a signed network consensus. Clients receive it and use it to build paths through the Tor network.
Your torrc file affects what your relay offers. It can set an ORPort, apply an exit policy, set bandwidth limits, and publish contact info. It does not grant Guard, Stable, Fast, or HSDir status. Each Tor relay has a persistent identity represented by a fingerprint.
A relay flag is the network’s current view of your relay, not a setting you can enable yourself.
The consensus updates regularly, so a relay may gain or lose flags after a restart, configuration change, reachability issue, or long period of uptime. Tor’s flag rules can also change as the protocol evolves.
Tor metrics can support monitoring and research, but the signed consensus, not a dashboard, is the authoritative status record.
A bridge relay is handled differently from a publicly listed relay, so its status may not appear in the public consensus. The phrase bad relay is plain-language shorthand for a relay that may be restricted, not a formal consensus flag.
That distributed coordination supports censorship resistance, but no individual flag certifies safety.
The Flags New Operators See First
Running, Valid, Fast, and Stable
These flags describe what authorities observe about a Tor relay, not simply what runs on the server. Running requires a recent connection through the published ORPort; a local process alone won’t qualify, and firewall, NAT, or address errors can prevent it.
Valid means the relay uses an accepted Tor version and hasn’t been treated as suspicious. StaleDesc means its descriptor is old, usually over 18 hours, pointing to publishing or connectivity problems.
Fast reflects measured capacity for higher-bandwidth circuits, while Stable reflects long-term reliability and can influence circuit selection. Tor metrics show these measurements but can lag the latest consensus. Authorities use relay activity and weighted mean time between failures, not simple uptime.
Guard, Exit, BadExit, and MiddleOnly
A Guard flag identifies a guard relay, a client’s entry point into the Tor network. It needs fast, stable operation because clients may keep it for long periods. A weak or frequently restarted server won’t become useful for this role.
An Exit becomes an exit relay when its exit policy permits traffic to reach public internet destinations. A middle relay carries traffic between circuit positions and usually has less legal exposure than an exit. Tor’s relay type guidance notes that guards and middle positions generally receive fewer abuse complaints than exits.
BadExit differs from Exit: authorities restrict it from exit traffic, often after unsafe behavior or incorrect DNS handling. An unsafe or incorrect exit policy can trigger this restriction. MiddleOnly limits a relay to the middle position, helping when it shouldn’t act as a guard or exit.
HSDir, Authority, and V2Dir
HSDir means Hidden Service Directory, and these relays store encrypted descriptors that help users reach an onion service. A relay usually needs Fast and Stable status plus about 96 hours of uptime to qualify, though eligibility rules can change.
Authority identifies one of the directory authorities. New operators shouldn’t expect this flag; these authorities are a small, managed part of Tor’s infrastructure.
V2Dir is a directory-protocol capability flag, mostly a compatibility detail rather than an operator target. Don’t open extra public ports merely to pursue a legacy-looking flag.
Match Your Relay Setup to Its Real Role
Guard and Middle Relays Need Consistency
A guard relay or middle relay is a good starting role for most new operators. It carries encrypted traffic through the Tor network but does not send user traffic to public websites. Choose your Tor relay’s role before tuning its configuration. A non-exit configuration should use a restrictive exit policy such as ExitPolicy reject *:*.
For a middle relay, translate the documented bandwidth recommendations into a realistic bandwidth rate. Tor Project guidance lists 10 Mbit/s upload and download as a practical minimum, with 16 Mbit/s recommended. It also suggests capacity for 7,000 concurrent connections, 100 GB monthly traffic in each direction, and 24/7 uptime where possible. Use those figures to assess your network capacity, then review the current relay requirements before committing server resources.
A stable static IP and a public IP address improve reachability. If you use NAT, forward the chosen ORPort correctly. Port 443 can help where less common ports are blocked, but it isn’t mandatory.
Exit Relays and Bridges Are Different Choices
An exit relay needs a clear exit policy, a working DNS resolver, contact info for abuse reports, and an understanding of local law. Don’t operate one casually from a home connection or business network, since abuse complaints can create legal and operational risks. Tor’s operator expectations are a sensible baseline before you permit exit traffic.
A bridge relay isn’t the same as a public relay. It helps provide censorship resistance for users who can’t reach public relays, and it doesn’t appear in the public consensus in the same way. Don’t evaluate a bridge relay using the public flag expectations you would apply to a public relay.
Your role should drive the configuration. Don’t select Exit because it sounds important, and don’t chase Guard before your uptime and available resources support it.
Why Your Relay May Not Receive Expected Flags
Check Reachability, Ports, and Relay Logs
A healthy Tor relay and valid server configuration don’t prove that remote peers can reach it.
Start with simple checks. Run tor --verify-config -f /etc/tor/torrc before restarting after a configuration edit. Then review your Tor logs for lines about ORPort binding, descriptor publishing, address discovery, and authority connections.
On many systemd Linux installs, journalctl -u tor@default -n 100 shows recent Tor messages. Some distributions use a different service name, so check your package documentation. ss -ltn can confirm that the expected TCP port is listening locally. A listening socket alone doesn’t prove public reachability.
Inspect the data directory for descriptor and state files, but don’t publish their contents.
Check these issues before changing anything else:
- Confirm your firewall and cloud security group allow inbound TCP traffic to the published ORPort.
- Check that NAT forwards the port to the same server running Tor, and confirm the public IP address is correct.
- Use a static IP when possible. Frequent address changes make a relay less useful.
- If you operate multiple relays, review their family configuration so related identities are declared correctly.
- Avoid restarting the relay repeatedly while waiting for consensus updates.
Compare the published status with external measurements in Tor metrics. If this is a bridge relay, don’t expect the same public flags as a public relay.
Give Time-Based Flags Time
A new relay may receive Running before it receives Fast, Stable, Guard, or HSDir. HSDir status has an uptime requirement of about four days. Stable and Guard depend on observed behavior over time and uptime statistics, not a promise in your configuration file. Tor metrics may lag local changes, so don’t treat a mismatch as immediate failure.
If BadExit or MiddleOnly appears, read the logs and inspect the configured exit policy first. A bad relay is often a configuration problem, not a formal flag. For an exit relay, a broken DNS setup, incorrect open resolver, or unsafe behavior can create problems. Tor’s bad relay guidance explains why misconfigured relays can be restricted.
Don’t publish private logs, IP details, or full configuration in public support requests. Remove sensitive information, then report unusual behavior through Tor’s community channels or your hosting provider.
Run a Relay With Security and Ethics in Mind
Protect the Server Behind the Relay
Use a supported operating system, patch it regularly, and keep your Tor relay separate from unrelated web applications. Review the server configuration carefully, and expose only the ports you need. As a relay operator, restrict SSH with key-based access, disable unused services, and monitor disk space, memory, and bandwidth limits.
If you believe a server has been compromised, isolate it, preserve logs, and contact your provider. Don’t scan, probe, or retaliate against another system. For authorized security testing, use a qualified service such as Pro Ethical Hackers For Hire, with written permission and a defined scope.
If you run an exit relay, review local laws and provider rules before enabling public egress. Respond carefully to abuse complaints, and document the configured egress rules and relevant system activity.
Declare relays under common control through a family configuration. Each relay has its own identity and fingerprint, but clear declarations help prevent unintended circuit relationships. The Tor network and circuit selection separate relay positions where possible, yet they don’t eliminate traffic analysis or end-to-end correlation.
Treat Onion Directories as Research, Not Trust Signals
People looking for verified Tor websites, Verified onion links, or deep web sites can mistake a directory entry for a safety approval. A directory or watch page supports discovery, but it can’t prove that a relay is reliable or that an onion service is safe.
A bridge relay can help users reach Tor when public relays are blocked. An onion service isn’t made safe merely by appearing in a directory. Misconfiguration and harmful operational practices can also create a bad relay, so check sources and avoid sensational claims.
Tor supports legitimate privacy, journalism, research, and censorship resistance. That doesn’t make illegal activity acceptable, and operators can’t inspect the contents of properly encrypted traffic.
For research and education, Verified Tor Onion Links may serve as one reference, but relay status should come from Tor’s consensus and official Tor Project documentation.
Frequently Asked Questions
Can I enable a Tor relay flag in torrc?
No. Flags such as Guard, Fast, Stable, and HSDir are assigned by directory authorities and published in the signed consensus. Your configuration can affect relay behavior, but it cannot grant a flag directly.
How long does a new relay take to receive flags?
A relay may receive Running before it receives time-based flags such as Stable, Guard, or HSDir. HSDir eligibility usually requires about 96 hours of uptime, while other flags depend on observed reliability and capacity.
Why is my relay not marked Running?
Running requires remote reachability through the published ORPort, so a local Tor process and listening socket are not enough. Check the firewall, cloud security group, NAT forwarding, public IP, ORPort configuration, and Tor logs.
What is the difference between a middle relay and an exit relay?
A middle relay carries encrypted traffic between circuit positions and normally uses a restrictive exit policy. An exit relay permits traffic to public internet destinations, which brings additional DNS, abuse-reporting, legal, and operational responsibilities.
Are Tor relay flags proof that a relay is safe?
No. Flags describe what the network has observed about a relay, such as its reachability, capacity, or role eligibility. They do not certify the operator, the relay’s safety, or the safety of an onion service discovered through a directory.
Final Thoughts
The flags in the consensus tell clients what the network has observed about your relay over time. They are useful signals, not trophies or manual configuration options.
Build a stable, reachable Tor relay, publish a reachable ORPort, and choose a sensible role. A bridge relay has different visibility and expectations. Read the logs before making major changes.
Reliable operation supports censorship resistance, but it doesn’t remove every privacy risk, including end-to-end correlation.