CGNAT on T-Mobile 5G: why it's both a feature and a trap

The feature

T-Mobile's CGNAT on AS21928 is the widest in US mobile. In a dense metro during peak hours, the number of real subscribers sharing a single public IPv4 address can be 10,000 to 20,000. That's the number that makes T-Mobile mobile proxies useful:

• Blast radius. A target that blocks a T-Mobile CGNAT IP instantly cuts off ten thousand real customers. Serious US targets (Shopify Plus retail, TikTok, Instagram, major DTC) don't do that reflexively; the collateral damage is unacceptable.
• Per-IP rate limits are rounding errors. If a target rate-limits at 40 requests per minute per IP, and 10,000 real users share that IP, that's 0.4% of the real-user traffic behind the NAT. Your scraper at 1–2 QPM blends into the baseline.
• Trust-score dilution. Per-IP reputation signals are diluted across thousands of real users; the IP carries an aggregated reputation that's hard to move in any direction.

That's the dream.

The trap: port exhaustion

Each public IPv4 address has a finite port budget — technically 65,535 ports, minus reserved / ephemeral-range constraints, which leaves something on the order of 60,000 usable ports. For CGNAT, the carrier allocates a slice of that port space per subscriber. The exact slice depends on the carrier's CGNAT configuration, but T-Mobile runs conservatively (by necessity — they're packing a lot of users behind each IP).

In practice: T-Mobile subscribers on 5G SA may get somewhere between 256 and 2048 usable NAT ports each, depending on time of day and pool contention. That's plenty for normal user browsing (a few dozen open connections). It is very much not plenty for high-concurrency scraping.

What happens when you run out of ports:

1. New connection attempts fail silently or get routed to a different public IP.
2. The specific public IP rotates under you even though you asked for a sticky session.
3. The connection failures look like target-side rate-limiting, but they're actually your own CGNAT port starvation.

This is the trap. Operators new to mobile proxies see "sticky 20 minutes" and try to run 500 concurrent connections through a single sticky session. The first 200 work. The next 300 time out or drop to a different exit IP. They blame the proxy pool. It's not the pool — it's port exhaustion on a single CGNAT public IP.

The diagnosis

The symptom of port exhaustion, specifically:

• Connections work for the first 30-90 seconds.
• Then you see a wave of ECONNREFUSED, ETIMEDOUT, or TLS handshake failures.
• If you check the exit IP on successful connections, it changes mid-session even though you asked for sticky.
• If you reduce concurrency to single-digits, everything works fine.

If that's what you see, you're hitting port exhaustion, not target rate-limiting.

The fix

Four operational fixes, in order of preference:

1. Lower concurrency per sticky session

The single biggest win: don't run more than 20–30 concurrent connections through a single sticky mobile session. If you need more concurrency, spread across more sessions.

Proxaro's Carrier plan gives you 600 concurrent sessions across the pool. That's way more than any single CGNAT IP can support; it's designed to spread across multiple exit IPs.

2. Let the gateway rotate you

Our mobile gateway automatically rotates you off a port-exhausted IP to a fresh one. You lose session stickiness on that rotation (the new exit IP is probably a different CGNAT pool), but the failure mode is much cleaner than waiting for ECONNREFUSED.

Set X-PX-Auto-Rotate: true in your request headers to enable rotation-on-error. Default is off because some workloads prefer the error.

3. Use Port plan for high-concurrency dedicated

Port plan at $799 dedicates a 4G mobile port to your account — single-user, no CGNAT port contention with other Proxaro customers. You're still sharing the CGNAT pool with real T-Mobile subscribers (that's inherent to the technology), but you're not sharing ports with other proxy operators.

For high-concurrency mobile-only workloads, Port is the right answer.

4. Prefer IPv6 where the target accepts it

T-Mobile's 5G SA assigns IPv6 by default. IPv6 has no CGNAT — each subscriber gets a globally-routable v6 /64. No port exhaustion at all.

The catch: most targets still don't accept IPv6 from mobile origins. Some do — Cloudflare-fronted retail, Google APIs, a growing tier of DTC-forward brands. If your target is v6-friendly, switch to our 5G pool and pass X-PX-Stack: v6.

What T-Mobile does when the pool gets congested

Observed behavior during peak hours (weekday evenings in dense metros):

• T-Mobile's CGNAT dynamically reassigns subscribers across public IPs to balance load. Your sticky session IP may change under you every 5-8 minutes during peak, even when you asked for 20-min sticky.
• The replacement IP is usually in the same /24 (same CGNAT pool) but not always. It's almost always the same /16.
• The geographic resolution is unchanged during peak rotation (same city, same DMA).

Most real-user workloads don't notice this. Scrapers do, because they're deliberately holding the session. The 20-min sticky advertised figure is an average — peak-hour sticky holds closer to 10-15 min on T-Mobile SA.

The Verizon alternative

Verizon AS22394 runs tighter CGNAT pools: fewer subscribers per public IP, fewer ports-per-subscriber contention under load. If your workload needs a mobile exit that holds sticky reliably through peak hours, Verizon is the right pick — at the cost of the slightly narrower CGNAT blast radius.

The tradeoff:

• T-Mobile: wider blast radius (huge trust protection), more peak- hour IP rotation (sticky less reliable), better for TikTok / Instagram / high-throughput work.
• Verizon: narrower blast radius (still fine, just less), better sticky hold, better for Shopify Plus long-session / account warming / sneaker queue holds.

A quick sizing sanity check

Before you commit to a plan, do this math:

• Estimate your peak concurrent connection count to your target.
• Divide by 20–30 (safe concurrent-per-sticky).
• That's the number of sticky sessions you need running in parallel.

If the answer is ≤ 10 sessions: Coast plan fits. If ≤ 30 sessions: Carrier plan. If ≥ 50 sessions or you need a specific single carrier dedicated: Port.

References and further reading

• Wikipedia: Carrier-grade NAT — technical background
• RFC 6888 — CGN architecture and port-allocation guidance
• T-Mobile 5G SA network deployment reporting 2024-25

For the 5G-specific details, see our 5G mobile pool. For the carrier comparison, see T-Mobile vs Verizon vs AT&T.