- tor-relays - lists.torproject.org

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

28 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 20 Aug '25

20 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 11 Aug '25

11 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 11 Aug '25

11 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

QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 07 Aug '25

07 Aug '25

Dear experts, I have a special question, for which I could not find 100% clear documentation after a research. Situation: - VPS with more than one IPv4 and IPv6 address - IPv4 within the VPS is private class-A only (i.e. 10.x address), so port binding happens to the private Class-A - External IPv4 is linked outside the VPS to the private Class-A - of course, VPS is externally reachable by the external IPv4 - I would like to use a secondary IPv4, i.e. NOT the one, which is shown, when you run the command 'curl -4 icanhazip.com' from within the VPS) - I would like to use a secondary IPv6, i.e. NOT the one, which is shown, when you run the command 'curl -6 icanhazip.com' from within the VPS) Let's assume, for my example only, I have the following secondary IP addresses : - external IPv4 7.8.9.10 - internal IPv4 10.0.0.7 - IPv6 [2345:bad:face::] Let's further assume, my ORPort was 1234 and the obfs4 port was 4321 In order to have TOR distribute the correct bridge line "obfs4 7.8.9.10:4321 <...>", is the following torrc config correct? BridgeRelay 1 ORPort 7.8.9.10:1234 NoListen ORPort 10.0.0.7:1234 NoAdvertise ORPort [2345:bad:face::]:1234 Address 7.8.9.10 Address [2345:bad:face::] OutboundBindAddress 10.0.0.7 OutboundBindAddress [2345:bad:face::] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 10.0.0.7:4321 ExtORPort auto ContactInfo johndoe(a)nowhere.org Nickname MyCoolBridge With this config, I indeed am able to connect to the bridge using the "obfs4 7.8.9.10:4321 <...>" bridge line, but is this line also communicated like that by the bridge distributor, or do I need to adapt the above config to ensure proper distribution? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

5 10

FW: RE: Re: Re: QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 05 Aug '25

05 Aug '25

Seems I only answered to George, instead of all, sorry. ---------------------------------------- Betreff: FW: RE: Re: [tor-relays] Re: QUESTION: OBFS4 on secondary IP and NAT Von: C. Pe. <peca-relay(a)mailfence.com> An: George Hartley <hartley_george(a)proton.me> Datum: 05.08.2025, 14:41:41 I am of course not the expert here. However - NoAdvertise and NoListen are usually combined in two consecutive ORPort statements. This is done to in fact to tell Tor to "listen to ip:port A, but advertise ip:port B", so there definitely is an advertisement of the relay. A relay works fine with that and the "relay piece of a bridge" (so to say) also works well. But yes, there indeed IS some hassle with the bridge distribution (see also my other post, which still waits moderator approval). Question remains: Is that a known "shortcoming" for pluggable transports, or is there a special way needed to configure this properly? So we seem to have two issues with bridge setup, NAT and binding to specific IP: 1. Not possible to properly advertise/distribute obfs4 external IP, if obfs4 port binding to internal IP. 2. In such cases, bridge distribution does not happen. I have, based an observation from another bridge without NAT, even the impression, that specifying a specific IP instead of 0.0.0.0 or [::] in the ServerTransportListenAddr causes a bridge distribution "none". Maybe a bug? C. On August 5, 2025 at 4:46 AM, George Hartley <hartley_george(a)proton.me> wrote: Is this not the purpose of NoAdvertise? You use that flag if you want a private bridge (for example, to give to your friends). Using both NoAdvertise and NoListen on an OBFS4 bridge behind NAT can make BridgeDB treat your bridge as “no distribution.” Because NoAdvertise strips the bridge descriptor from publication, and NoListen prevents the ORPort from binding on your public interface, BridgeDB can’t see or test your bridge. As a result, it marks its distribution status as “None.” The easiest fix is to forward your ORPort through NAT and remove (or at least temporarily disable) those flags so your bridge descriptor is published and reachable. Once BridgeDB can reach and verify your ORPort, it will resume distributing your bridge normally. If you’d like more control, you can also set a specific BridgeDistribution method (for example, moat) in your torrc. Regards George On Tuesday, August 5th, 2025 at 3:46 AM, Gary C. New via tor-relays <tor-relays(a)lists.torproject.org> wrote: I'm seeing a similar issue with a recently configured OBFS4 bridge using NAT, NoAdvertise, NoListen, and distribution status displaying as "None." On Sunday, August 3, 2025 at 12:36:37 PM MDT, C. Pe. via tor-relays <tor-relays(a)lists.torproject.org> wrote: Is there maybe another issue with rdsys being "stuck" ? I have again a new/renewed bridge in distribution status "None" since some days and https://bridges.torproject.org/status?id=<fingerprint> shows for all bridges the last testing two days ago (According to your below statement, updates should appear latest after 4h) Thanks & regards, C. Am 31.07.2025 um 13:12, meskio via tor-relays <tor-relays(a)lists.torproject.org> schrieb: You can always check if the bridgeline distributed by rdsys is correct by visiting: https://bridges.torproject.org/status?id=<your hashed or not fingerprint> This should display one bullet point per IP/transport, so in your case two, one for IPv6 and another for IPv4. Take into account that it might take up to 4h for this page to be updated when you do changes. -- Sent with https://mailfence.com Secure and private email _______________________________________________ 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

