Carrier-grade NAT explained: why many phones share one IP

If you have ever checked “what is my IP” on your phone’s mobile data, then checked again a few minutes later and seen a different answer, you have already bumped into carrier-grade NAT. it is the reason hundreds or thousands of phones can appear on the internet from the same public address at the same time.

If you build or operate browser agents, it matters because websites treat a shared mobile IP very differently from a home broadband IP or a datacenter address. this article explains the concept from scratch, with no networking background assumed.

what it is

Carrier-grade NAT (CGNAT, also written CGN or LSN for large-scale NAT) is network address translation done by an internet provider instead of by your home router. to understand it, start with ordinary NAT.

Your home router already does NAT. every device at home (laptop, TV, phone on wifi) gets a private address like 192.168.1.20, and the router rewrites outgoing traffic so it all leaves through the single public IP your ISP gave you. the original specification for this is RFC 3022, “Traditional IP Network Address Translator”, published in January 2001.

CGNAT is the same idea one level up. the carrier does not have enough public IPv4 addresses for every customer, so it puts a large NAT device inside its own network. your phone gets a private address from the carrier, and the carrier’s NAT translates it to a public address shared with many other subscribers.

The shortage is real and documented. the IANA free pool of IPv4 addresses was handed out in February 2011. a mobile carrier with millions of subscribers cannot get a unique public IPv4 address for each one, so sharing became the default.

how it works

A public IPv4 address plus a port number identifies one connection. there are 65,535 usable port numbers per address and protocol, which is what makes sharing possible. the NAT device keeps a translation table that maps each private address and port to a public address and port.

Here is the walk-through for two phones on the same carrier:

• phone A has the carrier-internal address 100.64.10.5 and opens a connection to a website from source port 50000
• phone B has 100.64.22.9 and also uses source port 50000 for its own connection
• the CGNAT device sees both, and rewrites them to the same public address (say 203.0.113.7) but different public ports, such as 31001 and 31002
• when the website replies to 203.0.113.7:31001, the CGNAT looks up its table and forwards the reply to phone A

The website only ever sees 203.0.113.7. it has no way to tell from the IP alone that the two connections came from different phones.

Those 100.64.x.x addresses are not random. RFC 6598, from April 2012, reserved the block 100.64.0.0/10 as “shared address space” specifically for carrier-grade NAT. it is listed in the IANA IPv4 special-purpose address registry, and it is separate from the usual private ranges so that carriers do not collide with the 192.168.x.x or 10.x.x.x networks that customers use at home or at work.

Carriers also have to manage the port budget. if one subscriber could grab thousands of ports, a few heavy users would starve everyone else on that public IP. RFC 6888, “Requirements for Carrier-Grade NATs”, from April 2013, covers this. it discusses limiting the number of ports per subscriber, and it describes port allocation approaches such as assigning each subscriber a block of ports. how any given carrier configures this is their own business, and I cannot tell you from the outside what a specific carrier uses. what you can observe is the symptom: connections work, but the public address is shared and sometimes changes.

Two other behaviours are worth knowing:

• mappings expire. the NAT forgets a table entry after the connection goes idle for a while, so very long-idle connections can break
• the public address can change. when your phone moves between cell towers, reconnects, or the carrier rebalances load, you may come out of a different public IP in the carrier’s pool

why it matters

First, it explains why mobile IPs look “dirty” in logs but are treated gently by many sites. because one public address can stand for hundreds of real people, a website that blocks it outright risks locking out a lot of innocent users. so many sites are cautious about hard-blocking mobile carrier ranges. that is a general pattern I have seen in practice, not a guarantee, and each site decides for itself.

Second, it changes how you reason about rate limits and reputation. if your agent shares an IP with strangers, their behaviour is partly yours. a noisy neighbour on the same public address can make a site more suspicious of everyone behind it. on a home broadband line with a dedicated IP, your reputation is mostly your own. I go through that difference in more detail in residential vs mobile proxies for browser agents.

Third, it affects anything that needs inbound connections. under CGNAT you cannot easily port-forward, because the public address is not yours alone. self-hosting a server at home behind a CGNAT connection, or running a remote-access tool that expects a reachable address, often needs a relay or tunnel instead. if you have ever had a home internet plan where port forwarding silently never worked, CGNAT is a common cause.

Fourth, it matters for identifying your agent honestly. if you run agents for your own properties or for users who have consented, the IP is only one signal among several. the industry is moving toward cryptographic identity instead of guessing from addresses, which I cover in what is Web Bot Auth for AI agents. a shared IP says very little about who is behind it, and that is exactly the gap signed requests try to fill.

common misconceptions

“A shared IP means my traffic is mixed up with other people’s.” no. the translation table keeps each connection separate. phone A’s reply goes to phone A. sharing the public address does not let other subscribers read your traffic. encryption (TLS) is a separate protection, and CGNAT does not weaken it.

“CGNAT is the same as a VPN or a proxy.” no. a VPN or proxy is something you choose and route through deliberately. CGNAT happens to you, inside the carrier’s network, whether you asked for it or not. the effect on your visible IP can look similar, but the purpose is address conservation, not privacy.

“If my phone is on CGNAT, I’m anonymous.” no. the carrier keeps records of which subscriber had which translation at what time. RFC 6888 itself discusses logging as a concern for operators. carriers handle those logs under their own policies and local law. this is not legal advice, and if the question matters for you, ask a lawyer who knows your jurisdiction.

“IPv6 makes this irrelevant already.” not yet. IPv6 gives every device a globally unique address, so no translation is needed, and many carriers have rolled it out. but as of October 2026 a lot of the internet still runs on IPv4, and many sites and services still need IPv4 to be reachable. phones commonly run both, and the IPv4 side is where CGNAT shows up. I would not bet on CGNAT disappearing soon.

where it touches browser agents

If you run browser agents that talk to sites you are allowed to use, the network path you pick changes how sites see you.

A datacenter IP is obviously a server. a home broadband IP looks like one household. a mobile IP behind CGNAT looks like a crowd. that is a property of the network, not a trick, and it comes with tradeoffs: shared reputation, addresses that can rotate, and sessions that can drop if a mapping expires.

If your agent needs a stable identity across a login session, address changes mid-session can cause trouble. that is where session handling matters. for how the proxy protocol side interacts with authentication in Playwright, see SOCKS5 vs HTTP proxies for a Playwright agent that needs authentication.

If you specifically need a real Singapore mobile carrier connection, for example to check how your own site renders for local mobile users, Singapore Mobile Proxy sells real Singapore mobile IPs with sticky sessions. it is Singapore-only, so it is not a fit if you need other countries. use any mobile network only within each site’s terms and with consenting users or your own properties.

where to go from here

Next topics, in roughly this order:

• the difference between mobile, residential and datacenter addresses: start with residential vs mobile proxies for browser agents
• how proxy protocols behave when you need authentication: SOCKS5 vs HTTP proxies for a Playwright agent that needs authentication
• how agents can identify themselves without relying on IP reputation: what is Web Bot Auth for AI agents
• running many browser sessions at once, which is where shared addresses and port limits start to bite: the best ways to orchestrate many Playwright browser sessions for a fleet of agents

You can also browse everything else on the blog index.

If you want to go deeper on the primary sources, the three RFCs linked above are short and readable. RFC 3022 explains plain NAT, RFC 6598 explains why 100.64.0.0/10 exists, and RFC 6888 explains what carriers are expected to do about ports and logging.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-14.