- tor-relays - lists.torproject.org

big german provider "Deutsche Telekom" has started blocking access to their SIP servers
by iji＠gmx.net 28 Feb '26

28 Feb '26

Hi a big German provider "Deutsche Telekom" has started blocking access (at TCP layer) to their SIP servers in February 2026. That means running a middle tor on this provider line results in a non-functional provider SIP service. You have to choose between running a middle tor or a working provider SIP service.

9 19

Happy Families migration status dashboard
by Tor at 1AEO 24 Feb '26

24 Feb '26

To help answer “what still needs to happen before the network can rely on Happy Families (and eventually stop depending on MyFamily)?”, we put together a small public dashboard that tracks the main rollout gates: https://metrics.1aeo.com/network-health.html#happy-families High-level flow: 1) Voting directory authorities upgrade (v0.4.9.x+) DAs need to be on v0.4.9.x+ so the network can move forward with the newer directory protocol pieces. 2) Consensus method moves to 35 Once a >2/3 voting DA majority supports method 35 (7/9), the consensus can adopt it. 3) Relays publish Happy Families material Relay families configure FamilyId so relays publish family-cert, which lets directory documents/micro descriptors carry the happy families identifier information. 4) Clients upgrade and use it As Tor clients (Tor Browser, tor, etc.) widely consume happy families identifiers, then deprecating MyFamily becomes possible. The dashboard shows live counts for DA readiness (v0.4.9.x+ and method-35 support), current consensus method, relay publication (family-cert), and a few “how much of the network is ready” slices (guards/exits/CW/bandwidth). References: - Relay operator guide (FamilyId / Happy Families setup): https://community.torproject.org/relay/setup/post-install/family-ids/ - Proposal 321: https://spec.torproject.org/proposals/321-happy-families.html Feedback welcome—especially if there are other readiness signals you’d like to track, or if you spot anything that looks off for your relays. On Tuesday, February 3rd, 2026 at 5:00 AM, Alexander Hansen Færøy via tor-relays <tor-relays(a)lists.torproject.org> wrote: > On 02/02/2026 22.36, tor_appliedprivacy.net via tor-relays wrote: > > Today we enabled the happy family setup across all our relays. > > > > Since all our relays run in a single /24 we also removed MyFamily at the > > same time. This should help reduce the overhead introduced by MyFamily. > > This is not what any of us on the Network Team are recommending right now, but > if others think this is a good idea despite that: please ensure that your IPv6 > addresses, at the very least, are also within the same /32 in addition to the > /16 requirement for IPv4. I am almost certain that is always the case, but > please just be sure before you proceed. > > We are very interested in hearing feedback on the 0.4.9.4-rc release candidate > and in resolving any issues before we stabilize 0.4.9. Maybe the above approach > will reveal some issues :-) > > Cheers, > Alex > > -- > Alexander Hansen Færøy > _______________________________________________ > tor-relays mailing list -- tor-relays(a)lists.torproject.org > To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org >

1 0

Question about Tor relay guard/middle probability fluctuations
by Tor-relay 23 Feb '26

23 Feb '26

Hi everyone, I have a question regarding my Tor relay’s lifecycle. Since the beginning, I have noticed that the guard and middle probabilities fluctuate significantly. I have not observed this behavior when comparing with other operators’ relays. After some time, the relay receives the Guard flag and the middle probability decreases, later it loses the Guard flag and the middle probability increases again. I waited for a long time to see whether this would stabilize, but the behavior has remained unchanged. I would like to ask what the possible reasons for this could be, and whether it might be related to my configuration. Relay fingerprint: 8E6E3B11C9AD2E9E3B3FC53A4E43D1AE3BEBE444 Tor metrics link: https://metrics.torproject.org/rs.html#details/8E6E3B11C9AD2E9E3B3FC53A4E43… Thank you in advance. P.S. If you check the relay statistics, please ignore the low consensus weight and probabilities during the last month, that was caused by my own mistake.

3 3

the case for relay state persistency
by Gilberto 23 Feb '26

23 Feb '26

