Nexus Link Desk Provenance, not popularity
Link Desk / How a link ages

Current Nexus addresses

Three nodes, one platform behind them. Copy, never retype, and verify the signature when you arrive.

Node 01 nexusb2l7fmqnefwphyy7m5zjhlkytlbo7qbb5lu5dlczr3azgii2gyd.onion
Node 02 nexusma2iqgauqqvjcgds4ckv5xbf272tkfagq4epojjhsgleqpwxiqd.onion
Node 03 nexusabcd6tyfhdwilyitaqiri6tisj2v2hueyjuj6qkvd6azvi5tuqd.onion

An address that loads is not an address that is genuine. The check that settles it takes under a minute.

How a link goes stale

Addresses leave the roster for ordinary reasons, and the leaving is invisible. For the first few days it is identical to a bad afternoon.

Why addresses get retired

Usually accumulated attention rather than anything going wrong. An address public for a couple of years sits in every scraped list, archived post and abandoned directory, and a growing share of what reaches it is automated scanning, stale bookmarks and whatever flooding is currently aimed at it. Eventually the noise outweighs the value of familiarity and a fresh address serves people better.

Less often the key material needs rolling, or the address was published somewhere the operators later decided against. From outside every reason looks the same. One address stops answering permanently while the others carry on normally.

Telling it apart

What you seeWhat it probably isWhat to do
One address down, others fine, back within hoursOrdinary outage or a bad circuitUse another address, forget about it
One address down for days, others fineRetiredDelete it from wherever you saved it
All addresses down, other onion services fineSomething shared, usually shortWait
All addresses down, other onions also failingTor network conditionsWait, nothing address specific helps
A long dead address answering againSomebody else is running itClose the tab
The discriminatorDuration is the only reliable discriminator and almost nobody waits long enough. Hours mean nothing. Days mean something.

Why the first hours mislead so badly

Because the failure modes of a healthy onion are numerous and all of them look like death. A descriptor that failed to publish, an introduction point dropping out of consensus, a slow relay in the middle of your circuit, congestion, a flood aimed at that address. Every one produces a page that will not load, and every one resolves on its own.

Tor deliberately tells clients very little about why something failed, because detailed failure information is useful to attackers. The cost of that design lands here, as an ordinary user unable to distinguish five very different situations. Building a new circuit and trying another address separates most of them in under a minute, and it is the step people skip in favour of reloading.

The thirty minute problem

There is a reliable window, roughly half an hour to a few hours into any outage, when external certainty peaks. Somebody has asserted the market is gone. Replacement addresses are circulating. Confidence is at its highest exactly when the actual problem is usually closest to resolved.

Anyone acting during that window is acting on the worst available information at the moment it feels most reliable, and the people seeding addresses into it know the timing precisely. This is covered properly in handling an outage because it is where most real harm in this whole subject occurs.

Keeping your own copies fresh

The maintenance is small and the failure is expensive, which is a good trade to make on purpose rather than by accident. Compare what you have saved against the roster every few weeks. Not because addresses change often, but because noticing a change late is what leads you to the next stage, which is an address in somebody else's hands.