- tor-relays - lists.torproject.org

Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays since Jun 25
by Tor at 1AEO 28 Jul '26

28 Jul '26

Summary: - Our guard relay family has been under a sustained circuit-building DoS wave since 2026-06-25 23:00 UTC, still ongoing: open circuits at 20x peak and 8x sustained, onionskin load 7x, stream creation 12x -- but bandwidth only +20%. Millions of near-idle circuits. See the attached charts (fleet open circuits, onionskin processing, and bandwidth, Jun 10 - Jul 10). - Every location and provider we run (EU + NA) was hit simultaneously with the same onset time, and the load arrives over existing OR connections (established TCP counts stayed flat). There is an onion-service introduction component. Looks network-wide or family-targeted, not host-specific. - Impact contained so far: tor's DoS defenses engaged, brief onionskin drops on a small subset of relays, consensus flags dipped ~5%, zero TCP port exhaustion and zero global rate-limit events. - EU servers shed 10-20% of real traffic, which are commonly closer to capacity, while NA absorbed more and have never been at capacity. - Jun 25 - Jul 10, full event window vs prior 15 days: open circuits +719% (the 8x sustained figure), onionskins processed +639%, stream creation +1126%, bandwidth +20% Details, chronological (times UTC; metrics from MetricsPort, fleet-wide): - Jun 22, 12:00-24:00 -- 12h precursor burst: open circuits ~8x normal, then two quiet days. - Jun 25, 23:00 -- onset: onionskin processing ~2.5x within 30 minutes; open circuits ~6x within 3 hours. - Jun 26-27 -- first major waves: introduce2_rejected bursts an order of magnitude above normal (peak Jun 27 03:00); conn_rejected ~5x baseline with bursts to ~10x. - Jun 26-28 -- overload symptoms: brief onionskin drops on a small subset of relays; tor's OOM handler ~10x more active; Stable/Fast/Running flag counts dip ~5% (Guard -3%). - Jul 5, 08:00 -- the 20x peak: open circuits hit ~20x baseline, the event's maximum so far. - Jul 6-10 -- slow decay: still ~5-6x baseline as of Jul 10. The symptom class matches the 2022-2023 network DDoS -- circuit creation floods overloading non-exit relays' onionskin processing, plus an onion-service introduction component: https://forum.torproject.org/t/tor-relays-dos-attacks-status-update/5333 https://blog.torproject.org/tor-network-ddos-attack/ Metrics to compare on your relays: tor_relay_circuits_total{state="opened"} tor_relay_load_onionskins_total tor_relay_streams_total tor_relay_dos_total (by type) Is anyone else seeing this since Jun 25? Happy to share more detail.

5 12

1gbp/s Tor Relay
by Lavender I Tor Relay 24 Jul '26

24 Jul '26

Hello, I was wondering if it's possible to allocate 1 Gbps of bandwidth to my Tor relay, or if it would be better to create multiple instances on the same server? I have a dedicated server in a data center. When I look at the list of the fastest relays, I see that some manage to reach 1 Gbps on a single instance, but I assume that requires a very powerful CPU and a very high single-core clock speed, given that my CPU is a bit old. Thanks!

4 5

Relay measured fine by moria1 but 0/26 measurements at maatuska (all stream errors)
by Beacon Tor Node 22 Jul '26

22 Jul '26

