- tor-relays - lists.torproject.org

Observing Moria1’s Higher Missing-Relay Measured Rate (May 24–30 2025)
by Tor at 1AEO 30 May '25

30 May '25

Been exploring how each directory authority measures relays and noticed that, over the week of May 24–30, Moria1 consistently reports significantly fewer relays measured than its peers—about 6% missing versus ~3.5% for most other authorities (over 2 σ below the mean). Quick stats (May 24–30): - Moria1: Weekly missing avg = 556 relays, Z-score = 2.44 - All authorities: Mean missing = 314 relays, σ = 99 Attached the full spreadsheet, some tables, and charts below. Has anyone else spotted this pattern or have ideas why Moria1’s “number of relays voted about” is lower? Any insights or pointers would be greatly appreciated! Sharing on tor-relay list as the ticket that caught my attention doesn't allow me to comment as I'm not part of the "project": https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90 Source: Used "Number of relays voted about" section of Consensus Health pages. Ex: https://consensus-health.torproject.org/consensus-health-2025-05-24-03-00.h… Attached xlsx with all the same data shared below. "Number of Relays Voted About" for May 24th to 30th 2025 Authority Weekly Missing Average Z-score moria1 556 2.44 longclaw 231 0.84 dizum 233 0.82 faravahar 263 0.51 tor26 363 0.49 maatuska 287 0.27 gabelmoo 292 0.23 bastet 296 0.18 dannenberg 308 0.07 Average 314 Standard Deviation 99 Authority 05-30-25 05-29-25 05-28-25 05-27-25 05-26-25 05-25-25 05-24-25 Average moria1 93.31% 93.90% 94.10% 93.86% 93.86% 94.09% 92.81% 93.71% tor26 95.05% 97.39% 96.28% 95.95% 95.95% 95.94% 94.56% 95.87% dizum 96.46% 97.78% 97.92% 97.83% 97.83% 97.84% 96.10% 97.40% gabelmoo 96.55% 96.92% 97.16% 96.83% 96.83% 96.81% 95.55% 96.66% dannenberg 95.60% 96.84% 97.19% 96.85% 96.85% 96.90% 95.73% 96.57% maatuska 96.17% 96.73% 97.37% 96.97% 96.97% 97.05% 95.73% 96.71% longclaw 97.12% 97.52% 97.74% 97.59% 97.59% 97.61% 96.36% 97.36% bastet 96.35% 96.83% 97.13% 96.83% 96.83% 96.80% 95.49% 96.61% faravahar 96.76% 97.26% 97.56% 97.10% 97.10% 97.27% 95.92% 96.99% Average 95.93% 96.80% 96.94% 96.64% 96.64% 96.70% 95.36% 96.43% 05-30-25 Total Running Missing 05-29-25 Total Running Missing 05-28-25 Total Running Missing 05-27-25 Total Running Missing 05-26-25 Total Running Missing 05-25-25 Total Running Missing 05-24-25 Total Running Missing moria1 9046 8441 605 moria1 8751 8217 534 moria1 8803 8284 519 moria1 8794 8254 540 moria1 8794 8254 540 moria1 8753 8236 517 moria1 8836 8201 635 tor26 9003 8557 446 tor26 8740 8512 228 tor26 8719 8395 324 tor26 8709 8356 353 tor26 8709 8356 353 tor26 8739 8384 355 tor26 8818 8338 480 dizum 9193 8868 325 dizum 8915 8717 198 dizum 8900 8715 185 dizum 8891 8698 193 dizum 8891 8698 193 dizum 8857 8666 191 dizum 8932 8584 348 gabelmoo 8951 8642 309 gabelmoo 8678 8411 267 gabelmoo 8718 8470 248 gabelmoo 8708 8432 276 gabelmoo 8708 8432 276 gabelmoo 8664 8388 276 gabelmoo 8743 8354 389 dannenberg 9191 8787 404 dannenberg 8916 8634 282 dannenberg 8902 8652 250 dannenberg 8893 8613 280 dannenberg 8893 8613 280 dannenberg 8858 8583 275 dannenberg 8939 8557 382 maatuska 8951 8608 343 maatuska 8678 8394 284 maatuska 8713 8484 229 maatuska 8705 8441 264 maatuska 8705 8441 264 maatuska 8655 8400 255 maatuska 8738 8365 373 longclaw 8951 8693 258 longclaw 8679 8464 215 longclaw 8718 8521 197 longclaw 8707 8497 210 longclaw 8707 8497 210 longclaw 8662 8455 207 longclaw 8743 8425 318 bastet 8950 8623 327 bastet 8675 8400 275 bastet 8718 8468 250 bastet 8707 8431 276 bastet 8707 8431 276 bastet 8661 8384 277 bastet 8743 8349 394 faravahar 8970 8679 291 faravahar 8748 8508 240 faravahar 8731 8518 213 faravahar 8721 8468 253 faravahar 8721 8468 253 faravahar 8678 8441 237 faravahar 8755 8398 357 consensus 8664 consensus 8446 consensus 8508 consensus 8465 consensus 8465 consensus 8428 consensus 8389 [image.png] [image.png]

