Linux Kernel Tuning for High-Speed Tor Relays: 2026 Guide

Tor relays maintain many simultaneous connections (thousands at high bandwidth). Each connection requires a file descriptor. Default Linux file descriptor limits: system-wide maximum (fs.file-max, default 65536-1048576 depending on distro), per-process limit (ulimit -n, default 1024). For a high-speed relay, increase: in /etc/sysctl.conf: fs.file-max = 1000000. In /etc/security/limits.conf: tor soft nofile 65536; tor hard nofile 65536. In systemd service file for Tor: LimitNOFILE=65536. After applying: sysctl -p and restart Tor. Verify: cat /proc//limits | grep 'Open files'. High-bandwidth relays may need file limits up to 200,000+ at sustained high concurrency.

Larger network buffers improve throughput by allowing more data in flight. /etc/sysctl.conf additions: net.core.rmem_default = 87380 (socket receive buffer default), net.core.wmem_default = 65536 (socket write buffer default), net.core.rmem_max = 16777216 (maximum receive buffer), net.core.wmem_max = 16777216 (maximum write buffer), net.ipv4.tcp_rmem = 4096 87380 16777216, net.ipv4.tcp_wmem = 4096 65536 16777216 (TCP socket buffers - min/default/max). For 1 Gbps+ relays: increase rmem_max and wmem_max to 67108864 (64 MB) and adjust tcp_rmem/tcp_wmem max values accordingly. net.core.netdev_max_backlog = 32768 (queue depth for incoming packets before processing, default is 1000).

TCP parameter optimization for Tor relays: net.ipv4.tcp_fin_timeout = 15 (reduce TIME_WAIT duration from default 60s to free sockets faster), net.ipv4.tcp_tw_reuse = 1 (reuse TIME_WAIT sockets for new connections), net.ipv4.tcp_max_syn_backlog = 4096 (queue for incoming SYN packets before accepting), net.ipv4.ip_local_port_range = 1024 65535 (increase available outbound port range), and net.ipv4.tcp_max_tw_buckets = 400000 (maximum simultaneous TIME_WAIT sockets). These settings reduce the time connections spend in cleanup states, freeing resources for new connections faster. Important: do not set net.ipv4.tcp_tw_recycle = 1 (deprecated in Linux 4.12, can cause connection issues behind NAT).

Network interrupt handling (IRQ) by default routes to a single CPU core, creating a bottleneck on multi-core systems with high network traffic. IRQ affinity distribution: use irqbalance service (installed by default on most distributions) to automatically distribute network interrupts across CPU cores. For very high bandwidth (10 Gbps+): manual IRQ pinning combined with CPU affinity for Tor processes. Set IRQ affinity for the network interface card's interrupts to specific cores, and set CPU affinity for Tor to different cores (CPU affinity via taskset or Tor's Affinity torrc settings). NUMA awareness: on multi-CPU servers (NUMA architecture), ensure network IRQs and the Tor process are on the same NUMA node (to avoid cross-node memory access). Check topology: numactl --hardware. Run Tor with numactl --membind=0 --cpunodebind=0 tor for NUMA-aware execution.

After applying tuning changes: validate file descriptor limits (cat /proc//limits), verify network parameters are active (sysctl net.core.rmem_max should return new values), and monitor performance under load. Benchmark tools: iperf3 (tests raw TCP throughput between two servers, useful for baseline), and nyx (Tor relay monitor shows real-time relay bandwidth to compare before/after tuning). Expected improvements from tuning: on default kernel settings with a 1 Gbps NIC, achievable relay bandwidth is often 200-400 Mbps due to buffer limitations. After tuning, the same hardware may achieve 700-950 Mbps. The improvement is most pronounced at high concurrency (many simultaneous Tor circuits). Monitor for side effects: increased memory usage (larger buffers consume more RAM), and ensure the server does not OOM (Out of Memory) after tuning.