Mobile proxy concurrency planning for 2026

Mobile proxy concurrency planning is what stops your team from buying too few ports and watching jobs queue, or buying too many ports and bleeding cash. Get this right at procurement time and your ops are smooth for the contract term. Get it wrong and either the work piles up or you end up paying for unused capacity. This guide gives you sizing models, formulas, and worked examples for common 2026 workloads.

For pricing implications of concurrency choices, pair this with the TCO worksheet. For protocol context, see what is a mobile proxy.

what concurrency means for mobile proxies

Concurrency, in the mobile proxy context, is the number of simultaneous TCP connections (or HTTP requests) the proxy can carry without performance degrading. It is bounded at three layers: the per-port limit, the per-account limit, and the per-modem physical limit.

A mobile modem (the LTE module behind a port) has finite radio resources. A 4G modem typically supports 50-100 simultaneous TCP connections before performance degrades. A 5G modem can support more. Above the limit, latency spikes, packets drop, or the radio renegotiates the cell connection. The vendor caps per-port concurrency below the modem’s hard limit to leave headroom for stability.

The smallest of these binds you. For most workloads in 2026, target-imposed limits are the binding constraint, not the proxy. A target site that throttles after 5 requests/second per IP makes per-port concurrency above 5 useless.

the concurrency planning formula

The general formula:

required_ports = ceil(
    target_requests_per_second / per_port_safe_rate
)

per_port_safe_rate = min(
    vendor_per_port_concurrency,
    target_per_ip_rate_limit,
    your_app_throughput_per_request_per_second
)

The three caps are vendor, target, and your app. The vendor cap might be 30 concurrent connections per port. The target cap might be 5 requests/second. Your app might serialize at 2 useful requests/second per worker. Take the smallest.

Applied: if you need to scrape 100 product pages/second on Shopee, and Shopee throttles at ~3 RPS per IP, you need approximately 34 ports.

five workloads, five capacity profiles

Different workloads have very different concurrency profiles. Same target site, different jobs, can need very different port counts.

profile 1: continuous scraper

Always-on scraper that pulls a steady stream of pages. Throughput requirement: average + 30% headroom.

profile 2: burst scraper

Runs for 2 hours every night, peak rate during that window.

The burst job needs 5x more ports than the continuous job for the same daily volume.

profile 3: account warmer

Logs into accounts, simulates human behavior, holds session for 30+ minutes.

Account warmers do not benefit from concurrency above the active-session count.

profile 4: ad verification

Hits ads on real sites, verifies creative, checks placement.

profile 5: cyber threat intel

Pulls threat feeds, malware samples, dark-leaning sites with anti-bot.

Adjust upward if any single fetch is large or session-bound.

comparison: undersizing vs oversizing

Undersizing is the more dangerous failure. Bills can be cut next month; missed pages are gone forever.

headroom planning

Always size with headroom. The right amount depends on workload variance.

For variable workloads, prefer a vendor with burstable plans over a flat plan. Even at higher list price, burstable wins on TCO when you have variance.

per-port limits in practice

Vendor-stated per-port concurrency is the upper bound, not the real-world ceiling. Real-world ceiling depends on target site response size and whether the target throttles.

A small JSON API response (5KB, fast turnaround) might let you saturate 30 concurrent connections per port. A large product page (500KB with images, 8-second total time) saturates a single connection’s bandwidth and the radio’s capacity earlier. On heavy pages, useful concurrency per port is often 3-5 even if the vendor allows 30.

Test your specific target during the POC to find the real number.

scaling architecture

Once you have a port count, design how your jobs distribute across them.

worker pool

import asyncio
import aiohttp
import random

PORTS = [
    {"id": 1, "url": "http://u:p@gw1.example.com:8001"},
    {"id": 2, "url": "http://u:p@gw1.example.com:8002"},
    # ... up to N
]

async def worker(queue, port):
    async with aiohttp.ClientSession(
        connector=aiohttp.TCPConnector(limit=5)
    ) as session:
        while True:
            target = await queue.get()
            try:
                async with session.get(target, proxy=port["url"], timeout=20) as r:
                    body = await r.text()
                    handle_result(target, port, r.status, body)
            finally:
                queue.task_done()

async def main(targets, concurrency_per_port=5):
    queue = asyncio.Queue()
    for t in targets:
        queue.put_nowait(t)
    workers = [
        asyncio.create_task(worker(queue, port))
        for port in PORTS
        for _ in range(concurrency_per_port)
    ]
    await queue.join()
    for w in workers:
        w.cancel()

