Proxy detection
The set of techniques sites use to decide whether a visitor is behind a proxy, ranging from network lookups to behavioural analysis.
The first thing to correct is the mental model. Detection is almost never a yes or no answer about whether a proxy is present. It is a score assembled from many weak signals, and you never get to see it. That is why the experience is so confusing from the outside: the same setup sails through on Monday and gets challenged on Thursday, because a threshold moved or one input changed, not because you were unmasked.
The cheapest inputs come first, because they cost a lookup and nothing else. Which organisation owns this address. Is it in a range published as hosting. Does it appear on a commercial proxy or VPN list. Has this address misbehaved here before. Those four questions alone dispose of most datacenter traffic before anything examines the request itself.
Then come the contradictions, which are the interesting ones, because they catch setups that pass every individual check. An address geolocating to Germany paired with a browser reporting a New York time zone. A residential IP whose TLS handshake belongs to a Python library. A single household address suddenly carrying the request volume of an office. None of those signals is damning alone; the point is that they disagree with each other, and real users are rarely internally inconsistent.
Volume-shaped signals sit alongside them. Perfectly regular intervals between requests, a traversal order no human would produce, sessions that never load an image or a stylesheet, a fresh address that goes straight to a deep URL nobody could have navigated to. All of that describes a program, and none of it involves knowing your IP is a proxy.
So the useful conclusion is that no address is undetectable on its own merits, and chasing one is the wrong goal. What survives is coherence: an address, a fingerprint, a time zone, a handshake and a rhythm that all tell the same story. A trusted residential IP driven carelessly gets caught, and an ordinary setup driven carefully often does not.
How it works
- 1.Look up who owns the address and whether the range is published as hosting.
- 2.Check the address against reputation and known-proxy lists, plus any local history of abuse.
- 3.Compare what the network claims about location against what the client reports: time zone, language, and any leaked origin from DNS or WebRTC.
- 4.Fingerprint the connection itself, at the TLS layer and in the browser, and check it matches the client it claims to be.
- 5.Score the request pattern: pacing, ordering, asset loading, session shape.
- 6.Add the weighted signals together and act on the total, which may be allow, challenge, degrade or block.
Frequently asked questions
Can a website tell I am using a proxy?
Often, and rarely by unmasking you. It looks up who owns the address and whether the range is published as hosting, checks it against known-proxy lists, and looks for contradictions between what the network claims and what your browser reports. None of that requires discovering your real address; it only requires noticing something inconsistent.
Which proxy type is hardest to detect?
Mobile, then residential, because both sit on consumer networks a site cannot dismiss wholesale without also dismissing real customers. But address type only sets your floor. A mobile address paired with a scripting library's TLS handshake and machine-regular pacing is caught on everything except the address.
Why does the same proxy work on one site and not another?
Because detection is a score with a threshold, and both are set per site. One target may only count requests per address while another buys reputation data, fingerprints the handshake and scores behaviour. The address did not change; what was being asked of it did.
How can I test what a site can see about me?
Send a request through the proxy to an endpoint that echoes back what it received, and check three things separately: which address arrived, which headers came with it, and whether your TLS fingerprint matches the client you claim to be. Then check for DNS and WebRTC leaks, which sit outside the request entirely.
Back to the full glossary.