CGNAT and mobile proxies: why IP bans do not work

For a decade and a half, website protection has been based on the assumption: one IP address equals one entity that can be punished. Cloudflare engineers measured how broken this assumption is and published the numbers. The main finding is unexpected: addresses behind which hundreds of real people sit receive rate limits three times more often than usual. Let's break down what CGNAT is, why mobile proxies are more resilient than others, and why the "crowd effect" is no longer a free pass.

Why "just banning an IP" is no longer a cheap solution

Any protection against automation — blocklists, rate limits, anomaly detectors — assumes that there is a clear respondent behind the address. Block the address — punish the violator. The cost of error is considered zero: well, we just didn't let one bot through.

This arithmetic holds true only as long as there is indeed one user behind the address. A data center IP typically has this: one address — one rented entity, and banning it costs the site nothing. For a home provider, it's one household, also nearly zero. However, for a mobile operator, a single public address can serve an entire neighborhood. And there, banning suddenly becomes a costly operation: along with the scraper, the site shuts off hundreds of real clients who have done nothing wrong.

It is this asymmetry of cost — and not the "magic of mobile IPs" — that determines who gets banned harshly and who is spared. And it has a specific technical name.

What is CGNAT and why is it ubiquitous among operators

CGNAT (Carrier-Grade NAT, also known as LSN — Large Scale NAT) is address translation at the operator level, rather than at the home router. Formally, the basis is documented in RFC 6598 (April 2012): a range of 100.64.0.0/10 was reserved for operator translators — 4,194,304 addresses that are not routed on the global network and should not cross the provider's network boundary.

The motivation in the RFC text is stated clearly: the IPv4 address space is nearly exhausted, but providers must support the growth of IPv4 clients until IPv6 is fully deployed. The /10 block was chosen as the minimum size that allows CGN to be deployed regionally without building nested translators.

Mobile operators face the most acute address shortage: millions of subscribers, tens of thousands of public IPv4 addresses. Therefore, CGNAT is not an option for them, but the default norm. One public address serves hundreds, and during peak hours, even thousands of sessions, and the subscriber address constantly changes — when switching between towers, when reconnecting sessions, when managing bandwidth.

This is where the practical value of mobile proxies comes from: you get not a "clean" IP, but an address that the site cannot shut down without collateral damage.

What exactly did Cloudflare measure

In the study "One IP address, many users: detecting CGNAT to reduce collateral effects" (Vasilis Giotas and Marwan Fayed, published October 29, 2025, updated July 15, 2026), Cloudflare addresses the inverse problem: learning to distinguish addresses behind operator translation to apply softer measures to them.

The methodology is compiled from several independent sources:

Distributed traceroute from more than 9,000 RIPE Atlas nodes — to catch addresses from 100.64.0.0/10 along the way;
WHOIS and PTR records — searching for markers cgnat, cgn, lsn in names and descriptions;
Public directories of anonymizers — for collecting addresses of VPNs and proxies;
XGBoost model on client signals, transport layer behavior, traffic volume, and diversity of destinations, aggregating both per individual IP and per /24 subnet.

The size of the training sample: 200,000 CGNAT addresses, 180,000 VPN and proxy addresses, 900,000 regular addresses, with a 70/30 split and tenfold cross-validation. The claimed quality — accuracy 0.98, weighted F1 0.97, log loss 0.04, macro-AUC 0.9946.

A separate detail that is rarely discussed in the industry: the ratio of user agents to addresses is noticeably higher in Africa than in other regions. The historical distribution of large IPv4 blocks was allocated to North America and Europe decades ago — and today this results in users from developing regions being more frequently subjected to collective punishment. Cloudflare refers to this as a socioeconomic bias.

The main figure: rate limits three times more often

The key finding of the study sounds counterintuitive to anyone used to considering mobile IPs as "untouchable": users behind CGNAT face rate limits three times more often than users outside CGNAT.

There is no contradiction here — there is a division of measures by cost. A hard ban on an address is expensive because it affects real subscribers. In contrast, rate limits, challenges, and CAPTCHAs are cheap and reversible. Therefore, protection does not shut down such an address; it squeezes it. Additionally, the mechanism triggers more frequently for an arithmetic reason: on a shared address, the traffic of many independent people accumulates, and thresholds are reached faster.

