How to Test VPN Stability Without Logging Your Browsing

You want to know whether the tunnel survives a laptop sleep, a walk between access points, or an hour of calls, and you would rather not hand anyone a log of everything you read while finding out. Three things answer it: a fixed probe, the same four facts sampled on a schedule, and the event that changed them written down. Ten minutes of that beats an afternoon watching a page fail to load. The log you end up with is also short enough to attach to a ticket without redacting half of it.

Decide what stable has to mean

"The VPN dropped" is four different failures wearing one word. The peer can lose its handshake, the route can fall back to the local gateway, name resolution can go to a server that never answers through the tunnel, or all of those can be healthy while one application still fails. Decide which one matches your symptom before you collect anything, because each needs a different probe. Then pick an interval you can keep: one sample every thirty seconds for ten minutes catches a roam without turning the test into workload.

If the complaint is a call freezing when you walk to the kitchen, the property you need is whether a fresh request completes after the roam. That is checkable in one line and it records no browsing at all.

Fix one harmless probe

Pick a destination you are allowed to query that is not tied to your accounts: a documentation host, an internal status endpoint, or the tunnel gateway itself. Make the operation repeatable, for example curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, which prints one line per attempt. Keep that output format fixed for the whole run. A status code and a duration collected the same way twice are what make two runs comparable.

Resist the site you actually rely on. A bank or webmail page drags trackers, redirects and personal content into the measurement, and it prints session identifiers into whatever you paste into a ticket later. Use the same destination for the whole investigation, and note it next to the interval.

Sample the four facts

Peer state, route, resolver and one fresh request are the four observations, and each has a cheap source. On WireGuard, wg show wg0 latest-handshakes gives the peer timestamp and ip route get 1.1.1.1 shows which interface the kernel would use. On OpenVPN the same state sits in the status file written by --status /run/openvpn/status 10 or behind state on the management interface. A Windows client stays in PowerShell with Get-NetAdapter and Resolve-DnsName.

Loop them in one terminal so every line carries a timestamp: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. That loop covers three of the six log fields; the client version goes in once at the top, and the event timestamp gets added when the event happens.

The resolver is the fact people skip, and dig +short hides it, because that form prints the answer only. Ask for the server explicitly with dig example.com | grep SERVER:, or use nslookup example.com where dig is not installed, which prints the address of the server the query went to. An old handshake on an idle tunnel is not automatically a fault either, since WireGuard only rekeys when there is traffic to protect.

Trigger the event, not a leak

Take five quiet minutes as a baseline before the event you care about, whether that is closing the lid, walking to another access point, or switching to a phone hotspot. Note the time you caused it, so the samples on either side can be lined up.

Without that timestamp the log shows a gap and nobody can say whether the client or the network closed it. Two runs with the event in different places are worth more than ten without one. Use the client's own disconnect and reconnect controls. Do not disable the kill switch or push traffic outside the tunnel to see what happens, because on a managed laptop that is a policy breach and on your own machine it creates the exposure you were testing for.

Keep a log small enough to finish

Six fields per sample: time, client version, endpoint, access network, event, result. Leave out URLs, payloads, tokens and anything carrying a session identifier, since the log is evidence about the tunnel and nothing else. Keep it beside the loop so the next person can rerun it without asking what the columns mean.

After a change, repeat the test with the same probe and the same interval; swap the destination and the client version together and the result belongs to neither. A clean ten-minute run is evidence for those conditions and that destination, not a promise about next month's hotel network. Keep the script and the log template where you will find them. WireGuard's documented limitations are worth reading before you attribute a drop to the protocol.