- tor-relays - lists.torproject.org

Upcoming Stabilization of Tor 0.4.9.x
by Alexander Hansen Færøy 28 Jan '26

28 Jan '26

Hello Tor Relay Operators! The Network Team, particularly David Goulet, is preparing to mark the Tor 0.4.9.x series stable. It will likely happen in the next few weeks, assuming that we don't run into trouble with the the 0.4.9.4-rc release that comes out this week (along with a probably-final update to 0.4.8). We hope you folks will update quickly, and provide the feedback we need, as you always do. Once Tor 0.4.9.x is released as stable, and is available in your package management system, we urge the relay operator community to begin this transition, particularly by adopting the Happy Family system included in this release. For more information, please check out the documentation[2]. At first, we will need you to co-maintain both the existing `MyFamily` system and Happy Families in parallel. If the network upgrade goes quickly, we hope to deprecate the `MyFamily` system sooner rather than later. This period, when both family systems coexist, will be painful, particularly for our Apple iOS users, due to the memory limitations of their Network Extension API. Once we can get rid of the `MyFamily` system, we expect our directory traffic and memory utilization to drop, which will hopefully make Tor more usable for these users and other users on lower-memory systems. In addition to the memory and traffic issues, we also want to acknowledge the pain points raised by the large operators, who currently need to partition their `MyFamily` settings into multiple logical subsets to avoid exceeding the max descriptor sizes we have in place to mitigate DoS. To use Happy Families, operators using `ansible-relayor`[1] should already have Happy Family key management support in the upstream project's GitHub repository. For everybody else, please have a look at the documentation[2] for more information on configuring Happy Families for your relays. Feel free to reach out here for assistance. Relay operators running a single relay where they currently don't set the `MyFamily` setting won't have to worry about Happy Families at all. Later this year, the Network Team + Network Health Team will have a blog post out on the current status of the Arti Relay project and how we foresee the remaining lifetime of C Tor. Happy Families was a bit of a special feature, as there was an urgent need for it, but it also lets us ignore the `MyFamily` system when building Arti Relay. Thanks! And I hope to see some of you at the Relay Operator Meetup[3] at FOSDEM in the upcoming weekend! Cheers, Alex [1]: https://github.com/nusenu/ansible-relayor [2]: https://community.torproject.org/relay/setup/post-install/family-ids/ [3]: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/ -- Alexander Hansen Færøy

1 0

Turkmenistan Censorship
by Dan 27 Jan '26

27 Jan '26

Hello, I have been emailing with a user of my bridge who is located in Turkmenistan. They contacted me to say that their ISP has blocked my bridge(s) and to request I rotate either the domain name, IP address, or both. Has anyone else found a solution seems to work in this scenario? I'm happy to request a new public IP from my VPS provider but I'd like to avoid purchasing new domain names every few months. Maybe the best option is to buy a cheap domain and setup a "private" bridge that isn't distributed except manually? This bridge is using Webtunnel which the user says is usually harder for their ISP to detect. Should I switch to Lyrebird? Thanks

4 8

Exit-Relay got no flags anymore - appears offline
by cembranutboys 22 Jan '26

22 Jan '26

Dear Tor team, My exit node has not had any flags for a few days. When I start the Tor service, the self-check says it can successfully reach my ORPort via IPv4 and IPv6. I was able to reach all authority servers via traceroute. I don't have a firewall active. I have restarted the Tor service several times, but unfortunately I am still not getting any flags. The node had been running successfully for over 220 days, which is why I don't quite understand the problems now. Fingerprint: F5EFEC7C4C4E4F48393D8EBA8CE18A4D1D3B2F67 Can you please help me? Thank you in advance. CembraNut~

2 2

name resolution with libc
by Marco Moock 21 Jan '26

21 Jan '26

Hello! I operate an exit relay on FreeBSD. I changed the values in resolv.conf (that file lists the actual nameservers, not a local resolver), but tor DNS traffic was still sent to the old servers for days until I restarted tor. How is that handled in tor? -- Gruß Marco Send unsolicited bulk mail to 1768731494muell(a)stinkedores.dorfdsl.de

3 3

Re: name resolution with libc
by Marco Moock 19 Jan '26

19 Jan '26

On 19.01.2026 01:52 D.O. Bronk wrote: > I just tried it out and funny thing, tor also didn't use the new > resolvers. So is my assumption right, that it doesn't use the libc functions, as in that case, the OS should handle that?

1 0

