The public VPN list says online; your client says no

You open the directory, sort by speed, pick a node marked online, and the client gives up before it finishes connecting. The list was not lying, exactly. It reported the result of somebody else's probe, from some other network, at some earlier moment, against a service that a volunteer can switch off at any time. Understanding that gap turns a frustrating hunt into a short sequence of checks you can run on any candidate.

What the list actually measured

A public directory keeps fields such as a last-checked time, an observed round-trip figure, a session count and sometimes a protocol list. Each of those describes the last successful observation from the project's own vantage point, not the state of the node when your packet arrives.

The freshness matters more than the number. A node checked four minutes ago and a node checked four hours ago can show the same green marker, and only one of them still resembles the recorded state. Look for the timestamp, not the colour.

Volunteer operation adds a second source of change that no monitor can fix. The operator may be rebooting a laptop, running out of bandwidth, changing an ISP, or simply closing the lid. A list entry is a candidate, and treating it as a service level agreement is a category error.

Watch the client's stages, not the spinner

Every VPN client passes through the same broad sequence: resolve the name, open a transport connection, negotiate security, authenticate, then configure the tunnel and pass data. A failure at each stage leaves different evidence, and the spinner shows none of it.

Start with name resolution. If the hostname does not resolve, nothing about the node's availability has been tested, because the connection never left your machine. Next, the transport: a refused or timed-out TCP or UDP exchange tells you the endpoint is not answering at that port, which is a real finding about the node. Then negotiation and authentication, where a wrong certificate, an expired profile or a mismatched cipher fails while the node is perfectly healthy. Only after the tunnel is configured can a routing or DNS fault explain the last step.

Read the client log at the highest verbosity that still fits on screen, and note the last line that succeeded. That line is where the diagnosis starts, and it is usually more informative than anything the directory displays.

One variable per attempt

Compare candidates with the same client, the same access network and the same profile format, changing only the endpoint. Otherwise a failure could be yours and you will attribute it to the node.

Two attempts are enough to establish a pattern, and a third confirms it. If node A fails at the transport stage and node B fails at authentication, you have two unrelated problems rather than one stale list.

When every node fails the same way

A universal failure at the first stage points at your side: a resolver that cannot answer, a local firewall that blocks the protocol, or a network that permits only web traffic. The directory cannot report that, because its probes do not run from your seat.

Check the shaped-network case deliberately. Some access networks allow HTTPS to the web and drop other protocols, which makes every candidate look dead while the list is accurate. Comparing a browser page load with a raw connection attempt separates those two situations in under a minute.

Read the failure at the stage it happened

Reproduce the attempt from a terminal so the stages are visible. The three commands below resolve the name, test whether the port answers, and print the negotiation lines from an OpenVPN profile:

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

If the port answers and the negotiation line reports a certificate problem, the node is up and your profile is stale. If the port does not answer at all, the entry is a candidate that failed, and moving to the next one is the correct response rather than debugging your client. Note the stage in a short line, and the next attempt starts from knowledge instead of hope.