How a mobile proxy on an Android phone rotates its IP

An Android phone with a SIM card is a residential mobile IP address, and businesses that verify ads, test geo-targeted content or run many accounts pay for exactly that. We worked with iproxy.online as a technology partner on the app that turns a phone into a proxy and the platform that controls it. This is how the IP changes, how the traffic gets through, and what it takes to keep a phone doing this for months.

Why mobile IPs are shared and trusted

Mobile carriers do not have enough public IPv4 addresses to give one to every handset. They put subscribers behind carrier-grade NAT, so one public address is shared by hundreds or thousands of phones at a time, and the address a phone has today it may not have after the next reconnect.

That sharing is why websites treat mobile addresses gently. Blocking a mobile IP blocks a crowd of real people on real phones, so anti-fraud systems score mobile ranges as low risk and rarely block them outright. The same request from a datacentre range is scored with suspicion and often challenged. A phone with a SIM therefore looks, to the site on the other end, like any other customer in that city on that carrier, which is the whole value of the product.

How a phone gets a new public address

The public address belongs to the NAT, and the NAT assigns one when the phone’s data session is established. Drop the session and start a new one, and the carrier usually assigns a different address. On Android there are a few ways to do that.

Toggling airplane mode is the blunt one. It tears down the radio, and when it comes back the data session is new. It takes a few seconds and the phone is unreachable for that time. Disabling and re-enabling mobile data does the same with less disruption to the rest of the phone. Switching the APN or forcing a change of network type also resets the session on some carriers. Which method works, and how reliably it produces a different address, varies by carrier and by Android version, because Google has steadily restricted what an app may do to the radio without a system permission. A rooted phone can do all of it directly; an unrooted phone needs the app to work through accessibility services, device-owner mode or a tethered controller, and the platform has to know which it is dealing with.

Rotation is also not guaranteed. A carrier can hand back the same address, so the app checks its public address after each attempt and tries again if nothing changed.

Scheduled, remote and sticky

Customers want the IP to change in three ways. On a schedule, every few minutes or hours, for work that should spread across many addresses. On demand, from an API call or a chat command, for an operator who wants a fresh address now. And not at all for a while, which is a sticky session: a login flow or a checkout that would break if the address changed halfway through.

The app keeps a timer for the schedule and listens for remote commands from the platform. The platform enforces the sticky window by holding off scheduled rotation while a session is pinned, and by exposing a per-session identifier so a customer’s tool can keep the same phone for the length of a task. The tension between “rotate often” and “do not rotate during my task” is resolved by making both explicit rather than by guessing.

Serving traffic from a handset

The proxy itself runs on the phone. HTTP and SOCKS5 are the common interfaces; most tools speak one or the other, and SOCKS5 carries anything, including UDP. OpenVPN and WireGuard configs are for customers who want all traffic from a machine to leave through the phone, rather than configuring each application. WireGuard is lighter on the phone’s CPU and battery and reconnects more gracefully when the mobile address changes, which it does by design.

A phone behind carrier NAT cannot accept incoming connections directly. The usual answer is a tunnel from the phone out to a relay server that the customer connects to, so the customer’s traffic goes customer to relay to phone to internet and back. The relay adds a hop and a few tens of milliseconds, and it is the part the platform has to run and scale. Alternatives such as a local Wi-Fi hotspot work for one customer in one room and nothing else.

Keeping the app alive

Android does not want a background process serving traffic for weeks. The app runs as a foreground service with a persistent notification, asks to be excluded from battery optimisation, and holds a wake lock while connections are active. Several manufacturers add their own killers on top of Doze, and a phone from one of those brands needs a per-brand setup. The platform watches for the heartbeat from each phone and tells the owner when one goes quiet, because the usual cause is that the phone rebooted after an update and the service was not restarted, or that someone touched a settings screen.

Heat is the other limit. A phone pushing sustained traffic over 4G or 5G while charging gets hot, and when it gets hot the modem throttles and the battery ages. A fleet of phones on a shelf needs airflow and chargers that do not cook them, and the app has to report temperature and throughput so the owner knows which units are struggling. Bandwidth per phone depends on the carrier and the cell, and a busy cell at peak will give a fraction of what the same phone did at three in the morning.

The control plane

Customers run many phones, often in different cities and on different carriers, and they manage them from software. A REST API covers it: list devices, get the current address, rotate, pin a session, read traffic counters, set a schedule. A Telegram bot covers the same operations for a person on the move, and carries the alerts, so the owner of a fleet hears that a phone has gone offline or that a SIM’s data allowance is nearly used before a customer does. The same bot and API are what resellers build on when they rent out access to their own phones.

What customers do with it

Ad verification is the oldest use. An agency checks that a campaign’s ads appear as bought, on a real mobile connection in the target city, because the ad server behaves differently for a datacentre address. Geo testing is similar: a product team confirms that pricing, content and consent screens look right from each market. Account management is the largest category, where a business that runs many accounts on platforms that limit accounts per address needs each one to come from a plausible, distinct mobile address and to keep that address for a session.

Each of these is legitimate when the customer is who they say they are, and a proxy platform’s abuse problem is telling those apart from the rest. Most of that work is about account behaviour rather than traffic, and we cover it in where LLMs fit in telecom platforms.

If you run, or are planning, infrastructure built on phones, SIMs and carrier connections, the telecom and messaging AI page covers what we build, and you can write to us about it.