- tor-relays - lists.torproject.org

deprecating >0.4.8.21 tor
by George 19 Nov '25

19 Nov '25

Not to disrupt the other relevant thread, but it's worth noting that 41.1% of relays are already running 0.4.8.21... https://nycbug1.nycbug.org/onion-stats/relays-vers-count.txt ... covering 42% of the network bandwidth https://nycbug1.nycbug.org/onion-stats/relays-bw-by-vers.txt Huge thanks for the responsiveness of the relay operators! g PS, and the OpenBSD port was just updated and the FreeBSD port is still on 0.4.8.20. -- A3F5 9814 DDDC 2FAA E485 C354 7226 51EA 22B6 D315

1 0

Switch from relay to guard
by Too 17 Nov '25

17 Nov '25

Hi, I've been running a tor guard / middle relay from my home for some while. We have rotating IP addresses but since a lot of official websites (like governmental or banking ones) seem to block us with all of our IPs, we probably looped often enough for the information to spread. Also, we don't have that much bandwidth left for tor (in theory 4MiB/s). To avoid the blocking in the future, I want to switch to a bridge. I have a few questions regarding that: - Does it even make sense to switch to a bridge after already exposing the IP(s) for the guard / middle relay for some while? - Does it make sense to run a bridge if my IP rotates every night? - Should I shut the relay off and wait some while before starting the bridge, to get the IP(s) off blocklists first? - What kind of bridge makes the most sense in this situation? In case no bridge makes sense, I'm thinking about utilizing the server capacities for a guard / middle relay that pipes the traffic through a VPN instead; I found conflicting information on whether that's a good idea though. Thanks & kind regards Top (they/them)

2 1

High Memory Usage observed on Windows Relay
by providedlan＠arcor.de 16 Nov '25

16 Nov '25

1 0

Exit relays and DNS privacy
by foreststack＠dmc.chat 04 Nov '25

04 Nov '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I run several exit relays. I'm trying to keep them in diverse locations (South Africa, Moldova, USA, and Canada so far, with none in any AS that hosts more than 1% of network bandwidth). I'm using Unbound as a local recursive DNS resolver so I don't have to trust 3rd parties with the DNS queries. But I can't run Unbound on the same IP that exit traffic goes through because some nameservers blacklist Tor, so I use a second IP. With the price of IPv4s these days, this can inflate the cost of a budget VPS by a significant percentage of its original cost. Right now, Unbound is set up with prefetching and key prefetching enabled, DNSSEC validation enabled, QNAME minimization, a large cache and negative cache, and a local copy of the root zone (RFC 8806). Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT? The way I see it, that has a few pros: * By saving on IPv4 costs, I can run more relays. * An attacker who can monitor the outgoing DNS traffic doesn't know which relay it is coming from, as all relay DNS queries are mixed. * By sharing a single cache, there will be more cache hits and less need to talk to nameservers and expose queries to them. In other words, a nameserver would only know "someone on one of forest's relays looked up this site" rather than "someone on this particular relay looked up this site". But I can see there being a few cons as well: * By sharing a single cache, "timeless timing attacks" may become worse because a single lookup will prime the cache of all of my relays. * Due to their diverse geographical nature, some exits will have sub- optimal routes to the "master" resolver, which increases latency and allows more entities to know when and how many lookups my servers are making (although not what is being looked up, because of DoT). So what should I do? Run a local recursive resolver on each exit? Set up my own upstream resolver and point all my exits to it? Try to use the ISP's resolver and hope that they configure it well? Use some privacy- friendly upstream resolver like dot.sb? Use a DNS resolver hosted by a major exit operator, as suggested by Nothing To Hide in his blog post https://nothingtohide.nl/blog/improving-dns-privacy-on-tor-exit-relays/? I would like advice on the best solution here. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj3/7UACgkQBh18rEKN 1gtA5RAAj7k0/SbG/ki9uQCAG4MjxQAZU8nfjuIaVet7PRCpiLoH8obBSM6m7Gve Qb+AV+uOl3IwjUwu914opEZmSolZXRF2CJ4mX+dfZlbigRHqf0jCiBwOVChCMeDR lGGrFICZvH+t2Sy3totmlcWD57aHXkDux/0eNHj0c5VmfOQKiehSqF0IlK6xI3KC ozNzBaYjjdYdtsQetpeQ0ZEgtv/xU4a+DqiLh5MApCiyt0lP88nTUTuQ8tu1qL3j ijLoac2/ZXG2nlMrKkIB7qNDG1r5CsIb6BdJM/hyfNr1d23VqJfrlILYJFXi3ZAd GurC4tGb/3m2BqWEgzNu/zT/xZ99Ky5zSK+oJDKCeQ8OLaP1IvgviMB0yXLLozB9 NlJweJMn3c1mJ9TxvG1zWbrABee847bizb0ncwkv3ikrownWaSRW5n4v1SXHv/lO yLYjrNI7KJfqvgECgtYni5n4DBzW98pNkFrD3sBxtz0BUtngC6lXjN1ru9l4m5sW EiMS7ifAOnCTN8g8ipocBihYoNvsESmbjzUka63nrnqnvmG3tZB5oIR+WpvXnU3o hxxmlXfjAgmBNf4kuzlAfBRenFf0HkfE9y//YOmCJOgiZzuV6Tv040kkdUKtXbbS F4ZShpS04UvpniCKSBa3mn8Ft33GR01mRvgzRZ2dXv3heqqWlmo= =wsTY -----END PGP SIGNATURE-----

