Bandwidth is one of the most misunderstood parts of Tor relay operation.
A relay can have a fast Internet connection, advertise a generous bandwidth limit, and still receive almost no Tor traffic during its first hours.
The reason is that Tor distinguishes between configured capacity, observed capacity, measured capacity, and consensus selection weight.
1. Configured Bandwidth
A relay operator can configure how much bandwidth Tor is allowed to use.
A fictional configuration might be:
RelayBandwidthRate 32 MBits
RelayBandwidthBurst 32 MBits
This represents an operator-controlled limit.
It does not tell Tor:
This relay has already proven that it can sustain this bandwidth.
It only says:
Tor is permitted to use up to approximately this amount.
2. Bandwidth Rate
Bandwidth Rate represents the sustained bandwidth limit.
It is a policy configured locally by the relay operator.
A server on a 1 Gbit/s connection may intentionally expose only:
30 Mbit/s
to Tor.
Therefore, the value says little about the total physical capacity of the underlying Internet connection.
3. Bandwidth Burst
Bandwidth Burst determines how much temporary traffic may exceed the normal rate.
For example:
Rate = 30 Mbit/s
Burst = 50 Mbit/s
allows temporary bursts beyond the long-term rate.
When Rate and Burst are configured identically, the relay effectively has no extra burst allowance.
4. Observed Bandwidth
Tor also records how much throughput the relay has actually observed.
This produces the Observed Bandwidth value.
A newly deployed relay may show:
Bandwidth Rate 4 MB/s
Observed Bandwidth 0
even though the physical connection is perfectly capable of much higher throughput.
This happens because the relay has not yet carried enough traffic to demonstrate its actual capability.
5. Advertised Bandwidth
Tor derives an advertised bandwidth from several values.
Conceptually, the advertised value is limited by the smallest relevant capacity figure.
For example:
Rate 4 MB/s
Burst 4 MB/s
Observed 800 KB/s
may result in an advertised capability around:
800 KB/s
This prevents a relay from advertising a capacity that it has never demonstrated.
6. Why Self-Reported Bandwidth Cannot Be Trusted Alone
If Tor trusted operator configuration directly, a malicious relay could claim:
100 Gbit/s
without possessing anything close to that capacity.
It could then attempt to attract an excessive share of Tor circuits.
Tor therefore uses independent bandwidth measurement infrastructure.
7. Bandwidth Authorities and Scanners
Specialized Tor measurement systems test relay performance.
A simplified process looks like:
Discover Relay
↓
Generate measurement traffic
↓
Observe performance
↓
Produce measurement result
↓
Feed result into directory voting
These measurements help the Directory Authorities estimate relay capacity independently of the relay operator’s own claims.
8. What Measured: True Means
Public Tor data may contain:
Measured: True
This indicates that the relay’s consensus bandwidth value is based on measurements from sufficient bandwidth-authority data rather than being entirely unmeasured.
This is an important milestone for a new relay.
It means:
relay discovered
✓
relay reachable
✓
relay measured
✓
It does not mean the measurement is already mature.
A very new relay may still receive a tiny consensus value.
9. Consensus Weight
Consensus Weight is one of the most important numbers on a Relay Search page.
It represents the relay’s weight in the shared Tor consensus and is used by client path-selection algorithms.
Consider:
Relay A: Consensus Weight 1500
Relay B: Consensus Weight 50
Under comparable roles and conditions, Relay A has considerably more influence on path selection.
However, the final probability is not a simple direct ratio because Tor also applies role-specific bandwidth weights.
10. Consensus Weight Is Not Real-Time Bandwidth
These values answer different questions:
Real-time RX/TX
→ What is happening this second?
Observed Bandwidth
→ What capacity has the relay itself observed?
Advertised Bandwidth
→ What capacity does its descriptor currently advertise?
Consensus Weight
→ How much selection weight has the Tor network assigned?
A relay can therefore show:
Current traffic: 0.2 Mbit/s
Configured limit: 30 Mbit/s
Consensus weight: extremely low
without any contradiction.
11. Consensus Weight Fraction
Relay Search may also show:
Consensus Weight Fraction
This expresses the relay’s consensus weight as a fraction of the total network weight.
It is easier to compare across relays than a raw weight number.
A very small new relay may initially represent only a tiny fraction of the global total.
12. Selection Probabilities
Public relay data may estimate:
- Guard probability
- Middle probability
- Exit probability
These are influenced by:
relay flags
consensus weight
bandwidth weights
role eligibility
A non-exit relay naturally has an exit probability of zero.
A relay without the Guard flag similarly has no Guard-selection probability.
Its main early role is therefore usually Middle.
13. Why Weight Often Increases Slowly
Tor intentionally avoids immediately treating a brand-new relay as a mature high-capacity node.
A typical early progression is:
Descriptor accepted
↓
Initial consensus entry
↓
Very low bandwidth value
↓
Bandwidth measurements accumulate
↓
Descriptors update
↓
Consensus weight changes
↓
More circuits select the relay
↓
More real traffic is observed
This creates a gradual ramp-up rather than an immediate jump.
Conclusion
Relay bandwidth should never be judged from a single number.
The useful hierarchy is:
configured capacity
↓
observed performance
↓
independent measurement
↓
advertised capability
↓
consensus weight
↓
actual path-selection probability
For a new relay, the most meaningful long-term signs of growth are increasing observed bandwidth, increasing consensus weight, and eventually a larger share of real Tor traffic.