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 MyFamily value and have a valid ContactInfo in your torrc configuration. The MyFamily 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.

If you run two relays and they have fingerprints AAAAAAAAAA and BBBBBBBB, you would add the following configuration to set MyFamily:

MyFamily AAAAAAAAAA,BBBBBBBB

to both relays. To find your relay's fingerprint you can look into the log files when tor starts up or find the file named "fingerprint" in your tor DataDirectory.

Instead of doing so manually, for big operators we recommend to automate the MyFamily setting via a configuration management solution. Manually managing MyFamily for big relay groups is error-prone and can put Tor clients at risk.

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.

Before enabling your tor daemon to use IPv6 in addition to IPv4 you should do some basic IPv6 connectivity tests.

The following command line will ping the IPv6 addresses of Tor directory authorities from your server:

ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && 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 it worked fine, make your Tor relay reachable via IPv6 by adding an additional ORPort line to your configuration (example for ORPort 9001):

ORPort [IPv6-address]:9001

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.

Note: You have to explicitly specify your IPv6 address in square brackets, you can not tell tor to bind to any IPv6 (like you do for IPv4). 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#/.*##'

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

Note: Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only.

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 for any reason. UptimeRobot is one of these services that allow you to monitor TCP listeners on arbitrary ports. This service can check your configured ports once every 5 minutes and send you an email should your tor process die or become unreachable. 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 all your relays' traffic over at least a week, then round that to the nearest 10 TiB (terabytes).
  • 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.