- tor-relays - lists.torproject.org

relayor v25.1.0 is released
by nusenu 15 Oct '25

15 Oct '25

Hi, relayor v25.1.0 is released. https://github.com/nusenu/ansible-relayor/releases/tag/v25.1.0 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… Changes: * Debian 13 is supported (please upgrade your Debian 12 relays because we plan to remove support for Debian 12 / Debian oldstable) * FreeBSD 14.3 is supported * increase minimal required ansible version from 2.16.14 to 2.18.1 **Note on upgrading from previous relayor versions** when managing Debian/Ubuntu relays A manual step is required when upgrading from previous versions on Debian/Ubuntu relays. To avoid conflicting apt sources make sure to move this file on your Debian/Ubuntu relays directly before running ansible-relayor v25.1.0 for the first time. You can use this command to move the file into your home: sudo mv -i /etc/apt/sources.list.d/deb_torproject_org_torproject_org.list ~ Make sure you did not edit the content of this file before. kind regards, nusenu -- https://nusenu.github.io

1 0

[Proposal] Tor exit lifecycle
by gus 15 Oct '25

15 Oct '25

Dear relay operators, We've drafted a new proposal for the relay operator community. The proposal introduces a lifecycle for Tor exit relays, inspired by the existing lifecycle used for Guard and HSDir flags. The main goal is to make it harder for attackers to quickly deploy malicious exit relays. Your feedback is welcome! You can read and comment on it here: https://gitlab.torproject.org/tpo/community/policies/-/issues/32. Alternatively, you can read the full text below. Gus ``` Filename: 102-tor-exit-lifecycle.md Title: Tor Exit lifecycle Author: Gus - gus at torproject.org, GeKo - gk at torproject.org, Hiro - hiro at torproject.org Created: 2025-10-14 Status: Draft ``` ## Overview Tor exit relays are maintained by volunteers and used to leave the Tor network and access websites and other online services. This proposal introduces a lifecycle for Tor exit relays, inspired by the lifecycle already used for non-exit relays to acquire particular flags, such as the Guard[1] and HSDir[2] flags. The main goal of this proposal is to make it harder for attackers to quickly deploy malicious exit relays and exploit Tor users. The proposed lifecycle adds a staging phase for new relays configured as exit relays. This is a period during which those relays are only functioning as non-exit relays. Afterwards, they become eligible for the Exit flag and can then be used as exit relays as intended. This exit relay lifecycle should raise the operational costs for malicious actors, enable earlier detection of bad relays[3], and provide more protection against Sybil attacks. ## Motivation Currently, because Tor is an open and public network, any relay operator can set up a new exit relay and, after a brief warm-up period, begin handling real user traffic. Malicious actors have exploited this openness to launch man-in-the-middle (MITM)[4][5] attacks, leading to a continuous "whack-a-mole" situation for the Network Health Team and the Directory Authorities: while attackers can often be blocked before causing major harm, significant human resources are required to keep up with them. As a small non-profit, it is essential for the Tor Project to focus its limited resources on mission-critical tasks. By implementing mitigations that force adversaries to invest more time and effort or make their attacks faster and easier to detect, we create a more favorable scenario for the Tor Project and its users. To help with that, a staged lifecycle for exit relays will: - Slow down the deployment speed of malicious exit relays as they will need to go through a staging phase. - Give time for analysis and automatic or proactive scanning before an exit relay sees and can exploit any outgoing user traffic. ## Proposal New relays configured as exit relays must complete a staging phase of 4 days (configurable) before becoming eligible for the Exit flag. The staging phase should be long enough to deter opportunistic abuse, but short enough not to discourage legitimate relay operators. ### Security implications The proposed change does not harm user anonymity or security. By reducing the number of new, untrusted exit relays on the Tor network, it improves safety for Tor users and disincentivizes short-lived "throwaway" malicious exit relays. ## Implementation considerations The exit relay lifecycle could be implemented with the help of Tor configuration options or consensus parameters, so that Directory Authorities can tune the staging length without a tor release, or disable the feature temporarily in unusual capacity situations. The exact code and format details will be specified in a follow-up torspec proposal (and then implemented in tor/arti). Note that the technical implementation may have slight changes to this proposal. ### Participation and Communication Once the exit lifecycle is implemented in a torspec proposal, a communication strategy will take place to inform and support relay operators. This strategy may include, but is not limited to, the following actions: - Update the [Tor Relay Operator documentation](https://community.torproject.org/relay) to include an explanation of the new exit relay lifecycle. - Display a banner on Tor Metrics Relay Search for new exit relays, directing users to the exit lifecycle proposal or relevant documentation. - Inform the relay operator community on their communication channels such as the tor-relays mailing list, blog post, and the Tor Forum. - Document new behavior resulted of the exit lifecycle, for example, if an exit relay drops of the consensus for a period, they will lose their exit flag and will need to restart the lifecycle described on this document. For the implementation discussion, see: https://gitlab.torproject.org/tpo/network-health/team/-/issues/220. ## Notes [1] Tor Guard specification: https://spec.torproject.org/guard-spec/index.html \ [2] HSDIR https://spec.torproject.org/tor-spec/subprotocol-versioning.html?highlight=… \ [3] Criteria for bad relays: https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-… \ [4] Also known as a monster-in-the-middle, machine-in-the-middle, meddler-in-the-middle, manipulator-in-the-middle, person-in-the-middle (PITM), or adversary-in-the-middle (AITM) attack. \ [5] https://blog.torproject.org/bad-exit-relays-may-june-2020/ -- The Tor Project Community Team Lead

