What Are 4G and 5G Mobile Proxies? A Technical Guide

A mobile proxy's block resistance comes from one property: the IP belongs to a mobile network operator's address block, and that block is shared by real subscribers behind carrier-grade NAT. A site that bans the IP bans paying customers along with you. That property is a function of the core network and the address pool, not the radio.

The radio generation controls three things: how fast bits move over the air, how much of the round trip is spent in the radio layer, and, on standalone 5G only, which network function hands out your address. It does not control the ASN, the WHOIS record, the geolocation database entry, or the connection-type flag that IP intelligence vendors return. A 4G IP and a 5G IP from the same carrier in the same city usually look identical to every commercial detection service.

So the honest framing is this. Buying 5G buys throughput and, sometimes, latency. It does not buy trust.

In an LTE network your modem attaches to an eNodeB, the tower radio, and the tower connects back into the Evolved Packet Core. Signalling goes to the MME. User traffic goes through the Serving Gateway to the PDN Gateway, usually written PGW, and the PGW is the piece that matters for proxies.

The PGW is the anchor point. When your modem establishes a PDN connection against an APN, the PGW allocates an address and keeps it for the life of that session. Every packet you send exits to the internet from the PGW, so the public IP the world sees belongs to the gateway, not the tower.

Three consequences fall out of that, and they explain most of the confusion in mobile proxy marketing:

• Handovers do not change your IP. Move between cells, between towers, between tracking areas, and the S1 or X2 handover relocates the radio leg while the PGW anchor stays put. The address survives. Driving a modem around a city rotates nothing.
• Geolocation resolves to the PGW site, not to you. Carriers run a small number of PGW sites per country. If an operator anchors a whole region on two gateways, every subscriber in that region geolocates to one of two places. City-level targeting claims on 4G mobile proxies are usually wrong for exactly this reason.
• The pool is per-gateway and finite. The PGW allocates from configured pools, typically a handful of /20 or /21 blocks. That bounds how many distinct addresses one SIM can ever pull, no matter how many times you rotate.

Most commercial 5G in 2026 is still non-standalone, defined in 3GPP Release 15 and usually deployed as Option 3x. In NSA the device connects to an LTE anchor cell, the master node, and adds a 5G NR cell as a secondary carrier. This is EN-DC, E-UTRA NR dual connectivity.

The critical detail for proxy users: NSA has no 5G core. Control plane signalling runs over LTE. The session is still a PDN connection. The address still comes from the PGW inside the Evolved Packet Core. The only thing 5G contributes is extra capacity on the NR carrier.

A "5G NSA proxy" is therefore a 4G proxy in every way a website can observe. Same PGW, same pool, same NAT, same ASN, same geolocation, same connection-type flag. If a provider runs 4G and 5G ports on one carrier and you sample both, you will see addresses from the same blocks, and often the exact same addresses.

You can confirm the mode from the modem in a few seconds. Per 3GPP TS 27.007, the access technology field returned by AT+COPS? separates them cleanly:

# Quectel / Sierra / generic 3GPP modem on /dev/ttyUSB2
AT+COPS?
+COPS: 0,0,"Operator Name",7     # 7  = E-UTRAN -> plain LTE
+COPS: 0,0,"Operator Name",13    # 13 = E-UTRA-NR dual connectivity -> 5G NSA
+COPS: 0,0,"Operator Name",11    # 11 = NR connected to a 5GCN -> true 5G SA

AT+QNWINFO
+QNWINFO: "NR5G-SA","23415","NR5G BAND 78",632628

On NSA the serving cell reports as LTE with an NR secondary cell attached. On standalone the serving cell itself is NR5G-SA. If a vendor sells you 5G and AT+COPS? answers 13, you bought EN-DC, which means you bought bandwidth.

Standalone 5G, from Release 16 onward, replaces the whole core. The gNodeB talks to the 5G Core. The Session Management Function allocates the address and the User Plane Function forwards traffic, acting as the new anchor. The session is a PDU session rather than a PDN connection.

This is the first generation change that touches the thing proxies actually care about. Four differences are worth planning around.

A different pool. SA subscribers draw from UPF pools provisioned separately from the legacy PGW pools. The blocks usually still sit inside the same carrier ASN, so trust is unchanged, but the specific /21s differ. If you keep reputation history keyed on subnet, expect a fresh set.

Smaller crowds per IP. SA is designed for a distributed user plane. Operators push UPFs toward the edge so traffic breaks out locally instead of trombone-routing to a central gateway. An edge UPF serves a metro or a district rather than a whole region, so fewer real subscribers sit behind each public address. Good for latency, slightly bad for you: the shared-blame effect that makes mobile IPs hard to ban is proportional to how many innocent users share the address. A centralised LTE PGW gives you more human cover than a district-level UPF does.

