How Residential Proxy Networks Work (and where they leak)

A residential proxy pool is not a list of IP addresses. It is a live market that pays a household two cents per gigabyte, resells that gigabyte for four dollars, and routes a credential stuffing run through a smart TV in Belo Horizonte on the way. Federal enforcement has taken down two of these networks in the last two years, and the peer-reviewed detection method most vendors still rely on lost 91 points of recall to a published evasion in February 2026. This is how the plumbing works, where it leaks, and what you can measure this week.

What Is a Residential Proxy Network?

A residential proxy network relays a customer's traffic through consumer devices so requests exit from ISP-allocated IP space instead of a datacenter. Traffic reaches a gateway, which forwards it to a residential exit node, which forwards it to your server. Most detection starts with the timing gap that extra hop creates, though that signal is now evadable.

The architecture is a backconnect tunnel, and the exit node is someone's television

Three machines sit between the buyer and you, and only the last one is visible in your logs.

Sophia Barnes and Stephanie Vezich Tamayo, in a Stanford CS244C study published in the winter 2026 term, describe the path precisely: a client sends traffic to a gateway server, the gateway forwards it to a residential exit node, and the exit node opens the connection to the target. They call it what the industry calls it, a backconnect proxy.

Your access log sees one IP. The residential one.

That is the entire product. Everything else, the geotargeting menus, the session stickiness controls, the ASN selectors, is orchestration layered on top of a three-hop forward.

The first-level mechanism is straightforward. Datacenter IP space is enumerable and cheap to classify, so anything originating from AS16509 or AS14061 gets scored differently from something originating in a Comcast or Vivo allocation. Renting the residential allocation removes the cheapest signal a defender has.

The second-level mechanism is where it gets interesting for detection, and it comes down to which layer the relay operates at.

Barnes and Vezich Tamayo found that the relay forwards TLS records without terminating or re-encrypting them. The exit node is a layer-4 forwarder. It moves bytes.

That design choice is not incidental. It is forced.

If the relay terminated TLS, it would need the certificate for whatever domain the buyer is hitting, which it does not have and cannot get. So the TLS session stays end to end between the buyer's client and your server, while the TCP session is split into two independent segments: buyer to relay, and relay to you.

Now the third level, which is the part almost nobody writes down. The reason this split exists at all is a property of the TLS handshake sequence, not of proxy software. TCP completes its three-way handshake before any TLS record is sent. Your server measures one round trip against the machine that answered the SYN, and a later round trip against the machine that answered the ServerHello. In a direct connection those are the same machine. In a backconnect path they are not.

The consequence is a measurable timing discrepancy that Elisa Chiapponi and Marc Dacier at EURECOM formalised as BADPASS in 2022, and I will come back to it in detail below.

Architecture also varies by provider in ways that matter operationally.

The Stanford team volunteered a single host as an exit node for two services, Honeygain and PacketStream, and captured 69.2 hours of outbound traffic. Honeygain routed everything through UDP tunnels to ten rotating gateway servers and resolved names over DNS-over-HTTPS. PacketStream held persistent connections to eight relay servers and used plaintext DNS.

That difference is not cosmetic.

Of PacketStream's 14,241 TCP streams, 602 carried plaintext data, and among them were 346 connections to SMTP servers and 222 DNS lookups for login.microsoftonline.com. Honeygain's encrypted tunnel architecture showed neither pattern, and 4 of every 100,000 of its streams carried plaintext.

The authors draw the inference explicitly, and I agree with it: the abuse profile of a proxy network is shaped by its own architecture, not only by who buys from it. A provider whose tunnel cannot carry SMTP does not have an SMTP abuse problem.

There is a second architectural split worth knowing. Mingshuo Yang and colleagues, publishing at ACM CCS in November 2022, found that Chinese providers frequently expose the exit node directly to the customer rather than routing through a provider-internal gateway. Direct-mode pools can be enumerated through passive DNS. Backconnect pools cannot.

Worked example, one connection. A scraper in Frankfurt buys a US exit. The request goes Frankfurt to gateway, gateway to a cable subscriber in Ohio, Ohio to your origin in Virginia. Your SYN-ACK is answered by Ohio in roughly 15 ms. Your ServerHello is answered by Frankfurt, roughly 250 ms later. Same connection, two very different distances.

