How to Record and Verify the VPN Exit Address You Used
Client apps show a location name, not the address your traffic left from. Capture the exit IP at connect time and compare it with a direct baseline.
Ask a desktop VPN client which servers you have used and the honest answer is usually a location name. That name is the entry point you dialled, and the address your traffic left from can be a different machine entirely. Nothing in the app is designed to keep the second number, so the record has to be built at the moment of use. Two approaches exist, and only one of them survives contact with a support case.
Two Records, Only One of Them Exists
The client's own view is a list of chosen locations with timestamps at best. That is a design decision rather than an oversight: addresses are operational detail, they rotate between assignments, and exposing the mapping makes both support and abuse handling harder. Providers front their networks with cloud instances precisely so the endpoint can move without telling anyone. What the app shows you is the choice you made, not the route it took.
The record you can build is a local file holding a public address and a UTC timestamp per line. It is smaller, uglier and far more useful, because it describes the one thing an outside observer can also see.
Option A: Capture the Exit Address Yourself
An echo service returns whatever source address the request arrived from, which is the exit address by definition. Run the capture after the tunnel reports connected, because a client that says connected before routes and DNS settle will record the pre-tunnel address and poison the log from its first line.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"Two details make that snippet usable rather than decorative. The timestamp and address share one line, so a later parse does not have to pair up records, and umask 077 keeps the file private from the moment it is created. Run it once per connection instead of once per boot, and keep one file per device.
The log records when you used a tunnel and which network you appeared from, which is closer to browsing history than to a counter. Choose a retention period you can defend, keep the file out of shared sync folders, and prune it deliberately.
Option B: Ask the Provider for a History
Some providers keep connection logs and will answer a support question with a timestamp and a server name. That record describes their infrastructure rather than your traffic, and it is only as good as their retention window and their willingness to look. It also describes a session, not a request. The window is usually short, and it is measured from the provider's side of the tunnel.
Providers that advertise no logging cannot produce this on request, and a client-side list of recent locations is not the same thing. Asking a no-log provider for an exit address usually ends with an explanation of why the data does not exist.
What Each Record Can Prove in a Support Case
The two records answer different questions, and the table is where the comparison stops being academic.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
Only the first column is under your control. A provider record can confirm that an account was connected at a given time, yet it cannot confirm which requests used the tunnel, and it will not name an address the provider treats as operational detail. Neither record identifies a person, because a shared exit address can carry many customers in the same minute.
Compare Both Against a Baseline Before You Trust Either
An address on its own proves nothing. Capture the direct address before connecting, the tunneled address after, and compare them. Identical values mean the tunnel is not carrying that request, whether because of a split tunnel, an overriding proxy or a client that failed over to a direct path.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1Repeat the comparison for DNS and for IPv6, since an address echo proves the path of one HTTP request and nothing about which resolver answered it. A device that leaks on either of those can look perfectly healthy on the other.