Building a Safe Non-Exit Tor Relay on a Small Server

Running a Tor relay does not require a dedicated datacenter server. A modest Linux machine behind a correctly configured router can operate as a useful public non-exit relay.

The key is to keep the design simple, explicitly disable exit functionality, limit resource consumption, and expose only the relay port that is actually required.

The following architecture is representative:

Internet
   ↓
Edge Router
   ↓
TCP port forward
   ↓
Linux Server
   ↓
Tor Non-Exit Relay

All names, addresses, usernames, domains, and ports below are intentionally generic.

Use a dedicated non-exit configuration

A minimal relay configuration might resemble:

Nickname relay-node
ContactInfo relay-contact@example.net

ORPort <RELAY_PORT> IPv4Only

SocksPort 0
ExitRelay 0

RelayBandwidthRate <RATE_MBITS> MBits
RelayBandwidthBurst <RATE_MBITS> MBits

MaxMemInQueues 1 GBytes

The most important lines are:

SocksPort 0
ExitRelay 0

SocksPort 0 prevents the relay daemon from acting as a local Tor proxy.

ExitRelay 0 prevents it from operating as an Exit Relay.

This creates a relay whose primary function is carrying encrypted Tor traffic between other Tor relays.

Understand the bandwidth unit

Tor configuration supports explicit bit-based units.

For example:

RelayBandwidthRate 30 MBits

means approximately:

30 megabits per second
≈ 3.75 megabytes per second

It does not mean 30 MB/s.

The distinction matters because:

30 MB/s
=
240 Mbit/s

Accidentally confusing the two could configure a relay for eight times the intended throughput.

Set a sustainable rate

The best relay bandwidth is not necessarily the fastest possible value.

A sustainable value should leave enough capacity for ordinary household or server traffic.

A sensible approach is:

start conservatively
       ↓
observe CPU / RAM / router load
       ↓
observe real network usage
       ↓
increase gradually

Long-term uptime is usually more valuable than short periods of excessive throughput followed by instability.

Limit queue memory explicitly on shared servers

Tor can automatically calculate MaxMemInQueues from system RAM.

On machines with large amounts of memory, the resulting automatic value may be several gigabytes.

That can be acceptable for a dedicated high-capacity relay, but a shared server may also host databases, web applications, file storage, or containers.

Explicitly configuring:

MaxMemInQueues 1 GBytes

can therefore provide a useful safety boundary for a moderate-bandwidth relay.

This setting should not be misunderstood as a hard 1 GiB process memory limit. It controls Tor’s internal memory accounting for several network queues and buffering structures.

Actual process RSS may remain much lower.

Router configuration should be narrow

The edge router only needs to forward the chosen Tor ORPort.

Conceptually:

WAN TCP/<RELAY_PORT>
        ↓
LAN <RELAY_HOST>:<RELAY_PORT>

Do not forward unrelated Tor ports such as SOCKS or TCP control interfaces.

The router rule should be restricted to TCP unless a future Tor configuration explicitly requires something else.

A representative nftables result might resemble:

tcp dport <RELAY_PORT>
dnat ip to <LAN_ADDRESS>:<RELAY_PORT>

The exact numbers should vary from deployment to deployment.

Keep the Tor Control interface local

Tor monitoring tools need access to its control protocol.

A Unix socket is often preferable to a public TCP ControlPort:

/run/tor/control

This keeps administrative communication local to the server.

The socket should have restrictive ownership and permissions so ordinary users cannot control the Tor daemon.

Run Tor under a dedicated service account

Linux distribution packages normally run Tor under a dedicated unprivileged system account.

The design should look like:

systemd
   ↓
Tor daemon
   ↓
dedicated service identity

rather than:

root
   ↓
Tor permanently running as root

The service identity owns the Tor state directory and identity keys while remaining isolated from unrelated application data.

Preserve relay identity

A Tor relay’s long-term identity is derived from cryptographic keys stored in its Tor data directory.

Backups should therefore preserve the relay state if maintaining the same identity after system recovery is important.

For virtual machines, full-system backups generally already include these files.

Only one live instance should use a given relay identity at a time.

Validate before applying changes

Before restarting or reloading Tor:

tor --verify-config \
  --defaults-torrc /path/to/service-defaults \
  -f /etc/tor/torrc

A successful validation should end with a message equivalent to:

Configuration was valid

For ordinary configuration changes that support runtime reload, a reload is preferable to a complete daemon restart.

A restart is still perfectly acceptable for package upgrades or changes that require full process initialization.

Final objective

A good small Tor relay is intentionally boring:

one public ORPort
+
no Exit traffic
+
no public SOCKS proxy
+
no public ControlPort
+
limited resource use
+
stable identity
+
long uptime

That simplicity reduces operational risk and makes long-term maintenance significantly easier.