Second worked example, the pool underneath. Xianghang Mi and co-authors, in the 2019 IEEE Symposium on Security and Privacy paper that opened this field, tagged requests through five providers and recovered 6.18 million distinct exit IPs across more than 230 countries and 52,000 ISPs in four months. Yang's China study collected over 8 million in six months, and found that 91% of individual exit IPs stayed in the pool for less than 10 days.

Ten days. That is the useful number for anyone maintaining a blocklist, and I will return to it.

Economics of the architecture itself. Running a backconnect gateway is cheap. It is a TCP forwarder with a session table. The expensive input is exit-node supply, which is why every provider's product page is really a recruitment page, and why the supply chain is where the interesting failures are.

Who this breaks for. A defender treating the exit IP as the actor gets the geography of a stranger's living room and none of the buyer's. The other victim is the household itself, whose IP accumulates the reputation consequences of traffic it never generated.

Counter-case, and it is a real one. Not every proxy relays at layer 4. Providers marketing static ISP proxies, where the address is allocated to the provider by an ISP rather than borrowed from a subscriber, have no split-path problem because there is no subscriber. Timing-based detection has nothing to find there, and the exit is genuinely a datacenter host wearing an ISP allocation.

What to instrument. Log the TCP handshake completion time and the first client TLS response time as separate fields, per connection, before you build any classifier on top. Most stacks discard both.

The supply side is paid two cents a gigabyte and the buy side is billed four dollars

The margin on relayed bandwidth is roughly fifty to one, and that number explains every other behaviour in this market.

Start on the supply side, where the numbers are published by the proxyware operators themselves. Honeygain's public rate has held at roughly $0.02 per gigabyte since launch, structured as credits per 10 MB. Pawns.app, IPRoyal's consumer-facing earner program, advertises a flat $0.20 per gigabyte with a $5 payout minimum.

Treat both as interested-party figures. They are recruitment marketing.

Real-world reports cluster low. Trend Micro's February 2023 write-up on proxyware quoted a blogger running the apps who cleared around $20 a month, with more than half of that coming from referrals rather than bandwidth.

Now the buy side. Aggregator pricing surveys published through 2026 put standalone residential traffic between roughly $1 and $15 per gigabyte, with enterprise vendors quoted near the top of that band and budget vendors near the bottom. Every one of those figures comes from an affiliate site or a vendor blog, so read them as directional rather than audited.

Even at the pessimistic end of the spread, the arithmetic is stark.

Worked example one, the margin. One terabyte relayed through a household on Honeygain's published rate returns the household about $20. That same terabyte, sold at a mid-market $4 per gigabyte, bills the buyer $4,000. At Pawns' higher $0.20 rate the household clears $200 against the same $4,000.

The peer captures somewhere between one half of one percent and five percent of the value of their own bandwidth.

Which tells you the supply is not being bought. It is being harvested, and the peer is not the customer.

Worked example two, the attacker's unit cost. This is the number defenders should be planning against, and it is small.

A bare HTTP request and response for a login endpoint is on the order of 50 KB with headers and a JSON body. At $4 per gigabyte that is $0.0002 per attempt. A million credential stuffing attempts consume roughly 48 GB and cost about $190 in bandwidth.

Push it to a full browser page load at 2 MB and the cost rises to about $0.008 per request. Ten thousand full page loads a day runs $80 a day. Ten thousand API-shaped requests a day runs $2.

Set that against your side of the ledger. If a fraud team is spending an engineer-week tuning a rule that raises the attacker's cost from $190 to $400 on a million-attempt run, the rule has not changed anyone's behaviour.

The economics only bend where the attacker's cost per success moves, which is a function of your challenge and step-up logic, not your bandwidth denial.

Where the curves cross. Bandwidth-metered pricing means image-heavy and browser-driven automation is expensive and API-shaped automation is nearly free. That is why scrapers strip assets and why login abuse is the most economically viable use of a residential pool. Any control that forces a full browser render forces a 40x cost increase on the attacker, which is the single largest economic lever available to a defender and it is priced in latency for real users.

Named victims of this economy, both of them real. The first is the household on a metered plan. Bandwidth-sharing reviews published in 2026 report devices moving 50 to 200 GB per month, which on a 1.2 TB cable cap is a meaningful fraction of the allowance, and on a mobile plan is a bill.

