Advanced obfs4 Bridge Tuning for Maximum Throughput in 2026

The default Linux kernel configuration limits throughput significantly on relays with many concurrent connections. Apply these settings to /etc/sysctl.d/99-tor-relay.conf:

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_max_syn_backlog = 30000
fs.file-max = 524288

Apply with sysctl --system. The most impactful change is enabling BBR (Bottleneck Bandwidth and Round-trip time) congestion control along with the fq queueing discipline. BBR was developed by Google and significantly outperforms the default Cubic algorithm on high-bandwidth-delay-product paths that characterize Tor circuit routing.

Tor opens a file descriptor for each circuit. High-capacity relays exhaust the default system file descriptor limit (typically 1024) quickly and start refusing new circuits. Increase the limit in /etc/security/limits.conf and in the tor systemd service unit:

# /etc/security/limits.conf additions:
debian-tor soft nofile 65536
debian-tor hard nofile 65536

# /etc/systemd/system/tor@.service.d/override.conf:
[Service]
LimitNOFILE=65536

Verify the limit is applied with: sudo -u debian-tor bash -c "ulimit -n". It should return 65536. The Tor process itself also needs to be told it can use more connections by setting MaxMemInQueues and ConnLimit in torrc. The default ConnLimit is 1000; increase to 8192 for high-capacity operations. Check the control port with: echo "GETINFO limits" | nc 127.0.0.1 9051 to see the effective limits after changes.

Several torrc options directly affect relay performance and should be tuned for high-capacity operations:

RelayBandwidthRate 100 MB
RelayBandwidthBurst 200 MB
MaxAdvertisedBandwidth 100 MB
MaxMemInQueues 2048 MB
CircuitBuildTimeout 10
LearnCircuitBuildTimeout 1
ConnLimit 8192
NumCPUs 4

Set RelayBandwidthRate to the sustained throughput you want to advertise to the directory authorities. RelayBandwidthBurst allows short bursts above the sustained rate for burstable workloads. MaxMemInQueues prevents tor from consuming all available RAM during traffic spikes. NumCPUs tells tor how many threads to use for cryptographic operations; set to the number of vCPUs on your VPS for full utilization.

AES-NI acceleration is detected automatically. Verify it is active by checking tor's startup log for "AES-NI available" or querying GETINFO version from the control port. If AES-NI is not detected, confirm that the CPU supports it and that the host is not running in a VM mode that hides the instruction set. AnubizHost VPS expose AES-NI by default on all plans.

On multi-vCPU VPS, pinning the tor process to specific CPUs can improve cache locality and reduce inter-CPU synchronization overhead. Use taskset to assign specific CPUs to the tor process after it starts:

taskset -cp 0,1 $(pgrep -x tor)

For systemd-managed services, add the CPU affinity setting to the service override:

[Service]
CPUAffinity=0 1

Set the tor process priority slightly higher than default to reduce latency from preemption by background tasks. In the systemd unit:

[Service]
Nice=-5

These optimizations become meaningful primarily on VPS with 4 or more vCPUs and sustained traffic above 200 Mbps. For small bridges on 1 to 2 vCPU VPS, the default configuration is near-optimal and these changes provide marginal benefit.

Validate tuning changes by comparing before and after metrics from the Tor Metrics portal. After making changes, allow 24 to 48 hours for the directory authorities to measure and reflect the new bandwidth in consensus. The measured bandwidth figure in nyx and Tor Metrics should increase after successful tuning.

Use iperf3 between two servers to verify that the OS-level TCP changes are actually achieving higher throughput before attributing improvements to Tor-specific configuration. Run iperf3 with multiple parallel streams: iperf3 -c TARGET -P 4 -t 30. Compare the aggregate throughput before and after sysctl changes. If the TCP throughput does not improve, the changes were not applied correctly or the bottleneck is elsewhere.

Monitor tor's circuit build times from the control port. Lower circuit build times indicate better performance for users. An average circuit build time below 5 seconds is good; below 3 seconds is excellent for a mid-capacity relay. Build times above 8 seconds indicate performance problems worth investigating before tuning further.