- tor-relays - lists.torproject.org

for tiny tor instances: 3 Tor config values worth to try out
by Toralf Förster 12 Aug '26

12 Aug '26

Based on advises here and there I configured my tiny Tor relays (1 vCPU, 1 GiB RAM) with these values: - name: DosCircuitCreationBurst value: 20 - name: MaxOnionQueueDelay value: 1000 - name: MaxMemInQueues value: 320 MB and it seems to help (beside the iptables solution ofc). -- Toralf

2 2

OT: How much Internet traffic overall is from Tor?
by Lars Noodén 07 Aug '26

07 Aug '26

Greetings, Are there any recent data estimating the percentage (or absolute volume) of Internet traffic which is from Tor? I suppose these metrics have been covered at some conferences now and again, but I cannot find anything other than comparisons of HTTP vs HTTPS or HTTP 1.1 vs /2 and /3. Decades ago, there used to be sites tracking the portion of traffic used by various protocols. The WWW (aka HTTPS and HTTP) has lately overwhelmed global mind share, such that it is now all but impossible to find mention of any other protocols, let alone traffic statistics. But I expect there are still measurable amounts of traffic with other protocols e.g. Tor, I2P, SSH, BitTorrent, Gopher, Gemini, RTSP, etc. FTP, WAIS, and Telnet are probably gone, thankfully. Which list would have been the right one to ask this? /Lars

1 0

Tor activities at Defcon
by Roger Dingledine 06 Aug '26

06 Aug '26

Hi folks! Many Tor people are here at Defcon this weekend. You can find us at: (1) Our booth, in the non-profit vendor area near EFF and others. People will be there Friday Saturday Sunday during daytime hours. Check out the cool new keychain onion plushies, or ask questions or answer questions. (2) A Friday evening "Tor Social Hour (but really two hours!)" at the Golden Monkey Tiki Lounge, inside Resorts World, 7pm to 9pm. It is BYOB (buy your own beverage) -- come say hi, meet Tor staff and community. (3) I have a talk super early on Sunday (0930 in the War Stories track), where I'll talk about past/present/future challenges with keeping the Tor network safe and working, both from the user perspective and the relay operator perspective. After the talk I plan to bring everybody to the booth for AMA / Q&A until everybody is out of questions. We didn't manage to schedule an official relay operator meetup this year, but I am thinking of trying to organize one next year as a slot in the privacy village. When you find me, please let me know if this is a good idea or a bad idea. :) --Roger

1 0

Post-Quantum Cryptography in Tor's TLS Layer: Help needed!
by Alexander Hansen Færøy 06 Aug '26

06 Aug '26