The second is the cloud tenant. Sysdig's threat research team documented attackers installing proxyware on compromised container infrastructure, where the victim organisation pays egress charges on the traffic and inherits the IP reputation.

The counter-case, and the person making it. Providers argue that the supply is consensual and compensated, and for the fraction of the pool sourced through opt-in earner apps with clear disclosure, that is defensible. Bright Data and Oxylabs both publish compliance and KYC documentation, and researchers have used opt-in pools ethically: the authors of the Pathfinder censorship study, published on arXiv in 2024, confirmed with Proxyrack that their measurement fell within its terms and that participants were informed.

I do not think that resolves the question, because consent obtained at a 50:1 value split and buried in an SDK dialog is not the same thing as an informed sale. But the ethical fraction of the pool is real and it is not zero.

What would change my mind. A provider publishing audited per-country payout data alongside per-country resale pricing. Nobody has.

What to instrument. Egress volume per host on your own estate, alerted on sustained outbound to unfamiliar ASNs. Proxyware on your infrastructure is your problem before it is anyone else's.

Roughly half the supply never agreed to anything, and two federal actions proved it

19 million IP addresses. $99 million in revenue. One administrator.

That is the US Department of Justice's account of 911 S5, unsealed on 24 May 2024, and it remains the clearest public documentation of how a residential pool actually gets built.

According to the indictment, YunHe Wang and co-conspirators distributed malware from 2014 through July 2022 via free VPN applications, named in the filing as MaskVPN, DewVPN, PaladinVPN, ProxyGate, ShieldVPN and ShineVPN, and through pay-per-install bundling with pirated software. The compromised machines were mostly residential Windows hosts. They were associated with more than 19 million unique IPs across over 190 countries, including 613,841 in the United States.

Wang received approximately $99 million between 2018 and July 2022.

The FBI, DCIS and Department of Commerce published guidance on the same day through IC3, noting the service went offline in July 2022 and returned as Cloudrouter in October 2023 before the seizure of 23 domains and more than 70 servers.

The downstream fraud is documented in the same filing: tens of thousands of fraudulent CARES Act applications, 560,000 fraudulent unemployment insurance claims, and more than 47,000 Economic Injury Disaster Loan applications.

Those claims were filed from residential IPs belonging to people who thought they had installed a free VPN.

The second case moved the recruitment upstream, into the factory.

On 5 June 2025 the FBI issued public service announcement I-060525 on BADBOX 2.0, describing consumer IoT devices, streaming boxes, projectors, aftermarket vehicle infotainment units and digital picture frames, arriving with backdoors preinstalled or acquiring them during setup from unofficial app stores. HUMAN Security's Satori team, which disclosed the campaign in March 2025, observed traffic from 222 countries and territories, with more than a third of infected devices in Brazil.

On 17 July 2025 Google filed suit in the Southern District of New York against 25 unnamed China-based defendants, alleging CFAA and RICO violations and revising the confirmed count to more than 10 million uncertified Android Open Source Project devices. Google's filing names residential proxy service as one of the monetisation paths, alongside ad fraud.

Preinstalled at manufacture. The buyer of the device never had a moment where consent was possible.

Then there is the ambiguous middle, which is larger than either.

Xianghang Mi and co-authors at NDSS 2021 identified 1,701 Android APKs across 963 apps carrying mobile proxy SDKs, with at least 300 million cumulative installs, and captured 625,000 cellular proxy IPs. Their user study found consent dialogs that were confusing where they existed at all, 48.43% of the APKs flagged as malicious by five or more antivirus engines, and 86.6% of the apps removed from Google Play by October 2019.

They also found one SDK that relayed traffic with no notification whatsoever.

Worked example, the supply mechanism from the attacker's side. Sysdig's Crystal Morin documented proxyjacking in April 2023: attackers exploiting Log4j for initial access, then installing proxyware rather than a cryptominer. Her cost model used the published Pawns rate, $9.60 per IP per month at 24-hour activity. A hundred compromised hosts returns close to $1,000 a month for effectively no compute and no detectable resource draw.

Compare that to cryptojacking, which pegs a CPU and shows up in every monitoring tool you own. Proxyjacking moves bytes.

