When purchasing proxy IP services, the size of the resource pool is often the easiest metric to compare. A difference between several million and tens of millions of IPs appears straightforward. However, for a workload that only requires specific cities or carriers, a large total pool does not necessarily mean that enough resources are available within the required scope.

The more practical questions are: How many valid exit IPs that meet the requirements can be obtained during the actual operating period? How frequently are those IPs repeated? Can new resources be supplied promptly when existing nodes become unavailable? These three questions provide a more useful basis for deciding whether an IP pool is suitable for ongoing procurement.

Why Is “How Many IPs Are in the Pool?” an Incomplete Question?

The total pool size only indicates the theoretical resource ceiling. It does not show how many IPs a specific workload can actually use.

A single provider may cover multiple regions, carriers, and product types. An enterprise usually needs only one particular slice of that inventory. When purchasing domestic IPs from designated cities, overseas nodes and resources from other cities do not increase the usable capacity of the target locations.

An IP pool should be divided into at least three layers:

Only the third layer should be included in the final acceptance report. A successful response from an IP lookup service merely proves that the exit IP can be identified. An IP should enter the business-valid pool only after it completes a real request and passes content validation.

How Should a Valid IP Be Defined?

A valid IP must pass identity, connection, and business-level checks.

Before an exit IP enters the valid set, it should satisfy at least the following conditions:

1. The actual exit IP can be identified.
2. Its region and carrier match the procurement requirements.
3. The proxy connection and TLS handshake are completed successfully.
4. The request returns within the configured timeout.
5. The response content passes business-field validation.

Checking only the HTTP status code can result in empty pages, error templates, or malformed content being counted as successful responses. Conversely, a defect in the business parsing script should not automatically cause the exit IP to be classified as invalid. Network outcomes and business outcomes should therefore be stored separately in the logs.

Hashed exit identifiers can be used to count unique IPs without retaining complete addresses in analysis files for extended periods:

import hashlib

def ip_key(ip: str) -> str:
    return hashlib.sha256(ip.encode()).hexdigest()[:16]

record = {
    "ip_key": ip_key(observed_ip),
    "region_ok": expected_region == observed_region,
    "proxy_ok": proxy_connected,
    "business_ok": content_valid,
}

Hashing in this example is used only for deduplication and internal statistics during testing. Production logs should also follow the enterprise’s data management requirements for access control and retention periods.

How Should the IP Repetition Rate Be Calculated?

The repetition rate should be calculated by time window and request sequence. Looking only at the global unique-IP count can conceal short-term concentration.

Suppose 10,000 requests are sent within one hour and 1,000 unique exit IPs are observed. The pool may appear reasonably large. However, if most requests during the first 20 minutes are concentrated on only 50 exit IPs, the workload can still experience substantial resource concentration.

At least three metrics should be calculated:

• Global unique rate: Number of unique valid exit IPs ÷ number of valid requests.
• Window repetition rate: Number of repeated exit-IP requests within each 15-minute window ÷ number of valid requests in that window.
• Concentration: Percentage of requests handled by the most frequently observed 10% of exit IPs.

Acceptable repetition rates vary across product mechanisms. For short-lived extraction products, testing should examine how IPs are reused within their validity periods. For rotating proxy gateway products, the results should be interpreted according to the configured switching rules. Before procurement, the provider should explain how exit-IP rotation works so that the repetition rate can be evaluated in the correct context.

Why Is Geographic Accuracy More Important Than the Number of Covered Cities?

Coverage answers whether a location is available; geographic accuracy shows whether the service delivers the requested location reliably.

A platform may cover more than 200 cities, but that does not mean every city has the same level of supply at all times. Workloads that require designated regions should calculate geographic accuracy separately:

Geographic accuracy =
Requests that match the required region and pass business validation
÷
Total requests requiring that region

The denominator must not include only successful requests. Connection failures, incorrect regions, and invalid business content should all remain in the calculation. Excluding them would artificially inflate the geographic accuracy rate.

The geolocation data source should also be fixed before testing begins. Different IP geolocation databases may produce different results for border areas, mobile-network exits, or recently updated address ranges. The acceptance criteria should specify which database will be used and when the lookup was performed. Otherwise, the purchaser and provider may evaluate the same IPs using different datasets.

How Can the Replenishment Speed of an IP Pool Be Tested?

IP pool quality depends not only on the current exits but also on whether new resources enter the pool after failed nodes are removed.

A two-stage experiment can be used:

1. Run the workload at low concurrency for 20 minutes and record the current effective working set.
2. Continue with the same request model for another 40 minutes, measuring how quickly new exit IPs appear and whether failed exits continue to be assigned.

The following metrics should be recorded:

Do not proactively filter out every repeated exit IP during the initial test. Doing so mixes the client-side strategy with the platform’s scheduling behavior. Test the product using its default mechanism first, and then run a second comparison group with local deduplication enabled. This makes it easier to determine where the problem originates.

What Evidence Should an IP Pool Acceptance Report Retain?

An acceptance report should make the result reproducible instead of preserving only a final percentage.

At minimum, retain the following information:

• The tested product, region, carrier, and access method.
• The start and end times of the test, together with the time-window definition.
• Total request volume, concurrency, and timeout settings.
• Unique exit counts, geographic accuracy, and repetition distribution.
• Proxy connection outcomes and business validation outcomes.
• The IP geolocation data source.
• Retry and local deduplication strategies.
• Abnormal time windows and the location of the raw logs.

When comparing different products, the test window and request model must remain consistent. If one provider is tested at low concurrency for 30 minutes and another at high concurrency for two hours, their unique-IP counts and failure rates should not be compared directly.

FAQ

Q: Is calling an IP lookup service enough to test an IP pool?

No. An IP lookup service can identify the exit IP and its region, but it does not represent the real business path. During acceptance testing, first identify the exit and then use the same session to complete a real request. The exit information, connection result, and business validation result should all be linked to the same request identifier.

Q: Does a higher number of unique IPs always produce better business results?

Not necessarily. The unique-IP count measures resource distribution, but geographic accuracy, response completeness, and the stability of individual exits also matter. If a large number of exits can complete IP lookup requests but cannot complete real business requests, their procurement value remains limited.

Q: Why can two tests produce very different unique-IP counts?

Differences may result from the testing period, concurrency level, product rotation mechanism, real-time regional supply, or randomized scheduling. First verify whether the test conditions were identical, and then determine whether the difference reflects pool volatility. Results from tests conducted under different conditions should not be used to draw conclusions about stability.

Q: How many days should IP pool acceptance testing cover?

There is no universal duration. Short-term workloads should focus on their actual execution periods. Long-running workloads should cover both normal and peak periods and include cross-day retesting. The test duration should follow the operating pattern of the workload rather than simply being extended for its own sake.