How to Run a Tor Relay: Guard, Middle, Exit, Bridge, Legal, Hardening

To run a Tor relay, pick a role you can support, install tor from the Tor Project's own package repository on a dedicated server, set a public ContactInfo, an ORPort and ExitRelay 0 in torrc, and keep the host patched automatically. Middle and guard relays need at least 10 Mbit/s each way; bridges need 1 Mbit/s. Exit relays carry legal exposure and should never run from home.

This guide goes one level deeper than our posts on Oblivious HTTP relays, private search and browsers and setting up a WireGuard VPN. Every figure comes from the Tor Project's relay documentation, the tor manual page or the Tor specifications. The legal section is general information, not legal advice. A past exit relay incident is covered separately in Tor exit relays hijacked for SSH interception, so we do not repeat it here.

Key takeaways

• A circuit has three hops: guard, middle and exit. A bridge is an unlisted relay that takes the guard position for censored users.
• The Tor Project says exit relays carry "the greatest legal exposure" of any relay type, and both it and the EFF legal FAQ say not to run an exit from home.
• Minimums: 1 Mbit/s for a bridge; 10 Mbit/s (16 recommended), 100 GB a month, 512 MB of RAM and a stable public IPv4 address for a middle or guard relay.
• Install from the Tor Project repository and stay on a supported series. Stable on 25 October 2026 is tor 0.4.9.14; 0.4.8.x reached end of life on 1 June 2026.
• Running more than one relay? Declare a family with a shared key and FamilyId.
• Monitor with Relay Search, Onionoo, nyx and a locked down MetricsPort, and never publish fine grained statistics.

How does a Tor circuit work?

The Tor Project's relay guide draws the standard path as: Tor user, guard relay, middle relay, exit relay, destination. With a bridge, the bridge takes the first position.

• Guard. The first hop and the only relay that sees the user's IP address. Clients keep a small set of guards for weeks. A 2013 Tor Project post explains why: if a client kept choosing new random first hops, the chance that an attacker running a few relays eventually sees one of its paths would climb toward certainty.
• Middle. Knows the guard and the exit, but neither the user nor the destination.
• Exit. Opens the connection to the destination, which sees the exit's IP address. Exits also resolve DNS for clients.

The path specification says clients choose the exit first, then the guard, then the middle. They never use relays without the Fast flag for normal circuits, never use one relay twice, never put two relays from the same family in one path, never pick two relays in the same /16 IPv4 or /32 IPv6 network, and the first hop must be a Guard. That family rule is why declaring your relays matters.

Directory authorities and the consensus

Clients learn about relays from the directory system, not by scanning. The version 3 directory protocol describes a small set of semi-trusted directory authorities whose list ships with tor:

1. Each relay periodically uploads a signed descriptor listing its keys, capabilities and exit policy.
2. Each authority builds its own view of known relays and sends a signed status vote to the others.
3. The authorities compute the result and sign a consensus document.
4. Directory caches re-serve the consensus to clients.

Authorities keep their long term identity keys offline or encrypted and sign medium term keys valid for 3 to 12 months. Each consensus carries valid-after, fresh-until and valid-until times, so clients know when their copy is stale.

What the relay flags mean

Flags in the consensus decide which positions clients use you for. This table follows the "Assigning flags in a vote" section of the directory specification, which notes that authorities may change these behaviours.

Once 500 or more relays have measured bandwidth (the default threshold), authorities base flags on measurements and treat unmeasured relays as zero. That is part of why a new relay is quiet at first.

What does each relay type expose you to?

Guard and middle relays do not send traffic to the internet, and the Tor Project says they "usually do not receive abuse complaints." Their IPs are public, though, so services that block Tor, such as some banking and streaming sites, may block them. If your relay shares your only home IP, that block hits your own browsing, and the Tor Project suggests a bridge or Snowflake proxy instead.

