Your provider claims 10 million IPs. You're still getting banned. This tool tells you why.
proxy-reality-check measures the real, observable pool behind your proxy plan — not the marketing number. It fires concurrent requests through your proxies, counts unique exit IPs, tracks collisions, and estimates actual pool size using collision math. In 60 seconds you'll know whether you have 200 real IPs or 2 million.
Short answer to why your scraper keeps getting blocked: Most residential proxy plans route through a shared pool of a few hundred to a few thousand addresses regardless of what the dashboard says. When you run 200 threads against a pool of 650 IPs, 70% of your requests share an address — and every target site sees that pattern within seconds.
- You bought a "10M IP" residential proxy plan and you're still getting CAPTCHAs and bans
- Your scraper worked fine at 50 threads but breaks at 200 — and you don't know why
- Your proxy provider support says "the pool is fine" but you want to verify that yourself
- You need to know how many concurrent threads your plan can actually support
- You want to compare providers with real numbers before spending money
Windows (.exe) — download, double-click, done:
Mac / Linux / Python users:
pip install httpx
python proxy-reality-check.pyProxy providers sell access to a shared pool. Your "10 million IP" plan doesn't give you 10 million dedicated addresses — it gives you a slice of a rotating pool that's shared across every customer on that tier.
The actual IPs available to your account at any given moment is typically:
| Provider claim | Reality (typical) |
|---|---|
| 10M+ IPs | 500 – 5,000 usable IPs per plan |
| Premium residential | 1,000 – 20,000 at any time |
| Static ISP | What they say (these are dedicated) |
| Datacenter | Small pool, often flagged by default |
When your thread count exceeds the real pool size, multiple threads start sharing exit IPs. Sites detect this because:
- The same IP appears across many sessions simultaneously
- Request patterns from one IP don't match a single human browser
- IP reuse rate is abnormally high in a short window
proxy-reality-check measures all of this and shows you the exact numbers.
Run the tool and pick a mode:
╔════════════════════════════════════════════════════╗
║ proxy-reality-check // NIXNODE ║
╚════════════════════════════════════════════════════╝
1 sprint 1 min — how many real IPs do I have?
2 marathon X min — is my pool growing or draining?
3 scale scan what thread count can my plan actually support?
4 burst how many unique IPs per synchronized batch?
Runs for 60 seconds at N threads. Answers: how big is my real pool?
Unique IPs seen 1,847
Collisions 312 (14.4%)
Estimated pool ≈ 2,100 IPs
Verdict: medium — moderate rate-limit risk
Capacity ~10,500 checks/hour
Runs for X minutes and logs new IPs discovered each minute. Answers: does my provider replenish IPs over time, or is the pool fixed?
A healthy provider shows consistent new IPs per minute. A pool that stops growing after minute 3 means you've already seen all the IPs available to you.
Automatically tests 25 → 50 → 100 → 150 → 200 → 300 → 500 threads (30 seconds each). Answers: what is the highest thread count I can run before IP sharing breaks my success rate?
25 threads 25 unique / 25 (100%) no collision yet
50 threads 50 unique / 50 (100%) no collision yet
100 threads 98 unique / 100 (98%) pool ≈ 2,401
150 threads 143 unique / 150 (95%) pool ≈ 2,187
200 threads 181 unique / 200 (91%) pool ≈ 1,980 <-- sweet spot
300 threads 238 unique / 300 (79%) pool ≈ 1,850
500 threads 296 unique / 500 (59%) pool ≈ 1,711
The sweet spot is 200 threads — above that, IP sharing accelerates and you're wasting concurrency.
Fires all N threads at the exact same moment, repeated across multiple rounds. Answers: when my scraper sends a batch of simultaneous requests, how many unique IPs do I actually get?
Rotating proxy list (file with one proxy per line):
# host:port:user:pass
resi.provider.io:9090:myuser:mypass
# URL format
http://myuser:mypass@resi.provider.io:9090
# SOCKS5 (auto-detected by port)
socks5://myuser:mypass@gate.provider.io:1080
Session-based proxies (generates a unique session ID per request):
resi.provider.io:9090:user-session-{session8}:pass
resi.provider.io:9090:user-s-{uuid}-country-us:pass
| Placeholder | What it generates |
|---|---|
{session8} |
8-char lowercase alphanumeric |
{Session16} |
16-char mixed-case alphanumeric |
{num9} |
9 decimal digits |
{alpha8} |
8 lowercase letters |
{hex8} |
8 lowercase hex chars |
{HEX8} |
8 uppercase hex chars |
{uuid} |
UUID v4 |
Length is configurable: {session20}, {num12}, etc.
Pool estimate — The tool uses collision math (birthday problem) to estimate pool size from observed IP reuse. More collisions = smaller pool. Formula: n × (n−1) / (2 × collisions).
Collision rate — What percentage of your successful requests got an IP that was already used. Below 10% is healthy. Above 30% means your threads are fighting for a small pool.
IPs/min — How many new unique IPs appeared in the last 60 seconds. This is your effective replenishment rate — if it drops to zero, the pool is exhausted for your plan.
Sweet spot (scale scan) — The highest thread count where 90%+ of requests still get a unique IP. Running above this doesn't buy you speed — it buys you bans.
Why am I getting blocked even with a residential proxy? The most common cause is pool exhaustion: you're running more concurrent threads than the provider has IPs available for your plan. Use the scale scan mode to find your actual thread ceiling.
My provider says I have millions of IPs — why does this tool show only a few thousand? Provider pool totals count every IP in their network globally. Your plan tier, your target country filter, and concurrent usage by other customers on the same shared pool all dramatically reduce what's available to you at any moment.
How does the pool size estimate work?
It uses the birthday problem formula: after observing N requests and C collisions (same IP appearing twice), the estimated pool size is N × (N−1) / (2 × C). The estimate converges quickly once you see a few dozen collisions.
What's the difference between rotating and session proxies? Rotating proxies assign a random IP from the pool on each connection. Session proxies use a fixed IP for the duration of a session ID — the tool supports both by either reading a proxy list file or generating session IDs from a template per request.
Will this get my proxy account banned?
This tool only makes GET requests to public IP-echo endpoints (ipify.org, icanhazip.com, etc.). It does not hit your target sites and generates no unusual traffic patterns on the target side.
What thread count should I use for scraping? Run the scale scan first. Use the reported sweet spot minus 20%. Providers throttle silently — staying under the observed threshold gives you headroom for pool fluctuation throughout the day.
If you want to build the Windows executable from source:
pip install httpx pyinstaller
pyinstaller --onefile --name proxy-reality-check proxy-reality-check.pyThe .exe will be in the dist/ folder. No Python required to run it.
pip install httpx
python proxy-reality-check.pyPython 3.8+ required. No other dependencies.
MIT — NIXNODE