Running a Private Tor Bridge: Complete Deployment Guide

Public bridges registered with BridgeDB are distributed to users who request them, providing broad access but also exposure to censors who systematically probe BridgeDB for bridge addresses. Censors in China, Iran, and Russia systematically collect BridgeDB addresses and probe them to detect and block Tor bridges. Private bridges avoid this systematic probing because their addresses are never in BridgeDB. The tradeoff is that private bridges serve only users who have received the address through trusted channels - they cannot help unknown users who request bridges from BridgeDB. Private bridges are ideal for specific trusted communities, high-risk activists, and journalists with established contact networks.

Install Tor from the official repository. In /etc/tor/torrc, configure as a bridge relay: BridgeRelay 1, ORPort 443, ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy, ServerTransportListenAddr obfs4 0.0.0.0:9443. Critical difference from public bridges: do NOT include PublishServerDescriptor bridge - this line is what registers your bridge with BridgeDB. Omitting this line makes your bridge private. Restart Tor and retrieve the bridge line from the notice log: grep 'Registered server transport' /var/log/tor/notices.log. The output contains the full bridge line to share with users.

Private bridge addresses must reach intended users without being intercepted by adversaries. Distribution methods by security level: in-person exchange (highest security - meet and verbally share or write down the address), encrypted messaging over Signal or Session (high security - messages are end-to-end encrypted, share bridge address as disappearing message), PGP-encrypted email (high security - requires both parties to manage keys), and voice calls (moderate security - avoids message storage but may be recorded). Never post private bridge addresses publicly, include them in unencrypted email, or share them in group chats that may include unknown participants. Brief users on the importance of not forwarding the bridge address without consulting you.

Unlike public bridges, private bridges allow you to monitor usage patterns without BridgeDB statistics. Monitor connection counts via the Tor control port (GETINFO clients/all) to understand how many users are connecting. Track bandwidth usage with vnstat to ensure you have sufficient capacity for your user base. If bridge addresses are compromised (shared too widely or obtained by adversaries), you will see unusual connection count spikes or connections from unexpected geographic regions. Tor logs approximate client locations through the country code of connecting guard nodes (visible in logs) - a sudden influx of connections from unexpected countries indicates the bridge address may have been shared beyond intended recipients.

Private bridge identity (fingerprint and obfs4 keys) can be regenerated if the bridge address is compromised. Stop Tor, delete the DataDirectory contents (preserving any important configuration but not the key material), and restart Tor - new keys generate a new bridge address and fingerprint. Distribute the new address to your trusted user base through secure channels. Establish a rotation schedule (every 6-12 months for high-risk deployments, when you suspect compromise) as a standard practice. Keep a secure record of the current bridge address and the last few previous addresses (users may be running outdated bridge configurations).