VPN Detection Depends on Where You Are Watching

Two detectors can watch the same user and disagree, both correctly. An observer beside the access link sees the VPN's outer conversation; the website sees the application connection arriving from the exit. Those are different connections with different fingerprints, and evidence from one does not transfer to the other. Naming the observation point before discussing any TLS or TCP test is what makes the claim meaningful.

A detector without a stated vantage point is describing an opinion rather than a measurement.

Two Vantage Points, Two Different Connections

The outer conversation belongs to the tunnel protocol: its own message formats, its own state machine, its own timing. The inner connection is the browser opening TLS to the website, carried through the tunnel and then forwarded from the exit. Both exist at the same moment and they are not the same flow. One is what an access network can see, the other is what the destination can see, and a middlebox that terminates either changes both pictures.

That difference explains most of the confusion in detection discussions. A test reporting one thing about a flow often answers a question about a different layer than the operator had in mind.

What the Access-Path Observer Sees

Beside the access link the visible material is the tunnel protocol itself: control and data packet types for OpenVPN, the fixed-size handshake and data patterns of WireGuard, or whichever wrapper the deployment adds. Whether a classifier can identify them depends on what is visible, which transport carries it and whether additional obfuscation is present. A recognisable pattern is evidence about a flow, and not evidence about the identity or intent of the person behind it.

Port 443 is a convention for reaching a service. It does not make every tunnelling transport into HTTPS.

What the Website Actually Sees

With a routed tunnel the browser still runs its own TLS session with the site. Translation at the exit does not turn the VPN gateway into the browser's TLS endpoint, so the ClientHello the site receives describes the browser or its TLS library. A JA3-style fingerprint therefore characterises the application connection, not the VPN software carrying it. Only a deliberately terminating proxy changes that arrangement, and it has to be identified separately.

TCP observations need the same care. Forwarding, translation and a proxy originating a fresh connection are three different designs, and only one of them rewrites the transport stack. A single unusual characteristic does not uniquely imply a tunnel.

Keep the Claim Inside the Evidence

Network classification, protocol observation, application fingerprints and account signals are inputs to a risk decision, each with false positives, false negatives and missing evidence. An address in a hosting range proves nothing about a commercial VPN, and a common browser fingerprint proves nothing about a direct one. When you evaluate a detector, use an authorised dataset with known paths and record which observation produced each result.

Keep protocol classification separate from a consequential access decision. A custom response or a malformed-packet trick does not validate the inference behind it; it just applies pressure to a guess.

A useful report names the observation, the vantage point and the confidence. A bare VPN detected line hides exactly the part that would let someone check it.