Running a Tor Relay Node

Tor does not really need an introduction, but beyond its name and usecase, I see its different components being referenced incorrectly all the time. The name "Tor" comes from The Onion Router. Think of onion layers: each layer hides the one beneath it. Tor works the same way:

Client (the user): starts by choosing a random path through the Tor network.

Guard (or entry) relay: the first server in the chain. Knows the user’s IP, but not their destination.

Middle relay: passes encrypted traffic along. Doesn't know the sender or the final site.

Exit relay: the final server that connects to the regular internet. Knows the destination, but not the original user.

This 3-hop design means:

No single relay knows both who you are and where you're going.

All traffic is encrypted until it leaves the exit node.

The more relays exist, the stronger Tor becomes.

Relays vs. Exits

When people hear "Tor node", they usually imagine an exit node. That’s the one websites see as the source of traffic. But relays are different:

Guard/Entry: first hop, trusted for weeks at a time.

Middle Relays: safely carries traffic between relays. Tor relays don't see plaintexttraffic (only exit nodes do)

Bridge: like a secret entry relay, used in censored regions.

Exit: connects to the wider internet. Useful, but legally risky (your IP shows up if someone uses Tor maliciously).

Running an exit node is a huge responsibility and it comes with legal and practical risks:

Abuse complaints: If someone uses Tor for hacking, spamming, or illegal activity, the target will see your server's IP as the source. Expect frequent abuse tickets from your VPS provider.Many VPS and hosting providers outright forbid exit relays. Running one can get your server suspended or your account terminated.

Legal exposure: Even though you didn't initiate the traffic, law enforcement or copyright enforcement agencies may contact you. If you aren't prepared, this can be overwhelming.

Technical overhead: Responsible exit operators set up abuse-handling processes, maintain detailed legal disclaimers, and often partner with hosting providers that explicitly support Tor exits.

For these reasons, you should not run an exit relay on a random VPS unless you know exactly what you're doing, have an appropriate hosting provider, and are ready to handle the fallout.

In this guide, we'll set up a middle relay. It's safe, stable, and won't get you abuse complaints.

Installing Tor on Ubuntu Server

Ubuntu already ships Tor, so no external repository is needed. Update your system and install Tor with Nyx (a monitoring tool):

sudo apt update && sudo apt upgrade -y
sudo apt install tor nyx -y

Check the service:

systemctl status tor

Configuring Tor as a Relay

Open the Tor configuration file:

sudo nano /etc/tor/torrc

Here's an example configuration for a middle relay.

## Basic relay identity
Nickname randomnamefortherelay
ContactInfo Your Name <youremail@example.com>

Nickname: a unique name that identifies your relay on the Tor network (it doesn't have to be secret, just memorable).

ContactInfo: an email or URL so Tor project maintainers or abuse desks can reach you if there's an issue.

## Relay settings
ORPort 9001
ExitRelay 0
SocksPort 0
DirPort 0

ORPort 9001: the port your relay listens on for other Tor relays. This must be open in your firewall.

ExitRelay 0: ensures your relay will not act as an exit node

SocksPort 0: disables the local SOCKS proxy

DirPort 0: disables directory mirroring

## Bandwidth management
BandwidthRate 5 MB
BandwidthBurst 10 MB
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB

BandwidthRate: caps the average traffic to 5 MB/s (~40 Mbps).

BandwidthBurst: allows short bursts above the cap (10 MB/s here).

RelayBandwidthRate / RelayBandwidthBurst: mirror the same limits, specifically for relay traffic.
Note: This ensures you don’t exceed your VPS bandwidth allocation.

## Stability & uptime
AccountingStart month 1 00:00
AccountingMax 500 GB
MaxAdvertisedBandwidth 5 MB
HeartbeatPeriod 1 hour

AccountingStart: resets bandwidth counters at the start of the month.

AccountingMax: total monthly bandwidth limit (here: 500 GB). Tor will stop relaying if you hit this cap.

MaxAdvertisedBandwidth: tells the Tor network "don’t expect more than this." Prevents overuse.

HeartbeatPeriod: logs status updates every hour for monitoring

## Security & resource management
DisableDebuggerAttachment 1
ControlPort 0
Sandbox 1

DisableDebuggerAttachment: hardens the process against debugging attempts.

ControlPort 0: disables Tor’s control port (used for automation; unnecessary here, so safer disabled).

Sandbox 1: runs Tor in a restricted environment for extra protection.

## Logs
Log notice file /var/log/tor/notices.log

Log notice: records important events without filling your disk with debug info.

Full example configuration:

## Basic relay identity
Nickname randomnamefortherelay
ContactInfo Your Name <youremail@example.com>

## Relay settings
ORPort 9001
ExitRelay 0
SocksPort 0
DirPort 0

## Bandwidth management
BandwidthRate 5 MB
BandwidthBurst 10 MB
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB

## Stability & uptime
AccountingStart month 1 00:00
AccountingMax 500 GB
MaxAdvertisedBandwidth 5 MB
HeartbeatPeriod 1 hour

## Security & resource management
DisableDebuggerAttachment 1
ControlPort 0
Sandbox 1

## Logs
Log notice file /var/log/tor/notices.log

Restart Tor to activate the config:

sudo systemctl restart tor

Monitoring with Nyx

Run:

nyx

You'll see bandwidth graphs, uptime, and logs in real time.

Some messages are normal (like IPv6 missing, or occasional 404s from directory servers).

After ~1–2 hours, your relay should show up on Tor Relay Search. Search by your Nickname.

Why a Relay?

Every new relay strengthens the Tor network:

More relays = more paths = stronger anonymity.

Middle relays carry huge amounts of traffic safely (without the liability of exit nodes).

You're directly helping people around the world bypass censorship and surveillance.

When running a relay, you are supporting a global project for online freedom.