Hi all, I'm running an exit relay and seeing a strange discrepancy between bandwidth authorities. Some measure my relay without any problem, while others fail every single attempt with stream errors. Relay: beacon Fingerprint: 85082CD18CF6C931968105DFFFDDE82EBC4C9AF8 Observations from 2026-07-22: moria1 (13:47 UTC) — success=3/3, error_stream=0, error_circ=0, bw=6400 tor26 (06:23 UTC) — success=1/3, error_stream=0, error_circ=2, bw=1 maatuska (14:21 UTC) — success=0/26, error_stream=26, error_circ=0, unmeasured=1, vote=0 longclaw (09:32 UTC) — success=0/7, error_stream=7, error_circ=0, unmeasured=1, vote=0 gabelmoo — no data for this relay What stands out: error_circ is 0 at both maatuska and longclaw, so circuits build fine. The failures happen at the stream stage, and they happen every single time. Meanwhile moria1 measures the same relay flawlessly on the same day. Configuration: ExitRelay 1, ReducedExitPolicy 1, IPv6Exit 1, RelayBandwidthRate 37 MBytes, RelayBandwidthBurst 42 MBytes What I have checked locally, without finding anything: - DNS: local Unbound resolver, 0 serverfailed, 0 refused, 0 truncated, 213 timeouts out of 4920 queries (~4%) - IPv6: globally routable, verified from outside - MTU: full 1500 bytes pass unfragmented on both v4 and v6, no packet loss, ~6ms latency - TCP: ListenOverflows 0, ListenDrops 0, PruneCalled 0, conntrack 710/65536 - File descriptors: 65536 limit, ~620 active connections - OOM: tor_relay_load_oom_bytes_total 0 across all subsystems - Onionskins: 0 dropped - Firewall: outbound policy ACCEPT, nothing blocked - Tor logs: no warnings or errors over the past several days - System clock: synchronized via NTP The relay is relatively young (relay_in_recent_consensus_count between 28 and 85 depending on the authority), so I'm also open to the possibility that this simply resolves itself with more measurement attempts over time. Thanks, beacon

1 0

relayor v26.2.0 is released - Goodbye "MyFamily"
by nusenu 22 Jul '26

22 Jul '26

Hi, relayor v26.2.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v26.2.0 This release marks the end of "MyFamily" support in relayor. Since all supported tor versions support the Happy Family design there is no reason to continue supporting the old "MyFamily" method to declare relay families. relayor is an ansible role that helps you with automating tor relay operations https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Changes since v26.1.0: - remove MyFamily support: The last tor version that required MyFamily (0.4.8.x) in addition to Happy Family support reached end-of-life on 2026-06-01 - use absolute filter name to fix error "No filter named 'ipaddr'" kind regards, nusenu -- https://nusenu.github.io

7 9

If the IPv6 ORPort can't be reached, will clients/relays fall back to the IPv4 ORPort?
by forest-relay-contact＠cryptolab.net 21 Jul '26

21 Jul '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. If a client or relay with IPv6 attempts to connect to a relay's IPv6 ORPort and receives no response, will it fall back to IPv4 or will it consider the relay unreachable? Assume that the directory authorities are able to reach the v6 ORPort. Is the behavior different if there is an explicit error returned, e.g. RST or an ICMPv6 no route to host? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCal6ZDgAKCRAw+TRLM+X4 xgM7AP9xJhuSw8vYilYYbtzscuPLZk8BMY58gqPL2gocHYy/9wEAnduiOSjAeG6c 2yzboG7z5+HCV56tjIwXhuUTrprCmAY= =CQEB -----END PGP SIGNATURE-----

4 7

adaption of a DDoS prevention solution
by Toralf Förster 20 Jul '26

20 Jul '26

Recent DDoS attacks caused me to update the DDoS solution [1] and to roll it out to Tor instances using [2]. The metrics below shows the effect for the (highly overloaded vCPU before), the throughput and the amount of protocol violations of a tiny Tor cloud instance: Another example is Tor instance at a bare metal server, attacked between 12 and 13 UTC (no Tor metrics during that time) and again after 16 UTC. The new rule set was developed between 14 and 15, and fully applies after a reboot at 15:20: The graph below shows that the ipset (which holds malicious ip addresses to be blocked) was not updated at the first attack. But with the new rule set in place it was updated soon at the 2nd attack. The yellow line in the 2nd graph shows the portion of the change. And finally the DOS Tor metric for this instance indicates that the Tor process has much less DOS to handle than before: I'm still fine tuning the solution. [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/tor-relays -- Toralf

