Running a Tor relay is not one decision — it’s four, scaling in exposure by roughly an order of magnitude at each step. A torrc file has one set of directives that decides which of four roles a machine plays: a stable, long-lived guard; an anonymous, structurally uninformed middle relay; an exit, where decrypted traffic re-enters the open internet under the operator’s own IP; or a deliberately unlisted bridge, built for users behind a censor’s firewall. Same binary, same protocol, four different risk profiles — the clearest real-world case study of how a volunteer network allocates adversarial exposure.
That allocation is the transferable lesson worth carrying past Tor: any system that needs volunteers to staff an adversarially exposed role has to solve an incentive problem before a technical one. Tor’s answer is to make three of the four roles cheap and safe to run in volume, concentrate the real legal risk in exactly one role, publish that risk in exhaustive detail instead of hiding it, and let operators self-select into it rather than compel anyone. What follows is what operating each role actually requires — the torrc posture, the bandwidth and stability bar, and, for the role where it matters most, the legal reality.
The Relay Spectrum: One Codebase, Four Risk Profiles
Every Tor relay runs identical software; what changes is which capability flags are set. Tor’s own relay documentation treats relay, bridge, and exit as three distinct operational postures rather than three products: an operator doesn’t choose a “type of Tor server” so much as how much of the network’s total risk to carry. A plain relay forwards already-encrypted circuit traffic and never originates a clearnet connection, so it’s essentially never a visible “source IP.” An exit sets an ExitPolicy allowing real egress ports and becomes the IP the destination site sees — inheriting abuse complaints, DMCA notices, and occasional law-enforcement inquiries for traffic it neither originated nor can identify. A bridge is kept out of the public relay list entirely so its address isn’t something a censor can simply download and block.
One scoping note: guard, middle, and exit are the three hops of an ordinary client circuit. Onion-service connections use a different topology — two independently built three-hop circuits joined at a rendezvous point, roughly six hops end to end — out of scope here and not to be conflated with the ordinary case.
| Role | Network exposure | Bandwidth / uptime requirement | Legal & abuse liability | Public in consensus? |
|---|---|---|---|---|
| Guard | Sees the client’s real IP; never sees destination or plaintext | Sustained bandwidth, weeks of measured uptime before the flag is granted | Essentially none — never originates outbound traffic | Yes |
| Middle | Sees neither endpoint, only adjacent circuit IDs | Same technical bar as guard, no flag threshold to clear | Essentially none — structurally never a “source IP” | Yes |
| Exit | Sees the destination and any unencrypted payload; never sees the client’s IP | Higher connection-count and RAM headroom for real egress traffic | Near-certain abuse complaints; occasional law-enforcement contact | Yes |
| Bridge | Sees the connecting client’s IP; withheld from the public list | Same technical bar as guard/middle | Low, plus a small amount of exposure on the operator’s own connection | No (deliberately) |
Guard and middle are the same operational commitment wearing two different flags — the directory authorities decide which relays earn the Guard flag, not the operator. Exit and bridge are opt-in decisions made explicitly in torrc: a relay can run for years without ever being offered the choice to become an exit, since exit and bridge are the two roles that require affirmatively asking for the exposure.
Guard Relays: Why Stability Outranks Everything Else
A relay doesn’t request the Guard flag in torrc — the directory authorities assign it based on weeks of measured behavior. Tor’s flag-assignment specification spells out the bar precisely: a router earns Fast if its bandwidth is in the top seven-eighths of known active relays, or at least 100 KB/s; it earns Stable if its weighted mean time between failures is at or above the network median, or corresponds to roughly seven days of continuous uptime. Guard status requires both plus a third condition — Weighted Fractional Uptime at or above the median for “familiar” relays (in practice, not among the newest eighth of the active population) — and bandwidth at or above the AuthDirGuardBWGuarantee consensus parameter (2 MB/s by default) or a place among the fastest quarter of the network.
None of that bar is arbitrary. It exists to defeat a predecessor attack: a client picking a fresh random first hop on every circuit will, given enough circuits over time, eventually hand its real IP to a hostile relay with near-certainty. The guard-persistence design that fixes this converts that compounding risk into a single, bounded one — but only if the guard set stays stable, exactly what Fast, Stable, and WFU measure. Running a guard isn’t a request; it’s proof, accumulated over weeks, that a relay is reliable enough to trust long-term.
Operationally, the guard torrc posture is unglamorous: an ORPort, a Nickname and ContactInfo for accountability, no ExitPolicy allowances, and — the part that actually earns the flag — consistent uptime. Tor’s relay-requirements guidance sets a practical floor around 10 Mbit/s of sustained bandwidth per direction (16 Mbit/s recommended), a minimum of 100 GB monthly traffic capacity, headroom for several thousand concurrent connections, and — the guard-specific requirement — reachability over two hours a day, ideally continuously. See Understanding Internet Bandwidth for Engineers and Architects for what those figures mean in practice; a relay that’s only up sporadically never clears the Stable bar, regardless of raw bandwidth on paper.
Middle Relays: The Safest Role in the Network
Middle relays run the identical binary and meet the identical bandwidth and uptime bar as a guard — the only difference is which position in the circuit path-selection weights put them in, and a middle relay has no flag threshold of its own to clear. Worth calling out separately: what it structurally cannot see. A middle relay never touches a circuit’s origin or destination, only the circuit IDs of the guard and exit on either side of it. It can never be the visible “source IP” for anything, because it never originates a connection to the open internet on anyone’s behalf — every byte that arrives is still wrapped for the next hop.
That makes middle the lowest-friction way to contribute real capacity: the same torrc skeleton as a guard (ORPort, Nickname, ContactInfo, default reject-all exit policy), no reverse-DNS conventions, no abuse-response process, and no legal exposure distinct from any other internet-facing infrastructure. It’s also the role most new operators are steered toward first — a relay must accumulate the Stable/Fast track record above before the directory authorities trust it with Guard, and running unflagged as a middle relay is how that record gets built.
Exit Relays: Where the Real-World Consequences Live
An exit relay earns its flag by a much simpler rule than a guard does: the same flag specification calls a router an Exit if it allows connections to at least one /8 address block on both port 80 and port 443. Clearing that bar is a torrc decision, not a weeks-long trust-building process — ExitRelay 1 plus an ExitPolicy permitting real egress ports is enough. What isn’t optional is what happens next: the destination site sees the exit relay’s IP, not the client’s, and any traffic the client didn’t already encrypt at the application layer becomes visible in plaintext to that exit — the one place in an otherwise fully layered system where decrypted data legitimately exists on the wire again. That’s precisely why application-layer encryption still matters on top of Tor; see Encrypt and Secure Your Data.
Tor’s own setup guidance tells new exit operators to start with a ReducedExitPolicy rather than allowing every port, specifically to cut the volume of abuse email a new exit generates, and to run exits on dedicated servers rather than machines used for anything else. It also gives concrete advice for the abuse mail that arrives regardless: put something like “tor-exit” in the reverse-DNS hostname (see What is the Domain Name System? for how that record resolves), make sure the IP’s WHOIS record identifies it as a Tor exit, and — pointedly — never use a torproject.org domain for that entry, since it isn’t a Tor Project server. Each step exists to make the honest fact — “this address is a shared exit for unrelated third-party traffic” — legible to whoever receives an automated complaint, before a human has to explain it manually.
That gets at the framing worth getting exactly right: the Tor Project’s position that operating an exit relay is legal is a stance, not a ruling. Tor’s abuse-and-legal guidance and the EFF’s Legal FAQ for Tor Relay Operators both hold running relays, including exits, is lawful under current U.S. law, grounding the argument in Section 230’s intermediary immunity and the DMCA’s Section 512(a) safe harbor for material merely transmitted without modification — a fair description of what an exit does to traffic passing through it. Neither is a ruling binding every jurisdiction, and the EFF says plainly that new technologies create legal uncertainty no FAQ resolves in advance.
What the EFF’s guidance is not ambiguous about is the operational reality underneath: law enforcement has, in documented cases, mistaken an exit’s traffic for traffic the operator originated, leading to seized equipment and home visits — why the standing advice is to never run an exit from a home connection, use a commercial Tor-friendly host instead, register the IP’s purpose with ARIN, and never inspect the plaintext passing through to self-police it (that risks wiretap-statute liability of its own). Middle and guard relays carry none of this: they never originate a connection to anything, so there’s no destination-side observer to mistake them for the source.
| Flag | What it means | Threshold |
|---|---|---|
| Fast | Eligible to carry meaningful traffic | Bandwidth in the top 7/8 of active relays, or ≥100 KB/s |
| Stable | Reliable enough for long-lived circuits | Weighted MTBF ≥ network median, or ≥7 days |
| Guard | Trusted as a client’s first hop | Fast + Stable + WFU ≥ median for “familiar” relays, and bandwidth ≥ AuthDirGuardBWGuarantee (2 MB/s by default) or top 25% fastest |
| Exit | Permitted as a circuit’s last hop for real egress traffic | Allows connections to ≥1 /8 block on both ports 80 and 443 |
| Running | Currently reachable | Contacted successfully on all published ORPorts within the last 45 minutes |
(Source: Tor’s directory-authority flag specification. AuthDirGuardBWGuarantee and similar consensus parameters are tunable — re-check the live spec before citing a specific value.)
Bridges: Unlisted Relays for Censored Networks
A bridge solves a different problem than the other three roles: not “how much risk does the operator carry,” but “how does a censored user get past a firewall that blocks the public relay list in the first place.” Tor’s own bridge setup guidance treats a bridge as a relay with one directive flipped: BridgeRelay 1 plus PublishServerDescriptor 0 runs the same circuit-forwarding code as any other relay while deliberately withholding its descriptor from the public consensus a censor could otherwise download and block wholesale. A bridge run this way is still detectable by protocol fingerprint under deep packet inspection — why bridges are almost always paired with a pluggable transport, most commonly obfs4. Adding ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy and ExtORPort auto makes the connection to the bridge resemble uniform random noise rather than a recognizable Tor handshake — obfs4’s own spec describes that Elligator2-based construction — defeating passive DPI in addition to hiding the address.
Because bridges are unlisted by design, the distribution problem moves outside torrc entirely: a bridge is only useful to people who receive its address through a channel a censor hasn’t also blocked. Operationally, running one costs the same as a plain relay — same bandwidth and uptime floor, same low abuse profile, since a bridge, like a middle relay, never originates a clearnet connection on anyone’s behalf. What it adds is a small amount of visible-to-a-censor risk on the operator’s own connection, since an unusual protocol wrapper is itself a faint signal something is being deliberately obscured.
One version-pinned caution: as of Arti 2.0.0 (February 2026), Tor’s Rust reimplementation is production-ready as a client and for onion services, but its release notes are explicit that relay, bridge, and directory-authority operation is not yet supported. Anyone setting up a guard, middle, exit, or bridge today needs the standard C Tor daemon.
AccountingMax: Bounding the Bandwidth Commitment
Every role above shares one operational lever unrelated to which flag a relay holds: AccountingMax. Tor’s bandwidth-limiting documentation describes a pair of directives — AccountingStart, setting when a metering period resets, and AccountingMax, capping how much data the relay sends, and separately receives, before it stops relaying new traffic until the period rolls over. A relay capped at 50 GB per direction on a daily reset (AccountingStart day 00:00, AccountingMax 50 GBytes), paired with RelayBandwidthRate/RelayBandwidthBurst to shape throughput within that budget, gives an operator on a metered connection a hard ceiling with no manual attention required — the kind of throughput-shaping tradeoff covered generally in Measuring Network Performance.
The trade-off runs through the Fast and Stable flags above: aggressive accounting caps that make a relay hibernate for hours will eventually cost it those flags, since a relay that goes dark every night never clears the uptime bar they measure. AccountingMax is the honest way to say “I can contribute bandwidth, but not unlimited bandwidth, and not around the clock” — legitimate, but it trades away Guard-flag eligibility specifically, since guard status depends on sustained, continuous-enough reachability above any other factor.
Why Every Additional Relay Strengthens the Anonymity Set
None of the four roles matter in isolation; they matter because of what a larger population of honestly-run relays does to an adversary’s odds. The guard-persistence design above only works if the pool of candidate guards is large and diverse enough that a hostile operator can’t cheaply buy a large fraction of it — the same logic Dingledine and Mathewson formalized as Anonymity Loves Company at WEIS 2006: a rational user picks an anonymity system partly by the size of its existing population, because the anonymity set a system provides is its population, cryptography notwithstanding. Every additional honestly-run relay dilutes the fraction of the network an adversary would need to run to have a meaningful chance of controlling a client’s full circuit.
That dilution isn’t uniform across roles. A hostile guard is dangerous because guards are trusted and persistent — the predecessor-attack math above. A hostile exit is dangerous because it’s the one position where plaintext legitimately becomes visible again. A hostile bridge is dangerous mainly to the specific users handed its address. Capacity added to the scarce, high-exposure roles — exit most of all — does more per relay to keep the pool an adversary would need to dominate large and expensive, precisely because so few volunteers choose to run them.
The Transferable Lesson: Aligning Incentives When the Risky Role Is Scarcest
Step back from Tor and this is a recognizable resourcing problem: a distributed system needs volunteers to staff a role with real legal exposure, and has no way to compel anyone into it. Tor’s answer solves the incentive problem before the technical one, in three moves that generalize past onion routing.
First, make the low-exposure roles trivially easy to run in volume: guard and middle relays share one torrc skeleton and one bandwidth bar, with essentially zero legal distinctiveness from any other internet-facing server — why they make up most of the network’s capacity. Second, don’t hide the cost of the high-exposure role — publish it in exhaustive detail: Tor’s abuse-expectations page and the EFF’s legal FAQ document reverse-DNS conventions, hosting recommendations, and the exact statutory arguments an operator can point to, because knowing a risk’s real shape in advance makes it easier to accept than discovering it afterward. Third, and easiest to get backward — never make the risky role mandatory. A relay running only as guard or middle contributes real, measured capacity without ever accepting exit-level exposure.
That’s the pattern worth stealing for any system — a CDN edge network, a package-registry mirror pool, a blockchain validator set — that depends on volunteers to staff a role with uneven legal exposure (see The Best Books on Distributed Systems for how such systems get built at all). Segment the roles so exposure is opt-in, be exhaustively honest about what the exposed role costs, and keep the easy roles easy enough that they don’t sit empty waiting for someone willing to take the hard one. The scarce role stays scarce regardless — Tor’s exit capacity has been structurally limited since the network’s earliest years — but this pattern at least ensures the scarcity is a supply problem, not a design failure that drove volunteers away.
❓ Frequently Asked Questions
Do I need a static IP address to run a Tor relay? No. Tor’s relay-requirements guidance accepts a dynamic IP as long as it stays stable for a few hours at a stretch; what matters for the Fast, Stable, and Guard flags is consistent reachability over days and weeks, not a fixed address.
Is running a Tor exit relay legal? The Tor Project and the EFF both hold that running an exit relay is lawful in the U.S., citing Section 230 and DMCA Section 512(a) safe-harbor protections. That’s their organizational stance and legal argument, not a court ruling binding every jurisdiction — abuse complaints are near-certain regardless.
Will I get in legal trouble for running a middle relay? Structurally, a middle relay never originates a connection to the open internet and is never the visible “source IP” for anything, which is why the EFF treats middle and bridge operators as carrying materially lower risk than exits.
How much bandwidth does a relay actually need? Tor’s community documentation sets a practical floor around 10 Mbit/s sustained per direction (16 Mbit/s recommended), roughly 100 GB monthly traffic capacity, and headroom for several thousand concurrent connections — more for a busy exit.
What’s the difference between a bridge and just not publishing my relay’s descriptor? Withholding the descriptor (PublishServerDescriptor 0) is the mechanism, but a bridge is usually paired with a pluggable transport like obfs4 too — the unlisted address defeats a block-list, and the transport separately defeats the deep packet inspection that would otherwise fingerprint Tor on the wire.
Can I run a relay, bridge, or exit using Arti instead of the standard Tor daemon? Not yet. Arti 2.0.0 (February 2026) is production-ready as a client and for onion services, but its release notes state plainly that relay, bridge, and directory-authority operation are not supported. All four roles here need the standard C Tor implementation.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Security Engineering: A Guide to Building Dependable Distributed Systems
Ross Anderson · Book · 3rd edition
The canonical text on threat-modeling real adversaries rather than imagined ones — the same discipline behind why Tor treats guard, middle, exit, and bridge as four distinct risk profiles instead of one undifferentiated “run a server” decision. If the exit-relay liability section above landed for you, this is the thousand-page version of that reasoning.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
Martin Kleppmann & Chris Riccomini · Book · 2nd edition
The reliability grounding behind everything this article covers operationally: uptime, stability flags, and bandwidth accounting are all instances of the same distributed-systems problem — keeping a volunteer-operated node trustworthy inside a network that has no central operator to fall back on.
Distributed Systems
Andrew S. Tanenbaum & Maarten van Steen · Book · 3rd edition
The broader field this article’s transferable lesson belongs to: how you design a system that depends on independent, self-interested operators to carry real load. Tor’s guard/middle/exit/bridge split is one worked example of a pattern that recurs across CDNs, mirror networks, and validator sets.
Free and worth more than any book here: the primary sources this article cites — Tor’s own relay-setup and abuse-and-legal documentation at community.torproject.org and support.torproject.org, and the EFF’s Legal FAQ for Tor Relay Operators.