Exit relays are what the internet sees. A user downloading copyrighted material through your exit can bring a DMCA notice, and complaints reach you through your host depending on WHOIS records. The Tor Project says most can be handled "through template letters," but that exits should not run from home and that ideal operators are institutions such as relay associations, universities, libraries or hackerspaces.

Bridges are not listed in the public directory, so they are harder to block. The Tor Project calls them "relatively easy, low-risk and low bandwidth" and says a bridge "isn't likely to receive any abuse complaints". It also notes that several countries have learned to detect and block plain bridge connections, which is why pluggable transports exist.

Pluggable transports: obfs4, Snowflake and WebTunnel

• obfs4 bridge. Tor with BridgeRelay 1 plus an obfs4 transport process (the project was renamed lyrebird). Needs 24/7 connectivity and two reachable TCP ports.
• Snowflake proxy. Snowflake is built into Tor Browser and other Tor powered apps. A standalone proxy needs only connectivity, but the Tor Project recommends 24/7 uptime, a full cone NAT or none, and inbound UDP open across the ephemeral port range. The requirements page points anyone below relay or bridge minimums to Snowflake.
• WebTunnel bridge. "Attempts to imitate web browsing activities." Needs a web server and domain you control, a valid TLS certificate, a static IPv4 address preferably, and at least 1 GB of RAM (4 GB recommended).

Two rules apply to every bridge. The expectations document discourages running a bridge and a public relay on the same IP, since censored users lose the bridge when the relay's IP is blocked. The manual says never to list a bridge in a public relay's family, because that reveals it.

Bridge, middle, guard and exit compared

You never choose "guard" in torrc. You run a non-exit relay, and the authorities assign the Guard flag once it qualifies.

What do you need to run a relay?

The Tor Project's relay requirements page sets these numbers.

A few details:

• 100 GB is a low floor. The Tor Project says it is about one day on a 10 Mbit/s line: 1.25 MB/s for 86,400 seconds is 108 GB.
• Eight relays per IPv4 address at most.
• AES-NI lets one tor instance reach roughly 400 to 450 Mbit/s each way on modern CPUs. Check with grep aes /proc/cpuinfo.
• No downgrades. Relays that try to move to an insecure, unsupported version "will be rejected from the network automatically."
• Time. The technical considerations page calls correct time "essential" and recommends NTP.

Home connection or VPS?

The technical considerations page says physical hardware on a fast line (100 Mbit/s or more each way) is best, at home or in a data center, and that rented servers cost from about $3 a month to thousands. At home, the 7,000 connection load "can overwhelm consumer-level routers", and your IP becomes public. For most home volunteers a bridge or Snowflake proxy is the better contribution.

Before buying hosting, the same page suggests asking: is traffic unmetered or throttled, is IPv6 available, which virtualisation is used (anything but OpenVZ should be fine), and, for exits, whether exits are allowed at all and whether you can set custom WHOIS and reverse DNS records. It asks operators to avoid networks that already host many relays, names four large ones by AS number, and links Relay Search's AS and country views so you can check. It also says the network "would most benefit from BSD and other non-Linux based relays". Read the community's good and bad ISPs page before you sign up.

Step by step: a middle relay on Debian or Ubuntu

This follows the Tor Project's Debian and Ubuntu guide and post install steps, with every torrc option checked against the tor 0.4.9.14 manual page. Run as root on a fresh, dedicated server.

1. Turn on automatic security updates

The guide's first step: "install security updates timely and ideally automatically." Install the tools:

apt-get install unattended-upgrades apt-listchanges

Replace /etc/apt/apt.conf.d/50unattended-upgrades with the stanza for your OS. Debian:

Unattended-Upgrade::Origins-Pattern {
    "origin=Debian,codename=${distro_codename},label=Debian-Security";
    "origin=TorProject";
};
Unattended-Upgrade::Package-Blacklist {
};
// Optional: reboot automatically when an update needs it
Unattended-Upgrade::Automatic-Reboot "true";

Ubuntu:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "TorProject:${distro_codename}";
};
Unattended-Upgrade::Package-Blacklist {
};