4 5

Being banned?
by Brian Henderson 25 Oct '25

25 Oct '25

Hi, first time using this group so I hope I am not braking any rules. I wanted to ask others if they have noticed themselves getting blocked from certain sites (such as banks) because they are running a tor relay? I have checked my ip on various lists and it seems two rarely used lists have a ban on a group of numbers from my isp, but not my number specifically. I have been using my bank for years from this connection, now i seem to be blocked and it coincides with starting to run a tor and i2p relays. I have tried to access the site from different software but it just hangs. The bank claim they are not blocking me. Anyone else had this type of problem? Brian.

6 5

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > IPv6 is locally resolved by each relay. If this fails, probably > because some DNS servers are IPv4-only, the relays shall forward > their queries to 1-2 central DNS resolver with IPv4 addresses. That would probably be doable, but it would negate the privacy and the security benefit of running a local DNSSEC-validating recursive DNS resolver. When I run my own, I can be sure that it's using a local copy of the root zone, that it's using QNAME minimization and aggressive- NSEC, that it's up-to-date and is aggressively caching negative answers (which are very common over Tor), etc. Perhaps I could have the resolver prefer IPv6 and if the nameserver doesn't support that, it could fall back to the exit's IPv4. If the nameserver blocks Tor, *then* it could be sent up to some privacy- friendly upstream resolver. I don't know if Unbound can be configured to do that natively. It might take a small patch. > The overlap of DNS servers that are IPv4-only and block Tor relays > might be small enough to tolerate the issue or just use a friendly > public resolver for them as fallback. I don't think it would be enough to tolerate the issue. Failures to get answers from big nameservers doesn't just break a few websites. It can break an entire zone. You may find that all .hu domains that lack IPv6 will become unreachable. Using a friendly public resolver as fallback, or even falling back to a high-latency resolver on one of my other nodes, is probably preferable. > In any way, I hope you enable IPv6 on your relays (start with DNS). > Because the IPv4 shortage only gets worse over time, and enabling > IPv6 is a (partial) way out, even already today. I have IPv6 enabled on all my exits that support it. Some of them do not support IPv6, but that is the fault of budget basement datacenters running in Romania, and not my own network config. ;) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj84v8ACgkQBh18rEKN 1gseMRAAi/g6rB/Bj84IepqIB2y+BVW4klxae7IYrSFK4YNezlpNjCp4BWZIZTlS lNL3jD6w7iJmJyxKXFmpwn+bEmv5sdin15j2LHn8486L+F72XyVmogHH5rQ7Bxn8 yITnjr8EBsfEWrLZQRmmPjfqgSXXUo2r8JDN42KdivASzFh4skrQY/N8f79/fKtL qJp5FohU+Z4BFRCkgdR4wNIpQeysp6cxm3cyOVUay/ZnWNB2yQDaoT3JKsV8JlDD nzIwLqYBiNZp/qALoVWEqdy0Ohzq1Sj6WtHZHbvlQNvOH2G2nAYwRFzcHYlrdrjz TRY91oqeFgEv0TeeXbc+rcSbPwz34mQTXy80VxhuMhNmihrwI7h6kDHWQ9FNTu6I joOZIOJWTxRNaAWLEauk2j+xSOxB3wHfuyjLtXfZjyGzHiicVzi126DKf8nqWaJX hmOnlM0pdeZwgYojG9j777pLN+K01QEK8JVvtrKvHXxVx4k0jbQ/9EcdhHG5PnNd skeCiex+8x7vnSH8/nr4l3x291gKr8vFJqIK64Whq2niAkK8xw6YrIYlvVUSD/4/ HESlYMZW7STS6f3VdnzW9fvYFU+voiQ4wCLCn5wwq/VoI1CxDYRX8QdnT+ra2ogF HgEBplSu3MNQpDAhbYRJy2FVYh9BlcdgXmYrd0yoyK14x2mrzvA= =2u/4 -----END PGP SIGNATURE-----