2 6

Abnormal Firewall-States since 0.4.9.10
by ProSecureRelays 19 Jul '26

19 Jul '26

Hi there, I want to report abnormal Firewall States since the update. Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand. In normal operation, I observed about 20k - 45k Firewall States for the relay. Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic. The days before it cycled from 120 - 145k States. Also far more than normal. Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) - all are Tor Related Connections. It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack? Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB). Best regards and have a nice weekend! Joker

4 5

adaption of a DDoS prevention solution (now with images)
by Toralf Förster 18 Jul '26

18 Jul '26

Recent DDoS attacks caused me to update the DDoS solution [1] and to roll it out to Tor instances using [2]. The metrics below shows the effect for the (highly overloaded vCPU before), the throughput and the amount of protocol violations of a tiny Tor cloud instance: Another example is Tor instance at a bare metal server, attacked between 12 and 13 UTC (no Tor metrics during that time) and again after 16 UTC. The new rule set was developed between 14 and 15, and fully applies after a reboot at 15:20: The graph below shows that the ipset (which holds malicious ip addresses to be blocked) was not updated at 12 UTC. But with the new rule set in place it was updated soon at 16 UTCk. The green line here is the (now first half) of the changed rule whilst the yellow line reflects the addition for that rule. And finally a graph of the DOS Tor metric for this instance which shows that the Tor process has much less DOS to handle than before: I'm still fine tuning the solution. [1] https://github.com/toralf/torutils#the-rule-set [2] https://github.com/toralf/tor-relays -- Toralf

1 0

5 to 10 times more outgoing than incoming traffic
by code9n＠pm.me 18 Jul '26

18 Jul '26

Hi, re. guard / middle relay : 6AD7A3E682FE74BDFE34AC0F0D17714480BA773B Until yesterday I was getting a normal balance of about 25MB coming in and going out. But today I'm getting around 10MB incoming and averaging about 75MB going out. Any idea what's going on and how to fix it assuming a fix is necessary? Thanks.

1 0

Onionoo shows family_cert but no family_ids
by rE-Bo0t.bx1 17 Jul '26

17 Jul '26

I’m seeing an Onionoo issue with one relay and wanted to check if others have seen it too. Relay: * Nickname: ShinobiHouou * Fingerprint: 7E87EC2F20A371E32E6672A6D04B55471BC5D369 * Tor: 0.4.9.11 * FamilyId: K620zs7GW3AqmEOzvkGYJE/D5HsWrOrmDlckrhxbrXE The relay has been online since 2026-07-11. Onionoo updates last_seen normally and the relay is reachable on IPv4/IPv6. The rest of my Shinobi relay family shows family_ids in Onionoo. This is the only one missing it, out of 15 relays. Onionoo’s full details document includes family_cert: |curl "https://onionoo.torproject.org/details?lookup=7E87EC2F20A371E32E6672A6D04B5…" | jq| Relevant part: |"family_cert": "AQwAB5K5AfR4C6AIeIu0XUQn5Td+xHll8Hon3vGRqcKUZIfD6YFbAQAgBAArrbTO..."| But this still returns no family_ids: |curl "https://onionoo.torproject.org/details?lookup=7E87EC2F20A371E32E6672A6D04B5…" | jq| Output: | { "relays": [ {} ] }| 1AEO also detects the relay as Happy Families, but keeps it under “Pending Onionoo refresh”. https://metrics.1aeo.com/relay/7E87EC2F20A371E32E6672A6D04B55471BC5D369/ So it looks like Onionoo sees family_cert, but does not derive/expose family_ids for this relay. I found what looks like a similar earlier tor-relays/forum thread: https://forum.torproject.org/t/tor-relays-onionoo-relays-with-family-cert-b… Is this expected/known behavior, or is there a way to debug why family_ids is absent even though family_cert is present in Onionoo? Any hints or sanity checks would be appreciated. rE-Bo0t.bx1 https://relays.brokenbotnet.com

1 1