Device VPN marker or exit address: which one proves what?
A network marker read on the device and an address observed by a server are different evidence. Decide which one the question you are asking needs.
Phone app and far-end server begin with different facts, and neither can borrow the other's. The app can ask the operating system about the network it uses, while the server only knows what arrives on the connection. Running your own endpoint rewrites the second and leaves the first untouched. Which of them answers your question depends on the question itself.
Two observation points, two kinds of evidence
Local evidence describes the device. It covers the interface carrying traffic, the transport the platform reports, and what the calling app is allowed to query. Remote evidence describes the connection: source address, protocol, timing, and anything the app chooses to transmit. No observation point is a superset of the other.
Mixing the two produces claims that sound exact and cannot be checked. A marker proves something about a network object on the device, not about how a remote service classifies the request.
Before arguing about detection, write down which point the question concerns. Is the issue whether a particular app can tell a tunnel is active, or whether a service can infer where the request came from? Those are separate investigations, and an answer to one says nothing about the other.
What a local platform interface can report
Android offers a specific marker. The NetworkCapabilities object can report TRANSPORT_VPN, and hasTransport tests whether that transport is present on the object. An app gets the object from the connectivity service and reads it, subject to network state permission.
The result is local platform information, not a lookup against a provider's address ranges. It describes the network the calling app is using.
Two limits matter. A split-tunnel rule that excludes an app can produce a different answer on the same phone than a colleague sees, because the app may be bound elsewhere. The marker also exists because the OS models VPN interfaces, not because any particular app collects it. Whether an app reads the field, forwards it, or ignores it is a property of that app. Its manifest and documentation are the only reliable sources for that question.
adb shell dumpsys connectivity | grep -i -m5 vpnWhat a remote service can see
A server sees the source address of the connection, the transport and the timing, and it can enrich the address with registry or routing data. It can also receive anything the app sends, including location when the app requests it and the user agrees. Those channels are separate, and only one resembles an address lookup.
An address registered to a hosting provider suggests a tunnel, while one registered to a residential network suggests a home connection. Both are statistical hints, not facts about the device.
A residential address does not place the person at that address, and a hosting address does not name the operator or the country. A service that treats the inference as certainty will sometimes be wrong without being able to detect it. If the requirement is reliability rather than a heuristic, address data cannot supply it, and a design that says so is more honest than one that hides the guess.
| Evidence | What it answers | What it cannot show |
|---|---|---|
| Local transport marker | Whether this network object is a VPN | Who operates the exit or where the device is |
| Remote source address | What address reached the service | Whether the device also carries a tunnel |
| Application payload | What the app chose to send | Anything the app did not send |
Why a self-hosted exit changes only one side
Running your own endpoint changes the source address a remote service observes, which can move it outside the ranges that service associates with commercial providers. It changes nothing in the local network model, because the tunnel remains a tunnel and the OS still reports it.
One side of the evidence moves; the other stays fixed. The gap between them is where expectations break.
A browser is a third case with its own interfaces and restrictions. Web content cannot read a native capabilities object, and treating a mobile OS feature as available to a web page is a category error. If the question concerns a website, study what a website can actually obtain instead of transliterating a platform API.
Decide with the question you are asking
If the question is whether a specific app can observe tunnel state, the platform interface is the right place to look, and the answer lives in that app's code and permissions. If the question is what a service can infer, connection metadata is the evidence. A legal or contractual question is settled by neither.
Name the question in one sentence before collecting anything. That sentence decides which observation point matters and keeps the investigation from drifting into a different argument.
Label each observation by its source when you report it, because an unlabelled claim cannot be reviewed. A local marker and an address inference are both useful and neither is conclusive, which is why merging them into one verdict is a mistake.
When a service rejects an authorised connection, use its supported review route instead of changing a local setting to hide a signal. Removing one observation never proves the others disappeared.