1. Make sure relay ports can be reached

If you are using a firewall, open a hole in your firewall so incoming connections can reach the ports you will use for your relay (ORPort).

Also, make sure you allow all outgoing connections too, so your relay can reach the other Tor relays, clients and destinations.

You can find the specific ORPort TCP port number in the Setup page (in the OS specific sections).

2. Verify that your relay works

If your logfile (syslog) contains the following entry after starting your tor daemon your relay should be up and running as expected:

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

About 3 hours after you start your relay, it should appear on Relay Search on the Metrics portal. You can search for your relay using your nickname or IP address.

3. Read about Tor relay lifecycle

It takes some time for relay traffic to ramp up, this is especially true for guard relays but to a lesser extent also for exit relays. To understand this process, read about the lifecycle of a new relay.

4. Configuration Management

If you plan to run more than a single relay, or you want to run a high capacity relay (multiple Tor instances per server) or want to use strong security features like Offline Master Keys without performing additional steps manually, you may want to use configuration management for better maintainability.

There are multiple configuration management solutions for Unix-based operating systems (Ansible, Puppet, Salt, ...).

The following Ansible Role has specifically been built for Tor relay operators and supports multiple operating systems: Ansible Relayor.

5. Important: if you run more than one Tor instance

To avoid putting Tor clients at risk, when operating multiple relays you must set a proper FamilyID value and have a valid ContactInfo in your torrc configuration. The FamilyID setting is simply telling Tor clients what Tor relays are controlled by a single entity/operator/organization, so they are not used in multiple positions in a single circuit.

Instead of setting up FamilyID manually, for big operators we recommend to automate it setting via a configuration management solution. Manually managing FamilyID for big relay groups is error-prone and can put Tor clients at risk. Please note that MyFamily, the previous family configuration method, has been removed.

6. Add firewall rules to protect against DDoS attacks

Configuring your firewall to stop too many concurrent connections has been shown to significantly help deal with DDoS attacks against relays.

Consider implementing one of the following mechanisms:

Note: These are community provided resources. You should check them carefully before applying them to your system. Additionally, be aware that these rules have been shown to work for particular attacks that have happened in the past. Attacks are constantly evolving and will often need new rules, so please stay connected to update these as necessary, either by subscribing to the relevant project or by subscribing to the tor-relays mailing list.

7. Optional: Limiting bandwidth usage (and traffic)

Tor will not limit its bandwidth usage by default, but supports multiple ways to restrict the used bandwidth and the amount of traffic. This can be handy if you want to ensure that your Tor relay does not exceed a certain amount of bandwidth or total traffic per day/week/month. The following torrc configuration options can be used to restrict bandwidth and traffic:

  • AccountingMax
  • AccountingRule
  • AccountingStart
  • BandwidthRate
  • BandwidthBurst
  • RelayBandwidthRate

Having a fast relay for some time of the month is preferred over a slow relay for the entire month.

Also see the bandwidth entry in the FAQ.

8. Check IPv6 availability

We encourage everyone to enable IPv6 on their relays. This is especially valuable on exit and guard relays. Note that Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only.

Before relying on IPv6, it's recommended to do some basic IPv6 connectivity tests. The following command line will ping the IPv6 addresses of Tor directory authorities from your server:

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.

At the end of the output you should see "OK." If that is not the case, do not enable IPv6 in your torrc configuration file before IPv6 is indeed working. If you enable IPv6 without working IPv6 connectivity, your entire relay will remain unused, regardless of whether IPv4 is working.

If IPv6 works, your relay is likely already reachable via IPv6. Since Tor 0.4.5, IPv6 address discovery is enabled by default. An ORPort line without an explicit address binds to both IPv4 and IPv6 (0.0.0.0:9001 and [::]:9001), and Tor attempts to auto-discover your IPv6 address the same way it discovers your IPv4. If it can't find a working IPv6 address, it simply publishes IPv4 only.

