Copied

> Torzon Mirror Status — Per-Endpoint Reachability

The three Torzon onion mirrors, each probed every ten minutes from six vantage points. What follows is the state recorded at the last completed sweep, the rolling uptime behind it, and the round-trip each transport measured — a documented snapshot, not a live socket. Last sweep: UTC

status@torzon:~$
# Probed endpoints — copy the address you intend to verify, then check it against the signed manifest
α
OPERATIONAL Region A · obfs4 ~145 ms · 90-day 99.6%
torzon65avdb6dm5jaibhmddj7oydej6s4764x6d7hdkspahkicoezad.onion
β
OPERATIONAL Region B · snowflake ~250 ms · 90-day 99.1%
torzon47iwf6pxx736dtbvrabzmvvjx5nakwkglvgeoyd6a5ejv7ktqd.onion
γ
OPERATIONAL Region C · meek-azure ~320 ms · 90-day 99.0%
torzontvfzbsp2q7cuuddadz4u3cewjkibaasgl4owmvvbaa5gfem6ad.onion
status@torzon:~$

Last Sweep — Per Mirror, Per Transport

Output of the most recent probe round. Each mirror is sampled over its recommended transport from the censored vantage points and the open reference points. Round-trip is measured circuit-end-to-end through the indicated transport.

$ torzon-probe --all-mirrors --transports=obfs4,snowflake,meek --window=90d
Mirror α (Region A) | obfs4: 145ms | REACHABLE 99.6%
Mirror β (Region B) | snowflake: 250ms | REACHABLE 99.1%
Mirror γ (Region C) | meek-azure: 320ms | REACHABLE 99.0%
Last sweep: — 0 open incidents · aggregate 90-day reachability 99.3%

Reachability Matrix — Region × Transport

Rolling 90-day reachability share for the mirror set, broken out by where the probe ran and which transport carried it. This is the table to read if you are asking “is Torzon reachable from my country” — find the closest vantage region and the transport you use.

Trailing 90-day reachability share, aggregated over the three mirrors, as of the 2026-06-26 sweep.
Vantage region obfs4 snowflake meek-azure Recommended
Western Europe (open) 99.8% 99.6% 99.4% obfs4 → α
North America (open) 99.7% 99.5% 99.5% obfs4 → γ
South America (open) 99.5% 99.3% 99.1% obfs4 → α
East Asia (censored) 96.1% 99.0% 98.6% snowflake → β
Central Asia (censored) 95.4% 98.7% 98.2% snowflake → β
West Asia (censored) 96.8% 98.9% 99.0% meek-azure → γ

Uptime History per Mirror

Rolling reachability over the last 30 and 90 days, aggregated across all vantage points. The bars are the 90-day figure.

Mirror α · Region A 30-day 99.8% · 90-day 99.6%
Mirror β · Region B 30-day 99.4% · 90-day 99.1%
Mirror γ · Region C 30-day 99.2% · 90-day 99.0%

Recent Incidents

Dated outage, degradation and recovery events from the probe history. The full running record is in the status log.

RESOLVED

Mirror β snowflake latency from Asian vantage points cleared after a four-day degradation. Reachability never dropped; only round-trip was affected.

DEGRADED

Mirror β round-trip crossed the alert threshold over snowflake from East and Central Asia. Flagged degraded, not down — probes still completed.

OUTAGE

Mirror γ returned circuit timeouts from every vantage point for about 38 minutes overnight, then recovered without operator action. Aggregate impact absorbed by α and β.


How to Read a Status

Three states, with thresholds, so a slow mirror is never confused with an offline one. The exact numbers are documented on the methodology page.

Operational

Probes complete from every vantage point and round-trip sits inside the normal band. The endpoint is answering and responsive.

Degraded

The endpoint answers but round-trip crossed the alert threshold, or an occasional probe missed inside an otherwise clean window. Slow or flaky, not offline.

Down

Probes from every vantage point time out across consecutive rounds. Only then is a mirror called down, and an incident is opened in the log.


A status is not a substitute for verification

A green reading confirms the endpoint answered our probes. It does not confirm that the address you copied is the real one. During an outage, look-alike addresses spread fastest — that is precisely when people grab a “fresh link” without checking. Before pasting any address:

  • Confirm it is exactly 56 base32 characters before .onion
  • Match it byte-for-byte against one of the three printed above
  • Validate the PGP signature on the published manifest — see the verification steps
  • Never trust an address pasted into a chat group or link aggregator

Why the Service Runs Three Mirrors

A single endpoint has a single point of failure. Three give the monitor something useful to report.

Mirrors α, β and γ sit in three distinct hosting regions, on three independent network paths, with three separate guard relay sets. From a monitoring standpoint that matters: when one region is throttled or AS-level filtered, the probes record a dip on exactly that endpoint while the other two stay green. A reader can then route around the problem instead of assuming the whole service is gone.

The pairing between mirror and transport is what makes the matrix readable. Mirror α consistently posts the lowest obfs4 round-trip from open networks. Mirror β is the most reliable over snowflake from heavily filtered regions where bridge IPs are burned. Mirror γ is the one that keeps answering over meek-azure behind networks that only permit HTTPS to known CDN fronts.

All three are Tor v3 onion services with end-to-end encryption from the client to the service backend, so no clearnet observer sees the request payload. The monitor only measures the entrance: did a circuit complete, and how quickly. What sits behind any mirror is identical and is none of this site’s business — we report reachability, nothing else.


Reading This During an Outage?

If a mirror reads down from your network but green here, the block is local. The access guide walks through switching mirror and transport before you conclude the service is offline.

Open the Access Guide