- tor-relays - lists.torproject.org

Re: Reducing ContactInfo to the family ID level
by DTMF dont.track.my.stuff 10 May '26

10 May '26

Hello together, thank you for raising the idea. As far as i understood - defining some kind of data attributes centrally which are unique on family level is causing more struggle in usability even if there could be a slight benefit in reducing the general payload. ////////////////////////////////////////// Single Point of Truth /////// I see a potential down side in the definition of the central point of truth. It could be one relay of the family. But when a single relay is holding that information and that relay disappears or is compromise, the information could be lost/altered. Are there any other location (non-torrc) where that information could be included. Maybe some functionality that could be added by the TOR-Project themselves instead of having workaround with third party specs like CIISS. ////////////////////////////////////////// Levels of relevancy /////// Furthermore i see different levels of relevancy. - FamilyID / HappyFamilyID Level - vServer Level (Multiple Relays) - Relay Fingerprint Level The ContactInfo (according to spec ciissversion:3) can contain also data attributes (hoster, ram, etc..) which are only relevant on Relay Fingerprint Level, or even vServer Level (multiple relays). That means when we will end up in a hydrid-state anyways. All relays would contain their specific (Relay Fingerprint Level ) data attributes in the ContactInfo field - only one relay would have have the additional information. I also like to understand which data attributes of ciissversion:3 you are specifically talking about. @NUSENU Is it only about these - that you want to markup centrally? (1) email: (2) url: (3) proof: Kind regards DTMS - dont track my stuff

1 0

Mangled metrics and more
by Ralph Seichter 08 May '26

08 May '26

I am currently looking at a relay's data on metrics.torproject.org. It is still listed as "first seen 31 days ago" although it has been active since the second half of 2025. Was this not supposed to get fixed for all relays? More importantly, over the last four weeks the amount of traffic routed through this node has dropped sharply, to less than half of what was in March 2026. Consensus weight has dropped significantly as well, which I assume is connected. The relay is online most of the time, with brief interruptions in the form of reboots about once a week. It uses the latest available version of Tor. I do not know what could cause this massive decline in node usage. Perhaps someone here can enlighten me? -Ralph

1 0

OneProvider using now Scaleway AS
by DeuZa 05 May '26

05 May '26

Hi everyone, Until now, I’ve been managing three exit nodes with OneProvider (WIIT), which is generally considered Tor-friendly. But apparently, they’re now working with ScaleWay, and my fourth server in the Netherlands—which I’d just set up—was suspended in less than 24 hours, and I have to pay $100 to the UCPROTECT mafia... I just wanted to let you know that they’re now using AS12876 (Scaleway SAS), which is already well known... As for me, I’m switching to maxko-hosting -- Alain alias DeuZa alias 0x2A

3 5

The tor-realay-list and the tor-ddos project will soon go down
by Chris Enkidu-6 03 May '26

03 May '26

Due to a serious Illness Soon I will not be able to maintain that list anymore. Without that list the Enkidu-6 Tor-DDOS iptable lists will become useless because they all point to the tor-relay-lists. I'm looking at someone established with enough resources to maintain that list and I'd be glad to offer them the source code for how I get that list. You'll just need to associate your PGP key with your Github account and hopefully have at least two separate servers to run the Cron job on. Any dedicated takers please let me know. The whole thing will go down in probably a couple of weeks. Thank you all for taking the time to read my post.

3 2

confirming onionoo/CollecTor issues vs. Happy Family relay misconfiguration
by nusenu 29 Apr '26

29 Apr '26

Hi, I've been contacting relay operators to verify suspected CollecTor/onionoo issues that appear since CollecTor got replaced in early April. To scale a bit better I'm sending this email to the tor-relays list + BCC instead. In most cases so far it turned out to be an onionoo issue but I see some slow improvements. If you are one of the operators listed below it would be great if you could help verifying your config and confirm if - this is indeed an onionoo issue (all your relays found by the onionoo URL below should have the same Happy Family configuration but according to onionoo do not) - or an inconsistent Happy Family configuration on your side: not all your relays have Happy Family configured (not an onionoo issue) - they are not actually your relays - in this case you can report them for removal to the bad-relays team if they use your contact information With your help we can get a better overview of the current onionoo / CollecTor situation. I noticed unexpected (missing) family_ids on relays using this CIISS url value: alxu.ca doedelkiste.de germancraft.net torix-relays.org tuxli.org for-privacy.net emeraldonion.org www.1aeo.com example onionoo URL for doedelkiste.de: https://onionoo.torproject.org/details?contact=doedelkiste.de&fields=family… You can simply replace the contact parameter value with your domain. You should be able to spot suspicious lines in the output because these lines are shorter (no family_ids string included). thanks for your help! nusenu -- https://nusenu.github.io

2 2

CollecTor has been rewritten in Rust and is now live
by Silvia Puglisi [Hiro] 28 Apr '26

28 Apr '26

