How Does a Mobile Proxy Work? 4G/5G, CGNAT and IP Rotation

Choosing a product, a sticky duration and a test method comes down to three questions: where in the carrier network the IP is assigned, how many people CGNAT shares the same address with, and which event changes the IP.

What is a mobile proxy and which path does the traffic take?

A mobile proxy request passes through five stops:

1. The client (browser, script or app) connects to the proxy gateway with a username and password.
2. The gateway forwards the request to a modem or phone with a SIM card. This device is connected to the carrier network like any ordinary subscriber.
3. The device reaches the cell tower over the radio link: an eNodeB on 4G, a gNodeB on 5G.
4. The cell tower carries the traffic into the carrier's core network. The packet gateway is called the P-GW on 4G and the UPF on 5G; the device's IP address is managed here.
5. CGNAT at the exit of the core network translates the device's internal address into one of the carrier's public IPv4 addresses, and the request reaches the target site with that address.

The target site sees only the last step: a public IP owned by the carrier. In an IP database, the owner of this IP is registered as a mobile carrier and the connection type shows as "cellular" or "mobile". The IP lookup tool shows which network an exit lands on, with the ASN and provider name.

The device can be one of many modems lined up on a rack in a data center, or a phone working out in the field. In both cases the carrier sees the same thing: a subscriber with a SIM card, connected to the cellular network.

Where does the IP address come from on a mobile network?

When a phone turns on mobile data, it sets up a data session with the carrier. On 4G this is called a PDN connection, on 5G a PDU session. The session is opened through an APN (Access Point Name), and the carrier gives the device an address for that session. The address stays fixed for the life of the session; when the session closes and reopens, a new address may be assigned.

The address given to the device is usually not routable on the internet. On the IPv4 side, carriers mostly hand out addresses from the 100.64.0.0/10 block, set aside for carriers' internal use by RFC 6598, or from private address ranges. The device sees this internal address on its own interface. In traffic leaving the proxy, though, the address the target site sees is the public IP assigned by CGNAT.

IPv6 works differently. Many carriers give the device its own IPv6 prefix, and IPv6 traffic leaves without passing through NAT. Some networks give subscribers only IPv6; access to IPv4 sites is provided through translation methods such as 464XLAT, defined in RFC 6877. So the same SIM can appear with an IPv6 address to a site that supports IPv6, and with a CGNAT IPv4 address to a site that uses only IPv4. How the two protocols differ for proxy use is covered in the IPv4 vs IPv6 article.

Why does CGNAT make mobile IPs shared?

IPv4 addresses are scarce, and a carrier cannot give each of its millions of subscribers a public IPv4 address. CGNAT solves this with port sharing. Connections from many subscribers leave through a single public IP at the same time; the NAT device tells which connection belongs to which subscriber by the source port number. RFC 6888 defines common rules that carrier NATs of this kind should follow, such as giving the same subscriber the same external IP across connections where possible and limiting how many ports a single subscriber can use up.

From the target site's point of view, sharing has two consequences.

First, an IP address on its own does not identify a person. If a server logs only the IP, it cannot tell apart the hundreds of subscribers coming from that IP at the same moment. For this reason RFC 6302 recommends that internet-facing servers log the source port and an exact timestamp alongside the IP. If a platform blocks an IP behind CGNAT outright, it also blocks the real users on that address at the time. This is why permanent IP blocks against mobile IPs are rare; platforms put more weight on account, device and behavior signals.

Second, the behavior of another subscriber sharing the same IP can affect your requests. Heavy, suspicious traffic from the same address in the same minute can trigger extra verification or a CAPTCHA for everyone coming from that address.

A mobile IP does not make an account or a request "safe" on its own. Heavy requests carrying a desktop browser signature look inconsistent even when they come from a mobile IP. The platforms' account and behavior rules apply regardless of IP type; at WeProxy, this framework is set out in the acceptable use rules.

What changes between 4G and 5G for a mobile proxy?

The IP behavior the target site sees is largely the same on 4G and 5G. With both technologies, the carrier assigns the address in the core network and IPv4 traffic mostly leaves through CGNAT. The difference lies in the radio layer and in how the core network is built.

Many 5G networks today run in NSA (non-standalone) mode: the radio link uses 5G, but the core network is the 4G core. In this mode, IP assignment follows the same path as on 4G. In SA (standalone) 5G, the core network is 5G as well and the packet gateway is the UPF; from the subscriber's side, the address is still assigned per session.

In practice, what 5G gives a proxy user is higher bandwidth. Latency still fluctuates with signal quality, cell tower load and handovers between 4G and 5G. Speed cannot be predicted from the technology name alone; measure it on your own target.

How does IP rotation work on a mobile proxy?

A mobile device's IP changes when the data session closes and reopens. Every rotation method triggers this event in a different way.

