Diagnosing a Tor Relay and Its Router: A Practical Health Checklist

Once a Tor relay is reachable from the Internet, the next challenge is determining whether it can remain healthy for months or years.

A useful diagnosis should cover both the Linux relay host and the upstream router.

The goal is not to chase theoretical weaknesses but to identify realistic operational bottlenecks.

Verify the configuration first

Always begin with:

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

Then inspect only the settings that matter operationally:

grep -E \
'^(Nickname|ContactInfo|ORPort|SocksPort|ExitRelay|RelayBandwidthRate|RelayBandwidthBurst|MaxMemInQueues)' \
/etc/tor/torrc

A non-exit relay should clearly show:

SocksPort 0
ExitRelay 0

Confirm process ownership

Check the actual process:

ps -C tor \
  -o user,group,pid,%cpu,%mem,rss,vsz,etime,cmd

The process should be running under the dedicated Tor service account.

CPU and RSS should also be recorded as a baseline.

Inspect listening ports

A focused command is:

ss -lntup

The Tor-specific result should normally show only the relay’s public ORPort.

A public SOCKS or TCP ControlPort should not appear unless intentionally configured.

Check file descriptors

Relays maintain many simultaneous TCP connections.

Linux file descriptors therefore matter.

Useful commands include:

PID="$(pidof tor)"

ls "/proc/$PID/fd" | wc -l

grep -i 'open files' \
  "/proc/$PID/limits"

For example:

Open descriptors: 150
Limit: 65536

would indicate enormous remaining headroom.

A relay using only a few hundred descriptors with a limit in the tens of thousands is not close to exhaustion.

Observe TCP connection growth

A new relay may initially have very few connections.

Over time, connection count generally increases as other Tor relays begin using it.

Useful commands:

ss -s

and:

ss -Hnt | grep -c ':<RELAY_PORT>'

The second command provides a rough count of TCP sessions involving the relay port.

Do not interpret rapid growth as a problem by itself. A relay is expected to maintain many persistent connections.

Watch system load

Basic commands remain extremely effective:

uptime
free -h
vmstat 1 5

Important values include:

• load average;
• available RAM;
• swap usage;
• CPU idle percentage;
• I/O wait;
• blocked processes.

For a lightly loaded relay, vmstat might show:

id 97–99%
wa 0–1%

which indicates minimal CPU and storage pressure.

Time synchronization is critical

Tor relies on reasonably accurate system time.

Check:

timedatectl

Healthy output should indicate:

System clock synchronized: yes
NTP service: active

Clock skew can interfere with directory information and circuit behavior.

Reliable NTP is therefore part of Tor operational security.

Disk space and inodes

Check both:

df -h /
df -i /

Disk capacity and inode exhaustion are different failure modes.

A server can have hundreds of gigabytes free and still fail if it runs out of inodes, although this is uncommon on ordinary Tor installations.

The Tor data directory itself is normally small:

du -sh /var/lib/tor

For a standard relay it should remain tiny compared with multi-terabyte application storage.

Search Tor logs intelligently

A useful filter is:

journalctl -u tor@default \
  --since "6 hours ago" \
  --no-pager -l |
grep -Ei \
'warn|error|fail|overload|memory|clock|reachable|descriptor|reject|too many|oom'

Particular concerns include:

• ORPort becoming unreachable;
• descriptor rejection;
• memory pressure;
• clock skew;
• overload warnings;
• file-descriptor exhaustion.

Old startup messages should not be confused with current failures.

Timestamps matter.

Diagnose the router too

A relay can be perfectly healthy while its router becomes the bottleneck.

On OpenWrt-like systems, inspect conntrack:

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

A result such as:

350 / 60000

indicates extremely low utilization.

Also check:

uptime
free

Consumer routers often have much less RAM than servers, so router memory can matter more than server memory.

Confirm DNAT packet counters

Using nftables:

nft list ruleset |
grep -n -C 3 '<RELAY_PORT>'

A healthy rule should resemble:

tcp dport <RELAY_PORT>
dnat ip to <INTERNAL_HOST>:<RELAY_PORT>
counter packets ...

Increasing packet counters prove that real Internet traffic is traversing the rule.

Kernel health

Router logs can be searched for:

logread |
grep -Ei \
'conntrack.*(full|drop)|out of memory|oom|netdev watchdog|tx timeout'

No output is often the ideal result.

Long-term diagnosis is more useful than a single snapshot

A new relay may look almost idle during its first hour.

A useful monitoring timeline is:

after 1 hour
after 24 hours
after 1 week
after 1 month

Track the same metrics each time:

Tor RSS
Tor CPU
TCP sessions
file descriptors
router conntrack
router memory
consensus flags
real bandwidth

The trend is more informative than any individual reading.