What Is CGNAT and How Does It Affect Proxies?

CGNAT (carrier-grade NAT) is network address translation applied at the scale of an entire internet provider rather than a single home. Standard NAT is what your home router does: it maps the private addresses on your LAN (like 192.168.1.20) to your one public IP so every device can share it. Carrier-grade NAT adds a second, much larger translation layer inside the provider's network, so many separate customers, each already behind their own router, also share a smaller pool of public addresses.

The result is a chain of translations often called NAT444: your device's private IP, then a carrier-internal address, then the public IP the rest of the internet sees. Engineers also call it large-scale NAT (LSN). Mobile networks were the first to lean on it, and fixed-line ISPs now use it too.

The key consequence is simple. The public IP a website logs is not yours alone. It's a shared front door for a crowd.

There aren't enough IPv4 addresses to go around. The 32-bit IPv4 space tops out at about 4.3 billion addresses, and IANA allocated its final central blocks to the regional registries on 3 February 2011 (IANA, 2026). The regional registries then ran dry over the following years. There are far more phones, routers, and IoT devices online than there are public IPv4 addresses to assign them.

IPv6 is the long-term fix, but adoption is partial and uneven, so carriers still have to serve today's traffic over IPv4. CGNAT is the bridge. Instead of buying a scarce, expensive public address for every subscriber, a carrier assigns each customer an address from a shared range and multiplexes many of them onto each public IP it owns. One public address can front a large block of subscribers, which stretches a finite pool across a growing customer base.

That economic pressure is the whole story. CGNAT is not a security feature and not a privacy feature. It's an accounting fix for a resource that ran out.

The mechanism is port multiplexing. Every TCP or UDP connection is identified by a four-part tuple: source IP, source port, destination IP, destination port. The port field is 16 bits, so there are 65,536 ports per IP per protocol. The CGNAT device hands each subscriber a slice of that port range and rewrites the source port on every outbound connection, so replies route back to the right customer.

Give each subscriber a budget of, say, 2,000 ports, and a single public IP can back dozens of subscribers holding connections at the same moment, plus many more across a day as sessions open and close. Carriers oversubscribe on purpose, betting that not everyone is at their port ceiling at once.

Two practical effects fall out of this:

• Port exhaustion. A subscriber who opens hundreds of simultaneous connections (many browser tabs, a torrent client, a chatty app) can hit their port budget and see new connections fail even though "the internet works." That's a CGNAT symptom, not a bandwidth problem.
• No inbound reachability. Your public-facing port mappings are created on demand for outbound traffic, so nothing on the internet can open a fresh inbound connection to you. Port forwarding, self-hosting a server, or receiving an unsolicited connection generally won't work behind CGNAT without a relay.

Carriers needed addresses for the middle layer, the space between the customer's router and the carrier NAT. They couldn't safely reuse ordinary private ranges like 192.168.0.0/16 or 10.0.0.0/8, because customers already use those inside their homes, which would cause collisions. So RFC 6598 (April 2012) reserved a dedicated block for exactly this job: 100.64.0.0/10, officially named Shared Address Space (RFC 6598, IETF, 2012).

That block spans 100.64.0.0 to 100.127.255.255, roughly 4 million addresses. It is not private (RFC 1918) and not public. It lives only between customer equipment and the carrier's NAT, and it must never appear as a source or destination on the open internet. If you ever see an address in this range on your router's WAN interface, that's a near-certain sign you're behind CGNAT.

CGNAT reshapes the single most important attribute of a proxy IP: its reputation. When one public address represents many real people, a website's anti-bot system faces a dilemma. Blocking that IP stops the bot, but it also blocks every legitimate customer sharing it. For a busy carrier IP, that can be a large, valuable group of real users. Most sites won't take that hit, so they treat shared carrier IPs far more gently than a datacenter IP that clearly belongs to one hosting tenant.

That's the upside for proxy users. The downside is that shared reputation flows in both directions. You don't control who else sits behind the same public IP, so you inherit their behavior. If another subscriber hammered a target an hour ago, you might land on a soft-flagged address. And CGNAT's port limits plus the lack of inbound reachability constrain how a proxy can be operated on that connection.

