Testing Tor Bridge Reachability

After setting up a Tor bridge, verify it is reachable before sharing with users. From a different machine (not the bridge server itself): attempt to connect to Tor using the bridge. On a Linux machine: install Tor, create a test torrc with only the bridge line (UseBridges 1, Bridge obfs4 IP:PORT fingerprint cert=... iat-mode=0, ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy) and run tor -f test_torrc. If Tor successfully builds circuits using the bridge, the bridge is working. From a censored network: the best test is from a machine that simulates a censored environment - use a VPS in a country that blocks Tor without bridges, and attempt to connect using your bridge. If the connection succeeds via the bridge but fails without it, the bridge correctly bypasses the local filtering. Tor Project's bridge reachability testing: bridges registered with the Tor Project are tested periodically by the Tor Project's infrastructure. The BridgeDB system (bridges.torproject.org) uses these test results to determine which bridges to distribute to users.

The Tor Project provides tools for checking bridge status. Tor Metrics (metrics.torproject.org): shows aggregate bridge usage statistics, including bridges by transport type and country-level usage. Does not show individual bridge status. BridgeDB (bridges.torproject.org): when you request bridges, BridgeDB only distributes bridges that have passed reachability tests. If your bridge has been idle or unreachable, it may be removed from the distribution pool. The Relay Search tool (metrics.torproject.org/rs.html#search): search for your bridge by fingerprint to see its current status, bandwidth, and flags. The bridge status page shows 'Running' (currently passing reachability tests) or 'Offline' (not currently reachable). Check this status after setting up your bridge and periodically thereafter.

For ongoing monitoring, automate bridge reachability checks. A simple monitoring script: every 15 minutes, attempt to connect to Tor using the bridge (via tor command with a test torrc), check if the connection succeeds within a timeout, and send an alert if it fails. The alert can be a local log entry, an email (via a Tor-proxied SMTP connection), or a message to a Telegram bot (proxied through Tor to avoid clearnet exposure). Uptime monitoring script example: create a bash script that runs tor with the bridge configuration, waits 60 seconds for circuit establishment, checks if Tor's SOCKS port is responding (via netcat or curl --socks5), and exits with success or failure. Use cron to run this script every 15 minutes and log results. Alert on consecutive failures (3+ failures = bridge may be down). Monitor also the obfs4proxy process itself: verify it is running with ps aux | grep obfs4proxy and that it is listening on the expected port with ss -tulpn | grep [port].

OONI (Open Observatory of Network Interference) provides probes that can test Tor bridge reachability from various countries. OONI Probe is installable on Android, iOS, Linux, and macOS. Running OONI tests from a machine in a censored country tests whether the bridge is reachable from that censorship environment. The OONI test for Tor bridge reachability (tor_bridge experiment) attempts to connect via the bridge and reports success or failure. This external testing perspective is valuable: a bridge may be reachable from the uncensored internet but blocked specifically in censored countries. OONI's published data (explorer.ooni.org) shows historical test results. Note: running OONI tests in heavily censored countries may have legal risks - assess before running.

If a bridge tests as unreachable, systematic troubleshooting: (1) Check the bridge server itself: is the Tor service running? (systemctl status tor). Is obfs4proxy running? (ps aux | grep obfs4proxy). Is the port listening? (ss -tulpn | grep [obfs4_port]). (2) Check firewall rules: are incoming connections to the obfs4 port allowed? (iptables -L -n | grep [port] or ufw status). (3) Check logs: /var/log/tor/log shows Tor startup messages and errors. The obfs4proxy log (usually in /var/lib/tor/pt_state/) shows transport-level issues. (4) Network-level test: from outside the server, use nc (netcat) to connect to the bridge IP and port. If the connection refuses or times out, the port is not reachable. (5) IP reputation: check if the server's IP has been blocklisted by major security services (AbuseIPDB, Spamhaus). A newly flagged IP may be blocked by some networks. (6) Server resource exhaustion: if the server is out of memory or file descriptors, Tor may fail silently. Check with free -m and ulimit -n.