This gives you N ports x M concurrency per port. Tune M based on target type.

round-robin vs sticky assignment

Two strategies for distributing requests across ports.

For sticky, hash the account ID (or session ID) modulo port count to always route a session to the same port. This preserves cookies, IP affinity, and request patterns the target expects from one user.

def pick_port(session_id):
    return PORTS[hash(session_id) % len(PORTS)]

monitoring concurrency in production

Three metrics to track:

1. mean concurrency per port (over 5-min windows)
2. p95 concurrency per port
3. peak concurrency observed

If p95 is at the vendor’s per-port limit, you are running out of headroom. Add ports before peak grows further.

metric                  | port_1 | port_2 | port_3 | ... 
mean concurrency        | 4.2    | 4.1    | 4.3    |
p95 concurrency         | 8.0    | 8.5    | 7.9    |
peak concurrency        | 12     | 14     | 11     |
target peak             | 30     | 30     | 30     |
headroom                | 60%    | 53%    | 63%    |

concurrency and bandwidth interaction

High concurrency consumes bandwidth quickly. A 50 concurrent connection workload at 100 KB/response and 5 RPS each uses 25 MB/s, or 90 GB/hour. Pair the concurrency plan with the bandwidth planning guide.

A workload that sounds modest in concurrency terms can blow your bandwidth budget if response sizes are large.

concurrency for special cases

cdn and edge-cached targets

Some targets respond from CDN edge. The same IP hitting the same edge will see consistent latency but cached content. Higher concurrency works well here because the target is doing little work.

authenticated apis

API targets that gate by API key, not by IP, do not throttle on per-IP concurrency. You can run high per-port concurrency without target-side issues. The vendor’s per-port cap is the binding constraint.

sticky-session workloads

If your workload requires sticky sessions (login, multi-step checkout, account warming), per-port concurrency is irrelevant. You need one port per concurrent session. Plan port count = peak concurrent sessions.

decision matrix

Use the matrix below to translate workload type to concurrency plan.

changing concurrency mid-contract

Most vendors allow scaling concurrency up but make it painful to scale down. Negotiate flexibility at signing.

Sample contract clauses:

Customer may add ports during the contract term at the per-port rate
plus pro-rated monthly fee. Customer may remove ports with 30 days
notice; removed ports cease billing on the next month boundary. Customer
may temporarily increase concurrency on existing ports up to 2x for
up to 7 days per month at no additional cost.

The 2x temporary burst is the most underused concession. Vendors will agree to it because they have headroom in their pool. You get a stress safety valve without buying for peak.

sizing exercise template

WORKLOAD: ____________________
Target site(s): ____________________
Target rate limit (RPS per IP): ____
Useful concurrency per port (from POC): ____
Avg requests per second I need: ____
Peak requests per second I need: ____
Headroom %: ____

Calculated ports = ceil(peak_RPS / per_port_safe_rate * (1 + headroom))
                 = ceil(___ / ___ * ___)
                 = ___ ports

Account-level concurrency = ports * per_port_concurrency = ____
Confirm against vendor account cap.

Bandwidth budget = ports * avg_RPS * avg_response_size * 86400 / day
                 = ___ GB/day
                 = ___ GB/month
Confirm against bandwidth plan.

Fill out one of these per workload. Sum across workloads to get account total.

vendor capacity questions to ask

faq

Q: Should we buy ports for peak or for average? A: For peak +20-30%. Underbuying for peak leads to rate-limit failures during the moments that matter most.

Q: Can we share ports across workloads? A: Technically yes, operationally risky. Each workload may have different session needs. Tag traffic and segregate logically.

Q: What if our target rate-limits below 1 RPS? A: You need many ports. This is the case for high-anti-bot targets. Concurrency plan focuses on port count, not per-port concurrency.

Q: Does mobile network speed cap real concurrency? A: Yes. A modem on 4G LTE typically peaks at 50-150 Mbps. Concurrent heavy responses share that bandwidth.

Q: How does port count interact with success rate? A: More ports usually means more diversity, which improves success rate. But beyond a certain count, marginal benefit drops. Track success rate as you scale and stop when it plateaus.

For a Singapore vendor that publishes per-port concurrency limits, supports temp burst, and lets you scale ports monthly, see SMP. Or check the pricing page for port-based plans.