en
Tor Exit Relay Performance Tuning for Operators
Exit relays carry the heaviest load in the Tor network, handling traffic to and from the clearnet on behalf of Tor users. Running a high-performance exit relay requires tuning at every layer - Linux kernel network stack, Tor daemon configuration, and the physical network connection. Operators who host exit relays in well-resourced data centers with uncongested uplinks contribute significantly to the network's overall capacity and speed. This guide covers the essential performance tuning steps for exit relay operators using modern Linux distributions.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Linux Kernel Network Stack Tuning
The Linux kernel's default network parameters are conservative and limit throughput for high-volume relays. Increase the socket buffer sizes by setting net.core.rmem_max=134217728 and net.core.wmem_max=134217728 in /etc/sysctl.conf. Enable BBR congestion control with net.core.default_qdisc=fq and net.ipv4.tcp_congestion_control=bbr - BBR significantly improves throughput over lossy or high-latency links compared to the default CUBIC algorithm. Apply with sysctl -p. For relays handling tens of thousands of simultaneous connections, increase the file descriptor limit using LimitNOFILE=1000000 in the tor user's systemd service unit.
Tor Daemon Configuration for Exit Relays
The core Tor configuration for a high-performance exit relay starts with RelayBandwidthRate and RelayBandwidthBurst set to match your available uplink. For a 1 Gbps port, start with RelayBandwidthRate 500 MBytes and RelayBandwidthBurst 750 MBytes to leave headroom. Set NumCPUs to match your processor core count - Tor is multithreaded but benefits diminish past 8 cores. Increase MaxMemInQueues from the default 8 GB to 16 GB or higher on servers with ample RAM. Configure a generous exit policy: ExitPolicy accept *:80, accept *:443, accept *:25, accept *:110, accept *:465, accept *:587, accept *:993, accept *:995 covers the most common legitimate ports.
Exit Policy Optimization and Abuse Reduction
Exit relay operators often face abuse complaints because their IP appears in server logs of destinations. Restricting exit policies to well-known application ports (HTTP, HTTPS, SMTP, IMAP, POP3) significantly reduces abuse while maintaining high utility. Registering your relay IP in the Tor Project's exit list and with abuse databases like dan.me.uk/torlist helps network operators identify Tor traffic and reduces complaint volume. Some operators add reduced.exit as their exit policy, which allows only ports commonly used by legitimate applications.
Memory and Connection Limits
Exit relays managing thousands of concurrent connections require careful memory management. Each Tor circuit uses approximately 30-60 KB of RAM for buffers and state. A relay handling 10,000 simultaneous circuits needs 300 MB to 600 MB for circuit state alone, before accounting for queued data. Set MaxMemInQueues to 75% of available RAM. Monitor actual memory usage with tor --verify-config and watch /proc/$(pidof tor)/status. The ConnLimit option (default 1000) restricts how many connections Tor opens simultaneously. For high-throughput exits, increase to ConnLimit 65535 in concert with the kernel file descriptor limit increase.
Monitoring and Performance Metrics
Track your relay's performance through the Tor control port with commands like GETINFO traffic/read and GETINFO traffic/written. The Nyx tool provides a real-time terminal dashboard showing bandwidth usage, circuit counts, connection statistics, and log output. Export metrics to Prometheus using the torctl2prometheus exporter. Set up Grafana dashboards to visualize these metrics alongside host-level stats from node_exporter. Alert on sustained bandwidth below your advertised rate (indicating upstream congestion) and on circuit build failures exceeding 5% of attempts. Regularly verify your relay appears in the consensus with a healthy flag set using Tor Relay Search at metrics.torproject.org.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.