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.
