Merge remote-tracking branch 'nusenu/relay-guide'

---

_template: layout.html

---

title: Relays requirements

title: Relay requirements

---

subtitle: Requirements for Tor relays depend on the type of relay and the bandwidth they provide.  Learn more about specific relay requirements. 

---

html: relay-operations.html

---

body:

Requirements for Tor relays depend on the type of relay and the bandwidth they

provide.

# Bandwidth and Connections

A non-exit relay should be able to handle at least 7000 concurrent

connections. This can overwhelm consumer-level routers. If you run the Tor

relay from a server (virtual or dedicated) in a data center you will be fine.

If you run it behind a consumer-level router at home you will have to try and

see if your home router can handle it or if it starts failing. Fast exit

relays (>=100 Mbit/s) usually have to handle a lot more concurrent connections

(>100k).

It is recommended that a relay have at least 16 Mbit/s (Mbps) upload bandwidth

and 16 Mbit/s (Mbps) download bandwidth available for Tor. More is better. The

minimum requirements for a relay are 10 Mbit/s (Mbps). If you have less than 10

Mbit/s but at least 1 Mbit/s we recommend you run a [bridge with obfs4

support](https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy).

If you do not know your bandwidth you can use http://beta.speedtest.net to

measure it.

# Monthly Outbound Traffic

It is required that a Tor relay be allowed to use a minimum of 100 GByte of

outbound traffic (and the same amount of incoming traffic) per month. Note: That

is only about 1 day worth of traffic on a 10 Mbit/s (Mbps) connection. More (>2

TB/month) is better and recommended. **Ideally a relay runs on an unmetered plan**

or includes 20 TB/month or more. If you have a metered plan you might want to

configure tor to only use a given amount of [bandwidth or monthly traffic](FIXME).

# Public IPv4 Address

Every relay needs a public IPv4 address - either directly on the host

(preferred) or via NAT and port forwarding.

The IPv4 address is not required to be static but static IP addresses are

preferred. Your IPv4 address should remain unchanged for at least 3 hours (if it

regularly changes more often than that, it does not make much sense to run a

relay or bridge there since it takes time to distribute the new list of relay

IPs to clients - which happens only once every hour).

Additional IPv6 connectivity is great and recommended/encouraged but not a

requirement. There should be no problem at all with this requirement (all

commercially available servers come with at least one IPv4 address).

Note: You can only run two Tor relays per public IPv4 address. If you want to

run more than two relays you will need more IPv4 addresses.

# Memory Requirements

* A <40 Mbit/s non-exit relay should have at least 512 MB of RAM available.

* A non-exit relay faster than 40 Mbit/s should have at least 1 GB of RAM.

* On an exit relay we recommend at least 1.5 GB of RAM per tor instance.

# Disk Storage

Tor does not need much disk storage. A typical Tor relay needs less than 200 MB

for Tor related data (in addition to the operating system itself).

# CPU

* Any modern CPU should be fine.

* It is recommended to use CPUs with AESNI support (that will improve performance

and allow for up to about ~400-450 Mbps in each direction on a single tor

instance on modern CPUs). If the file /proc/cpuinfo contains the word aes your

CPU has support for AES-NI.

# Uptime

Tor has no hard uptime requirement but if your relay is not running for more

than 2 hours a day its usefulness is limited. Ideally the relay runs on a server

which runs 24/7. Reboots and tor daemon restarts are fine.

# Tor Version

For security reasons, Tor relays should not downgrade their tor version from a

supported to an unsupported version of tor. Some unsupported versions are

insecure. Relays that attempt to downgrade to an insecure version will be

rejected from the network automatically.

html: relay-operations.html

---

body:

All nodes are important, but they have different technical requirements and

legal implications. Understanding the different kinds of nodes is the first step

to learning which one is right for you.

# Guard and middle relay

(also known as non-exit relays)

A guard relay is the first relay in the chain of 3 relays building a Tor circuit. A

middle relay is neither a guard nor an exit, but acts as the second hop between

the two. To become a guard, a relay has to be stable and fast (at least

2MByte/s) otherwise it will remain a middle relay.

Guard and middle relays usually do not receive abuse complaints. All relays will

be listed in the public list of Tor relays, so may be blocked by certain

services that don't understand how Tor works or deliberately want to censor Tor

users. If you are running a relay from home and have one static IP, you may want

to consider running a bridge instead so that your non-Tor traffic doesn't get

blocked as though it's coming from Tor. If you have a dynamic IP address or

multiple static IPs, this isn't as much of an issue.