2 1

Usefulness of independent Snowflake network?
by Jonah Aragon 27 Jul '25

27 Jul '25

Hi all, I’ve spent some time setting up a standalone Snowflake network this week, mainly for my own practice. Basically what I have is: - A Snowflake broker working with domain fronting on a CDN other than CDN77, and of course Amp Cache. - Two Snowflake bridges, https://metrics.torproject.org/rs.html#search/Triplebit%20transport:snowfla… - A handful of proxies with high-speed/no-NAT connections configured to use this network instead of the default. And everything works perfectly in stable Tor Browser. I was mostly curious about what the performance would look like, and of course it is better since I’m the only one using it :) I was thinking that a potential use could be to have a Snowflake network that has no browser extension proxies or proxies behind NAT, only standalone daemons on high-performance networks from operators willing to contribute. My theory is that there are some people who would benefit from a Snowflake bridge with performance more in line with obfs4 or WebTunnel, which may or may not really be true. What I’m wondering is, do you think this is a concept worth pursuing, or do I just leave it as a weekend experiment? Obviously a big advantage is lost by having fewer proxies compared to the current Snowflake network, which would make it easier to enumerate. I think a big advantage gained as a bridge operator is being able to publish the bridge line publicly and take advantage of domain fronting without actually proxying Tor traffic through a CDN. I can change the IPs of my bridges by swapping out proxies, without bridge users needing to update their bridges in their client, which seems like a win. What I don’t know: - Could this actually provide the same or greater value than just contributing more standalone Snowflake proxies to the public network? - Is this worthwhile compared to simply running WebTunnel bridges? - Is there one other relay association perhaps willing to volunteer to run a bridge on this network, and are there other relay associations or individuals willing and able to contribute only high-performing and standalone proxies to it? Let me know what you think! Best, Jonah

1 0

Re: webtunnel bridges for the telegram distributor
by George Hartley 24 Jul '25

24 Jul '25

Thanks, I agree that obfs4 looks like "random data" so it is relatively easy to block with middle-boxes or deep packet inspection. George On Monday, July 21st, 2025 at 1:19 PM, meskio <meskio(a)torproject.org> wrote: > Quoting George Hartley (2025-07-18 05:32:28) > > > > Russia is extending their Tor block[0]. Currently, they block Fully > > > Encrypted >Protocols like obfs4 on some mobile networks[1]. > > > > Does this also apply to obfs4 bridges with timing and packet-size obfuscation > > enabled on both client and server side (iat-mode=2)? > > > Yes, is not that they are detecting obfs4 as a protocol, but they block anything > that looks like random and they can't recognize. > > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 0

