WireGuard Fails After Idle: Test the Directions First

Four questions come before any setting change: does the same resource work while the client is active, how long was the idle period, did the device sleep or change networks, and does the failure appear only for traffic initiated from the far side. The answers separate an expired NAT mapping from a sleeping radio and from a stale application. They also tell you whether a keepalive is even relevant. Start with the direction, because it costs one command and eliminates half the possible causes.

Which Direction Fails?

A new outbound request from the client and traffic arriving toward it after a quiet period exercise stateful equipment differently. Outbound packets rebuild a mapping as they leave, while inbound packets need the old mapping to have survived. That asymmetry is the whole test. If the client can reach out but nothing reaches in, the mapping has probably expired, and if neither works the tunnel or the client's network access is gone.

Note how long the quiet period lasted, and whether the device slept or roamed to a different network in the meantime. Those two facts change the diagnosis before any setting does.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Run those three before and after the quiet period, because each answers a different part of the question. A handshake timestamp that has not moved says the peers stopped talking, while an endpoint that changed says the mapping moved rather than died. The transfer counters show whether anything arrived at all, which is the difference between a stale mapping and a silent application. Write the numbers down at both points, since the comparison is the evidence.

Sleep, Radio and Application State

On a phone or laptop, a sleeping device may have lost network access entirely, and a keepalive cannot restore a radio that is off or complete a captive portal that has not been satisfied. Mobile platforms suspend background work as a matter of policy, so whether periodic traffic continues depends on the platform and on what the app negotiated with it. A cached connection is the third case and the most misleading one, because the tunnel returning is not the same as the application reconnecting to it.

Reopen the application after the idle period instead of trusting the tab that stayed open. If a fresh request succeeds where the old session failed, the tunnel was never the problem.

What a Keepalive Actually Does

PersistentKeepalive sends a periodic authenticated empty packet to a peer, which is enough to keep a NAT mapping alive between peers and to let the peer's endpoint stay current, as the WireGuard quick start describes. It does not repair a sleeping radio, a lost route or an application that never retries. Choose the interval through the supported client settings, and do not enable an aggressive value everywhere just because a status display goes quiet.

Most idle periods are not failures. A tunnel that reconnects after five minutes of silence is behaving correctly, and the problem is only the case where something was supposed to arrive from the far side.

Wait Out the Interval That Used to Fail

Make one supported change, then let the same idle period elapse before retesting that resource. Waiting is part of the test rather than a formality. Immediate success after a reconnect says nothing about a long-idle symptom, because reconnecting is exactly the event that resets the state. If the problem also appears during active use, go back to handshake and data-path checks rather than adding more periodic traffic.

Keep one change per test and write down the idle duration used. Without that, every later comparison drifts and nobody can tell which change mattered. Record the four facts together: direction, duration, sleep state and application behaviour.