With the first four methods, the new IP comes from the same carrier's address pool. The ASN, country and usually the region stay the same; only the address changes. Because a carrier's pool is limited, it is normal to get an IP you have already seen after a few restarts. If the carrier renews the session during its own maintenance, the IP can also change without your request. So rather than tying a long session to a single mobile IP, plan in advance how the session will continue when the IP changes.

A reset link is usually an address taken from the panel and called with a simple HTTP request. In the example below, RESET_LINK is a placeholder for the address shown in the panel:

# Renew the IP, wait for the network to reconnect, print the new exit IP
curl -s "RESET_LINK"
sleep 15
curl -s -x "http://USER:[email protected]:8989" https://api.ipify.org

The wait gives the device time to reconnect to the network. During the restart the proxy may not respond for a short while; your script should handle errors in this window with retries.

Pool rotation is a different model. There are many mobile devices behind the gateway; in rotating mode each request goes to a different device, and in sticky mode requests go to the same device for a set time. The details of choosing between sticky and rotating are in the sticky vs rotating guide.

What is the difference between a real-SIM mobile proxy and a rotating mobile pool?

WeProxy has two mobile products, and they correspond to the two models above.

Mobile 5G Proxy (Real SIM) gives you a dedicated 5G connection. The IP changes with auto-rotate at the interval you set, or with a reset link whenever you want; until you trigger a change, the exit stays on the same connection. The Lite plan covers Israel, the United Kingdom, Austria and Italy, and the Premium plan adds Texas, Florida and New York in the US. The location is chosen from the panel without changing the package. Packages are weekly or monthly with no bandwidth limit. The protocol is HTTP only, and connections use username and password only.

Rotating Mobile IPv4 Proxies is a pool of 4G/5G carrier IPs. It has more than 180 locations, and you can change the IP on every request or open a short sticky session. HTTP and SOCKS5 are supported, billing is per GB, and purchased GB stay in your balance with no expiry.

The choice depends on who should control the IP change. If you want to keep an app flow on the same carrier IP for hours and trigger the change yourself, the real-SIM product fits. If you are running many independent checks from different countries, the pool is more efficient. The general decision between mobile and residential is in the mobile vs residential article, and a comparison of all proxy types is in the residential, mobile, datacenter and ISP proxy guide.

How do you verify a mobile proxy IP?

In a few minutes you can check that the exit you bought or are trying really comes from a mobile carrier and that rotation works as expected. The Python script below sends consecutive requests over the same proxy and prints the exit IP and duration of each request:

import time
import requests

proxy = "http://USER:[email protected]:8989"
proxies = {"http": proxy, "https": proxy}

seen = []
for i in range(10):
    start = time.perf_counter()
    try:
        ip = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30)).text
    except requests.RequestException as exc:
        print(f"{i + 1}. request  error: {exc.__class__.__name__}")
        time.sleep(5)
        continue
    elapsed_ms = (time.perf_counter() - start) * 1000
    seen.append(ip)
    print(f"{i + 1}. request  IP: {ip}  time: {elapsed_ms:.0f} ms")
    time.sleep(3)

print("distinct IPs:", len(set(seen)))

Replace USER, PASSWORD, the host and the port with the values from the panel. Other Python settings are covered in the guide to using a proxy in Python.

Check in this order:

1. Note your IP address without a proxy using the My IP tool. None of the IPs from the script should match it.
2. Look up the returned IPs in the IP lookup tool. The ASN should belong to a mobile carrier, and the country should match the location you chose.
3. Check the rotation. In the pool's rotating mode the IP should change on every request; in sticky mode it should stay the same. On the real-SIM product the IP should stay the same until the reset link is called or the auto-rotate interval comes around.
4. Read the timings. Timings fluctuate on a mobile connection; look at the median and the slowest requests instead of a single measurement.
5. If no connection can be made, first confirm with the proxy checker that the proxy responds. 407 points to credentials, while 502 and timeouts point to problems on the exit side; details are in the proxy error codes guide.

Because the real-SIM product supports HTTP only, do not test it with a tool that requires SOCKS5; the tool will fail to connect and the problem will be mistaken for a proxy fault.

Which jobs need a mobile proxy, and which don't?

A mobile IP makes a difference in jobs where the target platform expects traffic from a mobile network or treats carrier networks differently:

• Testing how a mobile app behaves on carrier networks in different countries, including its regional content and redirects.
• Checking how mobile ad campaigns appear in the target country from a mobile carrier IP; the workflow is described on the ad verification page.
• Using social media accounts managed through a mobile app from a carrier IP in the same country. Platform-side workflows are on the social media use case page, and the Instagram-specific choice is in the Instagram proxy guide.

The extra cost of a mobile IP usually does not pay off in these jobs:

• High-volume data collection from public web pages. Rotating residential or datacenter pools are more efficient for this.
• City-level search result tracking. The city targeting of a residential pool is more useful here.
• Web panels that need the same IP for days. Because a mobile IP can also change on the carrier side, static residential or ISP proxies give more predictable results.

Whichever IP type you choose, KVKK and GDPR obligations for work involving personal data, the target site's terms of use and robots.txt rules still apply.