reply to: 5 to 10 times more outgoing than incoming traffic
Update: re. 5 to 10 times more outgoing than incoming traffic on relay : 6AD7A3E682FE74BDFE34AC0F0D17714480BA773B About an hour after the large difference between incoming and outgoing it had quietened down to about 7MB each way. By two hours after that it is up to around 20MB each way - so I guess it's sorting itself out. I'd be interested if anyone has any idea what happened, though. thanks, Pete
The same thing happened to me. After the traffic spike lasted for several hours, my relay even lost its HSDir flag. I’ve seen this happen several times in the past as well, and I think we need to find out what is causing it. - - - Heartbeat: Tor's uptime is 4 days 8:30 hours, with 14984 circuits open. I've sent 1197.09 GB and received 704.58 GB. - - - 2026-07-19 00:00 21.03 GB | 22.06 GB | 43.08 GB | 12.26 MB/s 01:00 16.81 GB | 17.90 GB | 34.71 GB | 9.87 MB/s 02:00 17.99 GB | 18.98 GB | 36.97 GB | 10.52 MB/s 03:00 46.48 GB | 195.40 GB | 241.88 GB | 68.80 MB/s 04:00 46.37 GB | 234.14 GB | 280.51 GB | 79.79 MB/s 05:00 44.80 GB | 226.16 GB | 270.95 GB | 77.07 MB/s 06:00 12.46 GB | 12.44 GB | 24.90 GB | 7.08 MB/s 07:00 13.35 GB | 13.48 GB | 26.83 GB | 7.63 MB/s 08:00 19.01 GB | 19.87 GB | 38.89 GB | 11.06 MB/s 09:00 23.32 GB | 24.26 GB | 47.58 GB | 13.53 MB/s 10:00 21.33 GB | 22.21 GB | 43.53 GB | 12.38 MB/s 11:00 11.70 GB | 12.16 GB | 23.86 GB | 14.04 MB/s - - - Please pay attention to the output between 3:00 and 5:00.
We can confirm the divergence fleet-wide, date it, and explain it: a directory-serving write surge, 07-19 → 07-24, now over. Shape: fleet written/read held 0.99–1.07 through every wave since June. First tick 07-19 ~18:00 UTC; hard episode 07-22 ~18:00 → 07-23 ~18:00, peaking 2.15× — written ~2.5× to ~9.2 GB/s, read flat. Normal since 07-24. It's directory serving: at peak, our DirCache 0 relays (no V2Dir) sat at 1.01; our dir-cache guards ran up to 2.4–2.7×. Your example relay is a Guard+HSDir+V2Dir cache. Small requests in, multi-cell responses out. Public data, network-wide (CollecTor extra-infos dirreq-write-history): ~150–205 TB/day baseline → 400–450 (07-19→21) → ~810/~730 TB on 07-22/23 (~4×) → ~200 on 07-24. Same window as our fleet. First time in a year of this flood our overload count moved (steady 2–4 relays through everything): one event 07-23 19:00–22:00 UTC → peak 94 relays in overload-general (07-26), decaying since. Trigger: tor's MaxMemInQueues OOM handler — ~246 GB freed in 18 h, ~2k max-cell kills; zero onionskin drops, no CPU saturation, no kernel OOM. Outbound queues ballooning on large directory responses (slow-read), not compute. Operators in your ML thread seeing out≫in: check for [warn] We're low on memory, not CPU — raise MaxMemInQueues to its default (unset ⇒ auto: 40% of RAM, capped at 8 GB) and keep swap generous. Context: the malformed vector shut off 07-20 ~21:45 UTC (~7,200/s → ~25/s), this surge ran 07-19→24, and INTRODUCE2 collapsed ~73M → ~5M/day over 07-26→28 — the rotation continues. And the surge preceded HSDir's 07-22 year-low (945): at least partly a descriptor-fetch flood, not just demand concentrating on the surviving caches. Cross posting from gitlab tracking issue: https://gitlab.torproject.org/tpo/network-health/analysis/-/work_items/113#n... On Monday, July 20th, 2026 at 2:52 AM, chappie7--- via tor-relays <tor-relays@lists.torproject.org> wrote:
The same thing happened to me. After the traffic spike lasted for several hours, my relay even lost its HSDir flag. I’ve seen this happen several times in the past as well, and I think we need to find out what is causing it. - - -
Heartbeat: Tor's uptime is 4 days 8:30 hours, with 14984 circuits open. I've sent 1197.09 GB and received 704.58 GB. - - - 2026-07-19 00:00 21.03 GB | 22.06 GB | 43.08 GB | 12.26 MB/s 01:00 16.81 GB | 17.90 GB | 34.71 GB | 9.87 MB/s 02:00 17.99 GB | 18.98 GB | 36.97 GB | 10.52 MB/s 03:00 46.48 GB | 195.40 GB | 241.88 GB | 68.80 MB/s 04:00 46.37 GB | 234.14 GB | 280.51 GB | 79.79 MB/s 05:00 44.80 GB | 226.16 GB | 270.95 GB | 77.07 MB/s 06:00 12.46 GB | 12.44 GB | 24.90 GB | 7.08 MB/s 07:00 13.35 GB | 13.48 GB | 26.83 GB | 7.63 MB/s 08:00 19.01 GB | 19.87 GB | 38.89 GB | 11.06 MB/s 09:00 23.32 GB | 24.26 GB | 47.58 GB | 13.53 MB/s 10:00 21.33 GB | 22.21 GB | 43.53 GB | 12.38 MB/s 11:00 11.70 GB | 12.16 GB | 23.86 GB | 14.04 MB/s
- - - Please pay attention to the output between 3:00 and 5:00. _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Tor at 1AEO wrote:
It's directory serving
Is the attack coming from the same few IPs? Would rate-limiting output (with a very generous burst allowance) per-IP be effective here? I assume these different attack patterns are tests from the attacker, and the remaining circuit-building attack is just the one that they have determined is the one that is the most effective? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCamvzOAAKCRAw+TRLM+X4 xrOpAQDnbtTqBiaecljyQqBVcMHE6381JZChZTCkNMnCHwPKJgD/SuId5SdlunMx ASRs/d3prQzO5yVqeITLCTha9tsTNwQ= =9xVG -----END PGP SIGNATURE-----
A simple mitigation I used while my relay was under attack was the following. After noticing the unusual traffic, I enabled the option shown in [1] and then reloaded the affected Tor instance using the command in [2]. I left the instance in this state for approximately five minutes. Immediately after the reload, the abnormal traffic stopped. I then commented out the option shown in [1] in the torrc configuration file and reloaded the instance once again using the command in [2]. In this way, the attack was effectively interrupted. During this short interval of approximately ten minutes, my relay did not lose any of its flags. It appears that the attack tool was unable to determine that it should resume targeting the relay after the temporary interruption. [1] DirCache 0 [2] systemctl reload tor@relay2.service
participants (6)
-
Chappie -
chappie7＠riseup.net
-
code9n＠pm.me -
forest-relay-contact＠cryptolab.net -
Logforme -
Tor at 1AEO