Tor Bridge and Relay Monitoring with nyx and Metrics Dashboard

nyx is the official Tor relay monitor built on the Tor control port. Install from the package manager and configure the control port before running it:

apt install nyx
# Add to /etc/tor/torrc:
ControlPort 9051
HashedControlPassword $(tor --hash-password 'your-strong-passphrase-here')

Run nyx as the tor user: sudo -u debian-tor nyx. The interface shows live bandwidth graphs, circuit counts, flag status, and log messages. The bandwidth graph is particularly useful for identifying performance degradation over time. A bridge that showed 20 Mbps two weeks ago and now shows 5 Mbps may be experiencing upstream network issues or performance problems with the obfs4proxy process.

nyx also displays the current consensus weight if your relay has been assigned one, the uptime, and the contact info as published. These details confirm that the bridge descriptor has been accepted by the directory authorities and is being distributed to clients correctly. Discrepancies between your torrc settings and the displayed values indicate configuration problems that require investigation.

The Tor Metrics portal at metrics.torproject.org/rs provides detailed historical data for all public relays and bridges. Search by nickname, fingerprint, or IP address to find your relay. The relay page shows bandwidth history as a graph over the last 1, 3, 6, or 12 months, uptime percentage, flags earned from directory authorities, and version history.

For bridges specifically, the metrics bridge search at metrics.torproject.org/bridges shows daily user counts by country. This is the most important metric for bridge operators: the number of users who successfully connected through your bridge, broken down by the country their IP address geolocates to. A sudden drop in users from a specific country while overall relay traffic continues normally indicates censorship-level blocking specific to that country.

Set a weekly reminder to check your relay metrics. Trends that develop slowly are easier to catch with regular reviews than with alerts, which typically require threshold-crossing events. Gradual performance degradation or slowly declining user counts can be early indicators of problems before they become service-impacting.

Internal monitoring from the server side cannot detect when a bridge IP is blocked inside a specific country. A bridge can appear perfectly healthy from your monitoring perspective while being completely unreachable to users in Iran or China. External probing from inside those networks is the only reliable way to detect this.

The OONI (Open Observatory of Network Interference) project runs volunteers inside censored networks who test connectivity to Tor infrastructure including bridges. Submit your bridge fingerprint to OONI for testing via their explorer at explorer.ooni.org. Results take days to weeks to appear but provide empirical evidence of reachability from specific countries.

Build relationships with trusted users in your target countries. A private Telegram channel where users can report bridge status takes 5 minutes to set up and provides near-real-time feedback from inside the network where your bridge actually matters. Operators serving Iran typically get feedback within hours of a bridge being burned because users in the community actively monitor and report availability.

Configure systemd to restart the tor service automatically after failure, with a delay that prevents rapid cycling if tor exits in a crash loop:

[Service]
Restart=always
RestartSec=30
StartLimitIntervalSec=300
StartLimitBurst=5

Set up external uptime monitoring using a service like UptimeRobot or a self-hosted tool that probes your bridge port every minute and sends notifications when it becomes unreachable. This catches network-level failures such as data center outages, kernel panics, or full disk conditions that kill the tor process without triggering the systemd restart.

For more sophisticated alerting, parse the nyx control port output or the tor notice log with a script that counts errors per 10-minute window and sends a Telegram notification when error counts exceed thresholds. Use the Telegram Bot API for delivery: create a bot via BotFather, get the token, and send messages with curl to api.telegram.org. This works entirely without a GUI and can run as a cronjob on the bridge server itself.