Two paths · one device
Web traffic can be relayed through someone else's connection. A UDP round trip cannot, and a TLS handshake cannot hide how far away the real browser is. We measure all three on our own sockets and let them disagree.
First match wins, top to bottom. The row that decided your session is highlighted.
TCP path. The address your HTTPS connection arrives from. A proxy, VPN or corporate gateway sits here. Our engine terminates TLS itself, with nothing in front of it, so the kernel socket belongs to whatever connected.
UDP path. Your browser asks our own STUN server for its address. Browser proxies carry HTTP, not UDP, so this is usually the machine itself. The server hands the address back sealed (IPv4, timestamp and an HMAC inside an IPv6-shaped ICE candidate): the page can read it, but not change it. Two addresses in two different networks mean the web traffic is relayed. Same ASN and same /24 is carrier NAT.
TLS ÷ TCP. The kernel's TCP round trip time reaches whatever completed the TCP handshake: through a proxy that is the proxy, and it is usually close to us. The TLS handshake cannot be completed by the proxy; it round-trips to the real browser. Direct connections land near 1–2×, relayed ones at 3× and far beyond. This is the fallback when WebRTC is switched off, and it needs no JavaScript at all. It has its own page with the full reasoning.
Explain before you accuse. Cisco Umbrella, Zscaler and iCloud Private Relay split TCP from UDP and terminate TLS by design. Their addresses carry an ipapi.is egress-service flag, which is checked before any transport rule.
Credit. This test implements the method published by Justin at proxy.kyc.red: comparing the TCP and UDP egress of one device and, when UDP is blocked, the TLS handshake time against the kernel's TCP RTT. His write-up includes the reasoning, the decision tree and measured results across sixty residential proxy exits. Read it at https://proxy.kyc.red/.