Hello everyone, In our diskless infrastructure [0][1], we store all configurations generated by the node inside the TPM's memory. These memories are very limited (1-9k), but more than sufficient for saving the long-term keys of the relays. However, we have a problem: when rebooting the machines, we lose the state file and, with it, the bandwidth measurements of the various relays. This is quite annoying because upon reboot, our relays all start up announcing 0 B/s, and it takes them days to regain their bandwidth. Unfortunately, these files are too large to be stored in the TPM. We would like to be able to generate the BWHistory configurations based on some arbitrary values that we write into the node configurations, and then let the node handle redoing the measurements upon reboot. However, among all the configurations, it's not clear to us which ones are important for our needs and which others we can leave empty. In general, we would like to open a discussion, in view of Arti, about the organization of the datadir. Currently, it's not very clear which files are important for runtime, which are for persistence, etc. From our point of view, it would be quite useful to be able to group persistent data into just a few files, for example, one for all keys and one for states/configurations. Thank you, g [0]: https://osservatorionessuno.org/blog/2025/05/patela-a-basement-full-of-amne… [1]: https://osservatorionessuno.org/blog/2025/12/patela-v2-from-certificates-to…

4 4

Re: Issues with My Tor Relay
by stay.hydrated834＠passmail.net 23 Feb '26

23 Feb '26

Hi everyone, Thank you for the reply and the information you provided. While preparing my response about the blocked traffic, I wanted to clarify the NAT and WAN rules in the screenshots and replace the aliases with the actual IP addresses. During that process I discovered that I (the numb nut of an administrator) forgot to fill in the NAT alias, so there was never an active NAT rule only the WAN rule was present. Because both the NAT and WAN rules are now active, the Tor relay is functioning correctly: no traffic to port 9001 is being blocked, and outbound traffic is unrestricted. I wonder why some connections were allowed by the WAN rule while others were denied and are now only allowed due to the NAT rule. Bandwidth: Average throughput: ~60 Mbps (occasionally up to 140 Mbps) Recent spikes: short bursts up to 420 Mbps training i guess? Due to frequent firewall restarts while I’m re‑configuring my network. I expect the traffic to stabilize as the network settles and after the training finished, and I’m happy if the relay can make use of any unused capacity. 1000Mbps would be the Maximum so there is alot of room to grow. :D Unexpected traffic bursts Every few hours I see dozens of Tor nodes connecting to my relay for 2–5 minutes, resulting in 1,000–7,500 connections dropping. These bursts don’t line up with the bandwidth spikes as far as i seen. My CPU usage, which is usually around 1 %, can rise to about 1.2 % during those periods. Im glad i already thought its static. :D I don’t think this is an attack—nothing I’ve seen, even a smart bulb, generates comparable traffic. I’m wondering if I still have a misconfiguration somewhere. Regarding Snowflakes Is it possible to Route all of my phones (apps) traffic still through WireGuard back to home while allowing Orbot to use the mobile network to open a Snowflake relay (my IP changes every 24 hours after a phone reboot). I have an unlimited 25Mbit not fast but steady. Im on GrapheneOS Screenshots I’ve attached screenshots that highlight exactly what is being blocked, so you can see the traffic patterns I described. Thanks again to everyone who runs relays; your experience helped me finally get mine working. <3 Stay hydrated! Cheers

1 0

Scheduled migration: Nothing to hide infrastructure (23-02-2026)
by Nothing to hide 20 Feb '26

20 Feb '26

Hi everyone, This is a heads-up that a significant portion of the Nothing to hide infrastructure will be undergoing a major upgrade and migration on Monday 23 February 2026. We are replacing older servers and networking equipment with modern high-performance hardware and moving to a new data center. What to expect: * While we aim to limit downtime to a few minutes, extended outages are possible depending on how the migration proceeds. * In the days following the migration, many of our existing relays will be assigned new IP addresses and/or roles. * Once we consider the new network and infrastructure stable, we will be adding more relays to the network. This move also provides much-needed headroom for auxiliary services we plan to offer Tor operators, such as DoT, DoH, DoQ, and NTS. We'll share more details on these in the near future. Best regards, Nothing to hide

1 0

Programmatically determine if a relay is hibernating
by forest-relay-contact＠cryptolab.net 18 Feb '26

