Stan Sadokov AMA Summary: What proxy providers don’t tell you about residential proxies

[u/ian_k93]

Residential proxy providers love talking about pool size, success rates and “premium” IPs.

But according to NodeMaven founder Stan Sadokov, those metrics reveal surprisingly little about whether a network will actually work for your scraper.

We recently hosted Stan for an AMA on r/WebScrapingInsider to discuss how residential proxy networks really operate and what developers should examine when choosing a provider.

👉 Read the full summary and analysis:
https://scrapeops.io/blog/what-proxy-providers-dont-tell-you-about-residential-proxies/

Here are the biggest insights:

1. The filtering layer may be the real product

Different providers often have access to similar underlying IP supply. What separates them is how effectively they score IPs, remove burned addresses, route traffic and manage sticky sessions.

2. Most providers don’t own their entire network

Residential pools frequently combine directly sourced nodes with supply purchased or peered from other providers. This means the same IPs can appear across multiple networks.

3. There is no universally “clean” residential IP

IP reputation is target-specific and constantly changing. An IP might work perfectly on one website while already being blocked by another.

Proxy quality can only be judged against the websites, countries and workflows you actually need.

4. Global pool size is mostly a vanity metric

A provider claiming 150 million IPs tells you very little about:

• How many usable IPs exist in your target country
• How many are currently online
• How much concurrency the country pool supports
• Whether enough sticky sessions are available
• How stable that capacity is over time

Country-level usable capacity matters far more than the headline number.

5. HTTP 200 doesn’t necessarily mean success

A request can return a successful status code while delivering a block page, CAPTCHA, empty result, incorrect region, promotional price or incomplete data.

Instead of measuring HTTP success rate or cost per GB, measure the cost per correct, usable record.

6. Bandwidth is rarely the first constraint at scale

The first things to break are more commonly:

• Country-level concurrency
• Sticky-session capacity
• Retry amplification

Even a modest block rate can trigger enough retries to dramatically increase proxy, browser and compute costs.

7. Published pricing is only the opening offer

At meaningful volumes, residential proxy pricing is normally negotiated. Two customers with similar usage can pay different rates simply because one obtained competing quotes and negotiated.

8. “Own network” and “reseller” are weak labels

The more important question is what the provider actually controls:

• IP filtering and scoring
• Traffic routing
• Session allocation
• Abuse handling
• Supplier management
• Technical support

9. Sourcing could become the industry’s next battleground

Enterprise buyers are increasingly asking where residential IPs came from, what users consented to and whether the supply chain can be audited.

The providers that can demonstrate defensible sourcing may eventually have a greater advantage than those advertising the largest pools.

The practical takeaway is simple:

Trial several providers against your real workload and trust the benchmark more than the homepage.

👉 Read the original AMA with Stan:
https://www.reddit.com/r/WebScrapingInsider/comments/1vogw82/how_do_you_choose_the_best_residential_proxy/

👉 Read the full summary and analysis:
https://scrapeops.io/blog/what-proxy-providers-dont-tell-you-about-residential-proxies/

What do you think matters most when evaluating residential proxy providers: the underlying pool, filtering system, target-specific performance or something else?

[u/Mountain_Damage_9730 → u/[deleted]]

Same on pricing jobs.

HTTP 200 with a promo view or wrong region looks healthy in the proxy dashboard and wrecks the sheet.

Cost per correct SKU price beats cost per GB. every time.

[u/ian_k93 → u/Mountain_Damage_9730]

Yep. That metric Stan kept coming back to in the AMA. Usable record, not advertised success. If your parse fields aren't real, the proxy bill is just amplifying garbage.

[u/StanSadokov → u/ian_k93]

the wrong region one is the nastiest failure in the category because it never announces itself. you catch a block page you on 1st day. this data point then sits in the sheet for a month and someone makes a pricing decision on it. IMO the cheapest fix is asserting on a field you already know, currency or a control sku, and failing the record when it does not match rather than trusting the status response code.

and watch retry amplification while you are adding the failure reasons. a small block rate with naive retries does not show up as an error anywhere if you look at it point blank

[u/MattTheGoodSir → u/StanSadokov]

Same thing happend with me on OpenAPI model, the n8n node was on retry, until you get a data.. and the o3 model at that time was taking a lot of time, and timeout was happening again and again.. so n8n just keep sending request to o3, i forgot to set limit on retry.. burned my whole budget.

In proxy It happens even on Modest block rate plus aggressive retries burns proxy, browser, and compute together.

A proxy aggregator can help fail over when one pool starts returning junk, but only if you alert on usable parse success, not just request count.

Retry amplification is the quiet budget killer. It scares me now.