Second worked example, the lifetime. Yang's CCS 2022 measurement found 91% of exit IPs lasted under 10 days in the pool. A blocklist refreshed weekly is chasing a population that has already turned over.

Named victims. The Texas high school student whose infected computer investigators traced during the 911 S5 case, named in DOJ court filings as the source of a recovered malware sample. And the Brazilian household on an AOSP set-top box, which is the statistically typical BADBOX 2.0 victim and has no update channel, no security patches, and no way to know.

Counter-case, adjudicated. The proxy industry's position is that malicious pools like 911 S5 are criminal outliers and the commercial market is separate. Partially true. 911 S5 was prosecuted. But Mi's 2019 S&P paper found compromised hosts inside commercial provider pools, and the 2021 SDK work found ambiguous consent as a mainstream acquisition channel rather than a criminal one. The line between harvested and purchased supply is not where the industry draws it.

What would change my mind. Per-provider node provenance attestation that a third party could verify. It does not exist today.

What to instrument. Outbound connections from your corporate estate to known proxyware gateway infrastructure, and any endpoint running a bandwidth-sharing client. Employees install these on work machines to earn $20 a month.

For four years the timing gap was 250 milliseconds and it was almost too easy

Direct connections cluster at about 4 ms. Proxied connections sit at about 250 ms. The gap is the detection.

Elisa Chiapponi, Marc Dacier, Olivier Thonnard, Mohamed Fangar and Vincent Rigal published the method as BADPASS at ISPEC in 2022, built on a four-month campaign and a dataset of more than 90 million connections. The technique compares the round-trip time observed during the TCP handshake against the round-trip time observed during the TLS exchange on the same connection. Similar values mean direct. A TLS RTT materially larger than the TCP RTT means proxied. They set the threshold at 50 ms and reported 99.01% accuracy.

A note on that figure, because it matters more than the figure. Accuracy is the wrong metric for this problem and I would not quote it in a deployment decision. What you need is the false positive rate against the population of legitimate connections you actually serve, which is a different number in every deployment. The authors' follow-up work, below, is where the useful numbers live.

The mechanism, three levels down.

Level one: two TCP sessions, one TLS session. Your server handshakes TCP with the exit node and TLS with the buyer's client.

Level two: the relay cannot terminate TLS without the destination's private key, so it forwards records opaquely. This is not a configuration choice a provider can flip. It is the constraint that makes the product work at all.

Level three: the ordering is fixed by the protocol stack. TCP's handshake must complete before any TLS record can traverse the connection, so the two measurements are taken against two different endpoints at two different moments, and there is no way to interleave them. The signal exists because TLS was designed to run over an already-established transport, a layering decision that predates residential proxies by two decades.

Worked example one, independent replication with real numbers. Barnes and Vezich Tamayo purchased IPRoyal residential bandwidth and measured against their own servers in five regions during the 2026 winter term. Direct-connection medians: 3.76 ms in Oregon, 4.03 ms in South Carolina, 3.84 ms in the Netherlands, 4.08 ms in Tokyo, 4.48 ms in São Paulo. Relayed medians through the same five: 249.21, 262.38, 245.89, 264.91 and 263.41 ms.

Roughly 800 to 1,000 connections per cell. The distributions do not overlap.

Worked example two, walking the threshold. At a 50 ms cut, every direct sample in that dataset sits 45 ms clear on one side and every relayed sample sits about 200 ms clear on the other. You could move the threshold anywhere from 20 ms to 200 ms and the classification would not change. That is what a genuinely separable feature looks like, and it is rare.

Which should have made anyone paying attention nervous, because a feature that clean is usually a feature nobody has attacked yet.

The false positive population, and this is the part BADPASS got right. Chiapponi and colleagues presented a poster at ACM IMC 2023 investigating client-environment effects on the technique. Genuine users on web browsers produced no false positives. Users sharing a connection through a phone hotspot produced no false positives.

But mobile TCP-terminating proxies, deployed by carriers inside their own networks, did produce a gap above the 50 ms threshold, though considerably smaller than the typical proxied connection. Their proposed fix is a raised threshold specifically for mobile connections.

Named victims of a naive deployment. The subscriber on a carrier running a TCP-terminating middlebox, who is proxied by their own ISP and has no idea. And the satellite broadband customer, whose baseline latency exceeds the threshold before any proxy is involved.