1 0

Bug: conflux_util.h:24
by abir 13 Oct '25

13 Oct '25

Oct 12 21:24:47.000 [warn] tor_bug_occurred_: Bug: conflux_util.h:24: CIRCUIT_IS_CONFLUX: Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed. (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d) Oct 12 21:24:47.000 [warn] Bug: Tor 0.4.9.3-alpha (git-1ee22f8f9a98719d): Non-fatal assertion circ->purpose == CIRCUIT_PURPOSE_CONFLUX_UNLINKED failed in CIRCUIT_IS_CONFLUX at conflux_util.h:24. (Stack trace not available) (on Tor 0.4.9.3-alpha 1ee22f8f9a98719d)

2 1

shutting down a relay with less interruption for maintenance
by Marco Moock 13 Oct '25

13 Oct '25

Hello! I would like to ask what the preferred way is to shut down a relay gracefully in case of maintenance downtime to avoid interrupted connections. The shutdown process might take a while. -- Gruß Marco Send unsolicited bulk mail to 1760260473muell(a)stinkedores.dorfdsl.de

2 1

Relay not ramping up as expected
by tor＠busybear.se 13 Oct '25

13 Oct '25

Hello. My exit 7BE9E2EF2BB41BB662D9A3CD68289B9E3DBF8A08 WYSWYG has kinda frozen at the current status, although formerly being both guard, stable and advertising towards 60 MB output on a 1Gb fibre. My provider, Bahnhof, has no problem with Tor, even though my exit been investigated by the police as involved in the biggest leak in Sweden without consequences for me. Uptime should be enough by now for at least a stable flag. Speedtest on my IP says upwards 950 Mb up\down. My torrc is simple: ORPort 65532 DirPort 65533 #ClientPreferIPv6ORPort Nickname WYSWYG Contactinfo <tor AT busybear DOT se> ExitRelay 1 Log notice file /home/*/torlog SafeLogging 1 ProtocolWarnings 1 RunAsDaemon 1 ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /home/*/control_auth_cookie #GeoIPFile /home/*/TorBrowser/Data/Tor/geoip IPv6Exit 0 ConnDirectionStatistics 1 ExtraInfoStatistics 1 Any suggestions? Logs provided on request. \Bamse

1 0

My Tor Relay Is Slower Than Expected (Already Did Basic Debugging)
by eviljoel 09 Oct '25

09 Oct '25

Greetings, I'm running the "chinstrap" Tor relay and am seeing high variability on the bandwidth graph here: https://metrics.torproject.org/rs.html#details/F01C3861418540248EAEC724038C… I've run Tor relay's before and don't remember seeing this much variability. I've setup my relay as a bridge and can consistently pull 300k from the relay but the bandwidth graph is showing far less than that on average. I was hoping someone could take a look and tell me if anything looks wrong. Also, if there is a problem, what I can do to fix it? The relay is configured for 414.25 KBytes per second with a burst rate of four times that amount. Thank you, eviljoel -- eviljoel's PGP fingerprint: A2BE 2D12 24D1 67CA 8830 DDE7 DFB3 676B 196D 6430

1 0

Running a Snowflake bridge on Debain
by Keifer Bly 06 Oct '25

06 Oct '25

