Intermittent VPN Drops: What to Capture Each Time
An intermittent drop is a data problem before it is a config problem. Capture five fields per incident, then compare stages before changing settings.
Intermittent drops are a data collection problem before they are a configuration problem. Capture the same fields on every occurrence, or the incidents cannot be compared. Changing three settings after each event destroys the only evidence you had.
The procedure below takes about two minutes per incident and produces one line per event. It assumes read-only access on a device you administer.
Fix the fields before the first failure
Draw up the field list before anything breaks, because a template invented mid-incident always misses a column. Five fields are enough to start: local time with its offset, the trigger, the stage that broke, the exact error text, and whether a fresh attempt succeeded.
Trigger deserves its own vocabulary: idle, resume from sleep, network roam, load spike, credential renewal, or unknown. Leave unknown labelled unknown rather than filling it in later from memory. The stage field carries the most value, since it records where the chain stopped instead of what the user felt. Error text should be copied verbatim, because a paraphrase loses the distinction between two similar codes.
Keep gaps as gaps. A template that forces an answer invites invention, and invented context is worse than a blank.
| Field | Example | Why it earns its place |
|---|---|---|
| Time with offset | 2026-11-03T09:14+08:00 | Orders events across sources in different zones |
| Trigger | resume from sleep | Separates a cause from a coincidence |
| Stage | handshake ok, no route | Names the boundary that failed |
Capture the same five facts at the failure
Run the same commands in the same order, every time. Two minutes of output beats a photograph of the tray icon, and the sequence matters when timestamps later disagree.
date -Is journalctl -u wg-quick@wg0 --since "-2 min" --no-pager wg show wg0 latest-handshakes transfer ip route get 203.0.113.10 ping -c 3 -W 2 192.0.2.1
The first line stamps the observation with an offset, which is the only way to reconcile three sources recorded in different zones. The journal excerpt covers the service lifecycle, and the handshake line says whether the peer answered at all. The route lookup names the interface a specific destination would use, which is not the same fact as the interface existing. A ping to the tunnel address shows whether anything crosses the link, not whether the far side is reachable.
Write one line per incident into a running log, with those fields and nothing else. After five or six entries, sort by trigger and then by stage. Patterns appear as repeated pairs, and a pair that never repeats is probably a coincidence.
Locate the stage that broke
Local connectivity, peer state, routes and name resolution fail in different places, and each leaves its own trace. If the interface exists but no route points at it, the failure is local policy. If the handshake timestamp stops advancing while the interface stays up, the failure sits upstream.
Name resolution belongs in the same capture. A resolver that followed the tunnel on Monday and the local network on Tuesday produces failures that look random at the application layer.
For authorized server access, correlate the same attempt rather than a nearby reconnect. Preserve the original timestamps and record any offset separately, because converting them in place erases the evidence of the conversion. One attempt, one set of timestamps, one conclusion.
Compare one condition at a time
A controlled comparison changes one meaningful condition and keeps the failed run beside the successful one. Move the device to another network, or disable one exclusion, and change nothing else in the same step.
Keep the failing run in the record. Deleting it in favour of the working one discards the only evidence of the boundary you are trying to locate.
Share an excerpt, not the profile
Before sending anything, strip passwords, tokens, private keys, unrelated identities and payloads. A full profile is a configuration secret rather than a connection summary, and it does not belong in a ticket.
Send the excerpt with the five fields and say which stage you believe failed. That lets an administrator examine the boundary you named instead of scrolling through screenshots of a disconnected icon. If the boundary is still unclear, the next step is one more controlled capture, not another settings change.