Here's how CGNAT touches each common proxy type:

The pattern is consistent: the more real human traffic shares an IP through CGNAT, the more a website has to lose by banning it, and the more durable that IP is for legitimate data collection. Our guides on ISP proxies and residential proxy types and use cases go deeper on where each type sits.

Mobile proxies are the clearest example of CGNAT working in a proxy user's favor. Cellular carriers run CGNAT almost universally, and their public IP pools are comparatively small next to a huge subscriber base. So a single mobile IP can represent an enormous, constantly shifting crowd of phones.

Two properties make that valuable:

• Bans are expensive for the target. Blocking a mobile carrier IP risks cutting off thousands of real mobile users of the site or app. Detection systems know this, so mobile IPs carry a high baseline trust score and get challenged less often.
• Natural rotation. Behind CGNAT, the carrier reassigns public addresses as leases expire or as devices reconnect. Mobile proxy providers trigger this on purpose, for example by cycling the radio connection, so the exit IP moves to a fresh carrier address from the same trusted pool without an obvious pattern.

The trade-off is throughput and pool size. Mobile IP pools are smaller and slower than datacenter ranges, and you share real cellular bandwidth. For targets with aggressive detection, that trade is often worth it.

You can confirm CGNAT in a couple of minutes. The core test is comparing the address your router thinks it has against the address the internet sees.

1. Check your router's WAN IP. Log into your router's admin page and find the WAN or internet IP. Note it.
2. Check your public IP. From the same network, look up the address a website sees (for example by requesting an IP-echo service).
3. Compare. If the two differ, and especially if the WAN IP falls in 100.64.0.0/10 (or an RFC 1918 range like 10.x.x.x), your traffic is being translated again upstream. That's CGNAT.

A traceroute gives a second signal: a hop in the 100.64.0.0/10 range right after your gateway is the carrier NAT. A third tell is behavioral. If port forwarding never works and inbound connections always fail, you're very likely behind CGNAT.

The shared-range check is easy to script. This snippet flags whether any address is CGNAT shared space:

import ipaddress

CGNAT = ipaddress.ip_network("100.64.0.0/10")  # RFC 6598 shared space

def is_cgnat(ip: str) -> bool:
    return ipaddress.ip_address(ip) in CGNAT

for ip in ["100.72.14.3", "203.0.113.7", "10.0.0.4"]:
    print(ip, "-> CGNAT" if is_cgnat(ip) else "-> not CGNAT")
# 100.72.14.3 -> CGNAT
# 203.0.113.7 -> not CGNAT
# 10.0.0.4   -> not CGNAT

From a website's side, detection is different. IP intelligence services label the address's ASN as a mobile or fixed-line carrier and observe many distinct device fingerprints on one IP, which is a signature of CGNAT rather than a single automated client.

If your goal is to have a target see a trusted, CGNAT-backed carrier or residential exit instead of your own address, you don't have to build the plumbing yourself. The SparkProxy Scraping API routes the request through a residential or mobile exit and returns the page. Set premium_proxy to route through a residential pool, add device to request a mobile profile, and country_code to pick the exit country:

curl -H "X-API-Key: YOUR_API_KEY" \
  "https://scrape.sparkproxy.io/api/v1?url=https://httpbin.org/ip&premium_proxy=true&country_code=US&device=mobile"

The same call in Python, reading back the exit IP the target logged:

import requests

resp = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={
        "url": "https://httpbin.org/ip",
        "premium_proxy": "true",   # residential exit
        "device": "mobile",         # request a mobile profile
        "country_code": "US",       # exit country
    },
    timeout=60,
)
print(resp.status_code, resp.text)

The IP echoed back is the shared carrier or residential address, not yours. If the call returns 429, you've hit the concurrency limit and should back off; 510 means the scrape failed (often anti-bot or timeout) and is safe to retry on a fresh exit. Because these exits ride on CGNAT-shared reputation, per-IP bans are far less likely to stick than they would on a datacenter address. Requests travel over standard HTTP, so if you'd rather wire proxies in directly, our note on proxy protocols (HTTP, HTTPS, SOCKS5) covers the connection details.