VPN Keeps Disconnecting: Test the Radio Before the Server

A VPN disconnect can begin long before any traffic reaches the server. Wi-Fi loss, a handoff from Wi-Fi to cellular, congestion on the local access point, and a phone that sleeps can all interrupt the outer path while the tunnel software reports a clean failure. Walk outward from the device: the link first, then the client's own events, then a controlled comparison, and only then the server. That order keeps you from changing exit nodes for a problem that lives in the room.

Watch the link, not the signal icon

Look for link transitions rather than bars. A device can show a strong signal while the access point is saturated, while a roaming handoff is in progress, or while a power-saving policy parks the radio during screen-off.

Record the interface state, the current gateway, and the time of each change. Then check whether the disconnect lines up with the transition. A drop that happens every time the phone moves between rooms is a link problem until proven otherwise, no matter which server the app displays.

Read the client's own reconnect events

Most clients log a reason for the disconnect and a timestamp for the next attempt. A tunnel that renegotiates within seconds and then works is a different event from one that stays down until you toggle it manually.

Repeated short reconnects point at the outer path, because the client keeps reaching the server and losing the session. A tunnel that stays down points at authentication, an endpoint change, or a policy, because the client is not getting far enough to lose anything. Read the two patterns separately before you touch the configuration.

Compare a second endpoint with care

A second endpoint is a useful comparison, and it is not a controlled experiment by itself. It changes the route, the infrastructure, and often the country, so a difference between two endpoints does not prove that the first server is faulty.

Keep the device, the access network, and the workload fixed, and note what else changed when you switch. If both endpoints fail at the same time in the same place, the local path is the common factor. If only one fails, the server or the route to it becomes the lead. Write the confounders down so the conclusion does not outrun the evidence.

Correlate with the server you run

If you administer the endpoint, match the attempt time against listener and association records. Several unrelated clients failing at the same gateway is different evidence from one phone dropping whenever it moves.

One peer response does not establish continuous application health. After recovery, test the resource you actually need, because a successful handshake and a reachable server can coexist with a broken application path.

Write the report that narrows it down

Separate four statements: local link loss, outer reachability, tunnel negotiation, and the application's own state. Each one has its own evidence, and a report that keeps them distinct tells the next person where to look.

Note the limitations of the comparison as well. If policy prevented a direct-path test, say so instead of presenting the endpoint comparison as proof. The country label in the app does not identify the complete route, and a server that is geographically close can still be reached through a congested path.

The WireGuard project's known-limitations page is a useful reminder that a protocol can be correct and still leave link behavior to the operating system. Finish by repeating the same test after the next disconnect, since a single event is a data point and a pattern is a diagnosis.