A non-exit Tor relay requires minimal maintenance efforts and bandwidth usage

can be highly customized in the tor configuration (will be covered in more

detail later in this guide). The so called "exit policy" of the relay decides if

it is a relay allowing clients to exit or not. A non-exit relay does not allow

exiting in its exit policy.

# Exit relay

The exit relay is the final relay in a Tor circuit, the one that sends traffic

out its destination. The services Tor clients are connecting to (website, chat

service, email provider, etc) will see the IP address of the exit relay instead

of their real IP address of the Tor user.

Exit relays have the greatest legal exposure and liability of all the relays.

For example, if a user downloads copyrighted material while using your exit

relay, you the operator may receive a

[DMCA notice](https://www.dmca.com/Solutions/view.aspx?ID=712f28a5-93f2-467b-ba92-3d58c8345a32&?ref=sol08a2)

. Any abuse complaints about the exit will go directly to you (via your

hoster, depending on the WHOIS records). Generally, most complaints can be

handled pretty easily through template letters, which we'll discuss more in

legal considerations section.

Because of the legal exposure that comes with running an exit relay, you should

not run a Tor exit relay from your home. Ideal exit relay operators are

affiliated with some institution, like a university, a library, a hackerspace or

a privacy related organization. An institution can not only provide greater

bandwidth for the exit, but is better positioned to handle abuse complaints or

the rare law enforcement inquiry.

If you are considering running an exit relay, please read the [section on legal

considerations](FIXME) for exit relay operators.

# Bridge

The design of the Tor network means that the IP address of Tor relays is public.

However, one of the ways Tor can be blocked by governments or ISPs is by

blacklisting the IP addresses of these public Tor nodes. Tor bridges are nodes

in the network that are not listed in the public Tor directory, which make it

harder for ISPs and governments to block them.

Bridges are useful for Tor users under oppressive regimes or for people who want

an extra layer of security because they're worried somebody will recognize that

they are contacting a public Tor relay IP address. Several countries, including

China and Iran, have found ways to detect and block connections to Tor bridges.

Pluggable transports

(https://www.torproject.org/docs/pluggable-transports.html.en), a special

kind of bridge, address this by adding an additional layer of obfuscation.

Bridges are relatively easy, low-risk and low bandwidth Tor nodes to operate,

but they have a big impact on users. A bridge isn't likely to receive any abuse

complaints, and since bridges are not listed in the public consensus, they are

unlikely to be blocked by popular services. Bridges are a great option if you

can only run a Tor node from your home network, have only one static IP, and

don't have a huge amount of bandwidth to donate -- we recommend giving your

bridge at least 1 Mbit/sec.

<div class="container py-5">

  <h2 class="text-primary">{{ _('Why run a Tor Relay?') }}</h2>

  <div class="row py-5">

    <div class="col-8">

      {{ this.body }}

      <p>Illustration area</p>

    </div>

  </div>

  <h2 class="text-primary">{{ _('How to run a Relay?') }}</h2>

  <div class="row py-5">

    {% for child in this.children|sort(attribute='key') %}

      <div class="col-sm-6 col-md-6 col-sm-12 col-xl-6 py-4">

      </div>

    {% endfor %}

  </div>

  <h2 class="text-primary text-center">{{ _('Can\'t run a relay yourself?') }}</h2>

  <p class="text-center">{{ _('You can donate to these organizations that help relay operators:') }}</p>

  <div class="row">

  <div class="col-sm-6 col-md-6 col-sm-12 col-xl-6 py-4">

    <div class="card h-100 border-1">

      <img class="card-img-top" src="{{ 'static/images/gray-image.png'|asseturl }}" alt="Card image cap">

      <div class="card-body">

        <h4 class="card-title text-primary">{{ _('Tor Servers') }}</h4>

        <p class="card-text">{{ _('Two lines about the here. Two lines about the here. Two lines about the here. Two lines about the here.')}}</p>

      </div>

    </div>

  </div>

  <div class="col-sm-6 col-md-6 col-sm-12 col-xl-6 py-4">

    <div class="card h-100 border-1">

      <img class="card-img-top" src="{{ 'static/images/gray-image.png'|asseturl }}" alt="Card image cap">

      <div class="card-body">

        <h4 class="card-title text-primary">{{ _('Nos Ognions') }}</h4>

        <p class="card-text">{{ _('Two lines about the here. Two lines about the here. Two lines about the here. Two lines about the here.') }} </p>

      </div>

    </div>

  </div>

</div>