Hi, So I am running a snowflake bridge, and here is the output after it running for a few days. Wondering, on my system, as there is no torrc configuration, is there a port that needs to be forwarded? How can I check if the bridge is reachable? Is the app from here: https://snowflake.torproject.org/ Thanks all. --Keifer

2 1

bridge relay marked as down but I can manually connect to it
by Eritque arcus 05 Oct '25

05 Oct '25

Hi, I don't know why but my bridge relay marked as down but I can connect to it with my Tor browser. Nyx can successfully detected my traffic and two others join after my traffic(but in other time it's just ~700B/s w/o connection). And every-time I restart the tor service, it will up for some hours. There is no error or warning in log. More context: I setup my first relay on yesterday(>18hrs ago) on Ubuntu 24, Tor 0.4.8.18 following the guide; It's on KVM/QEMU VPS with some of my other services. the status is right here: <https://bridges.torproject.org/status?id=A69AD85C2E175BD0F753E1CCBE5D4BA371…> and <https://metrics.torproject.org/rs.html#details/A69AD85C2E175BD0F753E1CCBE5D…>. Do I need to allow some extra ports? right now I only accept the ORPort and block any others. Or it may relatives with my VPS ISP? -- Best, Eritque Arcus

3 3

It has been a good run, hasn't it?
by Ralph Seichter 25 Sep '25

25 Sep '25

I am sorry to say that after more than 9 years of continuous service, Tor node 0C3D5E19E3C75B505C8ACD26F89DCA2DF970553E is scheduled to cease operations on 2025-09-30. It has certainly been a good run and I am unhappy to see HORUS1 go dark, but the costs for the dedicated machine can no longer be justified. There were recurring abuse complaints forwared to me, by people who don't understand that a non-exit Tor node poses no threat and even due to IP packet spoofing, but that's something I was (and am) willing to deal with. Alas, money is tight. -Ralph

4 5

Automated Snowflake and WebTunnel role deployment now supports Debian Trixie
by Jacobo Nájera 24 Sep '25

24 Sep '25

Hi, Support for Debian Trixie has been added to the WebTunnel and Snowflake Ansible roles. With these roles, you can install, configure, and operate WebTunnel and Snowflake bridges for the Tor network. The roles are now fully compatible with Debian Trixie, which will receive full support until August 9, 2028, and LTS support until June 30, 2030. More details are available on the Acuarela Taller website: WebTunnel https://acuarelataller.org/en/ansible-webtunnel-bridges-tor-network/ Snowflake https://acuarelataller.org/en/ansible-for-tor-network-snowflake-bridges/ Best regards, Jacobo

1 0

(JAILED) U.S. Tor Operator Persecuted by FBI After Refusing Decrypt Requests
by Adrienne Rockenhaus 17 Sep '25

17 Sep '25

Hello Tor-Relays Community, I’m writing to you because my husband, Conrad Rockenhaus, was a member of your community. He was a long-time Tor relay operator, and he is now in serious danger. I believe you are one of the few groups who will truly understand why. Conrad’s ordeal began when he refused to help the FBI decrypt traffic from his exit nodes. Months later, the government arrested him. Their official reason was a minor, non-violent CFAA charge from a workplace dispute that had nothing to do with Tor. He was convicted of a single count (taking down the network of his former employer, Apple Leisure Group, after they fired their U.S. DevOps team to replace them with cheaper overseas hires). In fact, the statute of limitations was a couple of months from expiration. They clearly used this old charge as a pretext to target him. This minor charge was used to hold him. A U.S. Probation Officer then lied under oath to keep him jailed (pre trial) for three years. She claimed he installed a "Linux OS called Spice" to access the "dark web" and hide his activity. This was a technical lie. The software was just a standard SPICE graphics driver for his Ph.D. program. It was not an operating system and could not disable their monitoring. He now faces retaliation from U.S. Probation in Michigan. They have used fraudulent warrants to jail him again. He is currently in a county jail with a severe head injury from his arrest and has been denied a lawyer, a violation of his constitutional rights. This is a documented case of the government twisting technical facts to prosecute a member of your community. I am not asking for money. I am asking you to please help amplify his story. You understand the technical truth and why this fight is so important. We have all the evidence documented, including the court transcripts and fraudulent warrants. You can see everything here: https://rockenhaus.com Thank you for your time and for everything you do for privacy online. Sincerely, Adrienne Rockenhaus https://x.com/adezero

3 4