Hello Tor Relay Operators, With the arrival of OpenSSL 3.5.0 in 2025, we finally had an important missing piece of infrastructure to start enabling the Tor network to support Post-Quantum Cryptography in the outermost cryptographic layer of the Tor protocol. Since Tor version 0.4.8.17, we have supported the x25519/ML-KEM-768 hybrid handshake in our TLS layer, and we have gradually seen more relays supporting it in the production network. Tor Browser has been built against OpenSSL >= 3.5.0 since (at least) version 13.5.22, released in September 2025, and therefore supports Post-Quantum TLS handshakes today, but it requires that its guard node supports it. We need to give a big shout-out to the OpenSSL Team here to get this out and available to the masses! <3 Since Q3 2025, I've been running some semi-regular scans of the Tor production network to check for TLS cipher suite availability. This work started as part of the first Tor Community Gathering back in October, 2025[1]. The results are as follows: In January, around 28% of the Tor relays supported the Post-Quantum TLS handshake. The scan I did yesterday showed an increase of around 4 percentage points to 32.32%. Out of 9476 scanned relays, 9185 were reachable, 291 were unreachable. Of the 9185 reachable relays, I saw the following distribution of cipher suites: `TLS13_AES_256_GCM_SHA384`: 9023 relays. `TLS13_CHACHA20_POLY1305_SHA256`: 158 relays. `TLS13_AES_128_GCM_SHA256`: 4 relays. For the key exchange groups, I saw the following distribution: `secp256r1`: 6212 relays. `X25519MLKEM768`: 2969 relays. `X25519`: 4 relays. Of the Directory Authorities, 5 of them supported the `X25519MLKEM768` key exchange group during the TLS handshakes. 2969 / 9185 * 100 = 32.32% of relays support the `X25519MLKEM768` cipher suite. This number is a good start, but we should ideally bump it up! You can see the individual results for your relay(s) in the big table available at https://ahf.me/tor-tls-pqc/2026-02-26/ -- entries without a cipher suite or key exchange group were unreachable at the time I ran the scan. These missing entries can be due to a network problem anywhere on the path between my host and yours, so don't get worried if your relay is missing :-) The scanner I used is free software and is available as part of the Network Health Team's Margot tool[2], used for various analysis purposes. Please note that the goal here isn't to enumerate all available cipher suites for each relay, but instead I'm interested in the "strongest" possible cipher suite my custom client can negotiate with each relay. My ask for you as the relay operator community here is as follows: Next time you folks are doing maintenance on your relay(s), please have a look at whether you can upgrade either your packages or underlying software distribution to a version such that you either get a new enough version of OpenSSL (>= 3.5.0), or if you are a LibreSSL user, check whether the LibreSSL project supports the ML-KEM hybrid handshake, and upgrade to that version. It looks like the LibreSSL project is currently working towards supporting the ML-KEM handshake in the next upcoming release[3]. For Debian users, to get a new enough OpenSSL version that supports the PQC TLS handshake, you need to upgrade to (at least) Debian Trixie. For everybody else, it's best to check your respective software distribution's package management system to find the version you need to upgrade to. For Arti users, a licensing issue with the currently available crypto providers in Arti prevented enabling the ML-KEM handshake. Nick, however, has recently been making progress on this matter and has a patch up that is now pending upstream review[4]! :-) If you are excited about exploring different aspects of the Tor ecosystem, talking with other Tor enthusiasts, and you have nothing planned for your weekend in two weeks, I highly encourage you to look into the next Tor Community Gathering in Denmark. The event takes place from 2026-03-13 to 2026-03-15. For more information, check out our website at https://onionize.space/2026/ Thank you all for all the work you do to make Tor better! <3 Cheers, Alex [1]: https://onionize.space/2025/ [2]: https://gitlab.torproject.org/tpo/network-health/margot/ [3]: https://github.com/libressl/portable/blob/a989b7acb9a475fde656e48dbcb38289d… [4]: https://github.com/RustCrypto/rustls-rustcrypto/pull/143 -- Alexander Hansen Færøy

4 8

Tor Relay Crash
by Lavender I Tor Relay 04 Aug '26

04 Aug '26

Hello, I've been tearing my hair out a bit lately. I launched a Tor middle relay a few weeks ago, but every so often, I get a dramatic spike in upload traffic, and the relay becomes almost unusable—or even crashes... I thought it might be a DDoS attack, but I'm not sure. Is something going on with the network right now, or is it on my end? I’ve set the relay’s bandwidth rate to 52 MB and 55 MB burst, but sometimes the upload speed hits 100 MB/s… The relay averages around 10 MB, and then suddenly it runs at 60–100 MB/s for several hours at a time. I already have a UFW firewall that only allows the relay ports on my server. It takes a while to get flags, and since my relay crashes because of these network spikes, I lose a good portion of my flags and basically have to start all over again... It's really frustrating. Thanks

3 4

Heads up: anti-censorship tools now packaged on deb.torproject.org
by Micah Anderson 01 Aug '26

01 Aug '26

Greetings, We're currently preparing 4 new Debian packages to be included in the Tor Project Debian repository hosted at "deb.torproject.org" in the coming days: * lyrebird * webtunnel * snowflake-proxy * snowflake-client If your system is configured with "deb.torproject.org" in your APT sources and any of the above packages are installed from the regular Debian archive, they will automatically upgrade the Tor Project-published versions. We're doing this to ensure that downstream users of these important anti-censorship tools have an update channel that allows them to receive timely upgrades automatically. That being said, packages from both channels should remain compatible and interchangeable. If you encounter any issues with them, please let us know by creating an issue in https://gitlab.torproject.org/tpo/anti-censorship/team/-/work_items. If you wish to add "deb.torproject.org" in your Debian system's APT sources, please follow the instructions at: https://support.torproject.org/little-t-tor/getting-started/installing/#deb… -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

2 1

reply to: 5 to 10 times more outgoing than incoming traffic
by code9n＠pm.me 01 Aug '26

01 Aug '26

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

6 5

about vanguards
by Markus Reichelt 31 Jul '26

31 Jul '26

Hi, I do wonder if https://github.com/mikeperry-tor/vanguards is deprecated/dead/no longer needed. Already asked on IRC but got no reply. And then there is https://github.com/mikeperry-tor/vanguards/issues/99 Thanks for any pointers.

1 0

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 25 Jul '26

25 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