Some route, not a particular route
The condition is about the network you happen to be attached to at this moment. The wifi in a building. The socket at a desk. The connection a phone is sharing. It says that this network lets the client reach the wider network somehow. The word carrying the weight is somehow: the condition is satisfied by the existence of some route, not by any particular one, whether that is a direct connection or a bridge.
The two get confused constantly. A reader whose direct connection is blocked concludes the network is unusable. What is true is narrower. One route is unavailable, and the card asks about the set of routes. In the other direction, a reader running a bridge has not satisfied some separate condition. They have satisfied this one by another means.
Networks that refuse the obvious route are not exotic. Managed campus and school networks. Hotel and conference wifi. Workplace networks with an outbound policy. Public hotspots that pass only ordinary web traffic once a portal is satisfied. Some national networks. The mechanisms differ, and from inside they present identically: the client starts, tries to bootstrap, and stalls.
The client has to be a known quantity first
The browser came from the Tor Project is the only card under this one, and it supplies interpretability. The condition is diagnosed by comparison: the same client, two networks, two outcomes. A comparison needs one term held fixed. If the client is an unknown build, moving between networks changes one variable while another was already loose.
There is a plainer version of the point. A build that is not the published build can report a failure to connect that has nothing to do with where you are sitting, and a reader who trusts that report hunts for a network problem that does not exist.
Notice what is not directly upstream. Nothing about who administers the machine, and nothing about the clock, feeds this card along an edge of its own. It is a shallow card, close to the surface of the graph, which is a different thing from an unimportant one. Roots and endings shows why depth is a poor guide to weight.
The one edge out, and why it carries the stage
Exactly one card depends on this: The client can build a circuit at all. One downstream edge sounds like a small blast radius. It is the opposite, because that card is the neck of the map, and everything the site describes after stage B passes through it by inheritance.
The mechanism is unremarkable. Circuit construction begins as ordinary outbound traffic. The client has to reach a first hop and hold that connection open. If the local network will not carry it, no amount of correctness anywhere else produces a circuit. The clock can be exact, the build genuine, the address right to the character, and the client still sits at a figure that does not move.
| Cannot hold | The reason it cannot |
|---|---|
| The client can build a circuit at all | A network that will not carry outbound traffic prevents the first hop, and every later stage of the connection travels over that same hop. |
| You can tell a mirror from a copy of the market | Inherited. With no circuit every candidate string fails identically, so the distinction has nothing to work from. |
| You can log in a second time | Inherited further down. A second session needs the route to exist on the second occasion, which is a property of wherever you are sitting then. |
That last row is the part people miss. This condition is not settled once. It is a fact about a place, and it expires when you move. Satisfying it at home says nothing about the same client in a hotel next week, and a chain that was true in one building can be false in another with nothing on the machine having changed.
How a filtered network presents itself
The client starts and reports progress. The progress reaches some figure and stops there. Nothing errors in a way that names a cause. Eventually the attempt gives up, or the reader closes the window first, which is more common.
What follows is predictable in order. The browser gets reinstalled, which changes nothing, because the build was never the problem. Then the address falls under suspicion, despite not having been used for anything. Then the reader goes looking for a different address while irritated, which is where the checks in You hold the address as characters, not as a click start getting dropped.
The error points at the wrong place because the client can only describe its own state. It can say it did not connect. It cannot say that something between it and the first hop declined to carry the traffic, because it never received anything that would tell it so. Absence of a reply and refusal of a reply look the same from that end.
The comparison that isolates the network
Take the same client, unchanged, onto a genuinely different network and watch whether the behaviour changes. That is the whole check, and it is worth doing first because it is the cheapest instrument available.
- A pass
- The client bootstraps here. The condition is true on this network, for now, which is the only thing it ever claims.
- A fail that localises
- It fails here and works there. The machine and the build are fine and the network you were on is filtering. That is a diagnosis rather than a defeat.
- A fail that does not localise
- It fails on both. The cause is upstream of this card, most likely the clock or the build, and this is not the card to work on.
One caution about the instrument. The two networks have to be genuinely different. A phone sharing a connection while attached to the same building wifi is the same network wearing a hat.
Where this card stops
This is not instructions for getting around a filter, and it deliberately does not describe how one might be configured or defeated. It states a dependency and leaves it there. The adjacent thing it gets confused with is a broken client, which is the conclusion most people reach and the one the evidence does not support.