Hi everyone, We've rewritten CollecTor from the ground up in Rust, replacing the legacy Java service that has been increasingly unstable over the past months. The new service, collector-rs, was deployed yesterday and is now live. You can find the source at: https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs Shoutout to Juga who has been the main developer behind the redesigned service. A couple of things to be aware of: - Data continues to be available in the usual folders, so existing workflows should not be affected. - You may notice some folders are temporarily duplicated as part of the transition. This is cosmetic and the underlying data is consistent. - The instability of the old CollecTor may have affected services that depend on it as an upstream data source, including Onionoo, Tor Weather, the metrics website, and any community-run services or apps that consume CollecTor data. The new deployment should resolve these issues going forward. If you run into any issues or notice anything unexpected, please don't hesitate to reach out or open an issue on the GitLab repo. Cheers, hiro

2 2

relayor v26.1.0 is released with CPU affinity and flexible instance count
by nusenu 28 Apr '26

28 Apr '26

Hi, relayor v26.1.0 is released. If you upgrade from previous versions to this release please read the Upgrade Steps before upgrading (minor breaking change): https://github.com/nusenu/ansible-relayor/releases/tag/v26.1.0 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… New features ------------ - support arbitrary instance count per server - add CPU affinity support (Linux/systemd only) - when enabled each tor instance is bound to a distinct logical CPU core (disabled by default) - support CIISS v3 Happy Family based proof file generation (drop v2 proof files support) Bugfixes -------- - generate prometheus scrape configurations with correct starting section in YAML - FreeBSD: use py311-passlib instead of py39-passlib Changes ------- - kitchen: remove debian oldstable from kitchen platforms kind regards, nusenu -- https://nusenu.github.io

1 0

HSDirSniper
by Logforme 25 Apr '26

25 Apr '26

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 and saw something new in the log: Apr 24 15:29:38.000 [notice] HSDir cache exceeded limit (1338107635 > 1338067189 bytes). Pruned 50060715 bytes during an HS descriptor upload. Apr 24 16:18:02.000 [notice] HSDir cache exceeded limit (1338072160 > 1338067189 bytes). Pruned 50030005 bytes during an HS descriptor upload. [1 similar message(s) suppressed in last 2640 seconds] Apr 24 17:04:36.000 [notice] HSDir cache exceeded limit (1338085370 > 1338067189 bytes). Pruned 50018816 bytes during an HS descriptor upload. Apr 24 17:50:54.000 [notice] HSDir cache exceeded limit (1338083686 > 1338067189 bytes). Pruned 50017100 bytes during an HS descriptor upload. Apr 24 18:41:29.000 [notice] HSDir cache exceeded limit (1338071628 > 1338067189 bytes). Pruned 50005672 bytes during an HS descriptor upload. Found the message in the source for Arti (which I'm not running): https://tpo.pages.torproject.net/core/doc/tor/relay_8c_source.html. Also found this paper: https://dl.acm.org/doi/epdf/10.1145/3589334.3645591 Did someone just HSDirSnipe against my relay? Does the messages indicate Tor handled it? Anything I should do in my configuration?

1 0

bridge in limbo after new ip assigned
by mossy_road_523＠protonmail.com 24 Apr '26

24 Apr '26

I run an obfs4 bridge. The bridge had been up, operational and carrying (light) traffic for almost 60 days when my ISP assigned me a new address. I wasn't able to repair the bridge for 4 or 5 days. When I did get to it, I registered with a DDNS service, and in my torrc I replaced the hard coded IP with the new domain name I registered. After making that change I restarted the bridge. Logs all looked fine, it booted up to 100%, and reported that the IP was externally reachable (Excellent!). It has been running for 5 days now. It frequently reports having 20 or 25 circuits open (mostly hs_vanguards and conflux_linked; occasionally a "General" purpose circuit). Traffic has been extremely sparse. Even though the bridge seems healthy from my end, I get mixed results from the external checks: * Tor Metrics Relay Search site says the bridge is down, and shows 0 bytes moved and 0 users for the past many days. * bridges.torproject.org/status page always report the bridge as "dysfunctional." * Tor Project Tor Reachability Checker always reports "TCP port is reachable!" I don't mind the "broken" status pages so much, but the fact the bridge itself reports carrying very little (although non-zero) traffic has me concerned. Can any one shed any light on what might be happening, what I could try to further debug this, etc.? Happy to provide snippets of my torrc or any other info that might be helpful. Bridge id is 744DA6E2E2BCB93999C8B16C1C185BA06DFFA447 Tor Metrics page for the bridge: https://metrics.torproject.org/rs.html#details/744DA6E2E2BCB93999C8B16C1C18… bridges-status site: https://bridges.torproject.org/status?id=744DA6E2E2BCB93999C8B16C1C185BA06D… Thanks much for any help.

1 0

Please update standalone snowflake proxy to v2.13.1
by Cecylia Bocovich 20 Apr '26

20 Apr '26

Hello, After receiving reports of Snowflake proxies being blocked by DTLS fingerprint in Russia[0], we updated the standalone proxy to enable a new DTLS randomization and mimicry feature[1] by default. Proxy operators that are using the standalone version of the proxy will need to update or set the following command-line option: -covertdtls-config randomizemimic Browser-based proxies such as the browser badge or webextension were not blocked and do not require an update. Thank you for running a Snowflake proxy! [0] https://github.com/net4people/bbs/issues/603 [1] https://www.petsymposium.org/foci/2025/foci-2025-0006.pdf

6 6