DDoS defence architecture, queue and mirror scaling
What happens when Nexus is under coordinated network pressure, and why the queue is doing its job.
Coordinated network pressure against Tor hidden services is a recurring event, and Nexus Market has been hit several times across its operational history. This report walks through what happens architecturally when Nexus is under pressure and what the reader sees.
The anti-DDoS queue in detail
Every mirror sits behind a queue page. When a reader arrives on the login URL, they see the queue counter for 20 to 60 seconds under typical load. When network pressure spikes, the counter can extend to several minutes.
The queue is not just a delay. It is a rate-limiter that filters requests by holding them briefly and then admitting them serially to the captcha stage. This means a bot spinning up thousands of concurrent connections has to wait on each one, which converts a mass credential-stuffing attempt into a slow trickle that the storefront's login handler can absorb.
Multiple mirror addresses as a scaling mechanism
Under coordinated pressure, one address gets the brunt of the attack. Other mirrors on the rotation typically stay reachable because attackers concentrate resources on the primary. This is a soft form of load balancing: readers who cannot get through on the primary switch to backup addresses and complete their sessions there.
This is why the mirror rotation matters even for buyers who never touch a backup during normal times. The backups exist for the days when the primary is under load and their existence is the difference between a session that completes and a session that does not.
Observed patterns in past pressure events
Bureau editors have observed several coordinated DDoS windows against Nexus, spanning from a few hours to a few days. Common patterns:
Weekend timing. Attackers prefer weekends when operator response time is slower and reader activity is higher. The Bureau has observed disproportionate concentration in the Friday-to-Sunday window.
Queue extension. Peak queue times during the summer 2026 event reached about four minutes on the primary. Backups held at 60-90 seconds during the same window.
No captcha degradation. Under all observed pressure so far, the captcha continued to render correctly, the address remained embedded, and the login handler eventually succeeded. No reader has reported a completely inaccessible storefront across a pressure event lasting less than 48 hours.
What the reader should do under pressure
First: recognise you are under pressure rather than misconfigured. If the queue counter is decrementing, the storefront is working, it is just slow. Wait it out.
Second: try a different mirror if the primary is stalling for more than two minutes. Do not immediately assume the market is down.
Third: check for a signed operator statement. Under significant pressure the operator sometimes posts a note acknowledging the wave, which the Bureau will link from the security notes section.
Fourth: use New Identity in Tor Browser to get a different circuit. Sometimes the slowness is your Tor circuit, not the mirror.
What the reader should not do under pressure
Retype the address from memory. If the current session is under pressure, the phishing risk is elevated too, and typing from memory is more likely to land on a lookalike.
Trust a chat message claiming to be from Nexus support telling you where to log in instead. Nexus support does not run chat channels.
Skip the captcha check. Pressure is when the captcha check matters most, because attackers know readers are frustrated and looking for shortcuts.