Re: tor-relays Digest, Vol 176, Issue 1
by code9n＠pm.me 10 Sep '25

10 Sep '25

On Tuesday, September 9th, 2025 at 13:01, tor-relays-request(a)lists.torproject.org <tor-relays-request(a)lists.torproject.org> wrote: > > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: lower relay through-put: consensus or throttling? > (Georg Koppen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 8 Sep 2025 12:51:05 +0000 > From: Georg Koppen gk(a)torproject.org > > Subject: [tor-relays] Re: lower relay through-put: consensus or > throttling? > To: tor-relays(a)lists.torproject.org > Message-ID: 814fe4cb-affe-464a-91c2-6c0a52711ece(a)torproject.org > > Content-Type: multipart/signed; micalg=pgp-sha256; > protocol="application/pgp-signature"; > boundary="------------QI1vquvNwiOUwz7yMKJyMz29" > > Hello! > > code9n via tor-relays: > > > Hi, > > > > For the last 5 months or so my guard / middle relay ( 41D4F82AB54AE5C5FB8D3CD24B4FC84350EFEF03 ) has been moving about 8MB/sec each way which is lower than it had been doing for the 2 years up to that point - it had been averaging around 12MB/sec. > > > > There's been talk on this mailing list of northern European relays getting lower consensus weight recently. (Mine is hosted in the UK). > > > > When my vps was last coming up for annual re-payment I told the admins there (Hostworld) that I was maybe not going to renew my annual subscription and the relay's through-put went up to around 20MB/sec for a while - until I'd renewed. So they do boost / throttle to suit themselves. > > > Could you give us some dates about when you talked to the admins, when > you renewed etc. so we can try to look at the behavior of your relay > during that time and correlate those dates with drops/raises of its > consensus weight? > > > So my question is: Is my last few months lower efficacy likely due to Tor (consensus weight) or throttling by my vps provider? > > > I am not sure yet but I might be able to give you an educated guess > after looking closer at your relay's data with the help of the dates I > asked you about above. > > Georg > > > (It's not my settings in torrc, by the way, they're set way higher than is being used and are unchanged since the earlier, higher, through-put). > > > > Thanks, > > > > Pete > > > > _______________________________________________ > > 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

lower relay through-put: consensus or throttling?
by code9n＠pm.me 08 Sep '25

08 Sep '25

Hi, For the last 5 months or so my guard / middle relay ( 41D4F82AB54AE5C5FB8D3CD24B4FC84350EFEF03 ) has been moving about 8MB/sec each way which is lower than it had been doing for the 2 years up to that point - it had been averaging around 12MB/sec. There's been talk on this mailing list of northern European relays getting lower consensus weight recently. (Mine is hosted in the UK). When my vps was last coming up for annual re-payment I told the admins there (Hostworld) that I was maybe not going to renew my annual subscription and the relay's through-put went up to around 20MB/sec for a while - until I'd renewed. So they do boost / throttle to suit themselves. So my question is: Is my last few months lower efficacy likely due to Tor (consensus weight) or throttling by my vps provider? (It's not my settings in torrc, by the way, they're set way higher than is being used and are unchanged since the earlier, higher, through-put). Thanks, Pete

2 1

Webtunnels
by gerard＠bulger.co.uk 08 Sep '25

08 Sep '25

I have setup three Webtunnels running for some months, all set to Telegram distribution. Suddenly one of them in Australia has become very popular with 1000 outgoing connections while the two others, EU and USA have just 5-10 outgoing connections at an time. How can encourage a fairer distribution, and my Australian one will start costing + as exceeding data limits of the VPS provider at 6TB a month Gerry

1 0

Urgent: Assistance Regarding BadExit Flag on my Relay
by Dis 08 Sep '25

08 Sep '25

Hello, I noticed that my exit relay has been flagged as a BadExit on the Tor metrics site. I would really like to maintain a healthy exit node to help the network, as I understand there is often a shortage compared to non-exit relays. I would like to contribute to the Tor network in that way specifically. Could you please let me know what issues led to this flag and what steps I can take to resolve them? I’m fully committed to making the necessary changes. If that means updating configuration, improving stability, or upgrading my VPS resources, I'll do it. Here are my node's details: *Fingerprint:* A00EE720829232514D719A0F4C338C806B9F96F0 *OR Addresses:* 45.135.180.154:9001 *Nickname:*nyaa My contact email is listed in the relay configuration, and I’m emailing you from that address currently. Best regards, Dis

2 1

[bridge operators] Fix required for WebTunnel docker bridges
by gus 29 Aug '25

29 Aug '25

Hello bridge operators, During yesterday's upgrade of our WebTunnel docker image, some bridges stopped working due to an operating system issue[1]. Only WebTunnel operators using our official Docker image are affected. If your bridge is affected and you don’t apply this fix, it will remain non-functional and users will not be able to connect. You need to take action now! ### How to check if your bridge is affected Run the command: `docker ps` If your WebTunnel container is stuck in a restart loop (shows `Restarting (1)` or similar message), then your bridge needs fixing: ``` thetorproject/webtunnel-bridge:latest "/usr/local/bin/star…" 22 hours ago Restarting (1) 21 seconds ago webtunnelBridge5a35b7dd47c6 containrrr/ ``` ### How to fix your WebTunnel docker bridge 1. List your Docker volumes: ``` docker volume list ``` 2. Identify the persistent volume for Tor, then run (adjust the volume name accordingly): ``` docker run --rm -it -v root_webtunnel-tor-state:/var/lib/tor debian chown -R 100 /var/lib/tor ``` 3. Restart your bridge: ``` docker compose up -d ``` If you need help, please reach out to us on irc #tor-relays (irc.oftc.net) or matrix: https://matrix.to/#/#tor-relays:matrix.org. Thank you for running bridges! gus [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt… -- The Tor Project Community Team Lead

1 0

(no subject)
by kerem the secondary 21 Aug '25

21 Aug '25

[warn] Your server has not managed to confirm reachability for its ORPort(s) at 31.223.44.45:443. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. hello my relay doesnt work, firewall is not running, my isp did not block port 443, i have tried the official torrc file in the techincal setup page (only changed the log, contact and relay name) which did not work. I have not included the entire notices.log file because its 4 megabytes of the same error message. I have no idea what i did wrong please help. Thanks in advance

2 1

authority bandwidth measurements and latency
by Marco Moock 20 Aug '25

20 Aug '25

Hello! I operate 94DEAD24492D6D01E3DE614E8BE6B4035329A4D7 and I've seen various changes in the measured bandwidth in atlas. At the beginning, more than 10 MB/s were measured, now below 3. The machine itself didn't change, I can reach high up- and download rates if I transfer stuff via HTTP/FTP etc. I see that latency isn't that low (50ms https://atlas.ripe.net/measurements/116107380/results) and want to ask if that might be part of this situation. I dunno about the TCP settings of the authority bandwidth testing machines. Can anybody give some hints what's going on? -- Gruß Marco Send unsolicited bulk mail to 1751988041muell(a)stinkedores.dorfdsl.de

3 4

moria1 unreachable from AS202306
by Marco Moock 19 Aug '25

19 Aug '25

Hello! I cannot communicate with moria1 from 78.153.140.44 and it cannot reach my system. I can communicate with the rest of the world. For me, it looks like a firewall is blocking it, as traceroute clearly indicates a different behaviour for ICMP echo request and TCP. I've tried that multiple times. [m@teufel ~]$ traceroute -P tcp -p 9201 128.31.0.39 traceroute to 128.31.0.39 (128.31.0.39), 64 hops max, 40 byte packets 1 gw.hostglobal.plus (78.153.140.1) 0.460 ms 0.427 ms 0.349 ms 2 10.28.1.6 (10.28.1.6) 210.766 ms 353.511 ms 563.838 ms 3 ae8-209.rt.ad.rix.lv.retn.net (87.245.239.26) 25.299 ms 25.264 ms 25.228 ms 4 * ae1-5.rt.irx.fkt.de.retn.net (87.245.232.244) 51.147 ms 52.203 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * [m@teufel ~]$ traceroute -I 128.31.0.39 traceroute to 128.31.0.39 (128.31.0.39), 64 hops max, 48 byte packets 1 gw.hostglobal.plus (78.153.140.1) 0.286 ms 1.231 ms 0.219 ms 2 10.28.1.6 (10.28.1.6) 1041.847 ms 25.035 ms 25.234 ms 3 ae8-209.rt.ad.rix.lv.retn.net (87.245.239.26) 26.015 ms 26.091 ms 26.084 ms 4 ae1-5.rt.irx.fkt.de.retn.net (87.245.232.244) 61.037 ms 53.253 ms 52.533 ms 5 * * * 6 * ae2.13.ear2.Boston1.net.lumen.tech (4.69.230.138) 135.086 ms 135.092 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * What are your opinions about this? -- Gruß Marco Send unsolicited bulk mail to 1755409526muell(a)stinkedores.dorfdsl.de

2 2

Tor relay back to 1 weight
by tor＠obscurity.app 17 Aug '25

17 Aug '25

ADA11AA7FD14CFE904C7E302CA08EFBC8AFB415D My relay jumped to 13500 weight, then back to 1. Even thought relay is really young, this is (in my opinnion) not normal behavior? Tor notice logs doesnt give any error, and relay got unmettered bandwidth.

2 1

Tor People @ WHY2025
by Alexander Hansen Færøy 12 Aug '25

12 Aug '25

Hey Relay Operators, I'll be at the upcoming WHY2025 hacker camp in the Netherlands. WHY2025 is an excellent opportunity to do a Relay Operator meetup at some point during the camp days. Who else from here is going? At the latest CCCamp, we did a meetup at the BornHack village, but we did receive some negative feedback on the noise level in that general area, so I was thinking of investigating if there is a quieter place with some good seating where we could host the meetup this time, and announce the time and location here on the list. Suggestions of locations are most welcome. I recently received a link from tornth on #tor-relays on IRC/Matrix to https://wiki.why2025.org/Project:Tor_Relays, where it's relatively easy to add "Tor Relays" as a project from your WHY2025 wiki account. Cheers, Alex -- Alexander Hansen Færøy

4 6

Low consensus weight votes from European authorities
by Skye Clayton 12 Aug '25

12 Aug '25

Hello, I’ve had a non-exit relay (602D56DFD408530F7FE3056CAF1DA413A50ECAE4) that has been getting low weight votes from authorities like tor26, gabelmoo, and maatuska, compared to other authorities like moria1 and bastet after checking with the consensus-health tor site. At first, I questioned my ISP (ATT Fiber)’s routing to Germany based on an authority IP so I speedtested to four speedtest.net servers in Nuremberg but I received expected bw and around 100ms ping. Regardless, my relay hasn’t had anywhere as much traffic as it should have, and my relay is essentially offering resources to the Tor network that are being devalued right now. My relay’s consensus weight is around 3000, even though moria1 and bastet vote mine around 10000. I would also ask for the Tor developers’ reasoning for using median of authorities in consensus weighting rather than mean since in my mind, if no authorities are malicious/compromised to give false values, then mean would give a more accurate representation of actual measured bw performance from the authorities, IMO. Is median only used because of a large prevalence of extremely skewed bw vote distributions? Can this be remedied in software to allow for mean usage later on? Any help would be appreciated :)

