Copied
3 of 3 mirrors operational · checked 2026-06-26

Torzon Status — Mirror Reachability & Uptime Monitor

An independent reachability reference for the Torzon onion service. This page answers one question — is a mirror responding, and from where — by recording which of the three onion mirrors answered the last probe sweep, the regions the probes ran from, and which transport (obfs4, snowflake or meek-azure) carried the request. Everything below is a documented measurement with a timestamp, not a live socket. We monitor the service; we do not operate it.

Torzon Status dashboard — mirror reachability by region and transport
LAST REACHABILITY SWEEP COMPLETE
Snapshot taken: UTC · probe cadence 10 min
Mirror β latency recovered

Snowflake round-trip from Asian vantage points returned to its normal band on 18 Jun after a four-day degradation.

Probe cadence tightened

Sampling moved from every 15 minutes to every 10, shortening worst-case outage detection delay.

Mirror γ outage resolved

A 38-minute timeout window on 29 May cleared on its own; the other two mirrors stayed reachable throughout.

Mirror Status Snapshot

The three Torzon onion endpoints and how each one read on the last completed sweep. This is a published snapshot, refreshed from periodic probes — confirm an address against the signed manifest before you ever paste it into Tor Browser.

Torzon onion endpoints — last checked 2026-06-26

Status reflects the most recent probe round, not a real-time connection.

Read the status, then verify the address

A green status here means the endpoint answered our probes — it is not a substitute for verifying the address yourself. Copies harvested from chat groups and link aggregators are routinely swapped for look-alikes during an outage, exactly when people are most likely to grab a fresh link in a hurry.


Reachability by Region & Transport

Where the probes ran from and which transport reached the mirrors. Cells show the rolling reachability share over the trailing 90 days, not an instantaneous reading. Open-network rows are reference baselines; censored rows are the ones that actually move.

Trailing 90-day reachability share per vantage region and pluggable transport, as of the 2026-06-26 sweep. Blank cells indicate a transport not routinely probed from that vantage point.
Vantage region obfs4 snowflake meek-azure
Western Europe (open) 99.8% 99.6% 99.4%
North America (open) 99.7% 99.5% 99.5%
South America (open) 99.5% 99.3% 99.1%
East Asia (censored) 96.1% 99.0% 98.6%
Central Asia (censored) 95.4% 98.7% 98.2%
West Asia (censored) 96.8% 98.9% 99.0%

obfs4 reads lower from censored vantage points because published bridge IPs get enumerated; snowflake and meek-azure ride traffic shapes that are harder to block, which is why the recommended pairing differs by region.


What Torzon Status Tracks

Four signals, sampled on a fixed cadence and written to a history. No transactions, no listings, no payments — only whether a Tor v3 endpoint answers, and how well. The four columns below are the whole scope.

Mirror Reachability

Whether each of the three onion endpoints answered the last probe round, per vantage point.

Transport Reachability

obfs4 vs snowflake vs meek-azure scored separately, because a block rarely hits all three at once.

Uptime History

Rolling 30 and 90-day reachability shares, so a single bad hour does not read like a permanent failure.

Incident Log

Dated outage, degradation and recovery notices in the status log with start and clear times.


Uptime at a Glance

Rolling reachability per mirror, aggregated across every vantage point. Measured, not promised — a mirror that drops for an hour shows the dip rather than rounding it away.

99.6%
Mirror α — 90-day
Region A reference, strongest over obfs4
99.1%
Mirror β — 90-day
Region B reference, strongest over snowflake
99.0%
Mirror γ — 90-day
Region C reference, strongest over meek-azure

When a Mirror Reads Down

A red status is rarely the whole picture. Most of the time one mirror is unreachable from your network while the other two are fine. The full procedure lives in the access guide; here is the short version.

1
Check whether it is you or the mirror

Compare your symptom to this page. If the snapshot says all three are operational but you see a timeout, the failure is between you and Tor — not the service. Move to a different mirror before concluding anything is offline.

2
Switch to a sibling mirror

Each mirror sits in a different region on a different path. If α times out, try β or γ. The mirror status page shows which one currently reads cleanest from networks like yours.

3
Change transport, not just mirror

If every mirror times out, the block is at the transport layer. The matrix above shows snowflake and meek-azure outscoring obfs4 from censored regions — switch the transport and re-test before reporting an outage.

4
Confirm, then report

If two transports and all three mirrors fail from your location, that is worth telling us. Send your region and observed symptom so the next sweep can corroborate it — see the about page for the contact address.

Status Quick Answers

Is Torzon down right now?

This page is a periodic snapshot, not a live ping. At the timestamp shown above all three mirrors answered from every vantage point. If your own client fails while the snapshot is green, treat it as a local reachability problem first — switch mirror or transport before assuming a service outage.

Why can I reach Torzon from one country but not another?

Reachability is a property of the path, not just the endpoint. The same mirror that answers instantly from an open European network can time out from a censored one over obfs4 while staying reachable over snowflake. That is exactly what the region and transport matrix records.

What does “degraded” mean on a mirror?

Degraded means the mirror answered, but slowly, or it missed an occasional probe inside an otherwise clean window. It is a quality warning, not an outage. The methodology page lists the exact round-trip and miss thresholds that separate operational, degraded and down.

How do I know an address on this page is real?

Every v3 onion address is exactly 56 base32 characters before .onion, and the set we probe is cross-checked against a PGP-signed manifest. Verify both before pasting — the security page walks through the check, which matters most during an outage when fake links spread fastest.


What Torzon Status Is — and Is Not

Torzon Status is an independent reachability monitor for the Torzon onion service. It exists to answer a narrow, practical question: did the service’s mirrors respond, from where, and over which transport. We run probes on a fixed cadence from a small network of vantage points, record the outcome of each round, and publish the rolling result as the snapshot and history you see here. The signed mirror addresses are reproduced so a reader can confirm the endpoint a status refers to.

We are not the operator. We do not run the Torzon marketplace, hold escrow, vet vendors, or process a single transaction — those systems are outside the scope of a status monitor and we have no visibility into them. Counts of orders, vendors or revenue are not ours to publish and never appear here. What we publish is purely network telemetry: round-trip times, success and failure of probes, and the uptime windows derived from them.

If you maintain a status board, an OSINT timeline, or you simply need to know whether an unreachable mirror is a local block or a real outage, this is the reference. Start with the mirror status page for the full per-region breakdown, read how reachability is measured to understand the numbers, and keep the status log open for dated incident and recovery notices.

Mirror Status & Reachability History

Per-region, per-transport, per-mirror — every reading documented with a timestamp. Open the full status page for the complete reachability breakdown and the running incident history.

Open Mirror Status