facing out the moat bridge distributor
by meskio 23 Jul '25

23 Jul '25

tl;rd: if you have a bridge configured with "BridgeDistribution moat" remove this config option from torrc so it can be reassigned to another distributor or replace "moat" by "settings". In December we shutted down bridgedb[0] and stopped distributing "moat" bridges. The distributor that the Tor Browser uses automatically "settings"[1]. We hold the existing moat bridges without being distributed as they were still used by people around the world. So censors can't find them and users can still use them without getting blocked. As the usage of those bridges has declined now we decided to redistribute those bridges and automatically assign them either to the "settings" or "telegram"[2]. The only bridges that are not automatically reassigned are the ones with a configuration "BridgeDistribution moat". rdsys will not assign to any distributor bridges that have "BridgeDistribution" assigned to an unexisting distributor. If you run such bridge please remove the BridgeDistribution config line in torrc or change it an existing distributor so your bridge get distributed. If you want to hold your bridge undistributed is better to configure it with "BridgeDistribution none". Thank you. [0] https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/dis… [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

webtunnel bridges for the telegram distributor
by meskio 21 Jul '25

21 Jul '25

Hello, Russia is extending their Tor block[0]. Currently, they block Fully Encrypted Protocols like obfs4 on some mobile networks[1]. For a while, WebTunnel has been a good alternative, but since June, Roskomnadzor has enumerated some WebTunnel bridges and blocked them by domain name[2]. Bridge operators can bypass this block by creating a new subdomain or using a new domain for their WebTunnel bridge. We are working on multiple solutions for this problem. And one of them is to start distributing WebTunnel bridges over Telegram[3]. In the past, our Telegram distribution bot has proved to be fairly resistant to the attempts to enumerate bridges made by the Russian censor. But to be able to do that, we first need to have enough bridges assigned to that distributor. We are looking for a minimum of 30 bridges assigned to this distributor. If you are in the capacity to host a WebTunnel bridge, please do so! You can follow the documentation on the Community portal[4] and configure your WebTunnel bridge with this option in your torrc: BridgeDistribution telegram Or if you're using our Docker container, you will need to add the lines below to your .env file: OBFS4_ENABLE_ADDITIONAL_VARIABLES=1 OBFS4V_BridgeDistribution=telegram It is ok if your WebTunnel bridge is on the same IP address of another existing WebTunnel bridge as long as is in a different subdomain name, for example www1.example.com. As the censor is blocking the bridges by domain name and not by IP. Please avoid hosting your bridge with Hetzner, Digital Ocean, OVH and do not use Cloudflare DNS, as there are reports of these are being targeted and blocked by DPI[5]. Thank you. [0]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [1]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [2]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [3]https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158 [4]https://community.torproject.org/relay/setup/webtunnel/ [5]https://github.com/net4people/bbs/issues/490 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 6

new OBFS4 bridges with bridge distribution method "None" since a couple of days
by C. Pe. 15 Jul '25

15 Jul '25

