Every VPN operator eventually meets this moment: the dashboard shows green, the port responds to a TCP check, ICMP pings return in 30 milliseconds — and yet not a single user can browse through the node.
The problem is not your monitoring tool being broken. It is that the question it asks ("is this host reachable?") is fundamentally different from the question you need answered ("does a user's traffic successfully exit through this server?").
Ports open, tunnels dead
Most VPN protocols listen on a well-known port. A TCP connect to that port succeeds as soon as the kernel accepts the connection — before any protocol logic runs. WireGuard will silently drop packets from peers with wrong keys while leaving the UDP socket open. Trojan serves its camouflage website over valid TLS to anyone without the right password. OpenVPN answers TLS handshakes even when no user can authenticate.
In other words: everything that makes a port check pass has already happened by the time any of the VPN-specific logic executes. The failure modes that matter — wrong peer keys, expired certificates, exhausted auth backends, provider-side IP rotation — all live after that point.
The silent killer: exit IP drift
Even when a tunnel connects, there is a second way it can be broken: the address you exit from is not the address you think you are using. This happens when providers re-route nodes behind shared pools, when CDN fronting changes origins, or when NAT rules get rewritten during maintenance.
For commercial operators this is catastrophic in a specific way — users see a different country or a blacklisted IP while every reachability metric stays green. Anti-pooling checks exist precisely because this failure mode is invisible to anything that does not push traffic through the tunnel and look at what comes out the other side.
What correct VPN monitoring looks like
The only reliable method is to behave like a client. Bring up the tunnel with real credentials from somewhere outside your own network, push actual traffic through it, and compare the observed exit IP against expectation. Anything less is inferring health from proxy signals.
That is the entire idea behind ExitProbe: distributed probes that speak your protocol natively, verify the exit IP on every single check, and open incidents scoped to the exact protocol and region that failed — so "green" finally means what you think it means.
Stop guessing. Start verifying.
ExitProbe runs real tunnel handshakes and verifies exit IPs from live edge probes — free to start, no credit card.
Create free account