2 1

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 25 Oct '25

25 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > You should definitely try setting up IPv6. Essentially, your problem > is rooted in the limited number of IPv4 addresses. With IPv6, you > most certainly can have more than one IPv6 address on every VPS for > free. Using IPv6 wherever possible tackles the root issue. This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4. What I'm thinking of doing is choosing a single reliable exit in each geographic location that I run, and using it as the upstream DNS resolver for all the other relays in the region. Thus I can use one relay in the USA to serve my relay in Canada, and one relay in Moldova to serve other relays in Europe. I would only need to pay for an extra IPv4 for each geographic region, and wouldn't have to suffer from the nasty >200ms latency incurred through transoceanic cables. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj7ch4ACgkQBh18rEKN 1gu6jBAArMfWI6mXe6Ce+9UUQ8FQPgxDYjiySBij3QqN3NmM2N0TGxU/+wjldLrP wE/1zFjuTTQfZsOXJcLd13kmiqpt4jFRVAe+d0vpdfMkIppbDRmYRlcGrn7k1YwI Sdac1Dd3bUxRU3XLF/tVKeDjAsU55qu7el7qkd7RdhPjQ1IYV6GIzJPANcaREzv1 m6DBkkTAgkqvBVAQTFbOWLkLYL8KGXYTSjp14ZxB0SH8wrDKaZ/Hb0ASHlDYO7J8 lgjgR1fjfj13IlyjyRLlSeZiXmvHgi1W3NBLwp6nR2V1uwQ+VB7IIkjg+TJ3EN3x wMt1xCmqX9wqsfUgjR5wHJMFNu1maAgdMRUTSWDj0g1P4A4Dvvq1zQJUPtRViZsM 7NzgyrEqWd9gXHAxbP/82eM8QYbzflXEwtz5YFLDhFnXx1sQfE911pE3fklYMnEX SnyslYhK76Xg+E59Q6sGgKYnWyJSPIr88/KouTYKdqbywmg3duEM8a0tp/lLte6o nuA/HI83+sGrSnxGF8cZy8GOY6+MepzUEwX8uQlYSE9RNu/owqF3pCRpyJ6E6udz QvlSzQy6a8d8CewUQ6G8cQETAoSadaEsPdZzaEAj/6jgThTcZKnMnUFx3G/6VM2c ykHHoe6dBLlmesiqirXOiT99Hel09yvlI07H82kmT2JmRcqgUak= =M4IK -----END PGP SIGNATURE-----

3 4

Re: Exit relays and DNS privacy
by foreststack＠dmc.chat 22 Oct '25

