Your Server Sees the VPN Exit, Not the Visitor

A visitor connects through a commercial VPN and your application logs the exit address. That is not a hidden identity: it is the only source address the TCP connection has. Everything else people call detection is inference layered on top of that single fact.

What a request actually carries

The application sees the connection's source address and port, the handshake it completed, and the bytes the client chose to send. Under a full tunnel, that source is the exit, shared by everyone using it. Under a split tunnel, requests may arrive from the tunnel or from the local connection depending on the destination. If the client and server are both inside the same VPN, the source is the client's inner tunnel address, which identifies an endpoint rather than a location.

No field in an ordinary request carries the address the client had before the tunnel. A forwarding header is the client's assertion, or a proxy's, and it can be omitted or forged.

Detection is classification, and classification is a guess

The practical methods are lists of known VPN and hosting ranges, latency that disagrees with a claimed region, traceroute shapes, and account behavior. Each one produces a probability. A corporate VPN can sit on addresses that look residential, a residential proxy can look like a home line, and carrier NAT can look like a hosting range.

Blocking a shared exit blocks every unrelated user behind it, which turns a detection decision into a collateral outage. A confidence score is not an identity and should never be the only input to a ban or a refund decision.

If you own the VPN, you have a reliable signal that has nothing to do with detection: assign a dedicated pool and match the observed source against it. That works because you control both ends and can document the pool. It does not generalize to visitors you do not manage, and it stops being reliable the moment the pool is shared with other services.

Local evidence versus server-side proof

On the machine itself a tunnel is visible: a virtual adapter, a default route that points at a tunnel device, a resolver that changed. Code running there can enumerate interfaces and look for PPP, TAP, or a vendor driver.

A web page cannot read any of that. The common workaround loads an asset served only from the internal network and treats success as proof of tunnel use. It tests reachability instead: a split tunnel, a stale cached file, or an interception proxy yields the same result in either state. Local evidence stays local.

Choose access controls that survive the ambiguity

Build access control on verified identity, device health, and authorization per resource. Those predicates describe who is asking and what they may reach, and they remain meaningful whether or not a tunnel is involved. Whether a request arrived over a VPN is a weak signal that produces both false accepts and collateral blocks. Keep the evidence and the decision in separate fields, so a disputed block has something to review.

IP geolocation is one input among several, and browser location services may use Wi-Fi or GPS that never follow the tunnel. A map that still shows the visitor's city is evidence about location services, not proof that the tunnel failed.

Write down which signal drove each decision. When a customer disputes a block, that record is the difference between a review and an argument.