Then /etc/apt/apt.conf.d/20auto-upgrades on either:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::AutocleanInterval "5";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Verbose "1";

Test without changing anything:

unattended-upgrade --debug --dry-run

The TorProject origin is what lets tor itself update unattended. For how third party origins behave in general, see does unattended-upgrades install PPA and third party updates.

2. Add the Tor Project repository

The install page is blunt: "Do not use the packages in Ubuntu's universe. In the past they have not reliably been updated." Debian's own repository carries the long term support version, which may lag the latest stable. The Tor repository serves amd64 and arm64 only, for current Debian and Ubuntu releases up to the end of their LTS cycles.

dpkg --print-architecture          # must print amd64 or arm64
apt install apt-transport-https gnupg
lsb_release -c                     # your codename, e.g. trixie or noble

Create /etc/apt/sources.list.d/tor.sources with your codename:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

Add the signing key and install tor with the keyring package that keeps the key current:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor | tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
apt update
apt install tor deb.torproject.org-keyring
tor --version

The Tor download page lists 0.4.9.14 as stable on 25 October 2026. Leave out the experimental and nightly suites; the setup guide reserves alphas for people "eager to test and report bugs".

3. Write the torrc

# /etc/tor/torrc  (middle or guard relay, non-exit)
Nickname myNiceRelay
ContactInfo tor-ops@example.org
ORPort 443
ExitRelay 0
SocksPort 0

# Optional caps, see the bandwidth section
#AccountingStart month 1 00:00
#AccountingMax 1900 GBytes

# Only if you run more than one relay
#FamilyId PASTE_VALUE_FROM_tor_--keygen-family

Log notice syslog
SafeLogging 1
Sandbox 1

# Local control port for nyx
ControlPort 127.0.0.1:9051
CookieAuthentication 1

Start once with Sandbox 1 and read the log. If tor refuses to start, remove it.

4. Open the firewall

The post install guide asks for inbound access to the ORPort and all outbound connections allowed. The expectations document repeats: "Don't block outgoing connections." This nftables ruleset is adapted from the nftables wiki's simple server example:

#!/usr/sbin/nft -f
# /etc/nftables.conf
flush ruleset