Tighter geolocation. Local breakout puts the exit nearer the subscriber, so geolocation databases can resolve SA addresses to a smaller area. Useful if you need genuine city targeting, unhelpful if you were relying on the vagueness.

Faster session re-establishment. Registration and PDU session setup in the 5G core are lighter than an LTE attach, and that shows up directly in rotation time.

Network slicing and the IoT pool risk

3GPP TS 23.501 defines network slices identified by an S-NSSAI, whose slice/service type field takes standard values: 1 for enhanced mobile broadband, 2 for ultra-reliable low latency, 3 for massive IoT, 4 for vehicle-to-everything. Different slices can terminate on different UPFs with different address pools and different QoS profiles.

Here is the part nobody selling 5G proxies mentions. Proxy farms rarely run consumer handset plans, because consumer terms of service forbid resale. They run M2M or data-only SIMs. On a standalone network those SIMs are the natural candidates for the massive-IoT slice, and an IoT slice's address blocks are exactly the kind of range an IP intelligence vendor can classify separately from consumer broadband. The carrier ASN still looks fine. The usage-type label is what drifts, from "cellular consumer" toward "machine". Nothing about the radio betrays you. The provisioning does.

If you are buying 5G SA ports for anti-detection rather than for bandwidth, ask the provider which slice the SIMs sit on and what share of the pool is eMBB. Most cannot answer, which is itself an answer.

Every generation here runs carrier-grade NAT on IPv4, because there is no spare IPv4 to hand one address per subscriber. Your modem gets a private address, usually from RFC 6598 space (100.64.0.0/10) or RFC 1918 space, and the NAT translates it onto a shared public address. That sharing is the entire security model of a mobile proxy, and it is worth knowing how to size it. Our CGNAT explainer covers the mechanism. This is the arithmetic.

Carriers allocate ports in blocks per subscriber rather than one flow at a time, following the deterministic mapping approach in RFC 7422, because per-flow logging at mobile scale is impractical. A TCP or UDP address has 65,536 ports, of which roughly 64,512 sit above the well-known range and are usable. So:

usable ports per public IPv4      = 65536 - 1024 = 64512

port block 512   -> 64512 / 512  = 126 concurrent subscribers per IP
port block 1024  -> 64512 / 1024 =  63 concurrent subscribers per IP
port block 2048  -> 64512 / 2048 =  31 concurrent subscribers per IP

Concurrency is the number that matters, and it is much smaller than the marketing figure. Providers like to say "thousands of users share your IP", which is true across a whole day because sessions churn, but at any given second the count sits in the tens to low hundreds. On a 5G SA edge UPF serving a district, with a generous 2048-port block, you may be sharing with about thirty other devices. Still enough to make a permanent ban expensive for the site. Not the anonymous ocean the pitch describes.

There is a second wrinkle on IPv6-first networks. Many operators run the mobile bearer IPv6-only and deliver IPv4 through 464XLAT (RFC 6877), with a CLAT on the device and a NAT64 (RFC 6146) in the network. Your IPv4 exit address then comes from the NAT64 pool, which is typically far more heavily shared than a classic NAT44 pool. You can spot it on the modem interface:

# 464XLAT: the bearer holds only an IPv6 address, and the CLAT
# takes 192.0.0.4 out of the RFC 7335 range 192.0.0.0/29
ip -6 addr show dev wwan0
ip -4 addr show | grep -E '192\.0\.0\.[0-7]'

# Classic NAT44 CGNAT: the bearer holds an RFC 6598 address
ip -4 addr show dev wwan0 | grep -E 'inet 100\.(6[4-9]|[7-9][0-9]|1[0-2][0-7])\.'

If you see 192.0.0.4, you are behind NAT64, and your effective IPv4 pool is smaller and busier than the operator's subscriber count suggests.

The most persistent myth in mobile proxy operations is that moving between towers rotates the IP. It does not, for the anchoring reason above. Rotation happens only when the session is torn down and rebuilt, so the gateway releases your address and allocates a fresh one on reattach. Three ways to trigger it, in increasing order of reliability and time cost:

# 1. Deactivate and reactivate the PDP context. Fastest, roughly 4-10 s on LTE.
printf 'AT+CGACT=0,1\r' > /dev/ttyUSB2
sleep 2
printf 'AT+CGACT=1,1\r' > /dev/ttyUSB2

# 2. Radio off and on, the airplane cycle. More reliable, roughly 15-40 s.
printf 'AT+CFUN=4\r' > /dev/ttyUSB2
sleep 5
printf 'AT+CFUN=1\r' > /dev/ttyUSB2