22 Oct '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Don't forget to enable DNS over TLS! Of course. :) For my local resolvers, it's not possible of course, but it is DNSSEC- validating. If I use any kind of centralized upstream resolver, whether I operate it or not, I'll only use DoT/DoH/DoQ. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj41AcACgkQBh18rEKN 1gtybw/8CPyLiyhSzl5Bdze4kcO6/EvZlrZAh7oJTdkHALYdzItPs9qGN/OGTHzh mUD2TOqQ4sAIPeuq+n5Xs47zGefVjPt2aVpzJ7yKfzsrS6CQA8VtJrtAsuZIdGxg qjAgis87rLCH2t2x+xfArx65txfp6HhWkzLIUWhbwEDM6PLFTNSi5WVm0BCNwXOt 8pNYfzqlil1HhGjghlnA/B47VAvSnGlozUUFF6yVEoCVglKrRgFCdx24auj2p/Hf /87hIfeZ+UeMSKoRcwQ8JoZeFuDDs7WxdbJh3qFc9T+2hdb77CXciYaVO3+bJR3G IfkZPqKKCNdm982TU2wzy+wDghcfrs6VObk5m4GJoWbltOxSmyX3+Ld5ycDMtRQR EBiSdGM7+QCO82b/zNcCWIOD73ZiDkpe3d3poRAJd0/Bv8EvKsXv2hEhPGE+0eRe NnDwYGLJhwo/sWYeHC5Yr/iHFWr8aq87HnvxaF4GNsrpNlcs+Dnx9UFmLa+Jn41A E8OSZMB9WXmnVQvptrVUg1yx9mo1KloQSq+EhbF5nD7VbFEmJSz+MIg7p4xbMl0L pDg2qt2i9Xl9wp8DQVo+KjO1u05jMzmny93xSkaS2tyDndv0O2eaNzjnf4+GLjsA Pnum5/VRD2EOw1YdIlQ58ENhQDLSlbQXdU4/HwDziutmFlWtuK0= =ct/a -----END PGP SIGNATURE-----

1 0

Relay Search page is showing extremely low BW speed
by am 22 Oct '25

22 Oct '25

Hey there, My VPS is dedicated to running a Tor relay server, so the performance should be good. However, your Relay Search page (metrics.torproject.org) now says the speed is only just "XXX KiB/s"! (X is a number) This should not be true. I ran the `speedtest --secure --server XYZ` on the server in question, and it returns: Using server A Download: 98.34 Mbit/s Upload: 120.44 Mbit/s Using server B Download: 88.81 Mbit/s Upload: 104.86 Mbit/s Using server C Download: 94.34 Mbit/s Upload: 103.05 Mbit/s I also checked the firewall configuration, and it did not limit anything. Are you sure your network measurement server is not overloaded? How about teaming up with speedtest servers to measure real network value? So the questions are: Q1. Where are you measuring this from? Q2. If the Advertised BW is just this low, doesn't my Tor relay won't be used at all?

2 1

Re: tor-relays Digest, Vol 177, Issue 6
by Isaac Grover, Aileron I.T. 15 Oct '25

15 Oct '25

Good morning Brian, The bank may not be using these miseducated blocklist services, but their banking platform certainly might be. There's nothing you can do if the blocklist is blocking your IP address or even an IP block from your ISP. Best you can do is request a new IP address from your ISP, either by contacting their support or powering down your modem and hope it grabs a new IP address when it comes back online. On the other hand, if your specific IP address was being targeted, then if your ISP offers IP address blocks, then get a block and separate your relay from your main network using IP routing on your firewall. Make your day great, Isaac -----Original Message----- From: Brian Henderson <bhenderson001(a)yahoo.co.uk> Hi, first time using this group so I hope I am not braking any rules. I wanted to ask others if they have noticed themselves getting blocked from certain sites (such as banks) because they are running a tor relay? I have checked my ip on various lists and it seems two rarely used lists have a ban on a group of numbers from my isp, but not my number specifically. I have been using my bank for years from this connection, now i seem to be blocked and it coincides with starting to run a tor and i2p relays. I have tried to access the site from different software but it just hangs. The bank claim they are not blocking me. Anyone else had this type of problem? Brian.

1 0

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

14 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 14 Oct '25

14 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 12 Oct '25

12 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 05 Oct '25

05 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 04 Oct '25

04 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 24 Sep '25

24 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 16 Sep '25

16 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 09 Sep '25

09 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