What Is CGNAT? Carrier-Grade NAT Explained for Proxy Users

CGNAT — Carrier-Grade NAT — appears in almost every explanation of how mobile proxies work. It is one of the reasons mobile carrier IPs behave differently from datacenter or residential IPs, and it helps explain how shared carrier addressing affects IP rotation, reputation, and authentication for proxy users.

This guide explains CGNAT from first principles: what it is, how it differs from the NAT most people are familiar with on their home router, why carriers use it, what it means in practice for proxy workflows, and where its limitations are.

What Is CGNAT? The Plain-English Version

Devices communicating over an IP network need IP addressing to exchange IP traffic. IPv4, the version still widely used across the internet, uses 32-bit addresses and provides approximately 4.3 billion possible address values. That sounded like enough in the early days of the internet, but the global growth of connected devices has long since outpaced the available address space.

Network Address Translation (NAT) became a widely used solution to this problem at the consumer level. Your home router has one public IP address assigned by your ISP. All the devices in your home share that one public IP, while the router keeps track of which device sent which request and routes the responses back correctly. From the perspective of any website you visit, all your home devices look like one IP address.

Carrier-Grade NAT takes this same idea and scales it up to the ISP level. Instead of one household sharing one public IP, the ISP places an additional NAT layer between its customers and the internet. Now many different customers' connections are all sharing the same pool of public IP addresses, with the carrier's infrastructure keeping track of which customer sent which request. From the perspective of a website receiving a request, many different mobile subscribers all look like they are coming from the same IP address.

This is CGNAT: a second layer of NAT, above the level of the individual subscriber, managed by the carrier or ISP.

Home NAT vs CGNAT: The Key Difference

The distinction between standard home NAT and CGNAT matters for understanding how mobile proxies work.

How CGNAT Works Technically

When a device behind CGNAT sends a request to a server on the internet, the traffic may pass through translation layers at different points in the network. The exact number and type of translation layers depend on the network architecture. A typical residential setup may involve both customer-side NAT and carrier-side CGNAT, while a mobile device may connect directly to the carrier's NAT infrastructure.

A typical flow through two translation layers:

Device private IP (RFC 1918 range)
  -> Customer router NAT -> ISP-assigned WAN address
  -> Carrier CGNAT -> Public IPv4 address visible on the internet

The carrier's CGN device maintains translation state that maps subscriber connections to external IP addresses and ports. Because multiple subscribers may share the same public IPv4 address, the CGN uses translated source ports, addresses, and connection state to distinguish simultaneous connections. RFC 6888 defines common requirements for this type of carrier-grade NAT deployment, including requirements related to external address and port allocation.

For unsolicited inbound connections, there is normally no pre-existing translation mapping, so direct inbound access from the public internet is generally unavailable unless the carrier provides a specific mechanism to support it. Services that need to accept incoming connections such as self-hosted servers, certain VPN configurations, and peer-to-peer applications typically do not work behind CGNAT.

For typical forward-proxy workflows, traffic is initiated by the proxy device toward the target server, so CGNAT's limitations on unsolicited inbound connections generally do not affect the proxy connection itself.

Why Mobile Carriers Use CGNAT

IPv4 address exhaustion is the primary driver. IANA exhausted its remaining general-purpose IPv4 address pool in 2011, after which regional internet registries managed their remaining allocations under increasingly restrictive policies.

Mobile carriers faced a particular challenge: they needed to provide internet connectivity to massive numbers of subscribers, but public IPv4 addresses were increasingly scarce and expensive. CGNAT allowed carriers to serve many more subscribers than they had public IP addresses by sharing addresses across many connections.

IPv4 remains widely used alongside IPv6, and many networks still require translation mechanisms to provide access between IPv6-only subscriber networks and IPv4 destinations. This ongoing transition has its own implications for mobile proxies, covered in the IPv6 section below.

What CGNAT Means for Mobile Proxy IP Reputation

The network context created by carrier addressing is one factor that can make mobile carrier IPs behave differently from datacenter IPs in automated workflows.

Shared IPs and Traffic Profiles

A public IP address behind CGNAT represents many different subscribers simultaneously. Websites and platforms that receive traffic from this IP see a mix of real human browsing sessions, app usage, streaming activity, and everything else those subscribers do online.

At the IP-address level, traffic from a CGNAT address is mixed with traffic generated by many legitimate subscribers sharing the same public address. This contrasts with many datacenter IP ranges, which are associated with hosting, cloud, or server infrastructure rather than consumer mobile access networks.

Blocking and Detection Considerations

Because a CGNAT IP is shared among many legitimate subscribers, platforms may treat shared carrier IPs differently from datacenter ranges because blocking a shared carrier address can affect legitimate users. However, detection and blocking criteria are platform-specific and are generally not publicly disclosed.

This means the threshold for restricting a carrier IP can be influenced by collateral impact considerations, but it does not mean carrier IPs cannot be blocked or restricted based on behavioral signals or other evaluation criteria.

Limitations: CGNAT Is Not a Guarantee

CGNAT addresses the network origin layer of how traffic is evaluated. It does not address behavioral signals, browser fingerprints, session patterns, or account history, all of which are also evaluated by detection systems alongside the IP. A carrier IP with suspicious behavioral signals can still get flagged.

