Proxy Pool Size vs Usable Capacity: What to Measure Before Scaling

A large advertised proxy pool does not tell you how much useful work your account can complete in a particular market. Treat three questions separately: which exits you actually observed, whether they meet the required context, and whether the permitted workload finishes correctly before its deadline. Buy or renew against that workload evidence, with the applicable account limits, rather than treating a global IP count as capacity.

This guide is for teams expanding an existing authorized monitoring workflow. It provides a small offline calculation and a blank capacity worksheet. All numerical examples are hypothetical; none is an IPHTML benchmark or inventory estimate.

1. Ask what the pool number actually counts

Write UNKNOWN when a supplier does not specify the counting basis. A small sample cannot confirm or disprove a historical global inventory claim. Ask the supplier to reconcile the definitions rather than multiplying a marketing number by an assumed request rate.

2. Count addresses without inventing independent supply

RFC 6269 describes how a shared public IPv4 address can represent multiple subscribers. A unique address is therefore not a unique person or household. Different textual spellings can also represent one IPv6 address; RFC 5952 explains the representation issue. Normalize address values before counting. Keep IPv4 and IPv6 summaries separate; do not interpret either as a count of devices.

An ASN identifies a routing-policy grouping, as explained by RIPE NCC. Counting ASNs does not prove independent ownership, failure isolation, residential provenance or better task results. Record the lookup method and date; missing or conflicting classifications stay unresolved. MaxMind documents geographic accuracy limits, including variation by network and geography. Treat a city label as evidence from that lookup, not a physical-location guarantee.

For the exit used by a business request, prefer logs from a destination you control and are authorized to test, with trusted handling of any intervening proxy headers. Record the observation point. A separate “what is my IP” request only establishes the exit observed at that lookup destination at that time; even nearby requests or the same session label do not prove that the business destination saw that address. If target-side exit evidence is unavailable, mark it UNKNOWN and report the lookup sample separately. Do not add probe requests outside an agreed budget, or log credentials, cookies or personal data. The session guide explains why a session identifier is not itself an exit guarantee.

3. Reproduce a two-window exit calculation

Assume two windows with six known observations each from the same observation point and route configuration. Window A sees addresses 1, 1, 2, 3, 4, 4; window B sees 3, 3, 4, 5, 6, 6. These are synthetic documentation addresses, not reachable test endpoints.

from ipaddress import ip_address

a = [ip_address("192.0.2." + str(n)) for n in [1, 1, 2, 3, 4, 4]]
b = [ip_address("192.0.2." + str(n)) for n in [3, 3, 4, 5, 6, 6]]
sa, sb = set(a), set(b)
assert len(sa) == len(sb) == 4
assert len(sa | sb) == 6
assert len(sa & sb) == 2
assert len(sb - sa) == 2
assert ip_address("2001:0db8:0:0:0:0:0:1") == ip_address("2001:db8::1")
print({"observations": len(a) + len(b), "unique_union": len(sa | sb),
       "shared_unique": len(sa & sb), "new_unique_in_b": len(sb - sa)})

Run this locally with Python 3; it sends no requests. Expected values are 12 observations, 6 unique addresses across both windows, 2 shared unique addresses and 2 addresses newly observed in B. Adding the two window counts would incorrectly report 8. Across the combined sequence, 12 − 6 = 6 observations repeat a previously observed address: 6/12 = 50%. This is an observation-frequency description, not a probability of collision, a pool-size estimate or a failure rate. A repeated exit can be desirable for a stateful task.

The calculation uses Python's address parser. Real records need an explicit invalid/missing-address count; never coerce them into one shared “unknown IP” or silently remove them from the planned workload. Do not mix ports, session IDs or IPv4-mapped representations into the count without a documented normalization rule. These six values establish only the observed set in these windows. They say nothing about whether all six were available simultaneously or remain available tomorrow.

4. Compare job delivery at a bounded load

Start from an approved task list and the representative trial plan. Freeze the route, account/plan, client version, session mode, target set, response validator, request budget and schedule. Agree on source-side and account-side limits before execution; if either is unknown, HOLD. Where a direct connection, official API, licensed feed or existing approved regional node meets the task, compare that simpler route first.

