Tor Service Feature request

Summary

While investigating unexpectedly high, sustained bandwidth usage on my network, I traced the majority of real internet-facing traffic on one of my two StartOS servers (brave-crybaby, StartOS v0.4.0.1) to the built-in Tor relay running in public (non-bridge) mode.

I tried to throttle it under Services → Tor → Configure Relay, but the Bandwidth Rate and Bandwidth Burst fields only accept whole-number MB/s values and can’t go below 1 MB/s. Tor itself supports much finer-grained limits natively (KB/s, with a relay floor around 75–100 KB/s), so this looks like a UI/validation limit rather than a Tor limit.

Request: please allow RelayBandwidthRate / RelayBandwidthBurst to be entered at KB/s granularity (or accept decimal MB/s), so relay operators with limited upload budgets can throttle meaningfully below 1 MB/s.

Why this matters (the data)

Measured relay throughput was already averaging ~285–295 KB/s per direction — i.e. running close to saturating even the “minimum” 1 MB/s setting continuously:

Service Received Transmitted Total Extrapolated/day
tor 14.50 GB 13.71 GB 28.21 GB ~49.5 GB
my-speed 3.20 GB 0.52 GB 3.72 GB ~6.5 GB
ipfs 0.56 GB 0.58 GB 1.14 GB ~2.0 GB
nextcloud, nostr-rs-relay, bunker46, coturn, jitsi ~0.1 GB combined ~0.15 GB

Over a ~13h 41m measurement window, Tor alone accounted for ~85% of all traffic on the box.

What I’d like to set instead

RelayBandwidthRate:  ~30 KB/s
RelayBandwidthBurst: ~50-60 KB/s

This isn’t achievable through the current UI, since it snaps to whole MB/s and won’t go below 1.

Environment

  • StartOS: v0.4.0.1
  • Tor package: 0.4.9.11:8
  • Relay mode: standard (Bridge Mode off), OR Port 9001

Thanks for putting together all this detail and making this suggestion. I used your post here as the source for creating an actual feature request on GitHub so the development team can track it directly.

If you’re comfortable using GitHub, you can go ahead and open issues like this directly. The Start9 development team gets notified on GitHub issues and uses them for tracking feature requests and bugs. Items in the community forum don’t have the same visibility level.

And since StartOS and its services are open source, there’s another option for anyone who wants to get more involved: you can submit a pull request with a proposed fix or improvement.

You definitely don’t have to be an expert developer to contribute. I’m not a StartOS programming guru myself, but with help from tools like Claude and ChatGPT, I’ve been able to work through some changes and submit pull requests that were accepted.

Even if you don’t want to write any code, detailed reports like yours here are very helpful. Thank you again for taking the time to put this together!!!

hi Jesse,

can you add this as well into the feature request or somethjng you want to troubleshoot first ? Issue 2: Per-service Outbound Gateway setting doesn’t hold — Tor keeps reverting to the wrong route

After setting Tor’s Outbound Gateway (in Services → Tor → Configure) to my direct wired connection instead of my VPS-based StartTunnel, I expected Tor’s traffic to stay off the tunnel. Instead, the Tor logs show the relay’s detected external IP flipping back and forth between my direct IP and the tunnel IP 48 times over roughly 9.5 hours, with bursts as frequent as once per minute:

Sep 06 21:09:27  IP changed 103.xxx.xx.xx → 62.xxx.xx.xx   (tunnel → direct)
Sep 06 21:10:27  IP changed 62.xxx.xx.xx → 103.xxx.xx.xx   (direct → tunnel)
...
Sep 07 06:23:02  IP changed 62.xxx.xxx.xxx → 103.xxx.xxx.xx  (direct → tunnel)

Tallying actual time spent on each path over that window:

  • VPS Tunnel: ~83% of the time
  • Direct (ISP): ~17% of the time

So despite setting the per-service outbound gateway, the large majority of Tor’s traffic is still riding the metered VPS tunnel — confirmed independently by my VPS panel showing ~10 GB used since midnight. Each flip also forces a full ORPort reachability self-test and descriptor rebuild, adding extra overhead on top of the routing problem itself.

Request: please confirm whether the per-service Outbound Gateway setting is supposed to override gateway failover/health-check behavior, or whether there’s a known interaction that causes it to periodically revert. A chart of the flapping pattern is attached.

I posted your question in the Matrix support room Community - StartTunnel. Let’s see if there are any interesting responses there…