table inet firewall {
  chain inbound_ipv6 {
    icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
  }

  chain inbound {
    type filter hook input priority 0; policy drop;
    ct state vmap { established : accept, related : accept, invalid : drop }
    iifname lo accept
    meta protocol vmap { ip6 : jump inbound_ipv6 }

    tcp dport 22 accept    # SSH: restrict to your admin address if you can
    tcp dport 443 accept   # Tor ORPort
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  # No output chain: outbound stays open, as Tor requires
}

Load it with nft -f /etc/nftables.conf from a console you can fall back to. Our guide to an nftables default drop ruleset without locking yourself out covers the safe order. The post install page also recommends per source connection limits against denial of service attacks and links two community rule sets, with a warning to review them first because attacks change.

5. Start tor and confirm it works

systemctl restart tor@default
journalctl -e -u tor@default

Success looks like:

Self-testing indicates your ORPort is reachable from the outside. Excellent.
Publishing server descriptor.

About three hours later the relay should appear on Relay Search under its nickname or IP.

6. Check it from the command line

Relay Search runs on Onionoo, the Tor Metrics API. Its search parameter matches part of a nickname or the start of a fingerprint:

curl -s "https://onionoo.torproject.org/details?search=myNiceRelay&fields=nickname,flags,consensus_weight,recommended_version,version_status,or_addresses,last_restarted"

flags shows what the authorities assigned, consensus_weight is the weight clients use for path selection, and recommended_version tells you whether your version is still recommended. Search a bridge by its hashed fingerprint.

7. Back up the identity keys

Copy /var/lib/tor/keys somewhere secure after first start. If a disk fails, restoring the keys keeps the relay's history instead of restarting the ramp up. The post install page warns that stolen keys "could theoretically allow traffic decryption or impersonation".

Bandwidth limits and a worked example

Tor does not limit bandwidth by default. The manual describes two tools:

• Rate limits (RelayBandwidthRate, RelayBandwidthBurst, BandwidthRate) use a token bucket in bytes per second and count TCP data only, not headers or DNS. Tor uses powers of two, so 1 MByte is 1,048,576 bytes.
• Accounting (AccountingMax, AccountingStart, AccountingRule) caps traffic per period. By default it counts the larger of sent or received; AccountingRule sum counts both. When the quota runs low tor stops accepting new circuits, then hibernates until the next period.

Example 1: a 2 TB monthly plan. 2 TBytes is 2 x 1,099,511,627,776 = 2,199,023,255,552 bytes. Spread across a 30 day month (2,592,000 seconds), that is about 848,000 bytes per second, or about 6.8 Mbit/s, below the 10 Mbit/s minimum. A flat cap would make the relay too slow to be useful, and the post install guide says "Having a fast relay for some time of the month is preferred over a slow relay for the entire month." Let it run fast and hibernate instead:

AccountingStart month 1 00:00
AccountingMax 1900 GBytes

Setting the cap a little under the plan leaves headroom for SSH, updates and overhead tor does not count.

Example 2: sharing a 50 Mbit/s home upload. To give tor 20 Mbit/s: 20,000,000 / 8 = 2,500,000 bytes per second, which is about 2,441 KBytes in tor's units. RelayBandwidthRate 2400 KBytes with RelayBandwidthBurst 4800 KBytes holds tor near that target.

IPv6, families and offline keys

IPv6

The post install guide encourages IPv6, "especially valuable on exit and guard relays", but tor cannot run IPv6 only. Since tor 0.4.5 an ORPort without an address binds both families and tor auto-discovers your IPv6 address, publishing IPv4 only if discovery fails. An explicitly configured IPv6 ORPort that fails its reachability check stops the relay publishing at all, so test first with the guide's ping of the directory authorities:

ping6 -c2 2a02:16a8:662:2203::1 && ping6 -c2 2620:13:4000:6000::1000:118 && \
ping6 -c2 2001:67c:289c::9 && ping6 -c2 2001:678:558:1000::244 && \
ping6 -c2 2001:638:a000:4140::ffff:189 && echo OK.

Pin an address with a second line such as ORPort [2001:db8::10]:443, or disable IPv6 with AddressDisableIPv6 1.

Declaring a relay family

Clients must know your relays share an operator so they never use two in one circuit. The post install guide calls this necessary "to avoid putting Tor clients at risk." The current method, "Happy Families," arrived in tor 0.4.9.2-alpha and uses one shared secret key:

tor --keygen-family MyKey
# Prints: FamilyId <your id>   (save it)

Copy MyKey.secret_family_key into the keys directory of every relay (the name must end in .secret_family_key), add the FamilyId line to each torrc, and reload. A family-cert entry in the descriptor confirms it worked. To rotate a leaked key, add a new key and FamilyId alongside the old one everywhere, wait a few days, then remove the old lines.

The sources disagree on MyFamily. The older method listed every sibling's fingerprint in MyFamily. The Tor Project's post install page now says "MyFamily, the previous family configuration method, has been removed." The tor 0.4.9.14 manual page still says families should configure both FamilyId and MyFamily "for now" for older clients. With 0.4.8 past end of life, use FamilyId as the relay guide says, and check the guide and your version's manual before deleting existing MyFamily lines.

Offline master identity keys

A relay's identity is an ed25519 master key. Tor uses it to sign a medium term signing key, valid 30 days by default (SigningKeyLifetime). With OfflineMasterKey 1, tor never loads the master key, so it can live on another machine while you issue signing keys with tor --keygen. The Tor Project's FAQ notes the cost: renew before expiry, or tor exits. For unattended relays it suggests leaving the key in place with a backup. For fleets, the post install guide points to configuration management such as the Ansible Relayor role.

Running an obfs4 bridge

Steps 1 and 2 are the same (the bridge guide says Ubuntu users in particular need the Tor repository). Install tor and the obfs4 transport (apt-get install obfs4proxy where your release packages it), then replace torrc:

BridgeRelay 1
ORPort 8443                       # any reachable port except 9001
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443   # a second reachable port
ExtORPort auto                    # always auto
ContactInfo bridge-ops@example.org
Nickname PickANickname

The ports are examples. The guide warns against 9001 because "censors may be scanning the Internet for this port." Open both ports in the firewall and any NAT, then systemctl enable --now tor.service and look in the journal for "Registered server transport 'obfs4'" and the self test success line.

The bridge post install page says BridgeDB distributes bridges through six buckets (HTTPS, Moat, Email, Telegram, Settings and manual), that steady users can take "several days or weeks", and that the bridge shows on Relay Search about three hours after setup under its hashed fingerprint. Your bridge line is in /var/lib/tor/pt_state/obfs4_bridgeline.txt. Set BridgeDistribution none to keep it out of BridgeDB. Converting a public relay into a bridge? The guide advises a new IP, name and fingerprint.

Exit relays: policies, DNS and abuse handling

Read the legal FAQ section below before you set ExitRelay 1.

Prepare the address first

• Dedicated server. The exit guide says not to put exits on servers you need for anything else, and "do not mix your own traffic with your exit relay traffic."
• Reverse DNS. A PTR record with something like "tor-exit" in it, on a domain you own, never torproject.org.
• WHOIS. Ideally showing the IP is a Tor exit, with your own abuse contact. The exit guidelines say nervous abuse desks are one of "the biggest reasons exit relays disappear".
• Exit notice. An HTML page on port 80 via DirPort 80 and DirPortFrontPage, starting from the Tor Project's sample. The exit guide notes DirPort is deprecated since tor 0.4.6.5 but still documents this use.
• Your ISP. The EFF FAQ says tell your ISP and choose a Tor friendly one.

Exit policies and the reduced exit policy

Policies are evaluated first to last; the first match wins. A custom policy that does not end in accept *:* or reject *:* is prepended to the default rather than replacing it. An exit must allow ports 80 and 443 to be useful and to earn the Exit flag.

The exit guide recommends starting reduced, "especially if you are new to your hoster." The exit guidelines say it "drastically reduces the odds that a Bittorrent user will select your node." ExitPolicyRejectPrivate (on by default) blocks private networks and your own addresses, and the expectations document asks you to reject any destination your exit cannot actually reach.

ExitRelay 1
ReducedExitPolicy 1
IPv6Exit 1          # only if IPv6 works
DirPort 80
DirPortFrontPage /etc/tor/tor-exit-notice.html

Run your own DNS resolver

Exits resolve DNS for clients. The exit guide asks for a local caching, DNSSEC validating resolver with no forwarders, no large public resolvers as primary or fallback, at most two entries in /etc/resolv.conf, and a resolver source address your relays do not use. Its Debian steps for Unbound:

apt install unbound
cp /etc/resolv.conf /etc/resolv.conf.backup
echo nameserver 127.0.0.1 > /etc/resolv.conf
chattr +i /etc/resolv.conf
systemctl enable --now unbound

Confirm qname-minimisation: yes in /etc/unbound/unbound.conf and resolve a hostname before you enable exiting. Exits at 100 Mbit/s or more should watch tor_relay_exit_dns_error_total{reason="timeout"} on the MetricsPort.

Handling abuse complaints

The Tor Exit Guidelines say to answer complaints professionally and promptly. A large exit operator quoted there says roughly 80% of its complaints are automated, most of the rest accept a default reply, and it had not needed a lawyer "in many years of operation". A workable routine:

1. Check ExoneraTor, which answers whether an IP was a Tor relay on a given date and whether it allowed exiting, and cite it in your reply.
2. Reply with the matching Tor Abuse Template: a common explanation of Tor plus a paragraph for the scenario, such as forum spam or scraping.
3. If complaints cluster on one port, tighten the exit policy rather than shutting down.
4. For U.S. DMCA notices, use the EFF response template linked from the legal FAQ.
5. For a signed letter confirming your IP was an exit, the guidelines say to write to frontdesk@torproject.org.

The guidelines also suggest abuse phone and fax contacts where police use them, explaining Tor to local law enforcement in advance, and forming an organisation, which can help with liability and continuity.

What does the legal FAQ say?

This summarises the Legal FAQ for Tor Relay Operators, written by the EFF and hosted by the Tor Project. It is general information, not legal advice. The FAQ says it describes issues "in the United States", that other facts and jurisdictions give different answers, and that you should consult a lawyer licensed where you live. We report no outcome beyond what the FAQ and the Tor Project state.

• Prosecutions. The EFF knows of no one sued, prosecuted or convicted for running a relay, but says law enforcement has "occasionally mistakenly investigated" operators. Its examples: a 2016 Seattle police raid on the home of an activist running an exit, and the wrongful arrest in Russia of a relay operator who was later cleared.
• Legality. The EFF believes running a relay, including an exit, is legal under U.S. law, but says no one can promise you will never face liability.
• Statutes. It cites 47 U.S.C. § 230 against a range of civil claims (with criminal and intellectual property exceptions) and 17 U.S.C. § 512(a), the DMCA safe harbor for material "simply transmitted without modification". It adds that no court has yet addressed these issues for Tor itself.
• Exits at home. "No, this is risky and not recommended." Use a commercial facility supportive of Tor and a separate IP, and do not route your own traffic through it.
• Transparency. Tell your ISP, set descriptive reverse DNS, publish an exit notice and, if possible, register your own contact details for the IP range.
• Never inspect traffic. Monitoring, logging or disclosing users' communications may create liability under U.S. wiretap laws, and operators elsewhere may face similar laws.
• Requests for data. Explain that a properly configured relay holds little useful data, and do not hand over logs without consulting a lawyer.
• Police contact. You can ask to speak with an attorney before and during questioning, and if you do answer, tell the truth.
• Who to ask. Not the Tor developers, who are not lawyers and whose communications are not privileged. The EFF may help find counsel through info@eff.org.

The Exit Guidelines add that operators should know the communication provider rules of their own country and their host's country, list references for the United States and Germany, and invite contributions for others.

How do you monitor a relay?

You want to know when your relay breaks without publishing anything that helps attack users.

nyx is the Tor Project's curses monitor, with a bandwidth graph, deduplicated event log, connections view, configuration editor and torrc viewer. It connects through the ControlPort enabled above. The Nyx site lists 2.1.0, released January 2019, as the latest version; install it from your distribution or PyPI and run nyx.

MetricsPort serves tor's counters in Prometheus format. The manual opens with a warning that "exposing tor metrics publicly is dangerous to the Tor network users," and asks for a strict MetricsPortPolicy (reject all by default), an OS firewall as a second layer, and a tunnel such as stunnel because the port speaks plain HTTP. It also notes that allowing localhost lets every user on the box read it.

MetricsPort 127.0.0.1:9035
MetricsPortPolicy accept 127.0.0.1

Scrape it from a local Prometheus or over a VPN. Our posts on whether a Prometheus style metrics endpoint is safe to expose and homelab monitoring cover the pattern.

What not to publish. The post install guide says public monitoring graphs "could help attackers with deanonymizing Tor users." Its rules: aggregate over at least a day, prefer totals across relays to single relays, and remember that shorter periods, raw numbers, real time data and per category splits are all worse. The expectations document sets the same one day minimum for any public page.

How do you harden the relay host?

Mostly ordinary server hygiene applied strictly, plus rules from the expectations document (version 2.2, updated 25 August 2026).

1. One job per machine. The exit guide says not to put exits on servers you need for other services, and the EFF FAQ says to keep sensitive or personal data off exit hosts.
2. No onion services on the relay. The Tor Project's onion service operational security page says it is "generally a better idea to host Onion Services on a Tor client rather than a Tor relay, since relay uptime and other properties are publicly visible."
3. Automatic updates for the OS and tor, as in step 1, and keep other system software current.
4. A supported tor series. Relays on end of life, unsupported or known vulnerable versions "will be removed from the network". On 3 June 2026 Georg Koppen told the tor-relays list that 1,598 relays, roughly 19% of advertised bandwidth, were still on the end of life 0.4.8.x series, and that it was on track to be blocked in early September. Advisories such as an out of bounds write in tor's consensus handling are another reason. Subscribe to the low traffic tor-announce list.
5. Default drop inbound, open outbound.
6. SSH by key, from fixed admin addresses where possible. See how to harden a Linux server.
7. File descriptors. Relays need 10,000 or more, so make sure your package or startup script raises ulimit -n.
8. Sandbox and logging. Test Sandbox 1; keep SafeLogging 1 at notice level.
9. Protect keys. Back them up securely or use offline master keys; if they are stolen, tell the bad relays team so the keys can be blocked.
10. Never modify tor to inspect traffic, never record onion addresses, and never send exit traffic through a VPN or proxy.
11. Correct time through NTP.
12. Official guidance only. The expectations document says follow the official relay guide, and read any community script before running it.

The exit guidelines raise one trade off: disk encryption protects keys, but an unencrypted machine is easier to show as doing Tor and nothing else.

Why your new relay is quiet

A 2013 Tor Project post on the lifecycle of a new relay describes four phases. Its numbers may differ on today's network, but the shape explains the flags above:

Do not restart with a new identity to "fix" low traffic; that resets the history.

Common mistakes

• An exit on a home line. Both the Tor Project and the EFF say no; police have mistaken exit traffic for the operator's.
• No family declared. Two of your relays in one circuit defeat the three hop design.
• An end of life tor series, or packages from Ubuntu's universe repository.
• Onion services or other services on the relay host.
• Blocking outbound traffic. Relays must reach every other relay.
• Broken IPv6 configured explicitly, which stops the relay publishing.
• Public, fine grained graphs or an exposed MetricsPort or ControlPort.
• A bridge and a public relay on one IP, or a bridge listed in a family.
• Big public DNS resolvers on an exit.
• A slow flat rate on a metered plan instead of accounting.
• Identity keys kept only on the relay.
• A personal email in ContactInfo, which is archived publicly.

FAQ

Is it legal to run a Tor relay?

The EFF's Legal FAQ, hosted by the Tor Project, says it believes running a relay, including an exit, is legal under U.S. law and knows of no operator sued, prosecuted or convicted for it, but no one can guarantee you will never face liability. Answers differ by jurisdiction; this is not legal advice.

Can I run a Tor relay from home?

A bridge, Snowflake proxy or non-exit relay can, if your router handles the load (7,000 or more connections for a relay). Your relay IP becomes public and may be blocked. Never run an exit from home.

How much bandwidth does a Tor relay need?

At least 10 Mbit/s each way for a middle or guard relay (16 recommended) and 100 GB a month (2 TB or more recommended). A bridge needs 1 Mbit/s.

What is the difference between a Tor bridge and a relay?

Relays are listed in the public directory; bridges are not, so they are harder to block. Bridges usually use a pluggable transport such as obfs4 to disguise Tor traffic.

How do I become a guard relay?

You do not configure it. Run a reliable, fast non-exit relay and the authorities assign the Guard flag once it is Fast, Stable, familiar and has enough bandwidth.

Will running a Tor relay get my IP blocked?

It can. Public relay IPs are listed and some services block them, exits most of all. Bridges are unlikely to be blocked by popular services.

What is the reduced exit policy?

A built in policy, ReducedExitPolicy 1, that allows about 65 common ports and rejects the rest. The Tor Project recommends it for new exit operators.

How do I check if my Tor relay is working?

Look for "Self-testing indicates your ORPort is reachable from the outside" in the log, then find the relay on Relay Search about three hours later or query Onionoo.

Do I need MyFamily or FamilyId?

If you run more than one relay, yes. The current guide uses FamilyId with a shared key (tor 0.4.9.2-alpha or later) and says MyFamily was removed; the 0.4.9.14 manual still mentions both. Follow the guide for your version.

What should I do with an abuse complaint about my exit?

Reply promptly with a Tor Abuse Template, confirm with ExoneraTor that your IP was an exit at that time, and tighten your exit policy if complaints cluster on one port.

Where Safeguard fits

Safeguard does not run, monitor or harden Tor relays and does not inspect network traffic. The fit is indirect. A relay setup still includes software you install and update: tor from the Tor repository, an obfs4 or Snowflake proxy, a Prometheus stack, an Ansible role and scripts you write around Onionoo or key rotation. If you run a bridge from a container image or keep relay automation in a repository, Safeguard can scan it (safeguard scan --image, safeguard scan --dir .) to produce an SBOM, list packages and versions, and match them against vulnerability databases, with reachability analysis to rank what your code calls. Results land as JSON under ./output, and the platform shows which projects contain a given component and version. It does not patch the host OS or tell you whether your relay is in the consensus.

Relay operators already treat a supported, patched version as the only acceptable one, and the containers, scripts and automation around a relay pull open source dependencies of their own. Knowing when one of those needs a fix, and having a path to it when upstream is slow, is the supply chain side of running a relay well.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency scanning and remediation, not relay operation. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Run on the machine that holds your relay automation or bridge container image, the same scan lists the packages and versions inside, so you know what to rebuild when a component needs an update.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and the advisory, edits package.json to lodash 4.17.21 and runs npm install and npm test, asking before any command that changes something and pushing nothing. The same flow applies when you bump a dependency in a small Onionoo alert script or exporter you wrote for your relays.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Tor Project: Relay Operations
• Tor Project: Types of relays
• Tor Project: Relay requirements
• Tor Project: Technical considerations
• Tor Project: Technical setup
• Tor Project: Middle/Guard relay on Debian/Ubuntu
• Tor Project: Automatic updates on Debian and Ubuntu
• Tor Project: How to install tor
• Tor Project: Relay post-install and good practices
• Tor Project: Configure FamilyId
• Tor Project: Offline ed25519 identity keys
• Tor Project: Exit relay setup
• Tor Project: Unbound for exit relays on Debian/Ubuntu
• Tor Project: obfs4 bridge
• Tor Project: obfs4 bridge on Debian/Ubuntu
• Tor Project: Bridge post-install
• Tor Project: Standalone Snowflake proxy
• Tor Project: WebTunnel bridge
• Tor Project: Snowflake
• Tor Project: Expectations for relay operators
• Tor Project: Onion services operational security
• EFF and Tor Project: Legal FAQ for Tor Relay Operators
• EFF: DMCA response template
• Tor Project: Tor Exit Guidelines
• Tor Project: Tor Abuse Templates
• Tor Project: Good and bad ISPs
• tor manual page, 0.4.9.14
• Tor Specifications: Directory protocol outline
• Tor Specifications: Assigning flags in a vote
• Tor Specifications: Path selection and constraints
• Tor Metrics: Relay Search
• Tor Metrics: Onionoo protocol
• Tor Metrics: ExoneraTor
• Nyx
• Tor Project: Little-t tor download
• Tor Project blog: The lifecycle of a new relay (2013)
• tor-relays: 0.4.8.x reaches end-of-life on 2026-06-01
• tor-relays: PSA: 0.4.8.x is EOL now, please upgrade
• nftables wiki: Simple ruleset for a server

Last reviewed: 25 October 2026. Tor versions, family configuration and relay policies change; check the Tor Project's relay guide and your version's manual page before you deploy.