When a Torzon Mirror Reads Down — Recovery Guide

Before anything else, open the mirror status page in your everyday browser and read the snapshot.

• Snapshot green, your client times out: the block is local. Continue to step 2.
• Snapshot shows one mirror degraded or down: use a different mirror, skip to step 2.
• Snapshot shows all three down: a genuine outage is in progress. Check the status log for an open incident and wait it out.

The three mirrors live in three regions on three paths. A block or throttle on one rarely touches the other two, so the single most effective move is to paste a different address.

1. If α times out, try β, then γ
2. Pick by the reachability matrix — choose the mirror that reads cleanest from your region
3. Paste the new address only after confirming it against the signed manifest

If every mirror times out, the failure is below the endpoint — the transport itself is being blocked. The reachability matrix shows obfs4 dropping from censored regions while snowflake and meek-azure stay green, so the fix is to change how the traffic is shaped.

• In Tor Browser open Settings, then Connection, then Bridges
• Switch from obfs4 to snowflake — it rides WebRTC and is far harder to bulk-block
• If snowflake also stalls, try meek-azure, which hides inside HTTPS to a CDN front
• Re-test the mirror after each transport change before moving on

The pairing is documented for a reason: snowflake reads best against Mirror β, meek-azure against Mirror γ.

When the matrix shows an obfs4 dip from your region, the usual cause is bridge IP enumeration: the firewall learned the published bridge addresses and blocked them. A fresh bridge line restores reachability without touching anything else.

• Request new built-in bridges from Tor Browser, or import a fresh obfs4 line
• Remove the burnt bridge entries so Tor stops retrying dead IPs
• Re-test against the mirror the matrix recommends for your region

Some networks do not block Tor outright; they throttle anything that looks Tor-shaped until circuits time out. Wrapping Tor inside a VPN means the ISP sees only generic encrypted traffic to a generic provider, and the throttling has nothing to grab.

• Connect the VPN before launching Tor (the VPN-then-Tor order)
• Choose a no-log provider in a privacy-friendly jurisdiction
• Run a DNS leak test before opening Tor, then re-test the mirror

Do not reverse the order. Tor-then-VPN exposes you to the VPN as a Tor exit and does nothing for throttling.

A quick second-device test separates a desktop misconfiguration from a real reachability problem. If the same mirror and transport answer on a phone, your desktop setup is the culprit.

• Android: connect through Orbot with the same transport, then load the mirror
• iOS: use Onion Browser with a built-in obfs4 or snowflake bridge
• Note the result — matching failure on both devices points at the network, not the client

This is a diagnostic step, not a setup guide; the goal is only to confirm where the fault lives.

If two transports and all three mirrors fail from your location while the snapshot reads green elsewhere, you have found something the probe network cannot see from its current vantage points. That is worth reporting.

1. Note your region, the transports tried, and where each circuit stalled
2. Send it to the contact address on the about page
3. A corroborated report can add a vantage point or open an incident in the log

Good reports make the matrix more accurate for the next person in your region — that is the whole point of an independent monitor.