The second pair of figures explains why sites are willing to tolerate such addresses at all. The share of bots on CGNAT addresses: the median is 4.8% compared to 4.7% for others — meaning there is practically no difference in the median. However, the average tells a different story: 7% for CGNAT compared to 13.1% for non-CGNAT. This reads as follows: among regular addresses, there is a long tail of almost entirely automated ones — a typical data center range, where there are no real people at all, pulling the average up. Behind operator translation, such a tail cannot exist: there are always live subscribers diluting any automation.

For practitioners, the takeaway is straightforward: mobile proxies are purchased not for speed, but for resilience. The bandwidth per address is likely worse than that of data center IPs — but the address does not burn out permanently after the first mistake.

The bad news: CGNAT and proxies have learned to distinguish

The tempting conclusion "since many people are behind a shared address, I'll pretend to be a shared address" is undermined by the task setup in the study itself. Note the composition of the sample: CGNAT addresses and VPN/proxy addresses are two different classes, and the model was trained to distinguish between them, not to lump them together as "many users behind one IP."

They differ based on characteristics that the address renter cannot control:

Topology. Operator translation is visible on the route and in service records — by the range 100.64.0.0/10, by PTR and WHOIS.
Diversity of destinations. A real city neighborhood connects to thousands of different services; a scraping node connects to dozens, often just one.
Subnet profile. Aggregation by /24 shows whether the neighboring address block behaves like a subscriber or like a rented pool.
Client signals. The set of devices behind a shared address should resemble a real population, not just the same stack replicated a hundred times.

Moreover, this is not exclusive to Cloudflare: IP intelligence providers have long been offering not a binary flag of "proxy or not," but a numerical score — and the distinction between "shared subscriber address" and "rented pool" is already embedded in it.

Three practical takeaways

Reduce the load on the address, rather than increasing parallelism. Since a shared address is inherently closer to the rate limit threshold, the strategy of "squeeze the maximum RPS from one IP" fails the fastest. Spread the task over time and distribute it across addresses, rather than streams within one.
Protect the session. The resilience of an address is a resource you lose with aggressive IP switching: each new address goes through trust verification again. For tasks involving authorization and cart management, a sticky session is almost always more advantageous than rotation — where the boundary lies was discussed in the guide on sticky sessions.
Count successful responses, not addresses. A data center pool is cheaper per address and almost always more expensive per successful request where serious protection is in place. Comparing types makes sense only by the cost of the result: residential and mobile addresses pay off exactly where data center ones fail to reach a response.

Where the "crowd effect" doesn't help at all

It is important not to extend the logic further than it works. Protection against collective punishment only operates at the network address level. Once the platform moves to other identifiers, the advantage disappears:

Account ban. If the action is tied to an account, the quality of the IP is irrelevant to the decision.
Device and browser fingerprinting. The consistency of the stack is checked independently of the address — and it usually breaks down before the IP filter triggers.
Account linking. Platforms look for overlaps by subnets and behavioral matches, not just by exact address.

A separate factor in 2026 is supply. In a month, the market experienced two blows to sources of residential addresses: in July, LG announced a ban on proxy SDKs after discovering that about 42% of applications in its store were pulling TVs into proxy networks, and on August 3, 2026, Samsung imposed a platform-wide ban on residential proxy SDKs and has already limited the registration of new applications with such functionality. The finding was reported by Harrison Sand from the Norwegian Mnemonic; individual applications claimed installations on hundreds of millions of TVs. A detailed analysis of the first wave is in the article about the ban on proxy SDKs on LG TVs. Fewer sources of residential IPs mean higher prices, making the gap between cheap addresses and those that actually reach a response even more noticeable.

Conclusion

CGNAT has shattered the most basic assumption of web protection — "one address equals one respondent" — and protection has acknowledged and quantified this. However, this acknowledgment has not resulted in amnesty, but rather in a restructuring of measures: addresses behind operator translation are less frequently shut down permanently and three times more often throttled with limits, and their distinction from proxy pools has been moved to a separate classification task.

The practical implication for those working through proxies is simple: the type of address determines not whether you will pass or not, but at what cost the site can stop you. Build your operations around soft measures — moderate pace, long sessions, honest calculation of the cost of a successful request — and choose the type of IP based on the cost of error, not the cost per gigabyte.