18 Feb '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. What is the authoritative way to determine if a relay is hibernating? I would have thought that using the control socket would be best, but Tor seems to unlink it when it enters hibernation, so Stem does not work. There's a possible heuristic by checking if /run/tor/tor.pid exists when /run/tor/control does not, but that's fragile because it assumes that the control socket is even enabled. Parsing the logs is doable, but also quite fragile. And I could certainly parse /var/lib/tor/state, but its format is surely subject to change at any time. How do I correctly determine whether a Tor process is in hibernation? Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaZERAgAKCRAw+TRLM+X4 xshIAQCjNVgq0vBzT+MJhbn8Vetj3UObU8DinVvp3gtj9DeLKgD/aKy7N3nvCUSu zFSSFZTCR0MFxQh9TxjmYO/tKRrPoAE= =gAnQ -----END PGP SIGNATURE-----

3 3

handle malicous IPv6 systems abusing the /64 hostmask
by Toralf Förster 15 Feb '26

15 Feb '26

I extended my DDoS solution [1] by blocking systems where malicous connections attempts where observed from up to 256 IPv6 addresses of the same /64 block within 24 hours from hosters providing /64 hostmasks. For now it is rather a quirk than a generic solution. But it works well. And it extends the solution to accept now manual block requests like ipset add tor-ddos6-5443 <IPv6 address> -exist [1] https://github.com/toralf/torutils?tab=readme-ov-file#details -- Toralf

2 2

Tor Node infected with ransomware
by skankhunt42 15 Feb '26

15 Feb '26

Hello there, today I woke up to an execution error of the relayor playbook. I then tried to look into the affected node (tor-nl1.skankhunt42.pw; nickname skankhunt42nl1) and couldn't SSH into it. So I went to the hosters VNC console and found a ransomware notice: Your files are encrypted, requires payment for decrypting Contact us: Telegram: @cloudcone_raidbot UUID: bfaa20d9-7b11-417d-a702-cfa95d6c203c I then tried to boot into recovery and look at the disk but as expected, partition table and ext4 superblocks were gone. hexdump head of the disk was just the ransomware note shown above. I was running Ubuntu 24.04 Minimal with ESM enabled and unattended-upgrades, everything else managed by relayor. I obviously checked the other nodes for unsual SSH logins (as they had the same SSH key) and didn't found anything. I am rotating the keys for now and shut down the VPS at HostSlick. Not sure if there is something to further investigate maybe. What's odd is that I couldn't find anything about "cloudcone_raidbot", doesn't even exist on telegram. I really want to understand what I did wrong. Maybe someone with more experience may take a look at it? Best, skankhunt42

4 4

Issues with My Tor Relay
by stay.hydrated834＠passmail.net 13 Feb '26

13 Feb '26

Hello there, For the past week I’ve been running a Tor relay using the Tor‑Relay plugin on my OpenSense. While the relay appears to be functioning, I’ve noticed a few irregularities: 1. Selective blocking: Some IP addresses that connect to me are being denied by default, whereas others with similar characteristics connect without any issue. 2. Low bandwidth usage: The relay isn’t consuming much bandwidth. I’m not sure whether this is normal while the relay is still learning its capacity or if something else is limiting traffic. 3. No connections on port 9030: So far, I haven’t seen any inbound connections to the directory port (9030). For testing, the following IP is reachable via ICMP ;) - 109.199.164.117 – Port 9001 (OR) / DIR 9030 Could you advise on why these behaviors are occurring and whether any configuration changes are needed? Thanks for your help, and stay hydrated!

3 2

Call for more Snowflake proxies!
by gus 07 Feb '26

07 Feb '26

Dear relay operators, The Snowflake network is currently overloaded and we need more Snowflake proxies. If you have spare bandwidth or available servers, please consider running Snowflake proxies. As online censorship continues to increase around the world -- particularly with the recent Internet restrictions in Iran[1] --, we are seeing a significant increase on snowflake usage. We urgently need more Snowflake proxies to help handle this surge and ensure that users can continue to access the open Internet. Please share this call with your friends, communities, hackerspaces and anyone who may be able to help! Gus ### How to help There are multiple ways to run snowflake proxies: - Option 1: Run a browser-based proxy. Click the link below, switch it ON and leave the tab open: https://embed-snowflake.torproject.org/ - Option 2: Install Snowflake browser extension: https://snowflake.torproject.org/#addonBtns - Option 3: Run Snowflake standalone proxy (recommended for relay operators): https://community.torproject.org/relay/setup/snowflake/ - Option 4: Install Orbot (iOS/Android) and enable Kindness mode. https://orbot.app/ ### FAQ for relay operators Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? A: It might not be helpful for censored users as Tor relays are frequently blocked on censored regions. Q: I'm operating a Tor bridge, can I run a Snowflake proxy on the same IP? A: It might expose your bridge IP address and censors might take this opportunity to block your bridge. Q: Can I run Snowflake proxy for a short period? A: Yes. Proxies can run for any amount of time. Even short periods help increase available capacity. Q: Do I need to share my Snowflake proxy manually? A: No. Your proxy is automatically distributed by the Snowflake broker. After setup, no further action is required. Q: Where can I see Snowflake proxy statistics? A: Snowflake proxy statistics are available from Tor Collector. You can download the data here: https://collector.torproject.org/recent/snowflakes/ [1] Censorship analysis in Iran: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… -- The Tor Project Community Team Lead

