Addresses / Pair 05 of 41
Your path through Tor, or the far end
Tor builds a path through relays it chooses on your behalf, and that path can come apart without anything else being wrong. When it does, you get the error you would get if nothing were answering at all.
What the screen actually gives you
The failure is on your half
The chain of relays your client built has degraded or dropped. Relays go offline, fill up, or simply stop responding in time. All of that happens on a schedule that has nothing to do with whatever you were trying to reach.
The failure is at the far end
Nothing is answering where you are pointing. Your path can be in perfect health and still hand you nothing, since a healthy path to an empty place delivers exactly as much as a broken one.
The error page is written by your own client. It is not sent by the far end, it is generated locally when something did not complete, and it is worded the same regardless of which half gave out. That single detail explains most of the confusion on this page.
Onion connections also have more moving parts than ordinary ones. There are introduction points and a rendezvous to arrange before any content moves, and a failure at any stage of that arrangement produces the same blank result as a failure at the end of it. Your screen collapses a fairly elaborate sequence into one flat outcome.
Your path and the far end
The relays in your circuit have no relationship with the service you are trying to reach. They were picked out of a directory by your client, minutes ago, on statistical grounds. They can be slow, they can drop, they can be swapped underneath you, and none of that says a word about the service at the other end.
The independence runs both ways, which is the part worth holding onto. A service can be perfectly fine while your path is rubbish, and your path can be excellent while the service is gone. Neither state tells you anything about the other, so an error that arrives through both of them tells you less than it feels like it should.
Changing one side only
Vary your half of the connection
Change your half and leave everything else alone. Build a fresh circuit, then load a different onion service you already know. If that one fails too, the fault sits on your side.
- Ask your client for a new circuit for this site, or restart it so it builds fresh paths from scratch.
- Try the address once more. One retry, not ten. Repeating over the same broken path proves nothing.
- Now load a completely unrelated onion service, one you had no trouble with recently.
- If the unrelated one also fails, your path or your client is the problem. If it loads, your half is working and the failure is at the far end.
- A client left running for days without a restart, quietly holding on to paths that stopped being good hours ago.
- A system clock that has drifted. Tor is fussy about time, and a wrong clock breaks connections that would otherwise be fine.
- A network that filters or throttles, which shows up as everything being slow rather than one thing being dead.
- Every onion service you try failing the same way inside the same minute. That pattern is about you, not about any of them.
Why the wrong reading sends you shopping
- If you treat a dying circuit as a site that is down
- You conclude the market is gone and go hunting for replacement addresses. That hunt is where manufactured strings wait, and you arrive at it rattled and in a hurry.
- If you treat a site that is down as a dying circuit
- You spend an hour rebuilding paths for a service that was never going to answer. You lose the hour and nothing else.
The expensive direction is not the one that looks urgent. Deciding your circuit is fine and the market is finished pushes you straight into collecting addresses from wherever you can find them, and that is the single activity this whole section exists to slow down. An hour of pointless retrying, by contrast, costs an hour.
Which is why the order matters. Rule out your own half first, always, since it is free and it is the more common answer. Only once your half is demonstrably working is it worth reading an outage against a market that has ended, and even then the honest answer is usually that you do not know yet.
After the error page
- If it is your circuit
- Get a fresh path, check your clock, and restart the client if it has been up for days. Then try again once. Do not collect any new addresses while you are in this state.
- If it is the far end
- Stop working on your own setup, since there is nothing there to fix. Keep the set you already hold and come back later rather than going looking for another one.
One thing this site will never do is tell you which of the two it was. Nothing here is monitored and no address printed here is checked, so the only report available is the one on your own screen. The questions page covers what that limit means in practice.
Questions readers send about this pair
Why does the same address work on one attempt and fail on the next?
Each attempt can use a different path through the network, and paths vary wildly in quality. Inconsistency across attempts points at your side of the connection rather than the far end.
Does a new identity fix this?
It gives you fresh circuits, which is the useful half. It does not fix a drifted clock, a filtered network, or a client that has been running for a week, so treat it as one move rather than the answer.
If everything onion fails but ordinary sites load, what does that mean?
It points firmly at your client or your network rather than at any particular service. Ordinary browsing does not use the same machinery, so it working tells you very little about whether Tor is healthy.