Load Balancing Tor Hidden Services on Multiple Servers

Multiple backend servers can host the same Tor onion service (hidden service) to provide load balancing and high availability, but it cannot be achieved by simply copying the same private key across different servers. Because Tor relies on a distributed hash table to publish service descriptors, running duplicate keys causes routing collisions and connection failures. To properly distribute traffic, administrators use specialized tools such as Onionbalance, which aggregates multiple independent backend instances under a single public onion address.

Why Duplicate Keys Fail

When a Tor onion service starts, it establishes introduction points on the Tor network and publishes a descriptor to the Hidden Service Directory (HSDir). If multiple servers attempt to run the exact same private key simultaneously: * Each server independently generates its own list of introduction points. * Each server continuously overwrites the other servers’ descriptors on the HSDir. * Clients attempting to connect receive conflicting routing information, leading to failed circuits, timeouts, and unstable connections.

The Standard Solution: Onionbalance

The official and most effective method to distribute Tor traffic across multiple servers is Onionbalance. Designed for modern v3 onion services, Onionbalance separates the master onion identity from the backend worker nodes.

1. Independent Backends: Each backend server runs its own Tor instance with its own distinct onion key and creates its own introduction points. These individual addresses remain private and are not shared with end users.
2. Master Management Node: Onionbalance runs on a management server that holds the master private key corresponding to the public .onion address.
3. Descriptor Aggregation: Onionbalance periodically queries the backend instances, collects their active introduction points, and combines them into a single master descriptor.
4. Publication to HSDir: The management node signs this aggregated descriptor using the master key and publishes it to the Tor network.

When users connect to the public onion address, Tor randomly selects an introduction point from the master descriptor, distributing incoming connections evenly across the pool of backend servers.

Alternative: Reverse Proxy Architecture

Another common approach is running a single Tor daemon acting as a gateway that forwards decrypted traffic to a local load balancer, such as HAProxy or Nginx.

• How it works: The Tor daemon listens for incoming circuits and proxies the traffic over a private network to a standard load balancer, which distributes requests to multiple application or database servers.
• Trade-offs: This method relieves load on the web application layer, but the single Tor daemon remains a single point of failure and a bandwidth bottleneck.

Key Benefits of Onionbalance

• Horizontal Scalability: You can add or remove backend nodes on demand to handle fluctuating traffic volumes.
• Enhanced Security: Backend nodes never hold the master private key. If an individual backend node is compromised, the primary onion address remains secure.
• High Availability: If a backend server crashes or goes offline, Onionbalance automatically removes its introduction points from the master descriptor, ensuring uninterrupted service for users.