1 0

Navigating Top Relay Trackers: Measure and Compare Tor Nodes
by Tor at 1AEO 27 May '25

27 May '25

Couldn't find an updated single reference of Tor relay trackers. Summarized up the main active trackers, as each varies slightly in data and presentation. Please take a look and let me know if anything’s missing or needs updating. Tracker List: Table pasted below; screenshot attached Also viewable on our blog (with working links): https://1aeo.com/blog/navigating-tor-relay-trackers-measure-compare.html Our favorite: Allium – super easy to deploy, offers ASN and family-level summaries, and update interval is configurable (ours refreshes every 30 min): https://1aeo.com/metrics/ Source: https://git.jordan.im/allium/ Thanks for your input, and happy operating! Name Live May '25 Bandwidth Aggregate By Family or AS Top 10 Charts & Graphs Map/Geo Features Update Frequency Search & Filter Relay Details Historical Data Source Code Source Last Updated [Tor Relay Search](https://metrics.torproject.org/rs.html) Yes Yes Yes Yes Yes No Continuously Nickname, Fingerprint, ASN, and more Bandwidth stats; Configuration; Uptime; Flags; Exit policy Bandwidth stats [Partial](https://github.com/torproject/metrics-web) 12/20 [OrNetStats](https://nusenu.github.io/OrNetStats/) Yes Yes Yes Yes Yes No Monthly Operator Bandwidth, Configuration; Uptime; Flags; Exit policy Guard/Exit probability trends [Partial](https://github.com/nusenu/OrNetStats) 05/25 [0x7c0 Relay Metrics](https://relays.0x7c0.com/) Yes Yes Yes Yes No No Hourly ASN; Families Bandwidth, Configuration; Uptime; Flags; Exit policy No [Yes](https://git.jordan.im/allium) 06/24 [Onionite](https://onionite.net/) Yes Yes No Yes No No On-demand Relays/Bridges search Bandwidth; Configuration; Uptime; Flags; Exit policy Bandwidth [Yes](https://github.com/lukechilds/onionite) 02/23 [TorStatus](https://torstatus.rueckgr.at/) Yes Yes No Yes No No ~15-minute Country; Flags; Contact Bandwidth, Configuration; Uptime; Flags; Exit policy No [Yes](https://github.com/paulchen/torstatus) 02/25 [TorMap](https://tormap.org/) No — — — — — — — — — [Yes](https://github.com/TorMap/tormap) 05/25 [image.png]

1 0

Tor Relay Deployment Dilemma: When to Not Pay for Underutilized Server Resources?
by Tor at 1AEO 23 May '25

23 May '25

Part 3 - Looking for feedback on our Tor relay configuration decision: Looking for guidance on optimizing server / bandwidth spending for Tor guard / middle relays across datacenters. Our current setup: - All same cost: Three servers in different datacenters, each with 10 Gbps unmetered bandwidth. - Identical hardware/software: Each server has 128 threads, 512GB–768GB RAM, and the same software stack. - Diversity benefits: Each server hosts fewer than 10 other relays, enhancing overall network diversity. - Primary differences: Geographic location and upstream peering/routing. Current Utilization: - Server 1: 2Gbps utilized (20% utilization) - Server 2: 6Gbps utilized (60% utilization) - Server 3: 8Gbps utilized (80% utilization) Overall, using 16 Gbps out of 30 Gbps purchased -- roughly half our bandwidth is idle / "wasted". Assuming we can't significantly optimize these servers any further and given the significant under utilization on Server 1 (80% idle) and Server 2 (40% idle), what would you do in this scenario? Some options we’re considering: - Consolidation: Paying only for the servers with the highest utilization. - Repurposing: Allocating the idle bandwidth to another purpose that benefits Tor (or a similar effort). - Reinvestment: Using the funds from Servers 1 and 2 to acquire additional high-utilization capacity (e.g., more of Server 3 configuration) to boost our overall contribution closer to 24 Gbps. - Other strategies: Any alternative approaches you might suggest. Appreciate any thoughts or best practices to help reduce wasted expenditure while maximizing the utility of our available resources. Thanks for your insights!

3 8

Tor Operators Ask Me Anything - 13-06-2025
by Nothing to hide 21 May '25

21 May '25

Hi Tor operators, We already briefly mentioned an upcoming Ask Me Anything (AMA) by Tor operators during the Tor Operator Meetup on the 10th of May. And now it's time for the announcement: https://www.reddit.com/r/TOR/comments/1krv4rt/tor_operators_ask_me_anything…. During this AMA, anyone can engage with us directly and ask us anything they're curious about. The following Tor operators are participating: R0cket, Nothing to hide, Artikel10 and CCC Stuttgart. The Ask Me Anything will be held on Friday 13 June 2025 between 08:00-23:00 UTC on /r/TOR. Feel free to ask your questions the 13th or to share this AMA with people or your communities. We also have a post on Mastodon to share: https://mastodon.social/@tor_ama/114545560947637613. We're experimenting with this format to see whether it benefits the community. Our goal is to provide answers and context about Tor, dispel myths and inspire more people to become Tor operators--or encourage current operators to expand their efforts, perhaps by scaling up or running exit relays. This initial AMA will help us learn from our mistakes and if successful, establish a regular series where other operators (of all shapes and sizes) can participate. We're looking forward to the 13th of June! And if anyone has questions about the AMA, feel free to ask them or send people our way :). Have a great day, Nothing to hide

1 0

Seeking Advice on Running a Tor Exit Node in India
by RUSTEDUSTED 19 May '25

19 May '25

Dear Tor Operators, I hope this message finds you well. I am planning to set up a Tor exit node and would like to seek your valuable advice and guidance before proceeding. Specifically, I want to understand the following: - What are the essential technical and operational considerations I should be aware of before running an exit node? - Are there best practices or configurations you recommend to ensure the node runs securely and efficiently? - What kind of bandwidth allocation is ideal? I am considering allocating around 30-40 Mbps on my internet connection—would this be sufficient or optimal? - Could you please share insights on the legal responsibilities and potential risks involved with operating a Tor exit node in India? - Are there any specific resources, communities, or contacts you recommend I engage with for ongoing support? - (most importantly) what hardware accelerations should my device support?? is it fine if i run it on raspberry pi 5 or would it need a modern x86 CPU? I appreciate any advice or resources you can share. I am eager to contribute responsibly and effectively to the Tor network. Thank you very much for your time and help. Best regards, Pradnyesh Email: rustedusted(a)proton.me Location: Pune, India

3 2

Next Tor Relay Operator Meetup - Saturday, May 10th @ 1800 UTC
by gus 10 May '25

10 May '25

Hi! The next online relay operator meetup is happening on Saturday, May 10th, 2025 at 1800 UTC[1]. ## Agenda - Announcements - Happy Family and updates from Network Team - Tor @ Universities - Next Tor in-person events: WHY, Bornhack, DEF Con - Next Tor Relay Operator meeting Feel free to suggest and add other topics for the meetup on this issue here: https://gitlab.torproject.org/tpo/community/relays/-/issues/114 ## How to join Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - Date & Time: Saturday, May 10th, 2025 @ 18.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room link above. The room will open 10 minutes before the meetup starts. Gus [1] If you're confused about UTC and your timezone, anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime -- The Tor Project Community Team Lead

1 1

Patela: A basement full of amnesic servers
by Osservatorio Nessuno 07 May '25

07 May '25

Hi everyone! A while back, we announced[1] our project to set up a server facility in Italy to host Tor exit nodes. After several weeks of testing, we’re excited to share that our first nodes are now in production, running on our autonomous system. [2] Four of these nodes operate diskless thanks to System Transparency [3] and Patela [4], a small, pull-based tool we developed to configure exit nodes efficiently. To optimize this infrastructure, we’ve worked on multiple fronts, including mTLS for nodes authentication, TPM for crypto operation and nftables rules. In this post[5], we’ll explain how the system works, and we’d love to hear your thoughts and feedback via the mailing list. Now that we’ve completed this initial testing phase, our next goal is to acquire suitable hardware to increase bandwidth capacity. Stay tuned for updates! Bye b [1] - https://osservatorionessuno.org/blog/2024/12/how-to-bgp-from-your-basement-… [2] - https://metrics.torproject.org/rs.html#search/as:AS214094 [3] - https://docs.system-transparency.org/st-1.0.0/ [4] - https://github.com/osservatorionessuno/patela [5] - https://osservatorionessuno.org/blog/2025/05/patela-a-basement-full-of-amne…

2 2

How Best to Maximize Impact of $500/mo Budget?
by Tor at 1AEO 05 May '25

05 May '25

If you have a budget of $500/mo (EUR or USD, roughly) that could be used to strengthen Tor network, what would you use it for and why? Some ideas: Run new relays: Lease VPS or colocate hardware yourself Fund existing operators: Provide stipends or grants to help other operators Donate to the Tor Foundation: Support core development, research, and docs. Other ideas: e.g. donation platforms, bandwidth grants, research funding? Which approach (or mix) yields the best consensus-weight gain per dollar? Any tips on pitfalls, vetting, or recommended donation channels? I've been leaning towards running new relays since it seems to always benefit from more diverse growth but wondering what others think. Thanks for your insights!

2 1

Tor Relay Deployment Dilemma: Handle BGP yourself or have it done upstream to announce your own AS?
by Tor at 1AEO 02 May '25

02 May '25

I'm currently evaluating the best approach for having my AS announced with my owned (not rented) IPv4 addresses, and I've observed that hosting providers have different preferences for handling BGP sessions. For example, one provider requires that the BGP session be managed on the same server running the Tor relays, while another handles the announcement with my AS entirely on their side. This inconsistency makes it challenging to determine the most effective approach. I'm seeking guidance on the following points (or others you think are helpful): - When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible? - When required to manage BGP myself: - To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing? - Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them? - Are there best practices for route filtering or failover management? - What are your experiences regarding the compute and memory requirements for these configurations? - What are some preferred monitoring solutions? bgpmon.net doesn't seem free... Helpful read and suggestions at the end from this 6 year old article from nusenu, but couldn't find too much beyond this: https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijackin… I'm already using ROA and RPKI via ARIN for each /24 and limit max length to /24 to help as well. "The Tor exit fraction located in /24 prefixes is much higher than the guard capacity. So hijacks against exit capacity might be harder than attacks against guard capacity." - Seems also good to have /24 prefixes for guards, not just exits. Thanks!

2 2

relayor v25.0.0 is released
by nusenu 29 Apr '25

29 Apr '25

Hi, relayor v25.0.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Most notable changes: * Support the MyFamily successor "happy families". This new relayor feature is currently opt-in as it also requires an alpha release of tor. When happy families reaches a tor stable release we will enable it by default and make the opt-in setting obsolete. I'm not so happy about the details but I also didn't want to introduce new dependencies so relayor is copying the family key file for **every** tor instance - see the background here [1]. Happy families is especially useful for large operators running many tor instances. The MyFamily configuration is not replaced by happy families, both designs are used when happy families is enabled. * prometheus integration improvement (backward incompatible change): remove variable tor_prometheus_config_file. relayor makes use of prometheus conf.d folder support instead of generating the entire configuration, relayor only drops the scrape config files into a configurable folder where prometheus is expected to read them. See prometheus' global config: scrape_config_files [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/41046 Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v25.0.0 kind regards, nusenu -- https://nusenu.github.io

1 0