Re: name resolution with libc
by Marco Moock 18 Jan '26

18 Jan '26

Am 18.01.2026 um 14:19:28 Uhr schrieb D.O. Bronk: > One of my exits is on FreeBSD too, I didn't know this yet, so good to > know. But normally a 'reload' instead of a 'restart' will suffice. > This way your tor relay doesn't lose it's uptime etcetera. > > If I'm not mistaken, this should also be done after sysctl fine > tuning. Is that anywhere documented? -- Gruß Marco Send unsolicited bulk mail to 1768742368muell(a)cartoonies.org

1 0

Tor guard relay memory: what actually reduces RSS on Ubuntu 24.04
by Tor at 1AEO 17 Jan '26

17 Jan '26

Hello, We ran experiments over 10 days on ~100 Tor guard relays (Tor 0.4.8.x) on Ubuntu 24.04 to determine which memory optimizations materially affect long-term, steady-state RSS under sustained load. Results: allocator choice dominates steady-state RSS outcomes. Using mimalloc 2.x and jemalloc 5.x produced large, sustained reductions in resident memory, on the order of 70–80 percent, compared to the default glibc malloc; tcmalloc showed a smaller but measurable improvement. By contrast, the two commonly cited configuration parameters, MaxMemInQueues and MaxConsensusAgeForDiffs, showed little to no impact on steady-state RSS when adjusted in isolation. Operationally, these reductions allow higher relay density per host, with guard relay memory footprints decreasing from roughly 5–6 GB to approximately 1–2 GB per relay under sustained load. Attached are the summary chart and table. Full methodology, comparisons, and data are here, with links to scripts on GitHub to reproduce: https://www.1aeo.com/blog/tor-memory-optizations-what-actually-works.html Tor at 1AEO Approach Result Viable? mimalloc 2.1.2 1.16 GB (80% reduction) Yes jemalloc 5.3.0 1.59 GB (72% reduction) Yes tcmalloc 2.15 3.79 GB (33% reduction) Partial mimalloc 3.0.1 4.39 GB (23% reduction) Partial DirCache 0 0.29 GB (94% reduction) No (loses Guard) MaxMemInQueues ~5.0 GB (no change) No MaxConsensusAgeForDiffs ~5.7 GB (no change) No Periodic restarts 5.0–5.3 GB (minimal) Workaround only glibc 2.39 (control) 5.68 GB Baseline

3 5

forest08 dropped out of the consensus; all authorities think it is down
by forest-relay-contact＠cryptolab.net 15 Jan '26

15 Jan '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. My relay with fingerprint BDB0F71C8EB2572080D38F036E3EB33494500E9E is no longer being recognized by the consensus. I can confirm that the entire subnet it is on is able to reach the directory authority's ORPorts, but, according to the consensus health page, not a single DA reports it as running. This has lasted for 11 hours so far. How do I get it back in the consensus? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaWjfzAAKCRAw+TRLM+X4 xsIVAP9E6Ijjzt1yt7AtFTUy6TSoTnVjGMgP2A09bZr0TWNseQD/SqWS27zFl2zq wdEZyZfQHArlgB4YHyS7j06gij2GzAo= =XdXh -----END PGP SIGNATURE-----

2 2

Tor exit relay lifecycle - update
by Georg Koppen 14 Jan '26

14 Jan '26

Hello! We have been working on a proposal to introduce an exit relay lifecycle (similar to the one we have for non-exit relays)[1]. That proposal got recently accepted and merged[2] and now we need to get it implemented. Folks interested can follow the implementation part by tracking the respective ticket in core/tor[3]. For more context see the discussion in the original exit lifecycle ticket[4] as well. Thanks, Georg [1] https://gitlab.torproject.org/tpo/community/policies/-/issues/32 [2] https://gitlab.torproject.org/tpo/community/policies/-/blob/main/docs/relay… [3] https://gitlab.torproject.org/tpo/core/tor/-/issues/41196 [4] https://gitlab.torproject.org/tpo/network-health/team/-/issues/220

1 0

Tor Relay Operator Meetup at 39c3
by Alexander Hansen Færøy 06 Jan '26

06 Jan '26

Hello folks, Leibi has managed to get a spot for a Tor Relay Operator Meetup here at #39c3. Folks can join us on day 3 at 00:00. For more information, check out: https://events.ccc.de/congress/2025/hub/en/event/detail/tor-relay-operators… Cheers, Alex -- Alexander Hansen Færøy

2 2