The attacker economics of this signal, pre-2026. Suppressing a timing gap costs nothing in bandwidth and everything in engineering. It requires per-flow state on the relay and privileged packet manipulation, which is why for four years the commercial providers did not bother. The signal survived because defeating it was not worth anyone's Tuesday.

Counter-case. Nobody serious disputed the measurement. The dispute, which arrived in 2026, was about durability.

What to instrument. Both RTTs, per connection, retained as raw values rather than a boolean. When the threshold moves, and it will, you want the history.

The RTT signal broke in February 2026, and recall fell from 99% to 8%

One published evasion, one conference, one number that should have ended the conversation about timing-only detection.

Temoor Ali, Shehel Yoosuf, Mouna Rabhi, Mashael Al Sabah and Hao Yun presented "Beyond RTT" at NDSS 2026 in San Diego in February. Their finding, stated flatly in the paper: a traffic scheduling attack reduces the recall of state-of-the-art cross-layer RTT detection from 99% to 8%.

Eight percent. The signal is not degraded. It is gone.

The mechanism is level-one simple, which is the uncomfortable part. Rather than transmitting when the application layer produces data, the relay follows a fixed schedule. The QCRI team implemented it by buffering the TLS ClientHello at the exit node and releasing it the moment the TCP tunnel to the destination is established, rather than when the buyer's client actually sends it.

The measured gap is then a property of the schedule, not of the path.

Level two on why this works: the detector was never measuring the proxy. It was measuring a coincidence of transmission timing, and any relay willing to hold a packet controls that coincidence.

Level three, the design constraint that made the fix available to attackers rather than defenders: the timing information lives entirely on the relay side of the connection. Your server observes the consequence and has no view of the cause. There is no protocol mechanism by which a destination can demand that a client prove when it actually generated a packet.

The Stanford team demonstrated the same class of evasion independently, from a different angle, in the same academic year.

Their relay measured the true client distance with a pre-flight probe, sending a fake SOCKS success response to trigger the client's first application flight early, then deliberately delayed the final outbound ACK to the destination by that measured interval. Without the manipulation, their three-region relay path produced a median gap of 147.55 ms and zero connections fell below the 50 ms threshold. With it, the median collapsed to 6.33 ms and 70.5% of flows evaded.

Two independent groups. Two different implementations. One conclusion.

Worked example, what the numbers look like on a dashboard. If you run a BADPASS-style rule today against a provider that has adopted scheduling, your proxied-connection distribution stops being a tight cluster at 250 ms and becomes indistinguishable from your direct traffic. The rule does not start alerting. It stops. A detection that silently reaches zero looks exactly like a threat that went away.

Second worked example, the cost of the evasion to the attacker. Barnes and Vezich Tamayo are honest about the limitation and it is the most useful thing in their paper for a defender. The technique requires privileged in-path packet interception on the relay host, which is impractical for userspace proxyware running on a stranger's phone without OS support or elevated permissions. It also introduces retransmissions under tight timeout settings and its own timing artifacts.

So the evasion is available to a provider that controls its exit software at a privileged level, and largely unavailable to one whose exits are opportunistic SDK installs.

That is a genuinely useful asymmetry, and it means timing detection is not worthless. It is now a signal that separates well-resourced pools from harvested ones, rather than proxied from direct.

What replaced it. Ronghong Huang, Dongfang Zhao, Xianghang Mi and Xiaofeng Wang published a transformer-based flow classifier in April 2024 that reached 93.04% recall at 92.87% precision using only the first five packets of a flow. The QCRI team's answer is CorrTransform, a two-tier design pairing a lightweight correlation-feature filter for volume with a deep model invoked selectively on high-risk cases.

Both move from timing to flow structure, which is harder to schedule away because it is a property of what the relay is doing rather than when.

Named victims of the transition. Any team whose vendor sold them proxy detection in 2024 and has not published a model update since. And the analyst who spends Q3 investigating why proxy detections dropped 90% quarter over quarter, when the answer is that the pool upgraded.

Counter-case, adjudicated. You could argue the QCRI result is a laboratory attack and commercial providers have not deployed it. The Stanford limitations section supports that reading for userspace proxyware. I still land on the pessimistic side, for one reason: the evasion is now published with implementation detail in two venues, and the class of provider that can deploy it is exactly the class with the revenue to bother.

