Proxies, VPNs and residential addresses: what a website can and cannot tell
Every website sees the address a request arrived from. What it decides about that address is a different matter, and the two get confused constantly. This article separates what a server can observe from what a detection vendor sells.
What the server observes
The server sees a source address and a port. From the address it can derive, by lookup, an approximate location, the organisation that owns the range (the ASN), and whether the range is registered to a consumer ISP, a hosting company, a mobile carrier or a university. It also sees the TLS handshake details, the HTTP headers the client sent, and the timing of the connection. That is the whole of the first-hand evidence.
What a lookup adds
Commercial databases classify address ranges: "residential", "data centre", "known VPN exit", "Tor exit", "mobile". They are built from public registration data, from traffic patterns, and from lists of exits that VPN providers publish or that have been observed. Sites buy access to these databases and ask them about each visitor. The "Proxy: yes" verdict on some diagnostic pages is the answer to that question; it is not something the browser said, and it is only as good as the database behind it.
This is why a diagnostic that does not query such a database should say "Not tested" for proxy, blacklist and anonymity checks rather than guessing. Guessing from browser signals alone would be wrong often enough to be misleading.
Proxy, VPN and residential, from the server's side
A VPN carries all of a device's traffic, so the browser's HTTP requests, WebRTC packets and DNS queries all exit from the same place. The server sees one consistent address, usually in a range the databases know belongs to a VPN provider.
A proxy configured in the browser carries only the traffic the browser sends through it. HTTP goes through the proxy; UDP for WebRTC may not; DNS resolution may happen locally or at the proxy depending on the proxy type. The server can see the proxy's address in the request and, if WebRTC is not contained, a different address in the candidates. This inconsistency, not the proxy itself, is what gets noticed.
A residential address is one registered to a consumer ISP. Databases treat it as the least suspicious category because it is what most real visitors have. Residential proxy networks route traffic through such addresses, which is why they are sold at a premium and why detection vendors spend effort identifying them by behaviour rather than registration.
The checks that do not need a database
Three comparisons work with no vendor at all. Does the browser's time zone match the address's? Does the WebRTC candidate match the request address? Does the language list fit the region? None of these proves anything, but each is free, and a mismatch in all three is hard to explain. A diagnostic that shows these side by side is giving you the same view a site gets before it spends money on a lookup.
What to take away
The address is a fact. The classification is an opinion from a database you cannot see. The consistency between the address and everything else the browser reports is the part you control, and it is the part worth checking.