VPN dropped mid-page: do background requests still go out?

The tab still shows the dashboard from before the tunnel died. Status numbers freeze, a small spinner keeps turning, and the address bar still carries the app you opened an hour ago. You did not touch anything after the drop, yet the page may still be trying to reach its server on its own schedule. That is the part people miss: a page that is merely visible and a page that is still sending requests look identical from the outside, and only one of them shows up in a network log.

Work a page starts without you

Four mechanisms keep a loaded document busy. A repeating timer can re-run a status call every few seconds. A fetch can fire when the tab becomes visible again after you switch back to it. A live channel built on WebSocket or server-sent events can attempt a reconnect on its own backoff schedule. A service worker registered by the site can wake for a queued sync even when no tab is in front of you.

None of those need a click, and none of them reload the document. The address bar, the scroll position and the rendered values all stay where they were. What changes is only the network side: each new attempt is a fresh decision made at the moment it starts.

That distinction matters because the visible page is stored locally. Pixels already painted say nothing about whether the next request succeeded. A frozen chart with a spinner is the ordinary look of a page whose requests are now failing. Reading the screen tells you what the server said minutes ago, not what the browser is doing now.

Why the earlier page load does not hold a route

Nothing in the page load binds the document to the tunnel. Routing is resolved per packet, at send time, from the table that exists when the packet leaves. When the tunnel interface disappears, that lookup no longer matches the tunnel route. It either falls through to the physical adapter or finds nothing at all, depending on what the client left behind.

Repeating callbacks are ordinary scheduled tasks. The timer section of the HTML standard describes how they are queued and treats the interval as a minimum delay rather than a promise of exact cadence, so a background tab can poll far less often than its code asks. Fewer attempts is not the same as no attempts, and bringing a tab back to the front is a common moment for a burst of them.

Where the failure policy lands

The client's block is evaluated when a connection is attempted, not when the page was fetched. If ordinary access is still permitted, the retry can leave over the physical link in the clear. If the policy holds that traffic until the tunnel returns, the attempt fails at connect time and the page shows an error it may retry a few seconds later.

Two details decide which of those you get. The first is the enforcement scope the client supports: a whole-device block, a block limited to the tunnel adapter, or a rule set with exclusions. The second is whether the destination falls inside an exclusion you added earlier for a local printer, a captive portal or a streaming service.

Application-level encryption does not change any of this. HTTPS protects the bytes between browser and server; it says nothing about which interface carries them. A page can be perfectly encrypted and still leave through the wrong path, and that is exactly what a narrow block allows.

A controlled check with a throwaway page

Use a host you control and a page that does nothing but call it, so no real data is in play. From a terminal, sample the path before and after the drop:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Run it with the tunnel up, then bring the tunnel down and run it again. A reply from a public address while the tunnel is down tells you the direct path is open. A timeout or a refused connection tells you the policy is holding. Repeat once more after the client reconnects, so you can see the tunnel path come back rather than assuming it did.

In the browser, the Network panel separates the two questions. Filter to Fetch/XHR, then read the initiator column: an entry started by a timer or a script, with no navigation recorded before it, is a background attempt rather than a reload. Compare its start time against the moment the tunnel dropped. If the entry is still pending when the tunnel is gone, the request is waiting on a path that no longer exists.

Server-side evidence is stronger than anything the browser shows. A request log with a timestamp and a source address proves the packet arrived. Browser entries can carry cookies, tokens and full URLs, so keep only the fields your question needs and redact the rest before you paste them anywhere.

What to do with the answer

If background attempts keep succeeding while the tunnel is down, the block is narrower than you assumed, and that gap is worth closing before you trust the client for sensitive work. If they fail, the policy is doing its job and the frozen page is cosmetic. Either way, closing one tab is not a device-wide control: other tabs, other browsers and other applications each schedule their own work.

Next steps worth taking: list which exclusions you have added and why, confirm whether the client blocks only tunnel-scoped traffic or all traffic, and watch one background request end to end with the server log open. Those three answers cover most of what a report of "the VPN dropped and something still connected" actually contains.