What would change my mind. Longitudinal RTT-gap distributions from a large destination showing the 250 ms cluster still intact through late 2026. If someone has that data, publish it.

What to instrument. Stop scoring on the RTT gap alone. Keep collecting it, move it to one feature among several, and add flow-shape features that do not depend on transmission timing.

From the exit node's side, the traffic looks nothing like a household

One residential IP. 38,803 TCP streams in 69 hours. Sixty-five distinct TLS fingerprints.

That is the Stanford capture, and it is the most useful public description of what a proxied household actually emits, because almost all prior work observed these networks as a customer rather than as a node.

The raw shape first. Across 69.1 hours the single volunteered host relayed 3,730 MB to 3,419 unique destination IPs across 340 ASNs in 42 countries, initiating 42,813 TCP connections and 649 DNS lookups.

A four-person household does not contact 340 autonomous systems in three days.

The client diversity is the loudest artifact. Honeygain's share produced 21,621 TLS Client Hellos carrying 42 distinct cipher suite fingerprints. PacketStream's produced 12,261 handshakes with 23. Sixty-five fingerprints total, from one IP address.

Each fingerprint is a different buyer's client stack. Real households run a handful of browsers and a phone.

Level two on why this is unavoidable: the provider cannot normalise TLS fingerprints without terminating TLS, which is the same constraint that creates the timing gap. The exit node forwards the buyer's ClientHello byte for byte, so it forwards the buyer's fingerprint.

Level three: the ClientHello is sent before any key exchange completes, in cleartext, by design, because the server needs the cipher list and SNI to select a certificate. Every proxied buyer therefore announces the shape of their stack in plaintext at the front of every connection, and there is no version of the protocol in which they do not.

Worked example, the timing shape. Connection inter-arrival on the captured node had a coefficient of variation of 2.09 for Honeygain and 1.57 for PacketStream. Mean inter-arrival was 3.93 and 8.37 seconds. That is bursty machine traffic, not the diurnal pattern of a person.

Connection reuse ran at 94% and 98%, meaning nearly every destination IP was hit more than once. Scrapers revisit. Households do not.

Second worked example, destination mix. Extracting SNI hostnames and DNS queries, the dominant categories across both providers were e-commerce and ad tech, consistent with scraping and ad fraud. PacketStream's tail included etherscan.io, Steam, Square Enix, disposable email APIs, and login endpoints for Microsoft, Google and Okta.

Also a handful of government and institutional destinations, including NIH and PubMed, from both providers. Which is the mundane truth about these pools: a large share of the traffic is legitimate, tedious commercial scraping, and the abuse rides alongside it.

Where this helps a destination-side defender. You cannot see the exit node's other 3,418 destinations. But you can see fingerprint diversity per source IP over time, and connection reuse, and burstiness, and those are the same properties viewed through a keyhole.

An IP presenting eleven distinct JA4 fingerprints in an hour is not a family.

Attacker economics of suppressing this. Normalising fingerprints across buyers would require the provider to terminate and re-originate TLS, which breaks the product for any buyer doing certificate pinning and requires the provider to handle plaintext customer traffic, a liability most will not take. The cost is not compute. It is legal exposure and buyer trust. That makes it one of the more durable signals available.

Named victims of a naive fingerprint-diversity rule. The corporate NAT, which legitimately presents dozens of client stacks from one address. And the university residence hall, which presents hundreds.

Which is exactly why this signal needs the next section before you ship it.

Counter-case, and the researchers making it. The Stanford dataset is one IP, two providers, roughly two days. The authors say so plainly and warn that their geography is biased by the node's US location. Yang's 8-million-IP China study and Mi's 6.18-million-IP campaign are far larger but observe from the customer side, where fingerprint diversity is invisible. Nobody has published a large multi-node exit-side capture. Until someone does, treat these shapes as strongly indicative rather than calibrated.

What to instrument. Distinct TLS fingerprints per source IP per hour, destination-path entropy per source IP, and connection reuse ratio. Store them. Do not act on them yet.

Block by ASN and you will bill the collateral to Lagos

Cloudflare found that IPs behind carrier-grade NAT are rate limited three times more often than IPs that are not, despite carrying traffic that scores as more human.