2 1

FW: Re: Tor
by C. Pe. 11 Aug '25

11 Aug '25

forgot to copy the list. ---------------------------------------- Betreff: FW: Re: [tor-relays] Tor Von: C. Pe. <peca-relay(a)mailfence.com> An: CIP <ciptorrelays(a)gmail.com> Datum: 09.08.2025, 17:10:51 Hi, after looking at the first five entries from your list, I observe one common pattern: - Each relay has got a reachable IPv6 address (next to IPv4) - Each relay has an IPv4 exit policy - Each relay has got NO IPv6 exit policy (i.e. "reject 1-65535") Could that be the reason? You have, so to say, an IPv4-exit and at the same time an IPv6 middle-only-relay. (Please note, that I am NOT a member of torproject.org, but just a bridge and non-exit relay operator, so I do not have any further insight) Regards, C. Am 08.08.2025 um 05:13, CIP via tor-relays <tor-relays(a)lists.torproject.org> schrieb: Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

3 3

No update of bridge distribution method?
by C. Pe. 09 Aug '25

09 Aug '25

Hello all, next to my posts about the NAT and non-default IP for bridges topic, I would like to draw your attention to my observation, that somehow, bridge distribution seems not updating and hence no distribution and no traffic. Please refer to the below examples, which all are configured properly without any "special" situation: E80088962F97FE190D734D67E0C656C2A6EADEE7 (webtunnel, on distribution method "none" since more than a week, despite method manually set in torrc) 45E1449B8B87ACFE6AF40CD33E91DFC3CB9B7488 (obfs4, this one is active way longer than indicated in "first seen", also shown as distribution "none") Is something wrong with the distribution DB ? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Tor
by CIP 09 Aug '25

09 Aug '25

Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC

3 2