You can confirm which addresses Tor bound to and discovered by checking your notice log (look for the Opened OR listener lines and the reachability-check results).

If you prefer to specify your IPv6 address explicitly - recommended if auto-discovery picks the wrong address - add a second ORPort line:

ORPort [IPv6-address]:9001

Note: Unlike an auto-discovered address (which Tor silently drops if unreachable), an explicitly configured IPv6 ORPort that fails its reachability check will stop your relay from publishing its descriptor at all, so only configure an address you know works. You have to explicitly specify your IPv6 address in square brackets.

The location of that line in the configuration file does not matter. You can simply add it next to the first ORPort lines in your torrc file.

If you have a global IPv6 address you should be able to find it in the output of the following command:

ip -6 addr | grep global | sed 's/inet6//;s#/.*##'

To turn IPv6 off entirely and disable auto-discovery, set AddressDisableIPv6 1 in your torrc.

If you are an exit relay with IPv6 connectivity, tell your tor daemon to allow exiting via IPv6 so clients can reach IPv6 destinations:

IPv6Exit 1

9. Maintaining a relay

Backup Tor Identity Keys

After your initial installation and start of the tor daemon it is a good idea to make a backup of your relay's long term identity keys. They are located in the "keys" subfolder of your DataDirectory (simply make a copy of the entire folder and store it in a secure location). Since relays have a ramp-up time it makes sense to back up the identity key to be able to restore your relay's reputation after a disk failure - otherwise you would have to go through the ramp-up phase again. Only do this if you have a very secure place for your keys as if stolen, these keys could theoretically allow traffic decryption or impersonation.

Default locations of the keys folder:

  • Debian/Ubuntu: /var/lib/tor/keys
  • FreeBSD: /var/db/tor/keys
  • OpenBSD: /var/tor/keys
  • Fedora: /var/lib/tor/keys

Subscribe to the tor-announce mailing list

This is a very low traffic mailing list and you will get information about new stable tor releases and important security update information: tor-announce.

Setting up outage notifications

Once you have set up your relay, it will likely run without much work from your side. If something goes wrong, it is good to get notified automatically. We recommend using Tor Weather, a notification service developed by the Tor Project. It helps relay operators get notified when their relays or bridges are offline, as well as for other incidents.

Another option is to use one of the free services that allow you to check your relay's ORPorts for reachability and send you an email should they become unreachable. UptimeRobot is one of these services that allow you to monitor TCP listeners on arbitrary ports. This checks only for the listener but does not speak the Tor protocol.

A good way to monitor a relay for its health state is to have a look at its bandwidth graphs.

System Health Monitoring

To ensure your relay is healthy and not overwhelmed it makes sense to have some basic system monitoring in place to keep an eye on the following metrics:

  • Bandwidth
  • Established TCP Connections
  • Memory
  • Swap
  • CPU

There are many tools for monitoring this kind of data, munin is one of them and is relatively easy to setup.

Note: Do not make your private monitoring data graphs public since this could help attackers with deanonymizing Tor users.

Some practical advice:

  • If you want to publish traffic statistics, you should aggregate your relays' traffic over at least a day or use bigger aggregation windows for bandwidth if feasable and combine graphs/statistics for multiple relays where possible.
  • Reporting individual relays is worse than reporting totals for groups of relays. In future, tor will securely aggregate bandwidth statistics, so any individual relay bandwidth reporting will be less secure than tor's statistics.
  • Smaller periods are worse.
  • Numbers are worse than graphs.
  • Real-time data is worse than historical data.
  • Data in categories (IP version, in/out, etc.) is worse than total data.

Tools

This section lists a few tools that you might find handy as a Tor relay operator.

  • Nyx: is a Tor Project tool (formerly arm) that allows you to see real time data of your relay.

  • vnstat: vnstat is a command-line tool that shows the amount of data going through your network connection. You can also use it to generate PNG pictures showing traffic graphs. vnstat documentation and demo output.

Learn how to configure your relays' FamilyID