Vasilis Giotsas and Marwan Fayed published the analysis on 29 October 2025. Their classifier was trained on labels assembled from distributed traceroutes across more than 9,000 RIPE Atlas probes, PTR and WHOIS keyword extraction, and directly collected VPN exit addresses, producing more than 200,000 labelled CGNAT IPs, 180,000 VPN and proxy IPs, and close to 900,000 single-subscriber IPs.

The bot-score comparison is the finding that should change your thresholds.

Median bot rate on CGNAT IPs: 4.8%. Median on non-CGNAT IPs: 4.7%. Effectively identical. But the mean tells a different story, 7% against 13.1%, because non-CGNAT addresses polarise toward either all-human or all-bot while CGNAT addresses sit in a mixed band below 15%.

CGNAT IPs are, on average, more human than the rest of the internet.

And they get rate limited three times as often, because volume from a shared address looks like volume from an individual.

Level two on the mechanism: rate limiting assumes one address maps to one accountable entity. CGNAT breaks the assumption by design, placing hundreds or thousands of subscribers behind a single public IPv4.

Level three, the design decision underneath: IPv4's 32-bit space supports 4.3 billion addresses, the RIRs exhausted their free pools by the early 2010s, and IPv6 deployment did not arrive fast enough. CGNAT is the workaround, and it is not going away. The IETF documented the consequences in RFC 6269 and RFC 7021 years before anyone was building bot scores on top of them.

Worked example, the false-positive population math. Take an ISP running 1,000 subscribers behind one address. If a single subscriber is running a scraper, a rule keyed on requests-per-IP fires on the address, and 999 households take the block. The precision of that action is 0.1%.

Now scale it. Giotsas and Fayed show that African ASNs have both the highest CGNAT deployment rates and the highest count of distinct user agents per IP, so the same rule imposes its heaviest collateral where address scarcity is worst.

Second worked example, what a proxy-flagged ASN actually contains. Consider blocking a mobile carrier ASN because your proxy scores are high there. Mi's NDSS 2021 work captured 625,000 cellular proxy IPs, so the proxy presence is real. But the carrier's total subscriber base is orders of magnitude larger, and the proxied nodes churn out of the pool inside 10 days per Yang's measurement. You are blocking a stable population to catch a transient one.

The economics of the wrong call. A blanket block on a mid-size mobile ASN in Brazil, applied to a retailer during a promotion, removes a customer segment for the duration. The attacker rotates exit country in a dashboard dropdown within a minute, at no cost. Asymmetric in the wrong direction.

Named victims, and I want to be specific rather than say "users." The Nigerian subscriber on an MTN mobile allocation shared with hundreds of others, who fails checkout because someone on the same address ran a scraper this morning. The Brazilian household whose AOSP TV box is a BADBOX 2.0 node, whose IP now carries proxy reputation the owner cannot see or clear. And the enterprise QA engineer behind a corporate egress IP that presents 40 automated client stacks by design.

Counter-case, adjudicated. Cloudflare's own evaluation found their bot scoring resilient to CGNAT bias. It is customer-configured rate limiting, not the model, that produces the 3x disparity. That is an important distinction and it cuts in a useful direction: the failure here is usually in the rules a team writes, not the score they buy.

Second counter-case. Some CGNAT ranges genuinely do carry disproportionate proxy traffic, and treating all shared addresses as untouchable means declining to act on real signal. The answer is not exemption. It is separating the rate-limit decision from the block decision, and making the shared-address status a feature rather than a bypass.

What would change my mind on the 3x figure. Independent replication from a second large CDN with a different customer mix. Cloudflare's number is measured on Cloudflare's customers' rule configurations, which is a specific population.

What to instrument. A shared-address flag as a first-class feature on every request, and separate thresholds for shared versus single-subscriber addresses. Then measure your own block rate on each population and see whether you already have this problem.

What doesn't work, with the reason each one fails

Four dead ends, each of which still ships in production somewhere.

IP reputation lists, as a primary control. The failure is arithmetic, not quality. Yang and colleagues found 91% of residential exit IPs remain in the pool under 10 days. A list refreshed weekly is describing a population that has largely turned over by the time you load it, and the addresses you inherit are households that have since left the network.

It looked plausible because it worked against datacenter proxies, where the address space is stable and the operator is the same next month. Residential supply has neither property.

