Operating Mobile Proxies at Scale

Session design per job

Before tuning anything, write down what each line is for. The right rotation policy follows from the job, and most production trouble starts when one line serves two jobs with opposite needs.

Keep one owner per line. If two teams share a line, one team's rotation logs the other out. On Coronium every line is one device rented to one customer, so you control the whole line; within your company, assign it to one job too.

Rotation timing

Every rotation is a reconnect. The modem drops its carrier session, gets a new one and comes back with an address from the carrier's range. That takes seconds, and any request in flight fails. So rotate between units of work, never during them.

There are hard limits too. On Coronium the minimum interval is 60 seconds, for the timer and for manual or API rotations alike. The API rejects a timer value between 1 and 59 seconds and accepts 0 to switch the timer off (Coronium API reference). Brazil lines rotate on request only, with no timer.

A rotation can also fail quietly. The carrier sometimes hands back the same address. The restart call, POST /api/v3/modems/:id/restart, reports this in its body: the documented rule is to read the rotated field rather than the HTTP status, because a call that returns 200 with rotated: false means the address did not change. Some lines answer 202 and rotate asynchronously; for those, poll GET /api/v3/modems/:id/rotation-status until the state is done or failed (Coronium OpenAPI specification).

A safe loop looks like this: check the line is alive, call restart, read rotated or poll the status, confirm the new exit with one request through the proxy, then resume work. If the IP did not change, wait a few minutes before trying again rather than hammering the endpoint.

# Rotate one line and print the API's answer (token from Account, API Access)
curl -s -X POST "https://api.coronium.io/api/v3/modems/$MODEM_ID/restart" \
  -H "Authorization: Bearer $CORONIUM_API_TOKEN"

# For lines that rotate asynchronously, poll until state is done or failed
curl -s "https://api.coronium.io/api/v3/modems/$MODEM_ID/rotation-status" \
  -H "Authorization: Bearer $CORONIUM_API_TOKEN"

Keep rotation links out of chat tools and email. A rotation link rotates on every GET request, including the automatic preview a messaging app fetches when you paste it.

Health checks

Probe each line on a schedule, and before any batch that depends on it. There are three levels of check, from cheapest to most realistic.

The account view. GET /api/v3/account/proxies/health returns one row per line you own with an is_alive flag and a recommended action. It exists so that automation can skip a dead line instead of retrying it for minutes. Call it before each rotation cycle.

The line's own test. POST /api/v3/modems/:id/test pings through the proxy and returns the external IP and response time, with a 12-second timeout.

Your own probe. Neither of the above uses your target or your client. A short script that requests two URLs through the line, one to read the exit IP and one to time a real page, tells you what your workload will see. Here is one written for cron, run with bash probe.sh NAME PROXY_URL, that prints a single CSV row per run, using curl's write-out variables (curl manual):

# probe.sh LINE_NAME PROXY_URL : one health probe through a line, printed as one CSV row
# columns: utc_time,line,exit_ip,http_code,connect_s,first_byte_s,total_s
name="$1"; proxy="$2"
ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
opts=(-s --max-time 20)
[ -n "$proxy" ] && opts+=(-x "$proxy")
ip=$(curl "${opts[@]}" https://api.ipify.org)
timing=$(curl "${opts[@]}" -o /dev/null \
  -w '%{http_code},%{time_connect},%{time_starttransfer},%{time_total}' \
  https://www.coronium.io/api/catalog)
echo "$ts,$name,${ip:-none},$timing"

We ran it twice locally with no proxy to confirm the format; the exit address below is replaced with a documentation address:

2026-10-30T11:18:50Z,direct-test,203.0.113.10,200,0.019086,0.109837,0.129162
2026-10-30T11:18:51Z,direct-test,203.0.113.10,200,0.024388,0.119858,0.139483

Through a line, expect larger and more variable times than a wired connection. What matters is the trend per line, not one reading. Replace the second URL with a page from your own target so the probe measures what your job depends on.

When to restart and when to replace

A failed probe has three common causes, and each has its own fix.

If the exit IP is fine but your target returns challenges, the line is working and the address or your pace is the problem. Slow down first, then rotate.

If the probe times out or returns no exit IP, rotate once. A restart reconnects the modem to the carrier, which clears many stuck sessions. Wait for the rotation to finish, then probe again.

If the line still fails after a successful-looking rotation, or rotations keep returning the same address, the device or its SIM may be at fault. That is when to request a replacement rather than rotating again.

Logging what matters

Google's SRE book names four signals worth watching in any service: latency, traffic, errors and saturation (Google SRE: Monitoring Distributed Systems). They map cleanly onto a proxy fleet.

Log target status codes separately from proxy errors. A 429 Too Many Requests is the target limiting you, as defined in RFC 6585, and rotating will not fix a limit tied to an account. A 407 is the proxy asking for credentials, defined in RFC 9110, and points at a configuration change on your side.

Record the exit IP with every result row. When a batch goes wrong, the first question is always which address it ran on, and you cannot answer it later if you did not write it down.

Alert on change, not on absolutes

Fixed thresholds work badly for mobile lines. A time to first byte that is normal for one carrier in one city can be poor for another, and the same line is slower in the local evening than at night. An alert set at one number either fires constantly or never.

Alert on change instead. Keep a rolling median of each signal per line over the last few days, and alert when the current hour moves well away from it: errors doubling, first-byte time rising sharply, or the exit IP leaving the expected carrier. Each line becomes its own baseline, and a new line earns one within a couple of days.

Two alerts deserve to be absolute. A line with no successful probe for several consecutive runs is down, whatever its history. And an exit IP that belongs to the wrong country is a configuration or replacement problem that should stop location-sensitive work at once.

Route alerts to the person who owns the job on that line, not to a shared channel nobody reads. Most fleet problems are found late because the alert existed but reached no one who could act.

Replacement rules

Sometimes a device has to be swapped. On Coronium you can make up to 2 device replacements per rolling 24 hours. The replacement device has new credentials and may be on a different carrier in the same country.

Plan for that in your tooling. The API's replace call returns the new line's host, ports and credentials, and the documentation notes that the line's ID changes on replacement while the remaining rental time and your metadata carry over. Anything that stored the old ID or password, such as a browser profile, a scraper config or a reseller's customer record, needs updating at once.

Keep a short record for each replacement: the old and new line IDs, the carrier before and after, and the reason. If accounts depend on one carrier, the record tells you which ones moved networks.

A weekly routine

A fleet stays healthy with fifteen minutes a week, done the same way each time.

1. Expiry and renewal. List lines expiring in the next seven days and decide which to renew. A line that lapses is released, and its address and device go with it.
2. Probe trends. For each line, compare this week's median time to first byte and error rate with last week's. Investigate any line that worsened sharply.
3. Rotation results. Count rotations that returned rotated: false or ended failed. A rising count on one line is an early sign of a device problem.
4. Replacements. Review the week's replacement records and confirm every tool was re-bound to the new credentials.
5. Job mapping. Check that no line has picked up a second job since last week.
6. Stock. If you plan to add lines, check current stock by country and carrier first; see live options on the mobile proxies overview.

Automate steps 1 to 3 with the API and keep steps 4 and 5 as a human review. The full endpoint list is in the API reference; our MCP server exposes the same operations to AI agents if you prefer to run the routine through one.

How we checked

Endpoint behavior is taken from Coronium's published API reference and OpenAPI specification (version 3.3.10), read on 30 October 2026. The probe script was run locally without a proxy to verify its output format; the address shown was replaced with a documentation address. We did not benchmark lines or carriers, and timings through a line will differ from the sample.

Frequently asked questions