Each mirror is its own key

People treat a mirror list like a list of doors into one building. Closer to the truth, it is a list of buildings that happen to contain the same thing.

Why this is structural

It follows directly from the address being the key. If the name is the key, then two different names are two different keys, with no room for one to be a nickname for the other. There is no CNAME in onion addressing and nothing that plays the role of one.

The only thing joining them is that the same operator published all three and points them at the same application. That connection lives entirely outside the protocol.

The practical consequences

• A correct copy of one address says nothing about whether your copy of another is correct.
• One address being unreachable says nothing about the other two.
• Availability is per address, because the descriptors that make a service findable are published per key.
• A wrong copy of one is not fixed by the other two being right.

The second point is the one worth using. Trying a second address is a cheap experiment precisely because the two are independent. If both fail identically, the shared factor is you or the network. The slow page entry uses this.

What people get wrong

The first mistake is ranking them. Primary, backup, fallback. Nothing in the addresses supports that ordering and this site refuses to imply one. Whoever labels an awazon working link as the main one is adding information from outside.

The second is assuming a shared fate. People see one address fail and conclude the market is gone. Three keys can have three different days. Descriptor publication, introduction points and the load on each service are separate things.

A third mistake, quieter

Assuming that because the three addresses show the same site, an unfamiliar fourth address showing the same site is also legitimate. Any site can be copied. Serving identical content is the easiest part of imitation, and it proves nothing about which key you reached.

Why operators run more than one

Reasons vary and none of them are visible from outside. Spreading load across separate services. Keeping one address in reserve. Limiting the damage when a single service attracts attention. All of these are guesses about a decision made by people we have never spoken to.

What is not a guess is the effect on you. More addresses means more chances that at least one is reachable from wherever you are, and more strings to keep correct copies of. The second half of that is the part people skip.

What would move this

Nothing in the protocol. There is no aliasing mechanism to introduce halfway. The only realistic change is at the application layer, where an operator might make one address issue a redirect to another. That would create a real relationship between them, and it would be a choice anybody could reverse, so the statement would drop into DEPENDS with the condition being the operator's current configuration.

• The three addresses
• Whether one is better than another
• What happens when one is retired