Relay forest18 is still not on the consensus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. One of my new relays is simply not showing up on the consensus. It's been a few days already. I ended up wiping /var/lib/tor and restarting in order to get a new fingerprint, but it has been a while and it is still not showing up on the consensus. I have 21 relays, and this one, the 18th, is the only one having this problem. Even the 21st has shown up on the consensus already. The new fingerprint is 6435C5172690160DA25681BEBA1EA5EAC6F2BE70. Is it possible that it has been incorrectly blacklisted due to being mistaken for one of the relays involved in the recent sybil attack? The IP address is 160.250.225.3. What confuses me is that, even after changing fingerprints, it still is not showing up. It is connected to the network and is reachable from the outside. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk1NxEACgkQBh18rEKN 1gtojw/9Hoix29gE4oevhlRJvGLftgbJHv5caZ7iGNZ7KdN7R/8HQ//0InfyG5d4 8Mb49D2jzNfLK+89svlMyNso5ZqR3sMcy7dpnTNAq+PlxB84AwQE/9Qb/8R3sTDZ A2S8ezzCtViQTEQh9eYx+zmnjJckwVt4sAbjumc6t3kIdN+f7CjOj2SZ+AbT6e4l hBZdaGwKLUQhPzL35SK20RSTjIvVNDHAwMo5rR6BsHCj/+W+3fmAG29pieqCAGp/ lwXR6E4EMII0f53Pb65ZB38FOTuMkBBFL0I3WUB90IqS4z+L3U9oU2u7KY1np1lp ApCSbQjoY+NSgpdJ0yH5b1ZZEvEnr1OhQqY0RMpVTLXOuByj79NG31mjE1v8aUaN a5Lwk6scYXuPr8ryOkxkX80tN5V21pIQWt9hubpXBHtPLvfGmTS51DwwOOEKYoIA yyFnVST75f38uyvm73H48s9c68263I5fKQvFCzUmq8Go0lpbLutjxC8LNML3J0cq 0rIINHWKDw4UjnboKihkuoRdXi+tH2ERW3ZAoKVUXTi1VHomwfDvBHJSYxb3SipI 54Qjrnd6IFr8LaHcTfFacrD/OH4WAYnGCE3lC4Ly3xX0P8Cb9KDkop8nXPuBJAup Jq7GgDP8vsmWW6hp4q/Sh+ajHkeZm/luNWA3DZqsp4q0grHi/IM= =Zdqz -----END PGP SIGNATURE-----
forest-relay-contact--- via tor-relays:
Hello.
One of my new relays is simply not showing up on the consensus. It's been a few days already. I ended up wiping /var/lib/tor and restarting in order to get a new fingerprint, but it has been a while and it is still not showing up on the consensus. I have 21 relays, and this one, the 18th, is the only one having this problem. Even the 21st has shown up on the consensus already.
The new fingerprint is 6435C5172690160DA25681BEBA1EA5EAC6F2BE70. Is it possible that it has been incorrectly blacklisted due to being mistaken for one of the relays involved in the recent sybil attack?
The IP address is 160.250.225.3. What confuses me is that, even after changing fingerprints, it still is not showing up. It is connected to the network and is reachable from the outside.
But it seems a majority of directory authorities can't talk to it. If you look at https://consensus-health.torproject.org/ and enter your fingerprint at the bottom then you can see what each authority thinks of your relay. Only 3/9 deem it to be running at this point. Neither your fingerprint nor IP address are on any of our block lists. Hope this helps, Georg
Regards, forest _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On 07.12.2025 08:13 forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
The IP address is 160.250.225.3. What confuses me is that, even after changing fingerprints, it still is not showing up. It is connected to the network and is reachable from the outside.
On which ports is it listening? I cannot find it in the relay search to look up. Can you seen incoming traffic and are the TCP handshakes successful? -- kind regards Marco Send spam to abfall1765091599@stinkedores.dorfdsl.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Georg Koppen wrote:
But it seems a majority of directory authorities can't talk to it. If you look at https://consensus-health.torproject.org/ and enter your fingerprint at the bottom then you can see what each authority thinks of your relay. Only 3/9 deem it to be running at this point.
Well that's odd. The relay is in India. Is there a possibility that it is being blocked by them? Is that a known issue in India? I seem to be unable to reach to moria1, gabelmoo, dannenberg, maatuska, longclaw, or bastet, either with ICMP or HTTP. According to traceroute, it manages four hops out of thirty: 1. _gateway (160.250.225.1) 2. 85.209.161.0 (85.209.161.0) 3. 180.150.241.241 (180.150.241.241) 4. 14.143.30.73.static-delhi.vsnl.net.in (14.143.30.73) After that, the trail is lost. This is the same for all of the affected authorities. I haven't noticed any other connectivity issues. I will try contacting my hosting provider and requesting that they get these IPs unblocked and, if they are unable to (they may very well not be in charge of the blocks), move me to a new location. Marco Moock wrote:
On which ports is it listening?
Only 160.250.225.3:9001. All others are blocked with nftables. Only the ICMP messages echo-request, destination-unreachable, time-exceeded, and parameter-problem are accepted. This configuration is used on all of my relays, and the rest have no reachability issues.
Can you seen incoming traffic and are the TCP handshakes successful?
I can see incoming traffic from other relays, at least enough for it to be used as a client. It's also successfully being used as an onion service as an alternative to simply running SSH on a non-default port. Of course, this is expected if the only blocked IPs are a few of the authorities while some other authorities are reachable. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk2nHgACgkQBh18rEKN 1gugjA/+PiJh8+zAA3lweNGYvupLzSaPobm4RrXD0/ZXNGvt542PZ5wCSKOEx910 b7knqAqLQn+wnI6lc/6TidPnoIuUXet52w9cQDRNo7lbaV9rX2mA6mS722dRvPNt 5QnrExyDaEKd/SPLxd7QcBwQf+PxYSD/XLadoBWgBVAW1C247hVzzYDdSoEvhM8Z dzIbFduuc8qHfXJpNnWZruzdg2+x+C+2DVrEbqdzZG4Wo+RSrBpr5ap+vdfr1exs b1b5mirkGgUolqB7KVV67YXEAYe0LXp033HQXI8l3x3OFynO+hBFsbuYA2gaMIse 05YKDs+c+aB23SMF8zSEKMTwigf/zkkz71f5WPOfNf/vW3byOJvLAGZptzcN7TPP yQSqINq/Ll6UHej+pFNbEIvQjiimrsEjUZ9LRlmyWg6YI0yWVjnf5LMRoVipYY/c GfpMW/DWlQsC9d9lDWSsWe6c5uWyNEkoMhFzcpAFMoV+mvNjmeBi2MYrLGiQ13n5 UbZyWcnkoOdDwe3A+BX1ejaumlOzQ63xlqvMZLZu3TOum4WnLLP+/MG7LQWBzg6z pD7VJ0Qmd1GGgyqw+xvRzT3y3qD2O2on15Fu/4Ipr41tgpDD/OyLKFTnhHlFsISa 2ZeSrAlPx7TPl/edzzSEmP8haxPrBjZXYkAmiEo/qmzfYj2rKl8= =YxL4 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Sure enough, their looking glass (https://lookingglass.rackoona.com/) diagnostics fails to access most of the authorities from their Delhi location, and the traceroute from the looking glass interface shows the last hop is, as in my own test, 14.143.30.73.static-delhi.vsnl.net.in. Their other working location in Illinois, USA. This one does not seem to have any issues, but I will be very annoyed if it turns out I will have to have the VPS migrated out of India and into yet another over- represented location. Hopefully they'll give me a refund, but unlikely. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk2nlwACgkQBh18rEKN 1gsANg/+KUFpZVx4oKLKFYSmR4vQfgunE1cQIps/aGWR9LKbNfFjdqaNYFR0+UPL ta9sDoQN5WE3uqKiplM7nTuyHBTKb4ur/lrNn+F6BHtTa0INk5XG6Al3qP489idD z0jzcL9EV70IBEY3xxABlTCyFBF7J9duNV//iSAPocBE473N16VrC41sfbk2OQEY VWVfiwF1SX1SFqPBPBitnhuv5qm/m35ZkolkPaAoLcKx0Dj3ZT3agW37uNsmxArK OhisqqR2JUtlHwz3tMoe9nnDHdtQJLI9Og7TspWgWnnVEB2HHF6AGc7/sYzgt0GR ifa4+XPZSKg4mSmpjUFKo28ZvTfEvdpgCS571maieuDnSHd2wm5hTPKcFQKAZqxL jCu68395BCYgkvHhIaO20iGkAqAw3GkU+MDUovjbPjbgxKHVARqgdczT6cCDS7Pu DyCKIcjb89alO3YwrvUez/trE/5fJHnFJO8tjnlmVjMamLC/6NLmOFGxeg/LahN0 sXcoTck4fonSChXRdr9hbeCXdO5Rek+1Vikv6+yCh/BGH7byjqgpy9RpVB193jyv TpjjspBH3o1xdg8YmQjnnaISHCNMe782nzmFFoF7vGxRxPsHMecu4ep15ixyoIah WNqz5lzn1wbgSkJpGrMVXffngDV10DEZYSX727qJdq1K9tSaDPg= =k5eS -----END PGP SIGNATURE-----
Hello,
Well that's odd. The relay is in India. Is there a possibility that it
is being blocked by them? Is that a known issue in India? I seem to be
unable to reach to moria1, gabelmoo, dannenberg, maatuska, longclaw, or
bastet, either with ICMP or HTTP.
Yes, there is an issue with connection between tor directories to India. I've tried to setup a relay through OVH Mumbai in the past and it was the same issues. ----------------------------------------
Am 11.12.2025 um 05:22:28 Uhr schrieb John Crow via tor-relays:
Yes, there is an issue with connection between tor directories to India. I've tried to setup a relay through OVH Mumbai in the past and it was the same issues.
Did you investigate where that issue is? Routing, censorship/firewall etc.? -- Gruß Marco Send unsolicited bulk mail to 1765426948muell@cartoonies.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Is there any workaround, such as routing connections to the authorities through a different server, or a way to get the authorities to attempt to contact my relay via the Tor network rather than directly (only the authorities seem to be blocked; the rest of the Tor network is fine)? If not, is there any other way to contribute to the Tor network using this server? For example, does Snowflake require direct reachability from the directory authorities? If the host provider is unable or unwilling to unblock the IPs (or is unable or unwilling to migrate my server to another DC), and there are no other ways I can use this server to help the Tor network, I could settle for a Hyphanet (Freenet) node or I2P router, but I would really rather use it to support Tor. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk7T6gACgkQBh18rEKN 1gv/ABAAj03ForqRUYeZml2kxml/8ydxpKVju+hvbIbhuCwBo+aJwg36q+XVOmP1 OkPw2pJZLvzzU860QczM4SstCXEZx4e4bbQYpPc6ZC6yDEfkNc+AD0O6jiwBsndO QdYNmnZnFgud/cUgrtTfn7bryqnVFqFoakMbl+MOYCQipVCsnF0dwesTmFVRXojs XNsxSSFVH3wxwt37tc6hdl9lR9HhzLeftHZI9neg7FtkQ4EhmjNrG/Kf9kxQCw9q DnCGssSJ72ACMbxWkSxpLOuEXhPEfuLgJl1Yp/8GEe63a1udrIE6xvliIzr0fB7H My0IBphgoEuX9qE1DnYKQcLeESLg6nGqyixhLqjpgVljLszNhW1mHkmn1tuzPHcg Mx5rTW5NDsRkR6lzGACxTvZb+1+Z7sAVp073tPCrXn50Lxr58huH4MYcGTF5pvi1 IzVX2kzwwz2G6w3z4F00na++igWBrCbN87Htf5UGyAKz2c/MjC1B0f7AaItej9f9 xh7nztuJuU0kSfGQ44eDUY6klG6c4PPQx0fp3ruyiezVI6+cDBGirIZ6gQLNdLsX Xt+OAcTb2tARHd7C/KfmIZRB7vJAcCb2vAaGGkNmjfhcw2F7RF3QzBSGwudRHy6l ZoAHTiZRzdm+lUy138oxdMzuBjjbR9CX6MHwszjRptQRbf2JbJg= =XlcS -----END PGP SIGNATURE-----
Am 11.12.2025 um 23:12:17 Uhr schrieb forest-relay-contact--- via tor-relays:
Is there any workaround, such as routing connections to the authorities through a different server, or a way to get the authorities to attempt to contact my relay via the Tor network rather than directly (only the authorities seem to be blocked; the rest of the Tor network is fine)?
Your relay is only helpful for others if it is reachable the "normal" way. So please investigate what is going on, e.g. using traceroute on the TCP port of the authority.
If the host provider is unable or unwilling to unblock the IPs (or is unable or unwilling to migrate my server to another DC), and there are no other ways I can use this server to help the Tor network, I could settle for a Hyphanet (Freenet) node or I2P router, but I would really rather use it to support Tor.
First investigate the issue. -- Gruß Marco Send unsolicited bulk mail to 1765491137muell@cartoonies.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Marco Moock wrote:
So please investigate what is going on, e.g. using traceroute on the TCP port of the authority.
First investigate the issue.
I have already determined the cause of the issue, as I described in an earlier message. The connection to several authorities is being dropped right after it reaches 14.143.30.73.static-delhi.vsnl.net.in, according to a traceroute (ICMP, TCP, and UDP) of all the affected authorities. It is unlikely to be an innocent routing issue, as only the authorities are blocked. For example, moria1 on 128.31.0.39 cannot be routed, but 128.31.0.38, which is on the same /24 on AS3, has no issues. I am currently waiting for the hosting provider to reply back to me. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmk7yYkACgkQBh18rEKN 1gu2EhAAnzZmBFeqjYcoH/1RmeH3AQ7V/7Rki3Ge78T0UnRK33i1HoXr5N8shwmI MVvrXFiC8Q2Djs6SIEiW0TDDukfmvv/kcwrjGtgpUnCp4/teVUU8wvCv3NbE6eIG D4OpqrGaXaR7nqzqP5pHMxNJ//+b+HQk97MIMdo4Tqh4p2kFHL8whwLVNllzWP7y 5E+ryrUeGnARguwrBNtKIu+M3lP8tJd14ihWt70r0oBlkMuWt4zSlsvq5PlSfFBH Uw6ZForsJuO7IhLfApr7xKpIBOlglPNb8WBQ+E5SUZehpBEPoJatX5d1XUJe4aGS 96t8sfaanBuSduHYVsQXzWyASatYfOEWms5NANOc54QphkVztHH+FDbpVeQzxO9l l9cfGhzPWOrA7U4bmj+BaqfH+NchH/yre81+goPMN5c4PbQgeSZAzNrE5SCgGYQE 2nwaABM8n5tQF4mcl+Z97S1STHZOIaCx8cOkyrZ4in3dUDuYI9XQw7enIoo0dBMa c3PYfUfkoO3agEK37TFhu+prMiHfh3r6eYW7SykBERdg1hMgLAg6XXaQwVfftDQA fxQcHs31rjBu1d49fGR1jnq6Oc2GgHEQ8GeMbHfKXjUNaJAb37HVioCV6SttXxiM 0s3oDzifwcig854MyZke9DL5mWw+GsnFwqjGptCxOoIg1rL2cRk= =HS5h -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It seems they are no longer blocking all of the directory authorities and forest18 has finally appeared on the consensus. This is despite them being less than helpful in a support ticket, as they demanded that I do a KYC check to run a Tor relay in their India location (I'm not sure if they really understood that it was a non-exit). Right now, only Serge (66.111.2.131) is blocked. Sadly, this provider does not support IPv6, so I cannot try to connect to Serge over that. But either way, enough authorities can now see the relay that it has been added to the consensus and traffic is slowly ramping up. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlFtl8ACgkQBh18rEKN 1gsINg/+NOCGetyZk340nTDPvTLjdJksqm7fqEXKmNUzwYeC2h7i4mTtm9bX3OiO pvaD7C6l9B3ai2vI9w32jRWR6M8l2DI2JclviyUVKIxnhexdYim/2jVJQZMfNyuW /EcB0ty082J8bwUG0nhHLBms+Hvd/M8sn+J5o5N6KMc9+jyA1i0ocmc1fprx9vqT SG0t4ULHwzmWIQOJQ0HE/inR4ur68WgsGFh3e/9twVIhLn10JWbQub4kaPLGs+lI IFuhNKOw6ZOEXPq+ehxxEpR2s01qsPB0avzOBghHYI5TiexnHNn2c4j2qQZAF/Ig ufzJq0tzSTvyq2awfpjitOyN7zFvFoCUGxXRQ60hAxQJD8BOvvGWmGdCH71Gf6HO fcmMK6DS7P0u0xuEt95tJDYAGBVxw/RVcz/g6jFa76RZ9PIV1oCEyyjDH8a97LA0 tT1akEXqhRC4P5G5JAccliSBSdijoZl6eaSw8h5e8WxpMJh7EFWJKfVdi4WfCj93 NEjlOCSb8/bxrnJJke+ibnWtHAIuwYSw7YlTuCg3ES1EEDouBiBTaF6kxI4Qk+xL xuYUSyjxifoz+MjEzxikaMDyC7lnf/LnKkPhx2h1ZDP0TpHpukUnPkvp7cLwgLiQ Us2EIJYmAhN91uKPUBYQfssJ/3hm5uAoUIKDELvdk6SaPXTgZII= =tqJ/ -----END PGP SIGNATURE-----
On 12/19/25 15:32, forest-relay-contact--- via tor-relays wrote:
It seems they are no longer blocking all of the directory authorities and forest18 has finally appeared on the consensus. This is despite them being less than helpful in a support ticket, as they demanded that I do a KYC check to run a Tor relay in their India location (I'm not sure if they really understood that it was a non-exit).
Right now, only Serge (66.111.2.131) is blocked. Sadly, this provider does not support IPv6, so I cannot try to connect to Serge over that. But either way, enough authorities can now see the relay that it has been added to the consensus and traffic is slowly ramping up.
No worries about accessing Serge at this point, since forest18 isn't a bridge. Serge, however, can nc(1) to your ORPort on forest18. g -- A3F5 9814 DDDC 2FAA E485 C354 7226 51EA 22B6 D315
Hello,
This is despite them being less than helpful in a support ticket, as they demanded that
I do a KYC check to run a Tor relay in their India location (I'm not
sure if they really understood that it was a non-exit).
Regarding this, I believe there is an Indian Law that requires all hosting providers and domain registrars that are operating in India to perform KYC checks by collecting your passport or ID.
why on earth are you running a relay in a hostile country? never kyc, especially while running tor relay. there are plenty providers (https://kycnot.me) that won't ask for your ID On Tuesday, December 23rd, 2025 at 2:08 AM, John Crow via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello,
This is despite them being less than helpful in a support ticket, as they demanded that I do a KYC check to run a Tor relay in their India location (I'm not sure if they really understood that it was a non-exit).
Regarding this, I believe there is an Indian Law that requires all hosting providers and domain registrars that are operating in India to perform KYC checks by collecting your passport or ID.
Is India hostile to TOR?
yes along with russia/iran and china which everyone knows Sent with Proton Mail secure email. On Wednesday, December 24th, 2025 at 4:38 AM, Marco Moock via tor-relays <tor-relays@lists.torproject.org> wrote:
Am 23.12.2025 um 11:12:59 Uhr schrieb tztao via tor-relays:
why on earth are you running a relay in a hostile country?
Is India hostile to TOR?
-- Gruß Marco
Send unsolicited bulk mail to 1766484779muell@cartoonies.org _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello.
why on earth are you running a relay in a hostile country?
Network diversity. I also run relays in Russia, Vietnam, Turkiye, and Nigeria. None of them are well-known for being particularly friendly to anonymity, but it's better than yet another NL or DE relay.
never kyc, especially while running tor relay. there are plenty providers (https://kycnot.me) that won't ask for your ID
Those providers are all over-used and are mostly just Hetzner and OVH resellers. I have relays with more than 20 different hosts, almost none of which are on kycnot and all of which took cryptocurrency without KYC. It's much better to do research and find providers that are not popular than to use some curated list. I've even taught a few about Tor! :) If anyone is interested, I use iHostART, Maxko Hosting, Advin Servers, Trabia, Servers Guru, DeluxHost, VeloxMedia, Pfcloud, ServerHost, Aluy, DartNode, SiteHub, Infofractal, OrangeVPS, Rackoona, JustHost, IncogNET, C1V Hosting, RackNerd, DataOnline, NoAckHosting, ReadyDedis, and VPS.tc. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlLwxkACgkQBh18rEKN 1gs2DA//c+0ChyoFoj57X/syzvpnSt469r/gLTJ2mmpUbGS+SOJOsQsiAWOeV1a/ yDjkFLAwVl3t2eaOZtTvokgGreV0kackC/jwji5qPlLMm8iW/S59UkMdiba64cSP 9fUg++Vct+eCDyCMArNUo83SxTqOOcCENfZaCN1Qhm1OvaPkkp/CWCIYzbDkF/TW 3soMkKtslNHRI24NkBk4YLuqUavsAsuUuIoZnr1ETDS+6UmYVLp+V7hpOcmDuQ8s zct3jgHLk9pQ8tKSifoT5HRUH01Ckp5fts+Sf1zm1i08ArbXL7HI8FqICLvZ6keo cnCrQugvFn20eV/R6Zs4EjAuKYnyBUC+HIreUG820GSch5+wxynFoxiN6Vbq5iRH GX0VRHMBYroUAtEFFYKz0taFsmJTerYkdDkfP7K1u4ffBgu7u7wROGUusdOK3DM8 I1HB0flpP28epGzh+rUWMNlmOzNjhIAtlBWo+ZpT9UKxYDZc4ZdZxcwE0RRWThUr 5ga+f+4iWqiKRES3pmKDwONAt4pkhaaDZ6ZXDodIq3vemxEskhpG9gBLxrIWnzsW OHcuFX6yfBv5lnNnYP8wyOS2qGZ3OAAVAP3QNkXHEfYvZ+PdT0peOPPsYTprh7vS AtMDzeyrNZSqEozRRp5SaGUQMzlQj0kzAojhfEPMlF3aJwDURIg= =brq7 -----END PGP SIGNATURE-----
i see ur a fellow lowendtalk user! i used some of em, good providers On Wednesday, December 24th, 2025 at 4:43 AM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
why on earth are you running a relay in a hostile country?
Network diversity. I also run relays in Russia, Vietnam, Turkiye, and Nigeria. None of them are well-known for being particularly friendly to anonymity, but it's better than yet another NL or DE relay.
never kyc, especially while running tor relay. there are plenty providers (https://kycnot.me) that won't ask for your ID
Those providers are all over-used and are mostly just Hetzner and OVH resellers. I have relays with more than 20 different hosts, almost none of which are on kycnot and all of which took cryptocurrency without KYC. It's much better to do research and find providers that are not popular than to use some curated list. I've even taught a few about Tor! :)
If anyone is interested, I use iHostART, Maxko Hosting, Advin Servers, Trabia, Servers Guru, DeluxHost, VeloxMedia, Pfcloud, ServerHost, Aluy, DartNode, SiteHub, Infofractal, OrangeVPS, Rackoona, JustHost, IncogNET, C1V Hosting, RackNerd, DataOnline, NoAckHosting, ReadyDedis, and VPS.tc.
Regards, forest
I have relays with more than 20 different hosts
wow thats expensive man, ur the superhero of tor network On Wednesday, December 24th, 2025 at 4:43 AM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
why on earth are you running a relay in a hostile country?
Network diversity. I also run relays in Russia, Vietnam, Turkiye, and Nigeria. None of them are well-known for being particularly friendly to anonymity, but it's better than yet another NL or DE relay.
never kyc, especially while running tor relay. there are plenty providers (https://kycnot.me) that won't ask for your ID
Those providers are all over-used and are mostly just Hetzner and OVH resellers. I have relays with more than 20 different hosts, almost none of which are on kycnot and all of which took cryptocurrency without KYC. It's much better to do research and find providers that are not popular than to use some curated list. I've even taught a few about Tor! :)
If anyone is interested, I use iHostART, Maxko Hosting, Advin Servers, Trabia, Servers Guru, DeluxHost, VeloxMedia, Pfcloud, ServerHost, Aluy, DartNode, SiteHub, Infofractal, OrangeVPS, Rackoona, JustHost, IncogNET, C1V Hosting, RackNerd, DataOnline, NoAckHosting, ReadyDedis, and VPS.tc.
Regards, forest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello.
Regarding this, I believe there is an Indian Law that requires all hosting providers and domain registrars that are operating in India to perform KYC checks by collecting your passport or ID.
They only said that they needed KYC for running a Tor relay. They were happy to let me rent a VPS from them anonymously. They haven't replied to the ticket so I requested that it be closed. It seems like they just forgot. Considering the IPs are no longer blocked, I see no reason to keep poking them. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlKeS8ACgkQBh18rEKN 1guvnxAAwnW5Tyje0j6vqMgY814wQi5w7fLmUXMjph4SzU0tfkRLRWbOHAFamklo Pxhy7BFNw9JiW0Bbki7HDzzUL/5YweIO7kmcoPku7zBNXlPsdj5CdYKWpc0exFa5 lNaxF1v03oa+FZlJMsUY7wv8hIDSxGmb6Dt34rnGtEm60GzzRhXUXwLXmMLIcYrb +7KizUWWz5AIKKls/exUWW7JjS2kIuXUg0x+N17+R73mfnX6nQ4FhCo+S06ViqD4 U/uXV8e5KgMJ1jZyXlFsoFiJcYkbkFEd7jSZHpTzmzeh0i8RnP1aZ5l/1k0vbFDT EBkv0BadmuwIo6Fy2XeHkqkyyVDL4h1q9ouM6T4leepmsW08+wt7UUMMQSuCBSpc 6aaUTTtRYFL1xlOq8M449/NhNxLVGPANJueb90QfVVP0OsqlBcN+Q371StkTeX0d oah5rMXAT5r9hdRo8qgJrs5GM4x0602hRLYStjwA55hynnjx+6YAfzocZpkptDzg lLpvW5qeFR5HSUF9fXzXPSxROM7SYtd+/PSq43Anjae4f7gtuZOjOQxoIY+5Hm/1 9uXutcMqw37NQ4WRvQB3oGPZiI1GwujnCK8mcl5AcVtAiPb8kFWGVD+lP/oTTX8i Gu8ABliZKelXi1RBwMWyiYWfNtSb+dLNCWhzbxnUlVvFhqXT21A= =f62b -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Tor at 1AEO wrote:
Short answer: yes — adding more relays is a reasonable experiment if the host has spare CPU, RAM, and bandwidth.
Unfortunately, while there is plenty of remaining bandwidth and the CPU is nowhere near saturated, memory is a limiting factor. Most of these low-performance relays have only 1 GiB RAM. When combined with zswap and a lighter kernel, my fastest 1 GiB relays can achieve about 150 Mbps. But the overhead of running multiple relays caused by all the extra non- swappable kernel memory needed for conntrack tables, socket structures, etc., causes the memory pressure to rapidly bring down the system. Hopefully there will be improvements to bandwidth measurement techniques in the future for relays which _do_ have good connectivity to Europe. Until then, I've just been adding I2P routers, which use up ~25x more bandwidth than Tor on the slower relays (3 Mbps vs 120 Kbps) and uses much less resident memory.
The cost imbalance you’re seeing is expected today: operating relays outside the EU materially improves network diversity, but it can be significantly more expensive per unit of traffic than running relays in EU-dense locations.
How does the improved diversity help if effectively no one is passing traffic through my relays? Is there any way I can estimate the maximum consensus weight that I will be able to achieve with a particular AS in a particular location if no one else is already using it? Many of the poorly performing relays I have actually have decent connectivity to the EU, without any single AS or IXP being a bottleneck for all traffic. Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaVuBVAAKCRAw+TRLM+X4 xkTXAQDouWFuLxL7Z6y5GWoD/6oddXLkQrNdipOJwRDOVSJHXgEA7JJMGURaQx0J SphncztsH58R/3VsGZVgbOSF9+fDaQE= =aM5b -----END PGP SIGNATURE-----
Thanks — what you’re seeing matches what we observe. For operators, there isn’t a simple fix. The most reliable approaches all depend on a fast path back to the EU, where, statistically, most Tor relay traffic (guard, middle, and/or exit) still concentrates. We see this clearly in our deployments: EU: 2 × 10 G servers, ~60 guard relays each, ~80 threads, ~512 GB RAM, consistently saturate the full 10 G link. US East (fastest North America path we could get to EU): 2 × 10 G servers, ~100–200 guards each, ~192–320 threads, ~768–1500 GB RAM, typically only reach ~2–4 G. US West and South: significantly worse. In the US, we’re paying for 60–80% unused bandwidth purely to help diversify the network. Running relays outside the EU does help long-term, but early operators bear the cost until there’s enough density to rebalance traffic. One clarification: the bandwidth authorities measure throughput, not latency directly, through their bandwidth scanners. There are six today (2 US, 1 CA, 3 EU), and they feed their measurements into directory authority votes and consensus weight calculations, as documented by the Tor Project: https://blog.torproject.org/how-bandwidth-scanners-monitor-tor-network/ For reference, the current bandwidth authorities and their locations are listed here: https://metrics.1aeo.com/misc/authorities.html For forest18 specifically, you can easily see the latest bandwidth measurements per authority on the authority vote page here: https://metrics.1aeo.com/relay/6435C5172690160DA25681BEBA1EA5EAC6F2BE70/#aut... The last column (“Cons Wt”) reflects the throughput observed by the authorities; recent values in the ~1.6–7.9 kb/s range are extremely low, which explains why the relay struggles to gain weight. Also worth noting: despite the challenges you've shared, your relays currently rank #2 on our Frontier Builders leaderboard, which tracks operators pushing capacity into underrepresented regions: https://metrics.1aeo.com/#frontier_builders That contribution really does matter! — Tor at 1AEO On Monday, December 29th, 2025 at 12:57 AM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Tor at 1AEO wrote:
Currently, looks like two main issues and a minor third issue for forest18
Right now the biggest issue is that, although they unblocked the IPs not too long ago, they've been re-blocked and they are now "looking into the issue". Hopefully they will unblock them again.
2) Fast flag: The speed is also very slow, shown by very low bandwidth scanner results from the 6 bandwidth directory authorities (Consensus Weight from Authorities, i.e. "Cons Wt" in source below).
I'm having that problem with many of my relays. The relay's CPU and port are absolutely capable of handling a sustained 100 Mbps. From what I understand, the problem is that the bandwidth authorities are mostly concentrated in the Americas and western Europe, so they mistake high latency for poor bandwidth capacity. I don't know how to fix that. I assume running multiple relays on the same VPS would help, although that seems to me like a crappy hack to patch up a real problem.
Meanwhile, of the 33 VPSes I have, each of the 3 in the Netherlands that I bought on a Black Friday sale simply because they were cheap pass more traffic than all my non-US, non-EU servers combined, despite scoring a bit low on speedtests. It would be nice if authorities simply increased the consensus weight of distant servers proportional to their distance.
It's a bit discouraging to run a relay in South Africa for months and have it pass 0.4 MiB/s when a server in Europe for a fraction of the price and a slower network port and CPU passes 12 MiB/s after just a few weeks.
3) Uptime: Relay reports and operator directly controls, also shows low, ~2 days.
I brought all my servers down for a few hours recently. That could be the reason for that.
Hi forest, 1 GiB RAM is a practical lower bound for sustained Tor relay throughput. Even with available CPU and bandwidth, memory pressure alone can cap throughput and make multiple relays per host counterproductive. ~150 Mbps on well-tuned 1 GiB EU guards matches our experience; in US East we typically see ~10–20 Mbps for guards. At very low consensus weights, a relay’s direct traffic contribution is minimal, which reduces the marginal value of added path and failure-domain diversity (AS, geography, operator). With the current measurement system, there is no reliable way to predict a maximum achievable consensus weight for a given AS or location in advance, especially where no relays already exist. Consensus weight depends on what bandwidth authorities observe over time, driven by traffic distribution, authority-to-relay path quality, and nearby competing capacity. Even locations with good EU connectivity can underperform if they are not on paths the authorities and relays exercise heavily. In practice, the ceiling is only discoverable empirically over weeks of stable uptime. On the tor-dev side, two useful longer-term questions are whether there are plans to improve measurement fairness for underrepresented regions without encouraging gaming, and whether Arti is expected to materially improve relay memory efficiency, especially for low-memory environments. Best, Tor at 1AEO On Monday, January 5th, 2026 at 1:15 AM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Tor at 1AEO wrote:
Short answer: yes — adding more relays is a reasonable experiment if the host has spare CPU, RAM, and bandwidth.
Unfortunately, while there is plenty of remaining bandwidth and the CPU is nowhere near saturated, memory is a limiting factor. Most of these low-performance relays have only 1 GiB RAM. When combined with zswap and a lighter kernel, my fastest 1 GiB relays can achieve about 150 Mbps. But the overhead of running multiple relays caused by all the extra non- swappable kernel memory needed for conntrack tables, socket structures, etc., causes the memory pressure to rapidly bring down the system.
Hopefully there will be improvements to bandwidth measurement techniques in the future for relays which do have good connectivity to Europe. Until then, I've just been adding I2P routers, which use up ~25x more bandwidth than Tor on the slower relays (3 Mbps vs 120 Kbps) and uses much less resident memory.
The cost imbalance you’re seeing is expected today: operating relays outside the EU materially improves network diversity, but it can be significantly more expensive per unit of traffic than running relays in EU-dense locations.
How does the improved diversity help if effectively no one is passing traffic through my relays?
Is there any way I can estimate the maximum consensus weight that I will be able to achieve with a particular AS in a particular location if no one else is already using it? Many of the poorly performing relays I have actually have decent connectivity to the EU, without any single AS or IXP being a bottleneck for all traffic.
Regards, forest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. tztao wrote:
i see ur a fellow lowendtalk user! i used some of em, good providers
I just read LET but don't participate, sadly. I did spend far too many hours grabbing flash sales during BF2025, though! Unless they allow Tor signups (or at least don't block signups from one of my VPSes), I'll have to remain a lurker, watching the drama and fumos from the shadows... But yes, many of the providers I use are from there.
wow thats expensive man, ur the superhero of tor network
No, as far as LET is concerned, that title goes to zGato. ;) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlRyw4ACgkQBh18rEKN 1gtluhAAwzWOEIOafZq5Rh+w2oCumle1wGxDlk4GWvpuByTAxKYc5LQdBnr2l1HJ 4OQEcAnprkr53YpW8foraSp7Z4/tFmsL1y/Ki733X/6AxmloHJJoHbgUWvild2WN 5BGEvYoPUOI6T3mBe/NAzk6HG8Q2njla0AH6IhS9c+ivqZZPkkR46eGXwtEXMBf/ q23GbZ7xzaAs6jC9YnWm5kPPj0savFYLq+b65m6CS+nRYLcKNpXBgKsIgykPMcqK RGPn4fs1NYPqXadramPajvDXVCrBXkK4phT/lrIkQtTojlLA/AUX9yrtfKL+AAND rFvpSxoS0fAs0qq/yIruSDNvHbcp6BHCO2t3UcpOs6b1iW21KNjvzaD+qyQ7poFM 9vTzi1M9PWNpRKiBU8lRItAjrsDQlAYteH4/0kq4+TdGV9+QTV1XHPF8Vs9zNuZT KFRTMOPxWO+KP77tRHDdvJUT+PD5+1/kaFxT2A6qEeg0b9JfL16Jes/gNVOkSgLI 7/6rFusvPyhnYl6ICIiniD7HH/gzq+I0WDpyHyrJzB6JGbtZTDR1EpOmoUqo3ukC grF7q4xHuEP3iJaSp5j1ahc8jG8pEQoair3y1mufNwGDJ3fk29WkCJ6CjOlpmc2H V7B+fiWsjsXbH8yUBtaSkg0Sjp4PyCi7TeQnmXGbgQD1baG6zXI= =AHkd -----END PGP SIGNATURE-----
It's great to see more geographic diversity of Tor relays! Currently, looks like two main issues and a minor third issue for forest18 1) Stable flag: struggling with consistent ORPort reachability from 8 of 9 voting directory authorities ("Stable MTBF" in source below) 2) Fast flag: The speed is also very slow, shown by very low bandwidth scanner results from the 6 bandwidth directory authorities (Consensus Weight from Authorities, i.e. "Cons Wt" in source below) 3) Uptime: Relay reports and operator directly controls, also shows low, ~2 days. Source: https://metrics.1aeo.com/relay/6435C5172690160DA25681BEBA1EA5EAC6F2BE70/#aut... On Friday, December 19th, 2025 at 12:33 PM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
It seems they are no longer blocking all of the directory authorities and forest18 has finally appeared on the consensus. This is despite them being less than helpful in a support ticket, as they demanded that I do a KYC check to run a Tor relay in their India location (I'm not sure if they really understood that it was a non-exit).
Right now, only Serge (66.111.2.131) is blocked. Sadly, this provider does not support IPv6, so I cannot try to connect to Serge over that. But either way, enough authorities can now see the relay that it has been added to the consensus and traffic is slowly ramping up.
Regards, forest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Tor at 1AEO wrote:
Currently, looks like two main issues and a minor third issue for forest18
Right now the biggest issue is that, although they unblocked the IPs not too long ago, they've been re-blocked and they are now "looking into the issue". Hopefully they will unblock them again.
2) Fast flag: The speed is also very slow, shown by very low bandwidth scanner results from the 6 bandwidth directory authorities (Consensus Weight from Authorities, i.e. "Cons Wt" in source below).
I'm having that problem with many of my relays. The relay's CPU and port are absolutely capable of handling a sustained 100 Mbps. From what I understand, the problem is that the bandwidth authorities are mostly concentrated in the Americas and western Europe, so they mistake high latency for poor bandwidth capacity. I don't know how to fix that. I assume running multiple relays on the same VPS would help, although that seems to me like a crappy hack to patch up a real problem. Meanwhile, of the 33 VPSes I have, each of the 3 in the Netherlands that I bought on a Black Friday sale simply because they were cheap pass more traffic than all my non-US, non-EU servers combined, despite scoring a bit low on speedtests. It would be nice if authorities simply increased the consensus weight of distant servers proportional to their distance. It's a bit discouraging to run a relay in South Africa for months and have it pass 0.4 MiB/s when a server in Europe for a fraction of the price and a slower network port and CPU passes 12 MiB/s after just a few weeks.
3) Uptime: Relay reports and operator directly controls, also shows low, ~2 days.
I brought all my servers down for a few hours recently. That could be the reason for that. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlSQjkACgkQBh18rEKN 1gtfgQ//dezd7LcYVE2hQ58VSWSpzA7u0t2m6Hv/OPnw4zoQIvm+VaMJFtc88/Mv ah4diOt1W7+zMfn/VvyAf7rO/M9VOQ6wjMAlDISnIeGwV70zxx7d3IricCslT03c keFuihoAPFOTnfVOstEWFid1QZoD21lQC3jx8ZIb1UOvXzeq/pVgj87jurRonjLg 7DHRT4RIb5HKvJi3H4GyQG7QFd35rQioxbslnFEkAC3j7wPv7nMC3qTKO5eNTSWL qevI7LmFnYISln71coclbF6zYlGIWIPW5n9Re2pikzA0zyQHS9X0d9DUiJgBNYLa 1h57YqIhkUuP+DRTwaXvdyCQUJ8cFL91qk5ZbccSH74jlWsv6/PN7FYDF0QR+0Fl VtrjWKnElvEzF0vCwe7QksR9ylceCy4T8/wzT7EuSXs8tBd+ykJNEvsu+GH3hhrK uAXIxt2Gnr2Pd8COzFNLAoQkw9WGAXMyX9CRBmjCcqMipN8ya0g4K+ASQcGocmOf Q/yO9uahUi3P9SsN2BLH3qnutBAL5191C5CMjLo1cD8OARLIaknzOCa9z70PSkA7 480YpWMuKWjQzx2rjyuaSwzA5mT8Vh4q7vp7vJZRjHm5U52oZKooN4uzKQnCaMYo c6FSVqZfaQ6+Ktt6GAZ59cdD0Ymwx9glTRcqjpl84QN1BBTAlRY= =EYhC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Regarding the very poor performance of forest18 (and a few others), is there anything that can be done to boost their weights? I have no idea why the bandwidth authorities are reporting such low performance, since I get decent throughput to servers in their locations. Will the consensus weights slowly increase, or will it be indefinitely capped? Or should I just spin up 16 relays on each IP? It's very discouraging to spend more than $1000 per year on dozens of diverse VPSes and achieve about the same throughput in total that I get from a single $9.99/year Black Friday promo VPS in the Netherlands. I get that the diversity is still useful, but still... Regards, forest -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQtr8ZXhq/o01Qf/pow+TRLM+X4xgUCaVsGmAAKCRAw+TRLM+X4 xhvvAQCbWV6iFMIod2QVzh43+SwBgX9Fmk8THvGpoXMFMgQxoAEAlOrJ7U1cIUYB roTy3/SjBY/uEgJsUnVIi47THSRgJgk= =xZwf -----END PGP SIGNATURE-----
Short answer: yes — adding more relays is a reasonable experiment if the host has spare CPU, RAM, and bandwidth. Add ~2–4 relays and allow 2–12 weeks for traffic and bandwidth authority measurements to ramp up and stabilize; there is no automatic increase beyond that. From our experience with large numbers of guard relays, the most common limits beyond host resources are traffic geography first (EU connectivity, a structural property of today’s Tor network), and bandwidth authority measurements second. Without strong EU connectivity, relays will struggle to pass traffic and authorities will observe low throughput, regardless of local speed tests. Running many relays per IP (e.g., 16) can help only until host or network limits are reached; beyond that, it adds complexity without increasing aggregate throughput. Adding relays will not help once CPU cores or RAM are saturated. Generalization: Guards: ~1 relay per CPU thread, ~3–6 GB RAM per relay Exits: ~1 relay per CPU thread, ~2–3 GB RAM per relay The cost imbalance you’re seeing is expected today: operating relays outside the EU materially improves network diversity, but it can be significantly more expensive per unit of traffic than running relays in EU-dense locations. Best, Tor at 1AEO On Sunday, January 4th, 2026 at 4:32 PM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Regarding the very poor performance of forest18 (and a few others), is there anything that can be done to boost their weights? I have no idea why the bandwidth authorities are reporting such low performance, since I get decent throughput to servers in their locations.
Will the consensus weights slowly increase, or will it be indefinitely capped? Or should I just spin up 16 relays on each IP?
It's very discouraging to spend more than $1000 per year on dozens of diverse VPSes and achieve about the same throughput in total that I get from a single $9.99/year Black Friday promo VPS in the Netherlands. I get that the diversity is still useful, but still...
Regards, forest
participants (7)
-
forest-relay-contact＠cryptolab.net -
Georg Koppen -
George -
John Crow -
Marco Moock -
Tor at 1AEO -
tztao