CGNAT and IP Rotation

CGNAT and mobile IP rotation are related concepts, but they are not the same thing. CGNAT allows multiple subscribers to share public IPv4 addresses, while IP changes occur according to the carrier's network management, session handling, device connectivity, and address-allocation policies.

A mobile device's public IP may change when the device reconnects, when the carrier reallocates network resources, or when the network establishes a new external mapping. However, CGNAT does not inherently require frequent IP changes. The actual rotation behavior depends on the carrier's network architecture and configuration.

For mobile proxy users, this distinction is important. A proxy provider may implement its own rotation mechanism by reconnecting a device or otherwise requesting a new network session, but that is a proxy-provider feature rather than a direct property of CGNAT itself.

This means that mobile proxy rotation should not be described as automatically natural simply because the underlying carrier network uses CGNAT. The IP type provides the network context, while the actual rotation behavior depends on the carrier and proxy implementation.

CGNAT and Proxy Authentication

CGNAT has a direct practical implication for how proxy authentication works, and it is one of the most common sources of configuration confusion for proxy users.

Why IP Whitelisting Is Less Reliable Behind CGNAT

IP whitelisting is an authentication method where the proxy provider grants access based on the client's outbound IP address. If your IP is on the whitelist, you can connect without a username or password.

Behind CGNAT, your public IP address is shared with other subscribers and may change when the carrier reassigns network resources. If the client's public IP changes, IP-based authentication can become unreliable because the newly assigned address may no longer be on the provider's allowlist. Even when the address remains stable, a CGNAT address may be shared by multiple subscribers, which can affect IP-based access control.

For clients whose public IP is shared or changes over time, username and password authentication is generally more reliable than IP allowlisting.

Username and Password Authentication

Username and password authentication sends credentials with each connection attempt. This method does not require the client's outbound IP to remain stable or uniquely identify the client, which makes it appropriate for use from behind CGNAT or any other network where the public IP may be shared or variable.

PowerProxy supports username and password authentication for proxy connections, so access does not depend on maintaining a stable client-side public IP address.

import requests

proxies = {
    "http":  "http://user:pass@gate.powerproxy.io:8000",
    "https": "http://user:pass@gate.powerproxy.io:8000",
}

r = requests.get(
    "https://ipinfo.io/json",
    proxies=proxies,
    timeout=30
)
print(r.json())

Replace user and pass with the credentials from your PowerProxy dashboard. The proxy client uses the supplied credentials when authenticating with the proxy server, without requiring the client's public IP address to be allowlisted.

IPv6 and the Future of CGNAT

IPv6 was designed to solve the address exhaustion problem that CGNAT exists to work around. An IPv6 address is 128 bits rather than IPv4's 32 bits, providing enough addresses for every device on Earth to have many unique addresses without any sharing.

As carriers migrate their internal networks to IPv6, the role of CGNAT changes. Some carriers now run IPv6-only internal networks and use translation mechanisms to provide IPv4 connectivity to subscriber devices.

464XLAT and NAT64

One important mechanism used in some carrier IPv6 deployments is 464XLAT (RFC 6877), which uses a customer-side translator (CLAT) and a provider-side translator (PLAT) to provide IPv4 connectivity across an IPv6-only network. The provider-side translation uses stateful NAT64 as described in RFC 6146, allowing IPv6-only devices to reach IPv4 destinations.

What This Means for Mobile Proxies

A mobile proxy device may operate on a carrier network that uses an IPv6-only architecture with 464XLAT. In such a deployment, the device's internal connectivity and the public IPv4 address visible to the target server can involve different translation layers.

For IPv4 destinations, the target server may see an IPv4 address allocated through the provider's NAT64/PLAT infrastructure rather than an address produced by a conventional IPv4 CGNAT deployment. The IP address is still a carrier-assigned address, but its technical origin differs from a classic CGNAT setup.

The practical implication for proxy buyers in 2026 is that verifying the specific network architecture of a proxy provider's devices matters more than it did a few years ago. A proxy operating on a conventional IPv4 CGNAT deployment behaves differently at the network level from one operating through 464XLAT.

Checking the IP Type

To check what public IP a mobile proxy is providing and which organization is associated with it:

import requests

proxies = {
    "http":  "http://user:pass@your-proxy-endpoint",
    "https": "http://user:pass@your-proxy-endpoint",
}

r = requests.get(
    "https://ipinfo.io/json",
    proxies=proxies,
    timeout=30
)
print(r.json())

The org field identifies the organization associated with the IP address, while ASN information can be used to identify the network announcing the address. A mobile carrier IP will often be associated with the carrier's organization or network in IP intelligence databases, although naming and database accuracy can vary.

IP intelligence services such as ipinfo.io can help identify the public IP, ASN, and organization associated with the connection. However, these tools do not necessarily reveal the complete underlying carrier translation architecture, such as whether the connection uses traditional CGNAT, NAT64, or 464XLAT. Replace your-proxy-endpoint with the endpoint shown in your PowerProxy dashboard.

CGNAT in Summary: What Proxy Users Need to Know

Frequently Asked Questions