Culvert VPNWhy a VPN should verify its own exit IP
A VPN app should confirm the tunnel works by asking its own server what address it saw, through the tunnel, not by loading a third-party IP-lookup page.
A VPN app should verify its own exit IP by sending a request through the tunnel to a server the provider runs and asking what address the request came from. That answer is proof the tunnel is carrying traffic, and it names the exit address the rest of the internet sees. Doing it by loading a third-party "what is my IP" page inside the app is worse on both counts: the result is not independent of the page's cache and trackers, and the page itself learns that someone behind this VPN address is checking.
What "verified" has to mean
A tunnel being configured and a tunnel carrying traffic are different states, and only the second one is a working VPN. The status bar icon appears at the first; only a packet that goes through the tunnel and comes back proves the second. So verification means, at minimum: send something through the tunnel, get an answer, and read the address the far end saw.
The answer is then worth comparing against something. The provider knows which server it sent you to and what address that server uses. If the address the server saw matches the address the provider expected, the tunnel is carrying traffic to the right place. Those two values come from different sources, one measured and one configured, which is what makes the comparison a check rather than a display.
The failure to watch for is an app that shows the server's listed address as "your IP" the moment the tunnel appears. Nothing has been measured. It is a label copied from a configuration file, and it will read the same whether the tunnel works or not. The exit IP explainer covers what the address is; this post is about how you know it is true.
Why not just load an IP page
Plenty of apps do exactly that: open a hidden web request to a public "what is my IP" service and show the result. It seems to be the same thing, and it is not, for three reasons.
The page learns something. Every request to it says: a device behind this VPN address, at this moment, ran a check. Over thousands of users that builds a picture of which addresses are VPN exits and how busy they are, and the request carries whatever cookies and identifiers that service has already set. A check that exists to find leaks should not itself be a small leak.
The page is a third party in your trust chain. If it is slow, wrong, cached or down, the app either shows a stale address or shows nothing, and you cannot tell which. A service the provider runs answers only the question asked and fails visibly when the tunnel is down.
The comparison is weaker. A public page gives you an address and a guessed location. The provider's own server can also tell you which server you actually reached, so the app can confirm not just that traffic flows but that it flows to the place the picker said.
How to do the check yourself
If your app does not verify, or you want to see for yourself, the manual version is short.
- With the VPN off, note the address a lookup page shows and the network name beside it.
- Connect and wait for the app to report a connection.
- Reload the page. The address should now belong to a hosting provider in the city you chose.
- Compare with what the app shows. An app that names a different address from the page is showing you a label.
Because this uses a third-party page, do it once to confirm the app's behaviour, not as a routine. The full procedure and what each result means is in how to check your VPN is working, and the leak-specific version is in the IP leak test.
Reading the app's own display
When an app does verify, the address on its connect screen has a small lifecycle worth recognising. The tunnel comes up and, for a moment, the address is absent or marked as checking; then the request returns and the address appears. If the network is dropping the tunnel's traffic, the address never appears, and that absence is itself the diagnosis: the tunnel is up and carrying nothing. An honest app shows you the gap rather than filling it.
The location shown under an address anywhere is a guess from a geolocation database, and those databases lag behind reassignments by weeks. The address is the fact; the city name beside it on a lookup page is an estimate.
What Culvert does
Culvert VPN's connect screen shows your IP address as seen by its own server, reached through the tunnel; it never asks a third-party page. That server is the same service the app already talks to for its account and its server list, so the check adds no new party to the conversation. On data handling: Culvert does not log the sites you visit, your DNS queries or the contents of your traffic; its VPN servers see only an opaque connection id; and it keeps the client's IP address for up to 30 days for abuse handling, as set out in the privacy policy. The app is on Google Play.
Questions people also ask
What is wrong with a "what is my IP" website?
Nothing, for a one-off check. The problem is using one as the app's built-in verification, because every check tells that site's owner that a user behind this VPN address is there, and adds a cookie and trackers to a test that is supposed to find leaks.
How do I know the app measured the address rather than printing it?
Look for a moment where the app is connected but the address is still absent or marked as checking. An app that shows the address the instant the tunnel comes up, before anything could have travelled through it, is printing the address it expected.
What if the verified address does not match the city I chose?
The address is what the server actually saw, so it is the real exit. The city under an address on a lookup page is a database guess and lags behind address changes; if the app itself names a different city, the app picked a different server and should say so.