Proxies for Automation Tools

Start from one address per concurrent thread — that's the baseline the whole setup rests on — and add 20–30% on top. The reserve isn't padding: some addresses will hit targets that already dislike their subnet, some tasks will need a retry from a fresh IP, and a monitoring thread or two always appears once the pipeline runs. A 100-IP package comfortably feeds an 80-thread pipeline; a 500-thread operation shops in the 1,000-IP range.

If your threads are short-lived and stateless — pure scraping with no logins — the arithmetic changes, and rotating proxies may fit better: every request exits from a new IP and you stop managing the mapping entirely.

Three practical reasons. First, compatibility: vanilla Selenium can't answer a proxy authentication prompt without extensions or workarounds, and headless modes make credential popups strictly worse — whitelisted IPs remove the prompt entirely, so a bare ip:port works in every driver. Second, hygiene: credentials hardcoded into scripts end up in logs, repos, and screenshots; an empty credential field can't leak. Third, team setups: we whitelist up to 5 source IPs at no charge, which covers your workstation, the server the pipeline runs on, and a teammate's machine at once.

Username/password auth remains available on every plan — it's the right choice when your source IP changes often, like a laptop on home internet.

Yes — the export is configurable rather than fixed. From your Dashboard you choose the fields, their order, and the delimiter: ip:port for whitelist setups, ip:port:user:pass where credentials travel with the list, or any custom arrangement your tool's parser expects. BAS and ZennoPoster both swallow standard colon-delimited lists directly, and their built-in checkers can verify the batch right after import.

Exports can also be automated: the PapaProxy API — the key takes a couple of clicks to create in your Dashboard — returns your current list programmatically, so a pipeline can refresh its proxy file without anyone touching the panel.

Depends on whether threads carry identity. Registrations, logins, warmed profiles, anything with a session — static, one address pinned per thread or profile, because an account whose IP jumps between countries mid-session is the fastest flag automation can raise. That's the package model: the list is yours for the term, and the mapping thread-to-IP stays put.

Stateless collection — parsing search results, checking prices, harvesting public pages — carries no identity, so a new IP per request costs nothing and spreads load perfectly. Do it either way: shuffle your package list between task runs, or hand the whole problem to a rotating gateway and skip list management.