There is a second, worse failure mode. Jinchun Choi and co-authors, in IEEE Access in 2020, found 86% of residential proxy IPs appearing on threat denylists against 79% of open proxy IPs, yet residential IPs appeared in verified attacks at only 0.27% versus 6.97% for open proxies. High denylist presence, low attack presence. The lists are flagging the household, not the actor.

ASN blocking. Covered above, but the mechanism deserves naming separately: an ASN is an administrative boundary, not a behavioural one. Yang's China study documented exit nodes inside government agency networks. Huang and colleagues in April 2024 documented unauthorised proxy deployments inside corporate environments. There is no ASN whose membership implies intent.

It looked plausible because ASN is cheap to compute and stable. Those are the same reasons it carries no information about the request in front of you.

Geolocation consistency checks. Comparing IP geolocation against declared address, timezone or card BIN feels like it should catch proxy use. It does not, because the buyer selects the exit country from a dropdown to match the target. Providers advertise city-level and ASN-level targeting as the headline feature.

Worse, this control fails asymmetrically. The traveller and the recent mover trip it. The attacker who spent thirty seconds in the targeting menu does not.

Assuming residential means human. This is the load-bearing assumption underneath the entire product, and it is the one that made a fifty-to-one margin possible. Every measurement study cited here contradicts it. The Stanford capture found 94% connection reuse and a coefficient of variation above 2 on a residential IP. Yang found 80% of exit nodes carried at least one malicious flow.

It looked plausible because it was true in 2015.

A fifth, which is newer and worth flagging. Buying proxy detection as a vendor boolean without asking which signal it computes. If the answer is cross-layer RTT and the vendor has not shipped since NDSS 2026, you are running a control with 8% recall against any provider that read the paper.

Ask the question. Ask for the date of the last model update. Ask for recall against scheduled traffic specifically.

How we measured this

Data: None of it is ours. This piece synthesises published measurement work rather than first-party telemetry, and I would rather say so than dress up somebody else's dataset.

Method: Sixteen primary and practitioner sources, weighted toward peer-reviewed measurement (IEEE S&P 2019, NDSS 2021, ACM CCS 2022, ISPEC 2022, ACM IMC 2023, NDSS 2026), federal enforcement filings (DOJ, IC3, CISA), and two operator-side studies with published methodology (Cloudflare in October 2025, Stanford CS244C in winter 2026). Commercial pricing figures come from vendor and affiliate sources and are labelled as claims throughout, because that is what they are.

Limitations: The exit-node characterisation rests on a single IP address enrolled in two providers over roughly two days, and its geography is biased by the node's US location. The proxy pricing spread is drawn from sources with a commercial interest in the numbers. The 3x rate-limiting disparity is measured on one CDN's customer configurations and has not been independently replicated. No figure here has been validated against traffic Blockdash scores, and where I have inferred rather than observed I have tried to say which.

Open questions

Four things I would want measured, none of which currently exist in public.

Has the RTT gap actually collapsed in production, or only in the lab? A large destination publishing monthly RTT-gap distributions through 2026 would settle it in one chart.

What does exit-side traffic look like across many nodes? Every characterisation we have of what a proxied household emits comes from single-node captures over days. A hundred nodes over a quarter would turn indicative shapes into thresholds.

What fraction of commercial pool supply is consensual, by volume rather than by node count? Node counts flatter the ethical case. Bandwidth would not.

And does static ISP proxy supply behave differently enough to need its own detection? It has no split path and no borrowed subscriber, which means most of this article does not apply to it, and almost nobody is writing about it.

Wrapping up

If you do one thing this week, separate your shared-address decision from your block decision. That is where the measured harm is, it costs nothing but rule surgery, and Cloudflare's data says you are probably three times more aggressive against your most human traffic than you intend to be.

If you do a second thing, audit what your proxy detection actually computes. Cross-layer RTT was an excellent signal for four years and it is now a signal about provider sophistication rather than about proxying.

The mental model to keep: a residential proxy is a layer-4 forwarder that cannot terminate TLS, cannot normalise the buyer's fingerprint, and cannot make one household look like one household when it is carrying sixty-five client stacks. Those constraints are structural. The timing gap was not.

Re-check in six months whether flow-correlation detection has held, or whether it went the way of the RTT gap.