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/#authority-votes 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@xxxxxxxxxxxxxxxxxxxx> 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.
Attachment:
image.png
Description: PNG image
Attachment:
publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx
