Proxy Manager
Software that centralizes and automates proxy usage - rotation, routing rules, retries, and per-target configuration - across your pool.
A proxy manager is software that sits between your scrapers and your proxies, automating how proxies are used. Instead of hardcoding proxy logic into every script, you point your tools at the manager, which handles IP rotation, per-domain routing rules, retries on failure, session management, and logging in one place.
It solves the mess of managing proxies at scale. Without a manager, each scraper reimplements rotation, ban detection, and retry logic. A proxy manager centralizes those concerns: define rules once - rotate every N requests, use residential IPs for this domain and datacenter for that one, retry failures with a fresh IP - and every tool benefits.
Features vary but commonly include automatic rotation, sticky-session control, per-target proxy selection, request retries and fallbacks, bandwidth and success-rate analytics, and health checks that drop dead IPs. Some are open-source tools you self-host; others are built into commercial proxy dashboards.
You need a proxy manager once your operation outgrows simple per-script configuration - multiple scrapers, multiple targets, and rules that differ by site. For a single small scraper hitting one target, a provider's gateway with built-in rotation is usually enough on its own.
The layer that decides which address runs the next request
A proxy manager sits between your code and your proxies and answers one question repeatedly: which address should this request use. Around that it usually adds health checking, retry handling, rotation policy and per-address statistics.
It becomes worth building or buying at the point where you have more than one type of proxy and more than one kind of target. Routing public pages to cheap datacenter addresses and protected pages to residential is a decision that has to live somewhere, and hardcoding it into every scraper does not scale.
The other job is memory. Recording which address served which response, and what happened, is what turns a vague sense that things are getting blocked into a specific list of addresses to rest and targets to reroute.
What to route where, with our products
A manager is only as good as its routing table. This is a sensible starting one:
Routing policy
Public pages, no filtering -> datacenter pool, cheapest per byte
403 on first request -> residential, retry once
429 -> same type, different address, back off
Login flows -> ISP or mobile, one address per account
Geo-specific checks -> residential with _c_ and _city_- Log the address with every response. Without it, you cannot distinguish a bad address from a bad target.
- Implement backoff per address rather than globally. One rate-limited address should not pause the whole run.
- Health-check static addresses on a schedule, because an expired or replaced address fails silently.
- Our API exposes what a manager needs: GET /proxies for the fleet, and the residential endpoints for gateway credentials.
Manager design mistakes
Retrying on the same address
The most common bug. A retry after a block should change the address, and often the type.
Global backoff
Pausing everything because one address hit a limit wastes the rest of the fleet.
No provenance
Without per-request address logs, every diagnosis is guesswork.
Rotating on every request by default
Sites that expect a returning visitor treat that as the anomaly. Route by target instead.
See this in practice
Ready to use proxy manager?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started