How Websites Detect Proxy Traffic: The Signals Explained

Every request that reaches a modern website is scored before the page is served. That scoring is not a single test but a stack of weak signals combined into a judgement, and understanding the stack explains a great deal about why legitimate research traffic sometimes gets treated as suspicious. This article is descriptive: it explains what the systems look at and why, not how to defeat them.

The IP address and its network class

The first thing any classifier sees is where the connection came from. An IP address belongs to an autonomous system, and that autonomous system has a published purpose. Hosting providers, cloud platforms and colocation facilities are all easy to identify from public registry data, and traffic from them is understood to be machine-originated by default.

That is not an accusation. Enormous amounts of entirely legitimate traffic comes from cloud ranges: monitoring services, integrations, search crawlers and internal tooling. But because a consumer sitting on a sofa almost never browses from a cloud range, the network class is a strong and cheap prior that classifiers weight heavily.

Carrier mobile ranges sit at the opposite end. They are registered to mobile network operators and, thanks to carrier-grade NAT, thousands of real subscribers share each public address at once. A classifier cannot separate one visitor from the crowd behind that IP without doing considerably more work.

• Registry data makes hosting and cloud ranges trivially identifiable
• Consumer broadband ranges look ordinary but map to a household
• Carrier mobile ranges aggregate many subscribers behind one address
• Network class is a prior, not a conclusion

Reputation history attached to the address

Beyond the network class sits accumulated history. Threat intelligence feeds record which addresses have recently been associated with abuse, spam or automated activity, and many sites subscribe to those feeds. An address with a clean recent record starts from a better position than one that does not.

Reputation is not permanent. Feeds decay entries over time, and addresses that are reassigned frequently naturally carry a mixed and constantly refreshing history. This is one reason why reputation alone is a poor sole criterion: the history of an address is often the history of many unrelated users.

Sites also maintain their own local reputation, which is usually more influential than any external feed. If a particular address has behaved normally on that site for months, it earns a tolerance that no purchased data set can grant it.

Behaviour and request patterns

The strongest signals are behavioural, because they are the hardest to acquire accidentally. Humans browse irregularly: they pause, scroll, backtrack, mistype and abandon. Automation tends to be rhythmically consistent, arriving at precise intervals, following a perfectly efficient path and never revisiting anything.

Volume and shape matter as much as timing. A thousand product pages fetched in perfect alphabetical order, with no images, no stylesheets and no favicon requests, describes a machine even if every other signal looks residential. Conversely, modest traffic that requests the full page as a browser would blends into ordinary use.

Session structure adds another dimension. Real visits carry cookies forward, reuse connections, and produce a coherent sequence of referrers. Requests that arrive with no history and no continuity are individually unremarkable but collectively distinctive.

• Timing regularity is a much stronger tell than raw volume
• Missing sub-resource requests reveal non-browser clients
• Perfect navigation paths look nothing like human browsing
• Session continuity, referrers and cookies form a coherent story or they do not

Fingerprints at the transport and browser layers

Before any HTTP is exchanged, the TLS handshake already carries identity. The precise list and ordering of cipher suites, extensions and supported groups differs between implementations, and that pattern indicates which library or browser build is speaking. When the TLS fingerprint says one thing and the user agent header says another, the mismatch is noticeable.

Higher up, a browser exposes a large surface: screen dimensions, timezone, installed fonts, language settings, graphics rendering characteristics and audio processing details. None of these identifies anyone individually, but combined they form a fairly stable signature.

Consistency is what classifiers actually examine. A configuration claiming to be an iPhone in Chicago while reporting a desktop screen size, a European timezone and a graphics stack no phone possesses is contradicting itself, and internal contradiction is far more informative than any single value.

Why the picture differs for carrier mobile IPs

Blocking a datacentre range costs a site almost nothing, because few genuine customers browse from one. Blocking a carrier mobile address is a different proposition entirely: behind that single IP sit thousands of real subscribers who might be customers, and a blanket block would turn away all of them.

This asymmetry is structural rather than a loophole. It comes from how carriers conserve address space, and it means classifiers must lean much harder on behavioural and fingerprint signals when the network class provides little discrimination. The IP stops being decisive and becomes one input among many.

For legitimate work such as ad verification, availability monitoring, brand protection and localised search checks, the practical implication is straightforward. Using real SIM cards on real carrier networks in the metro you are studying removes an artificial source of noise, but it does not exempt your traffic from every other check, and it should not be expected to.

Frequently asked