Bots & Automation Mobile Proxies with API Rotation
Automation stacks fail on the network layer more often than on the code. A Playwright worker that runs cleanly on a laptop starts hitting challenges from a cloud host, a Python job that used a shared residential pool gets a different address on every request and loses its session, and nobody can tell which of the twenty workers caused the block. NeonProxies is built for this traffic: one dedicated US mobile line per worker, an HTTP or SOCKS5 endpoint your framework already understands, a rotation link you call from code, and sticky sessions that hold until you say otherwise. This page lays out how to wire it in and how to keep it running.
Why automated traffic belongs on a carrier IP
A bot's biggest tell is its address. Datacenter ASNs are catalogued, and a residential-pool IP that a hundred other customers are also using carries their reputation along with yours. A carrier IP behind CGNAT is different in kind: a single AT&T or T-Mobile address fronts many real phones at once, so platforms score it gently because blocking it means blocking real users. Our lines are real SIMs in real modems, routers and Android phones in US cities, and each is dedicated to one customer. Your worker's requests leave from an address whose only other traffic is genuine handsets on the same tower, including the mobile-app endpoints that many platforms treat more leniently than their web front ends.
Rotate from code, hold between calls
The line exposes two behaviors and your code picks between them. In sticky mode the carrier IP stays put until you rotate, which is what a signed-in workflow needs: log in, do the work, log out on one address. When you want a fresh address, your worker requests the rotation link for that line from your NeonProxies dashboard, the modem re-attaches to the carrier gateway and receives another address from the regional pool, and the worker resumes. Build a short wait and an IP-check call into the rotation routine, since the modem takes a moment to come back and the pool is finite, so a repeated address is normal rather than a fault.
For crawl-style jobs that never sign in, rotate on a cadence tied to the target's tolerance rather than on every request. A new address every few hundred requests looks like a phone moving between towers; a new address every request looks like a pool. Rotating too eagerly also wastes the seconds each re-attach costs. Log the address you get after each rotation so you can see repeats and spacing over a day.
One worker per line and how to shape the queue
Run one worker per line. Concurrency on a single carrier IP is visible to the target as one address opening many connections at once, which is not what a phone does, and it makes rotation a shared event that interrupts every worker on the line. With a line per worker, each queue consumer owns its address, its rotation schedule and its cookie jar, and a challenge on one does not stall the others. Scale by adding lines, not threads per line.
Group jobs by target platform and by account when there is one. A worker that signs into an account should be the only worker that ever touches that account, always from the same line. Read-only workers can share a target across lines freely. Whatever the community says about how many accounts a proxy can carry, treat it as a tradeoff between cost and blast radius, and remember that every platform's terms on automated access and account use apply to your bot exactly as they would to a human.
Pick the metro the job pretends to be in
Automation that checks regional content, local pricing or metro-specific inventory should exit from a line in that metro. We offer New York, Los Angeles, Chicago, Houston, Phoenix, Miami, North Carolina and Boston. Carrier geolocation resolves to metro or state, so a Houston line is a Houston shopper for any practical check. Match the rest of the worker's identity to the line: time zone in the browser context, Accept-Language header, and a run schedule inside that metro's waking hours. A headless browser reporting Pacific time from a Boston address at four in the morning local is an inconsistency that automation detection scores.
Debugging a worker that started failing
Start with the address. Have the worker fetch an IP-check endpoint through the proxy and compare with the dashboard; a mismatch means the credentials point at a different line or the request bypassed the proxy. Then check whether a rotation happened mid-session, either from your own code or from a carrier drop that forced a re-attach, and whether the session cookies survived it. Proxy authentication errors in headless browsers usually come from passing credentials in the URL where the framework wants them in a separate option.
Timeouts at particular hours are cell congestion; our lines run at 20-45 Mbps on 4G and 50+ Mbps on 5G, and a 5G line or a quieter window fixes most of it. Repeated challenges on a healthy address point at the fingerprint, not the network, so review the browser context before blaming the line. If the line itself will not answer, email support with the line name and the time and NeonProxies will inspect the modem.
Setting up a Bots & automation proxy on NeonProxies
- Create a line for each worker in the NeonProxies dashboard and note its rotation link.
- Copy the host, port, username and password into your framework's proxy configuration or environment variables.
- Start the worker, have it call an IP-check endpoint through the proxy and log the exit IP and metro.
- Keep the session sticky during signed-in work and call the rotation link between jobs when a fresh address is wanted.
Bots & automation proxy questions
Is it allowed to run bots and automation through a mobile proxy?
Running your own automation through a proxy is your choice, but the target platform's terms govern what the automation may do. Many allow reading public data at a polite rate and prohibit automated account actions or scraping behind a login. A proxy changes the network path only; it does not make prohibited automation acceptable, and we do not assist with evading enforcement.
Should my workers use rotating or sticky sessions?
Sticky for anything signed in or stateful, rotating for read-only crawling. Our lines hold the IP until you call the rotation link, so your code decides. Rotate between jobs, not between requests, wait for the modem to re-attach, and log the new address. Expect repeats over a day because the carrier's regional pool is finite.
How many workers or accounts per line?
One worker per line, and where accounts are involved, one account per worker. Concurrency on a single carrier IP looks nothing like a phone and turns rotation into a shared interruption. Scale by adding lines. Any account-per-proxy number you have heard is a risk tradeoff, not a rule, and platform terms apply regardless.
Can I run the automation from a phone?
You can point a phone's Wi-Fi proxy at the line and run app-based automation or manual checks from it, and our real-phone lines already exit from a handset. For code-driven workers, a server or laptop running your framework with the proxy configured is the usual setup. Either way, verify the exit IP before the job starts.
Do you have US IPs in specific metros for regional jobs?
Yes. Lines are available in New York, Los Angeles, Chicago, Houston, Phoenix, Miami, North Carolina and Boston on AT&T, T-Mobile and Verizon SIMs. Carrier geolocation lands on the metro or state, which is precise enough for regional pricing, inventory and content checks. The locations page lists current availability by city and carrier.
Will a mobile proxy slow down my automation?
Throughput is 20-45 Mbps on 4G and 50+ Mbps on 5G, which is ample for page fetches and API calls from a single worker. Latency is higher than a datacenter route because traffic crosses the carrier core. Rotation adds a short pause while the modem re-attaches. Unlimited data means long-running jobs never hit a cap.