Updates, insights, and community posts from 1st Amendment Encrypted Openness.
Since late June the whole Tor network has been under a circuit-building DoS wave — reconstructed here entirely from Tor's own signed public archives (CollecTor + Onionoo): two overload waves reaching ~12% of all relays, the flood landing squarely on the guard position, and the Running flag flapping network-wide. Every number is reproducible. Read more
How the attack actually works. Since Jun 25 23:00 UTC, open circuits on 1AEO's guard fleet ran ~20x peak — arriving as three waves offset in time (an onion-service INTRODUCE2 burst, the main ntor_v3 circuit flood, a malformed-circuit tail), each tripping a different one of Tor's built-in defenses and riding Tor's own path machinery to pick which relays it hit. Read more
What absorbing the flood costs an operator — and how 1AEO ranked. The circuits are cheap to send; soaking them up pegged host CPU at 90–99% and drove memory to OOM, while the relays never stopped relaying. From Tor's public data, 1AEO held at 0.3% of guards overloaded — the most guards at the lowest overload of any major operator. Read more
Underneath the circuit flood ran a second flood no Tor counter records: the Linux kernel on 1AEO's relay hosts silently dropped ~1.3 billion fully-completed TCP connections at the accept queue — roughly 900 per second for two weeks, beginning 1–2 days before the circuit flood. Tor's per-IP defenses fired 27 million times and it didn't matter: the kernel dropped ~40x more, upstream of them all. Read more
Better metrics and what Tor could fix. How to see an attack like this without logging anything about the traffic or its sources, the two measurement traps that nearly fooled us, and the protocol-level changes we're asking the Tor Project to weigh — per-source limits that compose into a per-relay cap, proof-of-work for circuit creation, and RSS-aware OOM handling. Read more
5-Way Deployment Blog: Testing 5 allocators on 100 relays (20 per group) with Debian 13.2 for 6-10 days showed mimalloc 2.0.9 (1.41 GB) used 7.4× less memory than 3.0.1 (10.44 GB), so we migrated all 200 production relays to 2.0.9. Read more
After testing allocators, config tweaks, and restarts across 100+ relays, we found that switching to mimalloc or jemalloc is the only fix that actually stops Tor guard memory from ballooning to 5+ GB. Read more
Our 90-relay experiment on Ubuntu 24.04 proves that swapping glibc for mimalloc (79% reduction) or jemalloc (71% reduction) keeps Tor guards under 2 GB without recompiling or losing Guard status. Read more
Disabling DirCache cuts memory by 94%, but it also removes your Guard flag—making it a diagnostic proof point rather than a viable solution for production Guard relays. Read more
Despite its promising name, MaxMemInQueues only limits circuit buffers—not the directory cache fragmentation that actually causes Tor relays to bloat to 5 GB. Read more
Scheduled restarts can reduce memory by up to 19%, but they disrupt circuits and still leave you at 4.5 GB—use them only as a stopgap while migrating to a better allocator. Read more
Limiting how long Tor keeps consensus diffs had zero impact on memory—all test groups ended at 5.6–5.8 GB, proving the fragmentation problem lies in glibc, not cache retention. Read more
A straightforward guide to the leading Tor relay dashboards—compare their bandwidth stats, update frequency, map views, and detailed features to monitor your nodes and network with ease. Read more
Supercharge your Tor relay deployments with turnkey BGP configs that take you from zero to announced in minutes. Read more
Running a 10 Gbps Tor relay at maximum capacity reveals lessons every operator should know before scaling up. Read more
A recent thread on the Tor-relays list raises a fundamental question for operators: is it better to deploy a single high-capacity server, or several smaller ones distributed across locations and providers? Read more