# 3. Android handsets in a farm, over ADB.
adb -s "$SERIAL" shell svc data disable
sleep 4
adb -s "$SERIAL" shell svc data enable

Option 1 often returns the same address, because gateways commonly reuse a just-released address during a short hold time. Option 2 usually gets you a different one. On 5G SA the PDU session rebuild is lighter than an LTE attach, so cycle times land nearer the bottom of those ranges, which is a real operational gain if you rotate on every request.

What you should not assume is an unlimited supply of addresses. The pool is finite and you will see repeats. Measure it rather than trusting the pool-size claim on the pricing page:

import time, requests

PROXY = {"http": "http://user:pass@127.0.0.1:8001",
         "https": "http://user:pass@127.0.0.1:8001"}
ROTATE_URL = "http://127.0.0.1:8001/rotate"   # your modem manager's rotate hook

def current_ip():
    return requests.get("https://api.ipify.org", proxies=PROXY, timeout=20).text.strip()

def sample(n, settle=25):
    seen = []
    for _ in range(n):
        requests.get(ROTATE_URL, timeout=30)
        time.sleep(settle)
        seen.append(current_ip())
    return seen

# Lincoln-Petersen capture-recapture: two independent samples,
# m = addresses appearing in both, gives a pool size estimate.
first  = set(sample(60))
second = set(sample(60))
overlap = len(first & second)
estimate = (len(first) * len(second)) / overlap if overlap else float("inf")
print(f"unique in sample 1: {len(first)}, sample 2: {len(second)}, overlap: {overlap}")
print(f"estimated reachable pool: ~{estimate:.0f} addresses")

Run that before you commit to a monthly contract. A 4G port anchored on a large central PGW commonly estimates in the high hundreds to low thousands. A 5G SA port on an edge UPF frequently estimates lower, sometimes by an order of magnitude, for the same carrier and the same money. That one measurement tells you more about a mobile proxy than any spec sheet does.

Real numbers, measured to a nearby endpoint on loaded commercial networks. Treat them as planning ranges, not guarantees, because cell load dominates everything.

Two observations that should change buying decisions.

NSA barely improves latency. Control plane signalling and the initial exchange still run over LTE, so the round trip floor is set by the 4G leg. NSA uplink is often no better than LTE either, because in many Option 3x deployments the uplink stays on the LTE anchor unless supplementary uplink is configured. If your workload is request-heavy with small payloads, which describes almost all scraping, NSA gives you close to nothing.

Latency compounds inside a headless browser. A plain HTML fetch pays the round trip difference once, so 4G to 5G SA saves maybe 25 ms per page. Irrelevant. A rendered page pulling 80 subresources pays it per connection, and 80 requests at 25 ms of saved round trip is roughly two seconds per page. Across 100,000 rendered pages that is about 55 hours of wall clock. This is where 5G SA earns its premium, and nowhere else.

If you build your own ports rather than renting them, the generation gap bites hardest here.

The constraints people hit, in the order they hit them:

1. USB bus bandwidth. A USB 2.0 hub shares 480 Mbps across every port, so four 5G modems on one will never exceed roughly 35 MB/s combined, whatever the radio does. 5G modules need USB 3.x, and USB 3.x hubs with real per-port power are a different class of hardware.
2. Power budget. Twenty 4G dongles at 2 W is 40 W and a decent powered hub handles it. Twenty 5G modules at 5 W is 100 W plus inrush at attach, and bus-powered hubs brown out. That shows up as random modem drops which look exactly like carrier problems.
3. Antennas. 4x4 MIMO means four connectors per 5G module. Twenty modules is eighty antennas in one rack and they desense each other. Antenna isolation, not modem count, caps density in a 5G farm, and it is the biggest reason 5G ports cost more to operate.
4. Thermal throttling. 5G modules cut transmit power and fall back to LTE when case temperature climbs. A farm that silently drops to LTE under load is selling 5G and delivering 4G, and the customer almost never checks.
5. SIM terms. Consumer plans nearly always forbid resale, and apply deprioritisation past a soft cap in the 30 to 100 GB range. Data-only M2M plans are the compliant route, cost more per GB, and can land you on an IoT-labelled slice on a standalone network.

Typical 2026 market ranges. Mobile is billed per dedicated port or per GB on a shared pool. Datacenter is usually per IP with unmetered or generous transfer.

Put a real job through it. One million product pages at 250 KB each is 250 GB of transfer:

• Fifty datacenter IPs at $1 each: about $50 for the month, transfer included.
• Rotating residential at $4 per GB: about $1,000.
• A single 4G port pushing all 250 GB, if the SIM even allows it: $60 to $150, except you will be deprioritised long before 250 GB and one port's throughput stretches the run into days.
• A shared mobile pool at $10 per GB: about $2,500.