Illustrative plan: two required markets, US and DE; two application concurrency caps, 4 and 8 in-flight jobs. Each cell schedules 120 distinct jobs during 600 seconds, one at seconds 0, 5, …, 595, and allows a 60-second observation tail after the last release. Each job is one authorized GET with no retry in this simplified example. A valid result must match the approved item, required fields and market, and arrive within 60 seconds of its scheduled release, including queue time. Each cell requires at least 114 on-time valid results, complete reconciliation of all 120 planned IDs, and no unresolved outcomes or stop events. These are chosen teaching thresholds, not recommended universal limits. Actual browser jobs can issue many requests; measure their total requests and bytes separately.

Run the lower cap first, one cell at a time. Proceed to the next cap only if both lower-cap markets pass and the higher cap fits the approved limits. Use matched task lists and equivalent approved time bands, preserve actual start/end times, and repeat a lower-cap control to identify time-dependent changes. Keep a request-rate limiter as well as the concurrency cap; a cap alone does not enforce the permitted request rate. This controlled comparison changes the allowed simultaneous work, not the arrival schedule. It may never reach the cap; record actual observed concurrency. Do not force extra traffic just to fill it.

For this hypothetical table only, assume all other required evidence is complete, the remaining jobs have known late/invalid outcomes, and no stop event occurred. The CSV contains none of these results. DE shows more exits at cap 8 but misses the 114-result gate. That does not prove a proxy bottleneck: inspect client resources, queueing, target changes, parsing and route evidence. It supports holding the cap-8 expansion until the cause is understood and a matched retest passes. Cap 4 passes only this small workload scope; it does not prove capacity for twice the release rate.

The planned rate is 120/600 = 0.2 jobs per second. The threshold is 114/600 = 0.19 on-time valid jobs per second of scheduling window, with the stated observation tail. This is a window-normalized delivery measure, not measured peak throughput or a jobs-per-IP conversion. Four cells schedule 480 jobs in total; any probes are additional traffic that must have a separately approved budget. No live traffic was generated for this example.

5. Fill the capacity record before deciding to expand

Download the bilingual capacity worksheet. Its four hypothetical planning rows start with empty observations, NOT_RUN execution and HOLD decision. Replace the example markets and caps with your approved scope. Fill permission and limit references, account/route, required geography/ASN or explicit “not required”, session constraint, validator, planned job list, rate/probe budgets, time zone, owner and rollback condition before starting. Missing required metadata prevents PASS.

Keep a separate job ledger containing job_id, cell_id, scheduled_at, started_at, finished_at, outcome, validator_version, evidence_ref. Every planned ID must reconcile to an evidence-backed outcome, including jobs never started; a known unscheduled or late job is not a valid delivery. Keep exit observations in a separate ledger with cell_id, observed_at, observation_point, normalized_ip, lookup_source_version, classification, evidence_ref. Link a job to an exit only when the evidence supports that association. Store raw records privately; share redacted references with support.

1. HOLD: a required field, planned-job reconciliation, outcome, limit or required region/ASN evidence is unknown. If unique-exit evidence is unavailable but not a business requirement, record that fact; do not invent an inventory result.
2. STOP/FAIL: permission is withdrawn, a published/account limit is breached, or a refusal, challenge or 429 is observed. Stop admission and follow the applicable access/retry guidance; never rotate addresses to bypass the restriction. An inability to meet the delivery gate is also FAIL for that cell, even when the cause is unresolved.
3. PASS for the tested scope: permission and limits are confirmed, all required rows are evaluated, all planned jobs have evidence-backed outcomes, each row meets its delivery and required-context gates, and there are no unresolved outcomes or stop events. Record reviewer and time. A high aggregate score cannot rescue a failed required market.
4. Limited expansion: only after the required cells pass, review cost and a longer representative operating window. Declare a rollback trigger and owner; do not extend the conclusion to an untested arrival rate, market or period. Use the reliability scorecard for ongoing outcomes and the cost model for the economics.

Method: AI-assisted editorial analysis checked against the linked primary sources on October 18, 2026. Only offline arithmetic and the example code were executed. Worksheet thresholds, outcomes and address sequences are synthetic; real product capacity, customer results, payments and renewals are unverified.