Dear experts, according to the documentation, a new obfs4 bridge should get a bridge distribution method assigned after running a day. The two bridges listed below are running since more than a week and both still show "none" as bridge distribution method. (Probably due to that, they even don't get up to speed) Attempting to manually set the method in torrc does not change the situation... https://metrics.torproject.org/rs.html#details/76ADDDFD1C70D60BE6F524B111A3… https://metrics.torproject.org/rs.html#details/4FB2FA7B6678169B609B771F240B… Thanks in advance for any advice. C. -- Sent with https://mailfence.com Secure and private email

2 1

Tor relays on Android / Termux / Orbot
by ajxtaylor＠gmail.com 26 Jun '25

26 Jun '25

I'm trying to run a relay on my old Pixel 5 phone. Does anyone have recommendations or experience with this? It looks like Orbot won't be able to support running relays well since upstream support for it was removed: https://github.com/guardianproject/orbot-android/issues/1319#issuecomment-2… I tried Orbot anyway, and noticed my advertised bandwidth seems to come out to around only 2 MiB/s. I don't know what the limiting factor is: * I have power and ethernet plugged into it and it has nearly 1000 Mbps connection (as tested by my router's speed test, and I have a fiber internet connection). * In developer options I can see I'm using 4.8 / 7.8 GB RAM. * Not sure how to check CPU usage. The phone always feels cold though, so I doubt its using much CPU. * I know Android used to be limited to 1024 connectors / file descriptors, but I believe Pixel 3XL and above have that limit changed to 32768. * Max bandwidth / relay bandwidth are set to 40 MBytes (per second) in the custom torrc setting I'm trying out tor in Termux as an alternative. My one issue with Termux so far is it can't detect its own IPv6 address. The logs show it detects some other IPv6 address that doesn't show up as being assigned to my phone according to my router, and Tor logs say the ORPort isn't reachable on that address. I tried manually adding my phone's IPv6 address (according to my router) into the torrc ORPort config, and that worked, but might stop working once the IP rotates. (And side note, Orbot was able to detect the IPv6 address correctly.) I'm guessing Tor can't auto-detect it because of limitations of Termux. Network config isn't available within Termux unless the phone is rooted, as can be seen by attempting to run `ifconfig` and according to this reddit thread: https://www.reddit.com/r/termux/comments/1arucf7/ipv6_trouble/

1 0

New Tool: Tor Relay Leaderboards, Operator Metrics, & Network Health
by Tor at 1AEO 25 Jun '25

25 Jun '25

Hi All, Wanted to share an update on a new Tor metrics site we've launched: https://1aeo.com/metrics (updates every 30 min!) It builds on Allium (originally from git.jordan.im/allium, now end-of-life) and adds several new features—all powered by Tor Onionoo API (and more soon!) and open source for anyone to use, self-host, or build on. New Features - screenshots and some plain text Tor relay email list friendly versions below: - Operator Leaderboard (by AROI): See the top contributors across bandwidth, consensus weight, relay count, uptime, OS diversity, and geographic spread. Celebrating everybody's contributions! - Enhanced Operator Pages (by AROI): Quickly spot issues and compare operator setups across the Tor network. - Network Health Overview: Across all of Tor, show breakdowns of relay counts, bandwidth, uptime, operator diversity, AS and geo distribution, version compliance, and more. Goals: - Provide operators with new visibility into their relays and network-wide trends - Easily answer common questions without referring back to specifications and many page long text files - Push the boundaries of what “vibe” coding can do We’d love your feedback—especially through GitHub issues for tracking requests, bugs, or incorrect data: https://github.com/1aeo/allium/issues What’s Next: - Add support for consensus health parsing and other Onionoo endpoints (e.g. bandwidth stats) - Incorporate charts/graphs - Improve historical data tracking Hope it’s helpful, and open to suggestions from the community! Credits: Beyond Jordan's great open source work on Allium, many of the top operators have been reviewing and sharing feedback, AROI definition from Nusenu, Onionoo data, and many others! Top 5 Operators by Bandwidth (AROI) Rank Operator Relays Bandwidth Consensus Weight Guard/Mid/Exit Count Countries Platforms ----- -------------------------- ------- --------- ----------------- -------------------- --------- --------- 1 nothingtohide.nl 294 60.4 Gbit/s 6.61% 34 / 8 / 252 1 294 non‑Linux 2 quetzalcoatl‑relays.org 574 57.3 Gbit/s 3.80% 0 / 0 / 574 10 1 3 1aeo.com 566 53.3 Gbit/s 3.44% 293 / 273 / 0 2 1 4 prsv.ch 349 52.5 Gbit/s 4.26% 217 / 57 / 75 20 2 5 artikel10.org 128 30.2 Gbit/s 3.47% 0 / 0 / 128 1 1 Network Heavyweight Rankings Rank Operator Relays Net. Wt. Bandwidth G/M/E Countries---- ------------------------- ------ -------- ------------- --------- ---------- 1 nothingtohide.nl 294 6.55% 60.0 Gbit/s 34/8/252 1 2 prsv.ch 353 4.38% 51.3 Gbit/s 214/52/87 19 3 quetzalcoatl-relays.org 574 4.00% 58.1 Gbit/s 0/0/574 10 4 artikel10.org 128 3.47% 30.3 Gbit/s 0/0/128 1 5 1aeo.com 614 3.27% 54.2 Gbit/s 308/306/0 2 6 tor.r0cket.net 144 2.54% 28.2 Gbit/s 0/24/120 1 7 shadowbrokers.eu 32 2.25% 16.4 Gbit/s 3/0/29 3 8 applied-privacy.net 104 2.14% 21.3 Gbit/s 0/0/104 1 9 for-privacy.net 86 1.83% 20.1 Gbit/s 43/0/43 2 10 relayon.org 112 1.27% 17.5 Gbit/s 41/7/64 2 Exit Authorities Rank Operator Exits Exit % Tot. Auth. Exit BW Countries---- ------------------------- ------ ------- ----------- ------------ ---------- 1 nothingtohide.nl 252 14.44% 6.55% 51.1 Gbit/s 1 2 quetzalcoatl-relays.org 574 10.52% 4.00% 58.1 Gbit/s 10 3 artikel10.org 128 9.13% 3.47% 30.3 Gbit/s 1 4 tor.r0cket.net 120 6.69% 2.54% 26.9 Gbit/s 1 5 shadowbrokers.eu 29 5.71% 2.25% 15.7 Gbit/s 3 6 applied-privacy.net 104 5.64% 2.14% 21.3 Gbit/s 1 7 digitalcourage.de 30 2.95% 1.12% 9.2 Gbit/s 1 8 nos-oignons.net 54 2.78% 1.06% 11.3 Gbit/s 1 9 for-privacy.net 43 2.64% 1.83% 10.8 Gbit/s 2 10 prsv.ch 87 2.07% 4.38% 10.4 Gbit/s 19 Diversity Masters Rank Operator Relays Score Bandwidth Countries Platforms Unique AS---- ------------------------- ------ ------ ------------- ---------- ---------- ---------- 1 tor(a)zgato.ru 81 92.5 6.6 Gbit/s 26 1 39 2 prsv.ch 353 61.0 51.3 Gbit/s 19 2 20 3 Safe-mail 33 51.5 4.2 Gbit/s 16 1 18 4 your@e-mail 22 48.5 1.4 Gbit/s 13 1 21 5 nobody(a)tor.org 23 35.5 1.6 Gbit/s 8 1 18 6 a-n-o-n-y-m-e.net 17 35.5 1.9 Gbit/s 11 1 12 7 peca-relay 20 32.0 1.8 Gbit/s 10 2 9 8 freiraum 14 31.5 769.2 Mbit/s 10 1 10 9 FlashTor 11 31.0 289.5 Mbit/s 9 2 10 10 quetzalcoatl-relays.org 574 30.5 58.1 Gbit/s 10 1 9 Frontier Pioneers (Rare Countries) Rank Operator Rare Bandwidth Countries Specialization---- ------------------------- ----- ------------- ---------- ------------------------------- 1 freiraum 6 769.2 Mbit/s 6 AE, IN... 2 olokerunningtor 5 131.3 Mbit/s 5 AO, KE... 3 tor(a)zgato.ru 5 6.6 Gbit/s 4 EU, GE... 4 cembranutboys.com 3 211.5 Mbit/s 3 BZ, CW, TT 5 prsv.ch 8 51.3 Gbit/s 2 AM, TR 6 osservatorionessuno.org 2 1.2 Gbit/s 2 PT, TR 7 janfuger 2 193.4 Mbit/s 2 MK, TR 8 privacyhaven(a)duck.com 2 345.9 Mbit/s 2 IN, TR 9 email(a)airmail.cc 1 476.3 Mbit/s 1 AM 10 Safe-mail 1 4.2 Gbit/s 1 TR Network Veterans Rank Operator Relays Score Bandwidth Countries Platforms Specialization---- ------------------------------ ------ ------ ------------- ---------- ---------- --------------------- 1 tor(a)insc.de 1 6450 1.7 Mbit/s 1 1 6450 days * 1.0 2 tor-trouble 1 6105 198.7 Mbit/s 1 1 6105 days * 1.0 3 dennis 1 5469 66.8 Mbit/s 1 1 5469 days * 1.0 4 A1F1E776E110F29C 2 4884 51.4 Mbit/s 1 1 4884 days * 1.0 5 Jon Gjengset 1 4489 8.9 Mbit/s 1 1 4489 days * 1.0 6 Ranlvor 1 4248 44.2 Mbit/s 1 1 4248 days * 1.0 7 aholiday(a)yahoo.com 1 4096 931.8 Kbit/s 1 1 4096 days * 1.0 8 insomnia@orwell1984 1 4095 4.4 Mbit/s 1 1 4095 days * 1.0 9 tor(a)theyosh.nl 1 4082 79.7 Mbit/s 1 1 4082 days * 1.0 10 Ry4an Brase 1 4037 8.4 Mbit/s 1 1 4037 days * 1.0 On Monday, May 26th, 2025 at 11:44 PM, Tor at 1AEO via tor-relays <tor-relays(a)lists.torproject.org> wrote: > 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 > > Yes > > Yes > > Yes > > Yes > > Yes > > No > > Continuously > > Nickname, Fingerprint, ASN, and more > > Bandwidth stats; Configuration; Uptime; Flags; Exit policy > > Bandwidth stats > > Partial > > 12/20 > > OrNetStats > > Yes > > Yes > > Yes > > Yes > > Yes > > No > > Monthly > > Operator > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > Guard/Exit probability trends > > Partial > > 05/25 > > 0x7c0 Relay Metrics > > Yes > > Yes > > Yes > > Yes > > No > > No > > Hourly > > ASN; Families > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > No > > Yes > > 06/24 > > Onionite > > Yes > > Yes > > No > > Yes > > No > > No > > On-demand > > Relays/Bridges search > > Bandwidth; Configuration; Uptime; Flags; Exit policy > > Bandwidth > > Yes > > 02/23 > > TorStatus > > Yes > > Yes > > No > > Yes > > No > > No > > ~15-minute > > Country; Flags; Contact > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > No > > Yes > > 02/25 > > TorMap > > No > > — > > — > > — > > — > > — > > — > > — > > — > > — > > Yes > > 05/25 > > >

1 0

Request to redact reverse DNS (host name) for my relay
by Tor ITA Relay 24 Jun '25

24 Jun '25

Hello Tor Team, I am running a Tor relay and have noticed that the reverse DNS (host name) of my IP address is publicly shown on metrics.torproject.org. For privacy reasons, I would like to kindly request that the host name be redacted. Relay fingerprint: B8D94C8036FEE5253E32CA3158E916466191C407 Thank you very much for your time and support. Best regards, Gianluca

3 2

Some learning points and conclusions for our AMA
by Nothing to hide 21 Jun '25

21 Jun '25

Hi fellow operators, The first Ask Me Anything by Tor operators was held on 13-06-2025. The result can be viewed here: https://www.reddit.com/r/TOR/comments/1la9zgw/tor_operators_ask_me_anything/. We also made a quick evaluation for learning and improving the format going forward. This (and other AMA stuff) can be viewed here: https://codeberg.org/nothingtohide/TorAma/src/branch/main/250613-AMA-1/eval…. If you have any questions or suggestions, feel free to reach out. Have a great day, Nothing to hide

1 0

Attempting to create a relay with Orbot
by blueapple128 20 Jun '25

20 Jun '25

Hi, I am trying to use Orbot's "Enable your device to be a non-exit relay" option, but (after waiting enough hours) the relay's nickname fails to show up in Tor Metrics' Relay Search. How can I begin to debug this?

2 2

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

13 Jun '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 1

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

04 Jun '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]

2 1

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