High-Availability Tor Bridge Infrastructure: Design and Implementation

Bridges are entry points to the Tor network for censored users. If a bridge goes down - due to hardware failure, DDoS attack, VPS provider issues, or operator error - users lose access to Tor. For casual users, this is an inconvenience. For journalists working under deadline in a censored country, or activists communicating during a political crisis, bridge unavailability may prevent critical communications. Organizations with duty-of-care responsibilities to high-risk users should design bridge infrastructure with the same rigor as other critical communications infrastructure.

Running bridges in multiple geographic locations provides resilience against regional failures and ISP-level blocking. A bridge in Iceland and a bridge in Romania, both distributing the same credentials to the same user community, ensures that if one jurisdiction's network infrastructure is disrupted or one provider has an outage, the other remains available. Geographic diversity also provides resilience against routing failures - if a BGP routing issue affects one datacenter's connectivity, the other may remain reachable. For maximum resilience, use bridges in at least two different countries with different ISPs.

A simple high-availability pattern uses DNS-based failover. Assign both bridge IP addresses to a DNS hostname. Configure the obfs4proxy server on each to listen on the same port. The primary bridge's IP is preferred; the secondary's IP is published as a backup. This requires configuring bridge clients with the hostname rather than a static IP, which obfs4 clients can support. When the primary goes down, DNS failover (with low TTL) switches clients to the secondary. This provides automatic failover without requiring manual client reconfiguration.

Bridge availability monitoring requires monitoring from outside the bridge's network. Set up a monitoring VPS (in a third location) that connects to each bridge through its obfs4 transport and verifies successful connection. Alert on: connection timeout (bridge unreachable), TLS certificate changes (possible compromise or accidental misconfiguration), and bandwidth drops below expected levels (possible partial failure). Notification through encrypted channels (Signal, encrypted email) ensures alert delivery even if the bridge infrastructure itself is compromised. Monitor both the TCP reachability of the port AND the full obfs4 handshake success.

Bridge key material (the bridge's fingerprint-generating private key) must be backed up securely. If a server fails and the key is lost, the bridge's fingerprint changes and existing configurations pointing to the old fingerprint fail. Back up the /var/lib/tor/keys directory (for relay key) and obfs4 state directory (for obfs4 key) to an encrypted, offline backup. Test recovery procedures periodically - restore from backup to a new VPS and verify the bridge fingerprint matches the backed-up value and connections succeed. Document recovery procedures so that any authorized team member can execute them under pressure.