The provider promises "over 10 million IPs," but in practice, you receive the same address every few minutes. This is a classic situation with inflated numbers in proxy service marketing. There is a simple and reliable way to check the real size of the pool — make a series of requests and count how many unique IPs you receive. In this article, we will discuss how to do this correctly, avoiding mistakes that distort the results.
Why Check the Size of the Proxy Pool
The size of the pool directly affects how often IP addresses are repeated when making a large number of requests. If you are an arbitrageur and manage 50 Facebook Ads accounts, a repeating IP across multiple profiles is a direct path to a chain ban of all accounts. If you are an SMM specialist managing 30 client Instagram accounts through Dolphin Anty, each repeated IP poses a risk of linking different clients' accounts in the eyes of the platform's anti-fraud system.
For sellers on Wildberries and Ozon, a small real pool means that a competitor price parser will quickly hit rate limits or CAPTCHAs — the site will see dozens of requests from the same address and block it. Marketers testing geo-targeted advertising need to understand whether the requests are genuinely coming from different subnets and cities, rather than from three repeating IPs of the same data center.
The check takes 10-15 minutes, and its result saves weeks of work that would otherwise go into unblocking accounts and figuring out why "new" IPs turned out to be old acquaintances.
Why Providers Inflate Numbers
The declared size of the pool is often the total number of addresses that have theoretically been available in the provider's network throughout its existence, including IPs that have not been issued for a long time, are banned by target platforms, or belong to inactive devices in the case of residential and mobile proxies. The actual available sample at the time of your request may be significantly smaller.
There is a second reason: IP rotation for many providers works on the principle of "session — new IP," but the rotation pool may be limited to a specific geo or ISP subnet. If you are requesting IPs only from the USA, while the provider's overall pool is counted across all countries, the actual number of addresses available to you may differ from the advertised number by tens of times.
That is why a test with 1000 requests is not paranoia, but a mandatory due diligence step before building a business process on a proxy provider with dozens of accounts or a parser that runs 24/7.
Verification Method: 1000 Requests and Unique IP Counter
The logic of the method is simple: you make N requests to a service that returns your current external IP (for example, httpbin.org/ip or api.ipify.org), and with each request, the proxy should change the IP according to your rotation settings. All obtained addresses are collected in a set, which automatically filters out duplicates. In the end, you divide the number of unique IPs by the total number of requests — this is the real uniqueness ratio of the pool.
For a correct test, three conditions are important:
- Requests should be made at intervals corresponding to a real usage scenario — there is no need to make 1000 requests in 3 seconds if in real work you change IP every 5 minutes;
- Each request should initiate a new proxy session (for residential and mobile proxies, this usually means a new sticky-session token or a complete reconnection);
- You need to test the specific geo and type of proxy that you plan to use in production — testing on a general pool will not show the real situation for a specific country.
The number 1000 is not chosen randomly — it is a sufficient sample for the statistical significance of the result, while the test is performed in a reasonable time and does not create excessive load on the provider.
Ready-made Python Script for Testing
Below is a working script that makes 1000 requests through a proxy and counts unique IPs. Replace the variables PROXY_HOST, PROXY_PORT, PROXY_USER, and PROXY_PASS with the data from your proxy provider's dashboard.
import requests
import time
from collections import Counter
PROXY_HOST = "proxy.example.com"
PROXY_PORT = "8000"
PROXY_USER = "login"
PROXY_PASS = "password"
proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
proxies = {"http": proxy_url, "https": proxy_url}
TOTAL_REQUESTS = 1000
DELAY_SECONDS = 0.5 # pause between requests
ip_counter = Counter()
errors = 0
for i in range(TOTAL_REQUESTS):
try:
response = requests.get(
"https://api.ipify.org?format=json",
proxies=proxies,
timeout=10
)
ip = response.json().get("ip")
ip_counter[ip] += 1
except Exception as e:
errors += 1
time.sleep(DELAY_SECONDS)
unique_ips = len(ip_counter)
success_requests = TOTAL_REQUESTS - errors
uniqueness_ratio = unique_ips / success_requests if success_requests else 0
print(f"Successful requests: {success_requests}")
print(f"Errors: {errors}")
print(f"Unique IPs: {unique_ips}")
print(f"Uniqueness ratio: {uniqueness_ratio:.2%}")
print("Top 5 most recurring IPs:")
for ip, count in ip_counter.most_common(5):
print(f" {ip}: {count} times")
The script also outputs the top recurring IPs — this is useful to understand if there are one or two addresses that are "stuck" and are being issued by the provider anomalously often. If such addresses exist and their share is more than 5-7% of all requests, it signals problems with rotation on the provider's side.
Quick Check via cURL Without Code
If you don't want to write a script, you can perform a simplified check via the terminal. The following command in bash will make 50 requests and save all obtained IPs to a file, providing a quick assessment without installing Python:
for i in {1..50}; do
curl -s -x "http://login:[email protected]:8000" \
https://api.ipify.org >> ip_list.txt
echo "" >> ip_list.txt
sleep 0.5
done
sort ip_list.txt | uniq -c | sort -nr
The command sort | uniq -c will show a list of unique IPs with the count of each occurrence — this follows the same principle as the Python script, but without writing a program. For a quick check, 50-100 requests are sufficient to notice obvious problems with rotation.
How to Interpret Test Results
The uniqueness ratio depends on the type of proxy. Do not expect 100% uniqueness from cheap data center proxies, and do not be alarmed if residential proxies show slightly less than 95% — some providers use pools with limited geo, where it is physically impossible to have an unlimited number of home IPs.
| Type of Proxy | Expected Uniqueness on 1000 Requests | Assessment |
|---|---|---|
| Residential Proxies | 90-99% | Normal |
| Mobile Proxies | 70-95% | Normal (depends on operator density in geo) |
| Data Center Proxies | 50-90% | Normal, but depends on the declared pool of a specific subnet |
| Any Type | less than 30% | Problem — the pool is heavily inflated in advertising or rotation is broken |
Besides the overall ratio, look at the distribution: if 900 out of 1000 requests yielded different IPs, but 100 requests came from the same address — this is worse than a uniform distribution with the same average ratio. Uniformity is more important than the overall percentage of uniqueness, especially for multi-accounting tasks, where each repeated binding of an IP to a profile is critical.
Checking the Pool in Dolphin Anty and AdsPower Without Code
If you do not want to work with scripts, anti-detect browsers provide built-in tools for similar checks, albeit on a smaller scale. In Dolphin Anty, open the "Proxies" section → select the desired proxy → click the IP check button several times in a row with a couple of minutes interval and manually record the results in a table. In AdsPower, similarly: in the proxy management section, there is a "Check" button that shows the current IP, country, and network provider — repeated checks at intervals will show whether the address changes.
This manual method is suitable for quick selective checks before purchasing a large volume of proxies, but it does not replace a full test with 1000 requests if you plan to scale the process to dozens or hundreds of accounts. For serious verification before long-term use, it is better to run the script from the section above and obtain statistically significant data.
Common Mistakes When Testing the Pool
The first mistake is making requests too quickly, without pauses. Some providers intentionally return the same IP within a short time window (sticky session), and a fast test without pauses will show distorted low uniqueness, while everything is fine at real usage intervals.
The second mistake is testing through an IP checking service that caches responses or returns geolocation instead of the actual address. Use verified services like ipify.org or httpbin.org/ip, which return clean JSON without caching on their side.
The third mistake is not accounting for timeouts and connection errors in the overall statistics. If 200 out of 1000 requests ended with an error, and you calculate uniqueness from 1000 instead of 800 successful requests, the ratio will be distorted in a negative way.
The fourth mistake is testing the wrong geo that is actually needed in work. The pool may be huge globally, but tiny for a specific city or state — and local geo is often critical for geo-targeted advertising or local SMM.
What to Do If the Pool Turns Out to Be Small
If the test showed a low uniqueness ratio, the first step is to write to the provider's support with specific test figures and ask for an explanation. Diligent providers usually transparently explain the structure of the pool by geo and type of proxy and may offer a narrower but genuinely working sample.
The second option is to reconsider the type of proxy for the task. For farming accounts and working with advertising platforms, it is often more effective not to increase the intensity of data center IP rotation, but to switch to residential or mobile proxies, where the very nature of the network ensures a more natural distribution of addresses and less visibility to anti-fraud systems.
The third option is to reduce the load on the pool: increase the interval between IP changes, distribute tasks among several subnets or geos if the platform allows working from more than one specific country. Sometimes the solution lies not in increasing the pool, but in changing the request pattern to fit the actually available volume of unique addresses.
Conclusion
A test with 1000 requests counting unique IPs is a quick and objective way to verify whether the real proxy pool matches the provider's declared figures. A ready-made Python script or a simplified check via cURL takes minimal time, and the result helps avoid account bans, blocks when scraping marketplaces, and unnecessary expenses on proxies that do not fit the task.
If you plan to farm Facebook Ads or TikTok Ads accounts, manage dozens of Instagram profiles through Dolphin Anty or AdsPower, pay attention to mobile proxies — they usually show a more natural distribution of IPs and less frequently fall under the platform's anti-fraud systems. For scraping prices on Wildberries and Ozon or tasks where speed and stability are important, it is worth testing residential proxies using the method from this article before building a permanent workflow on them.