Mobile runs 20 to 50 times the cost of datacenter per unit of data, and the 5G premium adds another 30 to 60 percent for bandwidth you mostly cannot use, because SIM data caps bite long before radio capacity does. That is why mobile belongs on the small, high-value, block-prone slice of a workload while datacenter carries the bulk. Datacenter vs mobile proxies works through that split in detail, and the guide to using mobile proxies for social media automation and app testing covers the workloads where paying mobile prices is the correct call.

Five checks, ordered to catch the most misrepresentation soonest. Run them in the first hour of a trial.

1. Confirm the radio really attaches on NR. AT+COPS? returning 7 means plain LTE, 13 means NSA, 11 means SA. If you paid for standalone and see 13, you have non-standalone.

2. Check the exit address is genuinely mobile.

IP=$(curl -s --proxy http://user:pass@gw.example-provider.net:8001 https://api.ipify.org)
whois "$IP" | grep -iE 'netname|orgname|origin|country'
# Expect the mobile operator's ASN and a netname carrying a mobile or GPRS tag.
# A hosting ASN here means you bought a datacenter IP with a mobile label on it.

3. Estimate the pool with the capture-recapture script above, then compare it against the advertised figure.

4. Compare 4G and 5G exits on the same carrier. Sample 200 addresses from a 4G port and 200 from a 5G port. If the /21 blocks overlap, the 5G port is NSA on the same core and you are paying extra for the radio alone.

5. Measure the latency delta under your own workload, not with a speed test:

for i in $(seq 1 20); do
  curl -s -o /dev/null \
    --proxy http://user:pass@gw.example-provider.net:8001 \
    -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' \
    https://www.sparkproxy.io/
done | awk '{c+=$2; a+=$3; t+=$5; n++} END {
  printf "connect %.3fs  tls %.3fs  total %.3fs  over %d runs\n", c/n, a/n, t/n, n }'

The TLS handshake time is the honest signal, because it costs two round trips and cannot be cached away. If 5G does not beat 4G there, the extra spend buys nothing for your workload.

A carrier IP solves the network-layer half of the problem. It does nothing for the browser-layer half, and a mobile IP presenting a desktop Chrome fingerprint from a Linux host is a mismatch a detection vendor scores immediately. See TLS fingerprinting for why the handshake gives it away before your HTTP headers even arrive.

The SparkProxy Scraping API accepts your own upstream through own_proxy, so you can keep your 4G or 5G modem on the network path and let the API supply rendering, stealth and a matching device profile on top. The base URL is https://scrape.sparkproxy.io/api/v1, authenticated with an X-API-Key header.

curl -X POST "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: sk-xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.sparkproxy.io/",
    "own_proxy": "http://user:pass@203.0.113.10:8001",
    "device": "mobile",
    "render_js": true,
    "stealth": true,
    "format": "json",
    "tag": "mobile-5g/port-07"
  }'

device: "mobile" is the part people skip. It aligns viewport, user agent and touch capability with the carrier IP so the network layer and the browser layer tell the same story. stealth adds a homepage pre-warm, a forced referrer and idle delays, which matters more on a mobile IP than a datacenter one, because real mobile users do not land on deep URLs cold. Rotate the modem and retry when the target starts throwing challenges, keeping the tag stable so you can attribute failures per port afterwards:

import time, requests

API = "https://scrape.sparkproxy.io/api/v1"
HEADERS = {"X-API-Key": "sk-xxxxxxxxxxxxxxxx"}
PORT = "http://user:pass@203.0.113.10:8001"

def rotate_modem():
    requests.get("http://127.0.0.1:8001/rotate", timeout=30)
    time.sleep(25)          # LTE attach; drop to about 12 s on a 5G SA port

def fetch(url, attempts=3):
    for n in range(attempts):
        r = requests.post(API, headers=HEADERS, timeout=180, json={
            "url": url,
            "own_proxy": PORT,
            "device": "mobile",
            "render_js": True,
            "stealth": True,
            "format": "json",
            "tag": "mobile-5g/port-07",
        })
        body = r.json()
        if r.ok and body.get("status_code") == 200:
            return body
        if body.get("status_code") in (403, 429, 503):
            rotate_modem()
            continue
        time.sleep(2 ** n)
    raise RuntimeError(f"exhausted {attempts} attempts on {url}")

If your workload does not justify running modems at all, drop own_proxy and set premium_proxy: true with a country_code. That routes through SparkProxy's residential pool and costs a fraction of a dedicated mobile port on most targets.