Carrier-Grade NAT and Residential Proxy Architecture: Why Real IPs Are Getting Scarce
The global IPv4 address space ran out of new /8 allocations from IANA in February 2011. RIPE exhausted its last /8 in November 2019. APNIC hit the same wall in 2011. The practical response from consumer ISPs has been Carrier-Grade NAT (CGNAT), a second layer of address translation that puts hundreds or thousands of residential subscribers behind a single public IPv4 address. CGNAT keeps the existing Internet functional, but it has substantial implications for residential proxy infrastructure: the "one house, one IP" mental model is no longer accurate in most of the world. This post covers what CGNAT does at the protocol level, how it affects residential proxy pools, and the technical strategies providers use to deal with it.
What CGNAT Actually Does
Traditional consumer NAT translates RFC 1918 private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) inside the home to one public IPv4 address at the home router. CGNAT adds a second translation: the home router's "public" address is actually itself a private address from 100.64.0.0/10 (RFC 6598, the shared address space), and the ISP translates those 100.64 addresses to real public IPv4 addresses at the edge of the ISP network.
From the subscriber's perspective, nothing appears to change. Outbound connections work. Most inbound connections do not, because the subscriber's "public" IP is actually a 100.64 address shared with everyone else behind the same CGNAT gateway. Protocols that expect predictable inbound connectivity (FTP active mode, certain VoIP setups, BitTorrent, IPsec IKE) break or require NAT traversal workarounds.
Port Exhaustion
A CGNAT gateway maintains a translation table mapping (inside IP, inside port) to (outside IP, outside port). Each outbound flow consumes one entry. A public IPv4 address has 65,536 ports per transport protocol, but not all are usable: ports below 1024 are often reserved, and many CGNAT deployments carve up the port space into fixed blocks per subscriber (say, 2,000 ports per subscriber) to ensure fair sharing and simplify logging.
Two thousand ports sounds like plenty until you meet modern web applications. A single browser tab opening a page with 50 external resources can use 20+ concurrent TCP connections, and each requires a CGNAT port. A video call uses handful of persistent connections. A peer-to-peer application can open hundreds. Subscribers with heavy network usage hit the port ceiling and see connections fail with no error visible at the application layer, only at the CGNAT gateway's logs.
For residential proxy providers, this matters because a subscriber contributing their IP to a proxy pool is competing for port allocation with their own normal traffic. A proxy that opens 50 concurrent connections through a subscriber's CGNAT can starve the subscriber's own browser, making the proxy presence noticeable and leading to complaints, uninstalls, and pool shrinkage.
Session Affinity Across a CGNAT
When a target website sees a request from a CGNAT IP, it cannot tell which subscriber behind the NAT the request came from. If the subscriber's application makes two requests in quick succession, the target sees two requests from the same IP, possibly with slightly different source ports. If a second subscriber behind the same CGNAT makes a request 500 ms later, the target sees a third request from the same IP.
Session affinity based on IP address falls apart under CGNAT. A website that tries to track a user by IP is tracking the CGNAT gateway, not the user. This is why modern anti-bot systems have largely abandoned IP as a primary session identifier and moved to cookies, device fingerprints, and Cryptographic Client Identification via TLS session IDs or resumption tickets.
For residential proxies, the consequence is that "sticky sessions" cannot rely solely on IP. Two different proxy clients assigned to the same residential exit might land on the same target website within milliseconds of each other and be indistinguishable at the IP layer but entirely distinguishable at the cookie layer. Providers that sell "unique residential IP per session" at scale must either (a) maintain strict per-IP concurrency limits or (b) accept that the IP is a weak session identifier behind CGNAT.
How Large CGNAT Deployments Look in the Wild
Measurements from research groups including CAIDA and Cloudflare Research in 2024 and 2025 suggest that CGNAT deployment varies widely by region. Approximate figures: North America has CGNAT on roughly 15-20 percent of residential connections, mostly concentrated in a few mobile and rural ISPs. Europe is higher, around 30-40 percent, with heavy deployment in Italy and Eastern Europe. Asia-Pacific is highest, with India, Vietnam, and the Philippines running CGNAT on the majority of fixed-line residential connections. Brazil and Mexico are also heavy CGNAT users.
This has direct consequences for the makeup of a residential proxy pool. A provider selling "100 million residential IPs globally" is almost certainly counting distinct 100.64 addresses behind CGNAT as distinct IPs, even though many of them share the same public egress IP. The number of unique public egress IPs in such a pool might be an order of magnitude smaller than the headline figure.
Detecting CGNAT at the Target
Target websites can detect likely CGNAT with a few heuristics:
- Repeated IP across unrelated sessions. If the same IP shows 50 different User-Agent strings, 50 different cookie sets, and 50 different browsing patterns within a minute, it is almost certainly a CGNAT egress.
- ASN classification. Mobile carriers and Asian fixed-line ISPs are known to operate CGNAT extensively. An IP from AS 55836 (Reliance Jio) is very likely CGNAT-backed.
- Traceroute anomalies. The second hop from a CGNAT subscriber typically has a 100.64.0.0/10 address, visible in traceroute if the CGNAT gateway decrements TTL and sends ICMP responses.
For a scraper or testing workload, the implication is that "residential IP" is not a homogeneous category. A residential IP behind CGNAT shared with 500 other subscribers looks different to anti-bot systems than a fiber-to-the-home IP with a genuine one-to-one mapping.
Strategies for Providers
Residential proxy providers deal with CGNAT using a mix of approaches:
- ASN-based pool segmentation. Separate IPs from known-CGNAT ASNs into a distinct pool, priced and sold differently from IPs on known-single-subscriber ASNs. Customers who care about uniqueness pay for the non-CGNAT pool.
- Strict concurrency limits per IP. Cap outbound concurrent connections per residential peer to single digits, reducing the chance of starving the subscriber and increasing the chance that the target sees proxy traffic as a normal browsing session.
- IPv6 preference. When both the proxy peer and the target support IPv6, route over IPv6 to sidestep CGNAT entirely. This only works for targets that actually have AAAA records and treat v6 traffic the same as v4, which many anti-bot vendors do not.
- Sticky sessions via cookie forwarding, not IP pinning. Accept that the IP is shared and build session continuity at the HTTP layer instead.
Why ISP Proxies Sidestep This
ISP proxies are residential-class IPs assigned to infrastructure the provider controls directly. The provider owns the /24 or larger and announces it from their own ASN with residential classification. There is no CGNAT because there is no end-user behind the IP, just a proxy server. Each IP has the full 65,536-port TCP space available, session affinity works cleanly, and concurrency is bounded only by the provider's hardware.
This is why ISP proxies command a price premium over residential-peer proxies for workloads that need predictable per-IP behavior. A scraping pipeline that requires 50 concurrent requests per IP is trivial on ISP proxies and nearly impossible on CGNAT-backed residential peers.
The IPv6 Question
IPv6 has enough address space to give every device on Earth a unique public address. In principle, CGNAT becomes unnecessary once IPv6 is universal. In practice, IPv6 adoption at the consumer edge is above 45 percent as of April 2026 (Google IPv6 statistics), but adoption at target websites is much lower. Many anti-bot vendors still treat IPv6 traffic as a minority signal and classify it conservatively, meaning an IPv6-only residential proxy pool would have a higher block rate than its IPv4 counterpart even if the underlying connectivity is better.
This is the slow-motion transition that residential proxy architecture has to navigate for the next five to ten years: IPv4 gets scarcer and more shared, IPv6 gets more abundant but is still second-class at the application layer.
Conclusion
CGNAT is not a hypothetical concern. It is the default deployment model for residential broadband in large parts of the world, and it fundamentally changes what a "residential IP" means. Buyers of residential proxy capacity should ask providers how CGNAT-backed IPs are handled, whether pool counts reflect unique egress IPs or unique subscriber addresses, and what the concurrency limits look like per IP. Providers who cannot answer these questions are either not measuring them or not thinking about them.