Why mirrors slow down instead of failing outright
Users report outages far more often than outages happen. What they are usually seeing is congestion, which behaves differently, resolves differently, and calls for a different response. This chapter is about telling the two apart and understanding why a hidden service tends to get slow rather than simply stop.
#Where the time actually goes
A page load over Tor is not one connection, it is a chain. Your client builds a circuit through three relays, the service has its own circuit to a meeting point, and the two halves join in the middle. Six hops of latency before the request even reaches the application, every hop on volunteer hardware with wildly varying capacity and load.
That structure has an important consequence. There is no single bottleneck that can be saturated cleanly. When load rises, some circuits get slow, some fail to build, some fail halfway and get retried. The aggregate effect is a gradual slide from fast to sluggish to occasionally timing out, and only at the far end does it look like the service is down. Compare this to a clearnet server hitting its connection limit, which produces a crisp error at a well defined threshold.
| Circuit build | Three hops chosen and negotiated. Usually a second or two, occasionally much longer if a chosen relay is overloaded or dropping out. |
|---|---|
| Descriptor fetch | Your client asks the directory system where the service is currently reachable. Cached for a while, so this cost is paid on the first visit rather than every page. |
| Rendezvous | Both sides meet at an agreed relay. This is where a bad pick shows up as a connection that hangs rather than one that fails. |
| The application itself | Rendering the page, running the query, checking the session. Usually the smallest slice of the total, which is why blaming the market for slowness is often misplaced. |
Notice that three of the four items above are network conditions rather than anything the service controls. A mirror can be running perfectly and still feel unusable to you because of where your circuit happened to land.
#Why rate limits exist and what they feel like
A hidden service cannot see who is connecting. There is no source address to block, no geography to filter on, no reputation to check. Every connection arrives through a rendezvous point looking exactly like every other connection. That makes the usual toolkit for handling abuse unavailable.
What is left is limiting behaviour rather than identity. Requests per session, how fast a session can walk through pages, how many login attempts a connection gets, how expensive an operation is allowed to be. These limits are not there to inconvenience anyone. They are the only defence available against someone pointing an automated load at the address, and without them a single bored person with a script could make an address unusable for everyone.
#How to read what you are seeing
The pattern of the slowness tells you where the problem is, which tells you what to do.
| Everything slow, all addresses | Either broad network conditions or something local to you. Check whether other onion services are also slow. If they are, wait it out. Nothing address specific will help. |
|---|---|
| One address slow, others fine | Congestion or flooding on that address specifically. Switch. This is exactly the case the multiple address design exists for. |
| Fast at first, then slower | You are probably hitting a rate limiter. Slow down, stop reloading, give it a minute. |
| Hangs forever, no error | A dead circuit. Get a new one rather than waiting. In Tor Browser this is the new circuit option in the site information panel. |
| Loads but pieces are missing | Partial fetch under congestion. Usually harmless and resolves on a reload, but if a page renders wrong in a way that changes what you are being asked to do, stop and verify where you are before continuing. |
#What actually helps
Most advice circulating about speeding up Tor is either useless or actively harmful. The things that genuinely help are few.
- Build a new circuit before doing anything else. Cheap, fast, and fixes a large share of what looks like an outage.
- Try a different address. Second cheapest, and it separates address problems from network problems in one step.
- Stop reloading. Every reload under congestion adds load and moves you closer to a limiter.
- Wait during peak hours. Load is not uniform across the day. Something unusable at one hour is often fine a few hours later.
- Do not change the security level to make things faster. Lowering it does not meaningfully help speed and it costs you the protections described in the security chapter. This trade is always bad.
- Do not install anything that promises faster Tor. There is no such thing, and the category is entirely made of malware and fingerprinting.
#When slowness is worth worrying about
Almost never on its own. Congestion is normal, boring, and self resolving. The cases that deserve attention are when slowness comes with something else attached. A login page that looks slightly different from what you remember. A signature block that is missing or stale. A prompt for something you were not asked for before. An address that had gone quiet for days and is now answering again.
In those cases the slowness is not the point, it is the noise around the actual signal. Slow and normal is fine. Slow and different is worth stopping over. The next chapter covers what a real outage looks like from both sides, which is the other half of learning not to panic at the wrong things.