1The Core Problem: Availability Without a Fixed Address
An onion service like Dread does not live at one fixed address the way a regular website lives at a domain name. Instead, it exists as a set of rotating entry points. This happens because onion addresses can go dark, get overloaded, or become untrusted — and there is no central phone book to tell you which one is real right now.
Three pressures that make a fixed address impossible
Too much traffic
A single onion address can be hammered by legitimate users, bots, or crawlers until connection queues stretch for minutes. Rotation spreads the load.
Network changes
Operators may take a server offline, move infrastructure, or lose access to a private key. A permanent address would point to a dead end.
Impersonation risk
When one address circulates for too long, attackers build lookalike phishing pages around it. Rotating entry points shrinks the window where a copied link stays believable.
In practice, “reachable without a central server” means no single machine decides who gets in. The availability of the forum is not tied to one host, one IP, or one address string. A reader trying to reach Dread is really asking: which currently live address belongs to the real service, right now?
Think of it like a restaurant that changes its door code every few weeks, but still serves the same room behind the door. The building is the same, the people inside are the same — only the way in changes. That is the problem mirror rotation solves: not identity, but which entrance is open today.
Without a central server holding a master directory, availability becomes a negotiation between old links, new mirrors, and what the community treats as current. The next sections cover who actually decides which mirror is current and what keeps a mirror alive over time.
Contents
- The Core Problem: Availability Without a Fixed Address
- How Rotation Works in Practice: Who Decides Which Mirror Is Current
- What Keeps a Mirror Alive: The Economic and Infrastructure Layer
- Failure Modes: When Rotation Breaks and How Availability Recovers
- Practical Takeaways: Reading the Infrastructure to Judge Reachability
- FAQ
2How Rotation Works in Practice: Who Decides Which Mirror Is Current
A common misunderstanding is that somebody “runs” the Dread mirrors like a dispatcher with a master list. In practice, nobody decides the lineup from one chair. The rotation emerges from several groups that do not need to trust one another completely: long-running community members, technically capable operators, and the forum’s own landing rules. Each mirror can be launched by a different person, in a different jurisdiction, with different hosting costs. What makes a mirror “current” is not a single announcement, but a slow process of vouching, uptime checks, and repeated verification against known keys. A mirror that appears fresh but cannot prove continuity with earlier signed snapshots is treated as untrusted, even if it loads correctly.
Trust is built in layers, not through a central registrar
- Outer layer — any onion address that spreads through social channels, links, or search engine caches and is only a candidate until matched against the rest
- Middle layer — the set of mirrors that survive for several weeks without producing conflicting content, signed messages, or mismatched forum state
- Inner layer — the small, stable set of addresses that consistently show the same canonical forum data and are repeatedly vouched for by independent long-time users
The “who decides” question has a boring answer: observers distributed across the community decide by comparing. A mirror that is live for one person does not automatically become canonical. Instead, different users check whether the same threads, the same moderation markers, and the same signed identities appear across independent routes. If one mirror shows a thread as locked and another shows it open, both cannot be trusted equally. Over time, the set of consistent mirrors gains weight, while inconsistent candidates fall out of rotation.
This also prevents a single operator from controlling all routes. Even if one person launches five mirrors, they cannot make those mirrors agree with the wider network unless they also control the keys and content that others already verify. A cartel of mirrors that diverges from the rest simply becomes a suspicious island. The rotation therefore works less like a switchboard and more like mutual watching: each route is constantly tested against the others, and only the ones that keep matching survive as “current.”
3What Keeps a Mirror Alive: The Economic and Infrastructure Layer
Running a mirror is less like maintaining a website and more like keeping a safe house lit. There is no single owner flipping a switch; there are a handful of people, each paying for a slice of infrastructure with different resources. One operator might rent a small VPS with Bitcoin, another might run a box from a spare room, and a third could pay for storage on a network that barely asks questions. None of them collect a salary or sit in the same office.
| Layer | Centralized model | Onion mirror model |
|---|---|---|
| Funding | one budget, one invoice | many small, independent payments ;; Operator identity |
Why anyone keeps paying for it
The motivation is rarely profit. Some operators value the forum’s role as a discussion space; others have a personal stake in keeping a particular community reachable. There is also a reputation incentive: being known as the person who held a mirror through a rough month brings a kind of quiet status. In practice, it works like a volunteer fire brigade — people contribute because the alternative is losing something they use themselves.
Think of each mirror as a rented room with its own lease, landlord, and meter. If one room gets evicted, the others are unaffected.
What the money actually buys
Monthly costs go toward bandwidth, disk space, and occasionally a domain if clearnet bridges are involved. The software itself is often just a configured onion service with a cached copy of the forum database. There is no content delivery network, no legal team, and no uptime dashboard. That is why some mirrors appear faster than others: the operator simply bought more bandwidth or placed the server closer to a major Tor node.
- Cheap VPS
- Dedicated hardware
- Donated resources
A mirror that stays online for months can still disappear overnight if the operator loses access to the payment account or the host seizes the server. Never treat a mirror as permanent.
4Failure Modes: When Rotation Breaks and How Availability Recovers
“What actually happens when a mirror dies?” The short answer: nothing global. A mirror is just one doorway. When it stops responding, the directory that lists current doorways simply stops mentioning it after others fail to confirm it. There is no “server down” moment for the whole forum — only a doorway that quietly drops out of rotation.
The two most common failure shapes
Mirror disappears
A host drops offline or stops answering. The mirror link still circulates in old posts, but it now leads nowhere.
Mirror is impersonated
A fake mirror with a similar address circulates while the real one is slow or unreachable. Visitors type the wrong doorway and land on a copy.
Mirror falls out of sync
The mirror still loads, but content is stale — threads, messages, or captchas behave oddly because the mirror no longer reflects the current state.
None of these failures require a central office to fix. The system self-corrects through redundancy and repetition: other mirrors keep answering, and the current-mirror list shifts only when multiple independent observers report the same result.
A mirror that loads but asks you to re-enter your login or shows a slightly different layout is not the “new design.” Treat unexpected prompts on a known mirror as a sign that you are on a copy, not on the real doorway.
Recovery works because availability does not depend on any single host. If a mirror falls, others keep the forum reachable. The process is slow by design — a quick switch would be easy to abuse for steering people toward a fake link.
If one mirror fails, do not panic and do not rush to try random links from search results. Wait, use a second known-good doorway, and let the slower consensus catch up with what you already suspect.
5Practical Takeaways: Reading the Infrastructure to Judge Reachability
Think of reachability not as a switch that is either on or off, but as a stack of layers that must all agree at the same moment. When a connection attempt fails, the useful question is rarely “is Dread down?” and almost always “which layer stopped cooperating?” That mental shift turns confusion into a quick diagnostic habit.
What a failed connection is actually telling you
- You type an address Tor starts hunting for an introduction point that belongs to that exact onion name
- Tor receives a descriptor or gets nothingIf a mirror has rotated away, the old name no longer publishes a descriptor, so the lookup ends in silence
- Your client shows an error The message may say “not found,” “timed out,” or “connection refused,” but the underlying event is the same: that name is not currently announcing itself
- You try a different mirrorA fresh name may resolve in seconds, proving the network path and your Tor setup were never the issue
If one mirror fails instantly while another loads normally, you are not looking at an outage; you are looking at rotation.
Reading mirror announcements without trusting them blindly
Any announcement should be treated as a claim about infrastructure, not as proof. The useful habit is to compare three things at once: where the announcement appears, how many independent places repeat the same name, and whether the name behaves like a live service when you actually try it. A name posted in one thread, repeated nowhere else, and replaced by a new name a day later is likely part of a rotation cycle. A name that has stayed stable for weeks but suddenly stops working is more likely a mirror that was retired or blocked.
- Announcement source
- Repetition
- Behavior
Rotation means names appear, disappear, and reappear in patterns. A single error message tells you almost nothing until you see the pattern.
The difference between “down for me” and “down for everyone”
Your client can fail while the service is perfectly reachable from elsewhere. The most common causes are a stale link, an overloaded introduction point, or a local Tor circuit that never built properly. A mirror may also be intentionally unreachable from certain exit points or during certain periods. Before concluding that the infrastructure itself collapsed, change one variable: try a different mirror, or force Tor to build a new circuit. If a second mirror works, the first name was simply no longer the current one.
Do not retype a failing onion address into multiple browser windows in quick succession. That can hammer an introduction point and make a temporary overload worse — for you and for everyone using that mirror.
What “reachable” should mean to you long-term
Availability is a property of the system, not of any single address. If you mentally attach trust to one specific onion name, every rotation will feel like a break. Instead, treat names as disposable and treat the announcement pattern as the stable object. A healthy pattern shows: short-lived mirrors, visible rotation, repeated verification across channels, and quiet periods that resolve without drama. A broken pattern shows: one name promoted everywhere, no visible replacement, and silence about why a mirror vanished.
- Rotation
- the deliberate replacement of mirror addresses on a schedule or in response to pressure
- Reachability
- the chance that at least one current mirror is available to an average user at a given moment
- Announcement pattern
- the observable way new mirror names enter public discussion and how old ones leave it
FAQ
Why doesn’t Dread just use a single permanent onion address instead of rotating mirrors?
A fixed address would become a single point of failure and an easier target for sustained denial-of-service or takedown pressure. Rotation spreads the load and reduces the window during which any one location can be singled out, while still keeping the service reachable to users who follow the current pointer.
How do users know which mirror is the real current one if the list keeps changing?
The current mirror is established through an agreed process, not by users guessing or trusting random links. Users should rely only on the same trusted channels where Dread already publishes reachability information, and should treat any mirror list seen elsewhere as potentially hostile.
Does a mirror go down if its operator stops paying for hosting or loses interest?
Reachability does not depend on any single operator’s continued goodwill. The infrastructure layer is designed so that no individual provider or sponsor is indispensable, and loss of one mirror is absorbed by the remaining ones without requiring a central authority to intervene.
What actually happens if rotation breaks and no current mirror is visible for a while?
Availability can degrade temporarily, but the system is built to recover rather than collapse permanently. Users may see a gap, yet the underlying infrastructure can re-establish a current pointer once the failure is isolated or a new mirror takes over, so prolonged unavailability is not the default outcome.