2 2

Hetzner Netscan False Positives
by tor_appliedprivacy.net 07 Feb '26

07 Feb '26

Hi, we just wanted to let you know that we got a Hetzner network contact yesterday here at 39C3 to try to get this issue solved at the root. We can not promise anything at this point but we will likely update this thread in a few weeks (January) about the status with Hetzner on this topic. best regards, tor(a)appliedprivacy.net

6 9

Re: Question about Snowflake proxy on non-exit tor relay
by gus 07 Feb '26

07 Feb '26

Hi, Yes, it applies to all relays, independent of their flags (exit, guard, middle.). Thank you! Gus On Fri, Feb 06, 2026 at 10:58:43AM +0100, Tor-relay wrote: > Hi, > > I have a question regarding the following FAQ entry: > > “Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? > A: It might not be helpful for censored users as Tor relays are frequently > blocked in censored regions.” > > Does this limitation also apply to non-exit relays, or is it mainly a > concern for exit relays? > > Thanks in advance. > > > On Thu, Feb 5, 2026, 17:34 gus via tor-relays < > tor-relays(a)lists.torproject.org> wrote: > > > Dear relay operators, > > > > The Snowflake network is currently overloaded and we need more Snowflake > > proxies. > > > > If you have spare bandwidth or available servers, please consider > > running Snowflake proxies. > > > > As online censorship continues to increase around the world -- > > particularly with the recent Internet restrictions in Iran[1] --, we are > > seeing a significant increase on snowflake usage. We urgently need more > > Snowflake proxies to help handle this surge and ensure that users can > > continue to access the open Internet. > > > > Please share this call with your friends, communities, hackerspaces and > > anyone who may be able to help! > > > > Gus > > > > ### How to help > > > > There are multiple ways to run snowflake proxies: > > > > - Option 1: Run a browser-based proxy. Click the link below, switch it > > ON and leave the tab open: https://embed-snowflake.torproject.org/ > > > > - Option 2: Install Snowflake browser extension: > > https://snowflake.torproject.org/#addonBtns > > > > - Option 3: Run Snowflake standalone proxy (recommended for relay > > operators): > > https://community.torproject.org/relay/setup/snowflake/ > > > > - Option 4: Install Orbot (iOS/Android) and enable Kindness mode. > > https://orbot.app/ > > > > ### FAQ for relay operators > > > > Q: I'm operating a Tor relay, can I run a Snowflake proxy on the same IP? > > A: It might not be helpful for censored users as Tor relays are > > frequently blocked on censored regions. > > > > Q: I'm operating a Tor bridge, can I run a Snowflake proxy on the same IP? > > A: It might expose your bridge IP address and censors might take this > > opportunity to block your bridge. > > > > Q: Can I run Snowflake proxy for a short period? > > A: Yes. Proxies can run for any amount of time. Even short periods help > > increase available capacity. > > > > Q: Do I need to share my Snowflake proxy manually? > > A: No. Your proxy is automatically distributed by the Snowflake broker. > > After setup, no further action is required. > > > > Q: Where can I see Snowflake proxy statistics? > > A: Snowflake proxy statistics are available from Tor Collector. You can > > download the data here: > > https://collector.torproject.org/recent/snowflakes/ > > > > [1] Censorship analysis in Iran: > > https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… > > -- > > The Tor Project > > Community Team Lead > > _______________________________________________ > > tor-relays mailing list -- tor-relays(a)lists.torproject.org > > To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org > > -- The Tor Project Community Team Lead

1 0

Tor Relay Operator Meetup at FOSDEM 2026
by Alexander Hansen Færøy 06 Feb '26

06 Feb '26

