Telling a headless Pi boot failure from a network failure

The card comes out of the enclosure before anyone has asked which of the four things actually failed. The Pi stopped answering after a VPN or network change, and a reflash feels like the only move left. It rarely is: the lease can move, sshd can stop, or the reply can leave by a route you cannot follow, and each of those has its own fix. The useful work is separating what you observed from what you assumed.

Four results, not one

Booted, addressed, listening and reachable are four separate outcomes, and any one of them can fail while the others still hold. A board can boot perfectly and never appear on the network. It can appear with an address nobody expected, or hold the right address with SSH disabled. It can get all three right and still be unreachable because replies leave through the wrong gateway.

The reflash instinct collapses those four into one question, which is why it so often produces a working Pi and no explanation of what actually broke.

Where the evidence actually ends

Write down three things before touching anything: the address and uplink that last worked, what was changed, and the first operation that stopped working. A hostname that no longer resolves, an SSH connection that times out, and a TCP connection that is refused are three different observations pointing at three different layers. A failed ping tests reachability of one address and fails for every reason above, including a board that never started. That is why it cannot stand in for a boot test.

If a local display or a recovery console is available, use it, because the question it answers is whether the machine reaches its operating system. That is the only question a reflash would resolve. If the board fails before that stage, follow the platform's recovery documentation instead of inferring a hardware fault from an absent screenshot, and stop pulling power as a diagnostic.

Rebuild the access path on a running system

Find the current uplink and address through whatever owns the network configuration, then compare that with the router's present client list and with the address the SSH client used. A saved hostname or an old DHCP lease can point at yesterday's destination for weeks. Then confirm that sshd is enabled, listening on an address that exists, and permitted from the administration network. Raspberry Pi's SSH guidance treats enabling the server and connecting to the current address as two separate steps, and a fresh Raspberry Pi OS install leaves SSH off by default.

A hostname can be re-pointed at another machine, and a replacement image arrives with its own key, so check the fingerprint through a path you already trust instead of clicking past the warning. Deleting the warning is how a temporary address change becomes a permanent trust problem. If the key prompt is the only symptom, you are looking at an identity question rather than a reachability one.

Trace the reply route before blaming the board

A VPN can change route selection while the physical link stays associated, which is exactly the case where the Pi is up, listening and still unreachable. The request arrives and the reply leaves through a tunnel that the administrator's client cannot traverse. A local console and a listening socket prove nothing about the return path, so confirm which interface carries the reply and which gateway it selects. Compare that with the network the administrator is actually on, because this failure gets misdiagnosed as a dead board more than any other.

The cheapest check is to watch the reply leave: on the Pi, ask which route would carry the administrator's address and compare it with the interface the request arrived on. A mismatch there explains the whole symptom and costs one command.

One boundary at a time, and when a reflash is right

Correct the configuration through its owner after preserving the current state. Replacing the network manager, flushing the firewall and guessing a static address are three changes that make the next observation useless. If the evidence points at the VPN's route or filtering, fall back to that client's own stop or repair routine, working inside the agreed recovery plan; a controlled comparison is a different thing from switching off protection on a host you have not explained.

Reflashing is a deliberate recovery choice, taken once you understand the data, the identity and the stage that failed. It is not what a missing login should trigger by default.

Keep the configuration record somewhere readable without the Pi, and a way back in that does not run through the tunnel you are about to change. Then work in order: confirm the stage from a local console, find the current address, check the listener and its policy, trace the reply route, and change one thing. If the board never reached the operating system, the recovery documentation is the next step rather than the network.