en

Tor Bridge Bandwidth Management: Rate Limiting and Cost Control

Bridge bandwidth directly affects server costs and performance. Properly configured bandwidth limits prevent unexpected overage charges while ensuring your bridge provides useful capacity to censored users. This guide covers torrc bandwidth parameters and OS-level traffic shaping for complete bandwidth control.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Understanding Tor Bridge Bandwidth Parameters

Tor uses a token bucket rate limiting system with two key parameters: BandwidthRate and BandwidthBurst. BandwidthRate sets the average bytes per second the relay can use. BandwidthBurst sets the maximum burst speed for short periods before rate limiting kicks in. For bridges, RelayBandwidthRate and RelayBandwidthBurst apply specifically to relayed traffic, allowing different limits for client usage versus relay usage. Example configuration: BandwidthRate 50 MBits (average 50 Mbps), BandwidthBurst 100 MBits (burst up to 100 Mbps briefly). PerConnBWRate limits bandwidth per circuit (useful for preventing single users from consuming all bridge bandwidth). These parameters are in bytes, KB, MB, or Mbits - verify units in torrc comments.

Calculating Appropriate Bandwidth Limits for Your Plan

Match BandwidthRate to your server's included bandwidth transfer. If your VPS plan includes 5 TB/month: 5,000 GB / 30 days = 167 GB/day / 86,400 seconds = approximately 1.9 MB/s = 15 Mbits continuous. Set BandwidthRate to 15 MBits to use full monthly allocation without overage. For headroom: set BandwidthRate to 10-12 MBits to leave buffer for OS traffic and avoid approaching limits. If your provider charges per GB beyond allocation: calculate maximum spend on bandwidth overage, determine how many GB that allows, and set BandwidthRate accordingly. Monitor actual usage monthly with vnstat or similar to verify limits are being respected.

OS-Level Traffic Shaping with tc

Linux tc (traffic control) provides more granular bandwidth management than torrc parameters. Create a traffic shaping rule that limits the tor user's outbound traffic: tc qdisc add dev eth0 root handle 1: prio; tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit; tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50mbit; tc filter add dev eth0 parent 1: protocol ip u32 match ip protocol 6 0xff flowid 1:10. This limits TCP traffic to 50 Mbps. For user-specific limiting: cgroups combined with tc allow bandwidth limits per process user. IPtables MARK + tc htb provides fine-grained control. For most bridge operators, torrc bandwidth settings are sufficient without needing tc.

Monitoring Bridge Bandwidth Usage

vnstat provides per-interface bandwidth statistics with daily, weekly, and monthly summaries. Install and enable: apt install vnstat; systemctl enable --now vnstat. View stats: vnstat -d (daily), vnstat -m (monthly). The Tor relay monitoring page (https://metrics.torproject.org/rs.html) shows historical bandwidth statistics for your bridge. Tor's own logs include bandwidth accounting information if you configure RelayBandwidthAccounting. Check top bandwidth periods: vnstat -h shows hourly usage to identify when your bridge is most active. Set alerts with custom scripts that check vnstat data and email if monthly usage exceeds a threshold.

Bandwidth Accounting and Scheduled Throttling

Tor's built-in accounting allows automatically pausing relay operation when monthly bandwidth limit is reached. Configure in torrc: AccountingMax 3 TBytes (pause when 3 TB transferred), AccountingStart month 1 00:00 (reset counter on 1st of month). When the limit is reached, Tor stops relaying traffic until the next accounting period. This prevents overage charges completely. Scheduled throttling (reducing BandwidthRate at night when server costs peak) can be done with cron + sed scripts that modify torrc and reload: 0 23 * * * sed -i 's/BandwidthRate .*/BandwidthRate 5 MBits/' /etc/tor/torrc && systemctl reload tor. Daytime rates can be higher. This manual approach requires testing to ensure torrc syntax remains valid after sed substitutions.

Why Anubiz Host

100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Anubiz Chat AI

Online