Hello Tor Relay Operators, We will not only have a booth at FOSDEM this year, but we will also have a Relay Operator Meetup. The event will take place as a BOF on the Sunday (2026-02-01) at 13:00 to 14:00 in room H.3244. I'll do a little intro when we arrive, but I'll make sure we have enough time for a long Q&A session. Remember, this is an excellent opportunity to show up, ask questions, perhaps answer some questions, and say hi to some of your fellow Tor operators. For more information, please check out: https://fosdem.org/2026/schedule/event/DRMMAB-tor_relay_operator_meetup/ See you there! Cheers, Alex -- Alexander Hansen Færøy

2 4

appliedprivacy.net relays moved to the happy family setup
by tor_appliedprivacy.net 03 Feb '26

03 Feb '26

Today we enabled the happy family setup across all our relays. Since all our relays run in a single /24 we also removed MyFamily at the same time. This should help reduce the overhead introduced by MyFamily.

2 1

Re: Tor Node infected with ransomware
by skankhunt42 03 Feb '26

03 Feb '26

Hi, Thank you for the replies. At the time of writing I was in total panic mode and rotated all my keys. Only after that I saw all these posts from users across different hosters facing the same issue. It was a good practice to just re-evaluate my OPSEC, though. I opened a support ticket with my hoster (HostSlick) and got a reply about 12 hours later. I didn't want to re-deploy until they gave confirmation they are clean again. Luckily, with the awesome relayor playbook I recovered the relay, I just lost the Guard flags, but I think thats fine for now, they'll come back :) However, I decided to turn my back on that hoster and cancelled my VPS, will be up for a few more months. We already had a few disagreements when the problem with spoofed IP abuse reports arose last year. My relay was suspended (without any notice) at the time for multiple days and it took some time to explain to the hoster that the packets did not came from me. PS: Thanks Marco, I will look into a centralized solution for collecting logs, just to make any future incidents easier to understand. Best, skankhunt42

1 0

upcoming CIISS update
by nusenu 02 Feb '26

02 Feb '26

Hi, I'm working on a new contactinfo information sharing specification version. Current version (2): https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Some likely changes will be: * add happy family proof https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/407/diffs * add signal username field https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Pri… * maybe add keyoxide field as suggested by boldsuck: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/iss… Feel free to send me your suggestions and opinions before 2025-06-30 by creating github issues or by replying to this thread. kind regards, nusenu -- https://nusenu.github.io

3 5

Looking to interview Tor relay operators (online or at FOSDEM)
by Jules Dejaeghere 29 Jan '26

29 Jan '26

Hello, I am a researcher at the University of Namur (Belgium), and some of our research focuses on Tor. Recently, we started to investigate how Tor relay operators install and keep their relays up to date. This research was motivated by the (somewhat recent) policy of the Tor Project to exclude outdated relays from the network. As part of this research, we would like to interview relay operators to understand how they install and keep Tor up to date and what they think of the Tor Project policy. If you run, or used to run, Tor relay(s) and are willing to dedicate ~30 minutes of your time, let us know! Your participation will inform our current research about how Tor relay operators manage their relay(s). It will also provide community feedback to the Tor Project about their policy once our results are published. Interviews can be done either online (during the week of 2-6 February 2026, via Framatalk https://framatalk.org/abc/en/) or in person during FOSDEM in Brussels (31 January & 1 February 2026, https://fosdem.org/2026) To participate: - Contact me via email (jules.dejaeghere(a)unamur.be, PGP 0xEB4CC38446E3F82F) or Signal (@julesd.01) - Specify how you want to participate (online via Framatalk, or in person at FOSDEM) and what time slots work for you In practice: - The interview will be audio recorded for analysis by the research team - You can stop the interview at any time, and your answers will be deleted - The interview can be held either in English or in French You'll find attached the full consent form we will ask participants to sign, which describes how the data collected will be processed. If you have any additional questions, you can contact me. Regards, Jules Dejaeghere -- *Jules DEJAEGHERE* PhD Student · Researcher Computer Science Faculty jules.dejaeghere(a)unamur.be https://directory.unamur.be/staff/jdejaegh Université de Namur ASBL Rue de Bruxelles 61 - 5000 Namur Belgium Let’s respect the environment together. *Only print this message if necessary!*

4 10

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

29 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 23 Jan '26

23 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 22 Jan '26

22 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 19 Jan '26

19 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