What exit IP pooling is (and how to catch it before your users do)

Exit IP pooling happens when traffic that is supposed to leave through your server actually leaves through a shared address — sometimes yours, sometimes someone else's, sometimes several at once.

It is rarely malicious and almost never announced. A hosting provider migrates your VM behind a NAT gateway. An upstream re-routes during peering maintenance. A panel script "helpfully" load-balances nodes. From the outside, the only symptom is that the IP your users observe no longer matches the IP on your node.

Why it matters more for commercial operators

For a personal VPN, exiting from a different IP is an annoyance. For a commercial operator, the exit IP *is* the product. Streaming unlocks break. Geo-specific routing breaks. Blacklists accumulated by whoever else shares that pooled address now apply to you.

Worse, pooling tends to be intermittent — correct during your manual spot check, pooled during peak hours when load balancing kicks in. Point-in-time verification cannot see it; continuous verification from multiple regions can.

A practical detection playbook

First, establish ground truth per protocol, not per server: WireGuard and VLESS on the same box can exit differently if policy routing changed for one of them. Second, verify from outside your own network — querying your own IP from the box itself tests the box, not the path users take. Third, check continuously; the failure window between "fine at 2pm" and "pooled at 6pm" is exactly what scheduled checks exist to cover.

The mechanical part is simple: bring up the tunnel, request a known echo endpoint through it, compare the returned address with expectation. ExitProbe automates this loop on every check and deactivates nodes whose verified exit IP drifts — which turns a support-ticket discovery into a two-minute alert.