What Happens to a Tor Hidden Service During a Denial-of-Service Wave

What users see, what operators do, and why mirror rotation is the realistic answer rather than a heroic single-address defence.

If you spend time on Tor hidden services, you eventually have a session where the site you were using will not respond. The connection screen appears, the challenge page loops, the page never finishes. Most users assume the service is down. Most of the time, the service is fine. What is happening is the network path to that particular onion address is congested, and the service has either started routing traffic to another address or is asking you to do it yourself.

The shape of a Tor flood

Denial of service against a hidden service does not look like denial of service against a regular website. The attacker does not flood the server's IP directly, because the server's IP is not exposed. Instead, the attacker floods the rendezvous and introduction points that the service publishes in its descriptor. The Tor protocol forces every connection through those points, so flooding them at scale starves out legitimate attempts before they reach the server. The server's load is therefore not the bottleneck. The network path is.

What users see

Three symptoms cluster together. Connection screens that hang and never finish loading. Challenge pages (the small "verify you are not a bot" interstitials) that loop indefinitely. Pages that load partially and then time out on the next click. None of these is a server-side failure; all of them are network-side congestion.

The instinctive user response is to keep retrying the same address. That makes the problem slightly worse, because each retry queues another connection attempt against the already-stressed rendezvous points. The right response is the opposite: switch to a different address in the published mirror set.

Why mirror rotation is the practical defence

A hidden service that publishes only one onion address has no graceful way to handle a sustained flood. It can ride it out, or rotate to a fresh address and hope users find out. Neither is good. A service that publishes a set of addresses has an answer that works in real time. The addresses point to the same back end through different chains of relays. When one chain is under load, the others are usually clean. Users switch and continue. The site behind each address is the same; only the network path changed.

What operators do on the server side

During a sustained flood, the operator does a small set of things in parallel. They rotate fresh rendezvous points into the descriptor. They spin up additional onion services on new keypairs and add them to the published mirror set if the flood persists. They check that the back end is fine (it almost always is). And they update the published directory so users have current addresses to copy. The visible part of all this, from a user's perspective, is the directory update.

What you can do as a user

Three habits absorb the entire experience cleanly. Bookmark the directory, not the onion. The directory tracks rotation. Switch addresses, do not retry. If a connection screen loops, open the directory, copy the next address, and try that one. Use New Tor Circuit for this Site. Tor Browser's menu has this option. It rebuilds the network path without changing the address.