VPN keeps disconnecting: causes by verdict

A VPN that seems to keep disconnecting can be one of three things the app tells apart: it is idle, the device changed networks, or the connection stopped carrying traffic. Android adds two settings of its own, covered below. The app's message tells you which, and each has a different action.

Competing guides give one flat list: update, switch server, switch protocol, change battery settings. This page sorts the reasons by the message ForestVPN shows instead.

Is the VPN disconnecting or just quiet?

It is quiet when the connection details read "Nothing is being sent right now." That is net.idle, and the catalog marks it as not a fault: the tunnel is up and the app has simply had nothing to carry.

A quiet tunnel is why a setting like

PersistentKeepalive

a setting that makes a peer send a tiny packet at a fixed interval, so a tunnel with no user traffic still shows activity

exists; the lab runs below used it, and this page does not state what the phone apps set.

There is no action for net.idle, because there is nothing to fix. Start a download or open a page, and the status moves on.

The main screen keeps saying Protected while the app is idle. The exact message and its code are in the connection details (Health or Details), so open them before you decide anything. A real drop shows one of the messages in the table below.

Why does my VPN drop when I switch networks?

Because your device's source address changes, and a tunnel keeps sending from the old one until something tells it to rebind. Moving from Wi-Fi to mobile data, or between two Wi-Fi networks, replaces the address the tunnel's sockets were using.

The app's side of this is a rebind: the platform signals the change and the tunnel opens its sockets on the new address. If that signal works, traffic comes back. If it does not, you may see "Connected, then stopped carrying anything" until you turn the app off and on.

On iPhone, and in the other phone apps, the app holds the Protected headline briefly after a network change while it re-checks the connection; only a failed re-check shows Reconnecting.

A network change is a different event from a network that refuses to carry the connection. The first is something your device did; the second is something the path does to packets. The sections below cover the second.

The lab run at the end reproduces the first: the source address is replaced by a different one, and traffic comes back once the tunnel is signalled to rebind. It tests that the rebind step works. It says nothing about how a phone's operating system notices a change.

If the device really has no route, for example in a lift or a tunnel, the app says "No network." (net.underlay_down). Nothing further out can be judged until the network returns, and the app carries on by itself.

Why does my VPN say the server isn't answering?

It means the handshake, the first exchange of keys with the server, is not being answered. The app words it as "We're sending connection attempts and the server isn't answering" (net.blocked_at_handshake).

The help page for this message gives the action: turn the app off and on, and try another network if it repeats. The phone apps also offer another location on the card next to Try again. If you also cannot get a connection at all, VPN not connecting walks through the stages of connecting.

Hotspots that hold traffic until you complete their sign-in page can produce this message too. The networks help page covers them.

What if it says connected, then nothing is carried?

Two messages describe a tunnel that was up and then went dark, and both take the same action: turn the app off and on.

• Connected, then stopped carrying anything (net.blocked_after_handshake): the connection started, then stopped carrying traffic. Per its help page, the reasons include a network change or a fault on the server. The phone apps also offer another location on the card.
• Connected, but nothing is getting through (net.liveness_failed): the counters look healthy, but a test packet sent by the app itself got no answer. See the liveness help page.

The first is judged from the tunnel's own counters. The second catches what counters cannot see, such as a network that carries the start and drops the data.

For the version of this symptom where pages fail while the app looks connected, see VPN connected but no internet.

Do battery saver and Always-on settings drop the VPN?

These are Android settings; on iPhone the network-change behaviour above is the one that applies. On Android they can drop it. If the system limits ForestVPN in the background, the app has to keep reconnecting you, and the app's own diagnosis flags it as a warning. The Android help page lists the fix: say yes to the battery prompt, or use the diagnosis's Open battery settings button, and pick the option with no limit on ForestVPN.

Android's Always-on VPN is a separate setting. Android's developer guide says the system can start a VPN service at boot and keep it running, and that it can block connections that do not use the VPN. Another VPN app holding that slot is a second reason the app may keep losing its tunnel.

The kill switch is the app's own setting that stops traffic leaving outside the tunnel when the tunnel drops. It is not absolute: when the app itself is stopped, only Android's Always-on VPN with Block connections without VPN covers the gap, and neither covers every edge case. Seeing no internet while the tunnel is down is that protection working, not a second fault.

Should I restart the connection or change location?

Restart first for the three silent-connection messages; change location for two others. The catalog separates them for a reason.

• Turn the app off and on first: net.blocked_at_handshake, net.blocked_after_handshake, net.liveness_failed. For the two handshake messages the phone apps also offer another location on the card; net.liveness_failed is restart only.
• Choose another location: net.exit_unreachable, which the help page calls the one connection message that a change of location really fixes, and net.degraded, where the help page adds that if every location is slow, you should try another network.
• Do nothing: net.idle. Wait: net.underlay_down.

How was this tested?

Two runs in ForestVPN's network-namespace test harness, on the home lab, on 2026-10-29. Each ran in a throwaway virtual machine that was destroyed afterwards. No production account or exit server was involved.

In the roam run, the client's source address went from 10.11.0.1 to 10.11.0.5 and the harness passed only after traffic came back. In the handshake run the verdict was Working while healthy, then followed the table above; all samples matched. The assessor's BlockedAfterHandshake and BlockedAtHandshake verdicts correspond to net.blocked_after_handshake and net.blocked_at_handshake.