Inside the shared supply, real-time filtering and misleading metrics that determine whether a residential proxy network actually performs.
A residential proxy provider may advertise 150 million IPs, a 98% success rate and its own "premium" network.
None of those claims tells you whether it will work for your scraper.
Behind the marketing, providers frequently combine directly acquired IPs with third-party supply. The same addresses appear across multiple networks. An IP that works on one website can be completely unusable on another.
What separates providers may not be the pool itself, but the filtering, routing and session-management layer sitting between that raw supply and your scraper.
As NodeMaven's founder Stan Sadokov put it during our recent Reddit AMA:
Once that clicks, most of the marketing in this industry stops working on you.
Stan spent years working on browser fingerprinting and anti-detect technology at Multilogin before founding NodeMaven. During that time, he repeatedly saw apparently correct browser configurations fail because of problems at the proxy layer.
In our fifth r/WebScrapingInsider AMA, we asked Stan how residential proxy networks really work, what separates high-quality providers from weak ones and how developers should evaluate them.
Here are the nine biggest insights from the discussion.
1. The Real Product Is Often the Filtering Layer, Not the Proxy Pool
Ask most developers what a proxy provider sells, and they will say IPs.
Stan's answer was different:
Our product is really the filtering layer, not the pool.
A provider's main advantage may not be exclusive access to IPs at all. It may be how effectively it filters and manages the supply available to it.
Two providers can pull from similar raw supply and deliver very different results. The difference comes down to which upstream suppliers they accept, how they evaluate incoming IPs, which IPs enter the customer-facing pool, how quickly burned IPs are removed, how traffic is routed, how sticky sessions are allocated and renewed, how abuse is controlled, and whether support can diagnose real scraping failures.
NodeMaven describes its own product primarily as that layer. According to Stan, the system combines:
- Multiple reputation databases
- An internal honeypot network
- Dynamic weighting of reputation signals
- Automated checks when a customer connects
- Continuous removal of poorly scoring IPs
Here's the part providers rarely highlight: the underlying reputation databases are not proprietary. Other providers can purchase access to many of the same sources.
Same ingredients anyone can buy, the difference is the weighting and the fact that it is current rather than historical.
The differentiation lives in which sources are trusted, how heavily each is weighted, how well the signals predict actual blocks, how frequently the scores are updated, and how those scores affect allocation and routing.
The hard engineering problem is doing all of this without slowing anyone down.
The hard part was making it work at low latency for everybody at once, queuing and renewing session IPs and scoring them on the fly without the check itself becoming the bottleneck.
2. Your Proxy Provider Probably Doesn't Own Its Entire Network
Residential proxy pools are presented as if each provider operates its own private network of devices.
The reality is messier.
A customer-facing residential pool may include directly sourced residential nodes, nodes purchased from upstream suppliers, and supply peered from other proxy providers. Even providers that operate their own acquisition systems commonly supplement them with external supply.
Almost every provider that did build its own supply also partners with other providers on top of it.
Stan was direct about NodeMaven's own supply chain:
Most of our pool comes from third party suppliers, and a substantial chunk is our own.
The implication is uncomfortable for anyone comparing providers on pool exclusivity. Residential pools are not necessarily exclusive. The same IP addresses may appear across several networks.
You do not have to take anyone's word for it. Stan suggested testing for overlap yourself:
- Take trials from multiple providers.
- Collect several thousand unique IPs from each.
- Cross-reference the samples.
- Look for repeated addresses across networks.
Overlapping supply does not automatically mean identical performance. Providers may apply different filtering, routing and session-management systems to the same raw IPs. But it does mean the pool itself is a weaker differentiator than the marketing suggests.
3. "Own Network" and "Reseller" Are Mostly Marketing Labels
The proxy industry loves its labels. "First-party network." "Ethically sourced own pool." "Just a reseller."
According to Stan, those labels reveal very little about how a customer-facing pool actually operates.
When a company says own network, what it technically means is that they built their own SDK and got it onto devices.
An "own network" normally means the provider built a proxy acquisition SDK, distributed it onto consumer devices and operates the associated collection infrastructure. The SDK may reach devices through consumer bandwidth-sharing applications, Android apps, desktop software, smart TVs and TV boxes, or partnerships with application developers.
But owning an acquisition SDK does not mean every IP sold to customers came through that SDK. As covered above, even SDK operators peer in external supply.
Likewise, a provider using third-party supply may still independently control IP scoring, filtering, routing, sticky sessions, abuse handling and customer support.
The practical difference is not whether a company is first-party or a reseller. It is how much of the customer experience the company operates and controls.
What actually matters is whether the company controls quality, routing, support and abuse handling, because that is what you experience as a user.
4. There Is No Such Thing as a Universally Clean Residential IP
Every provider sells "clean" residential IPs.
According to Stan, clean is not an intrinsic or permanent property of an IP address. It is a changing assessment made by a particular system at a particular moment.
IP quality is not a property of the IP. It is a score some system assigns it at a moment in time, and every site scores differently.
The same IP can work on one marketplace and be blocked by Google. It can pass one reputation database and fail another. It can work today and be burned next week. IP addresses are also reassigned, recycled and used by different people or devices over time.
Different websites maintain different reputation systems, and none of them scores the IP in isolation. The address gets combined with signals such as TLS fingerprint, browser fingerprint, header order, cookies, navigation behavior and session continuity.
That cuts both ways.
A clean IP cannot compensate for an obviously automated browser or TLS stack. And a perfect browser configuration cannot rescue an IP the target has already classified as abusive.
When NodeMaven digs into customer failures, Stan said the causes land roughly evenly between the IP and everything above it, although each case has to be diagnosed individually.
There is no universally clean residential IP, only ones that are clean enough right now for the target you actually care about.
5. Pool Size Is the Industry's Favorite Vanity Metric
Every proxy homepage leads with the same number.
The number everyone puts on the homepage is pool size, so you get '150M IPs' everywhere you look and nobody can verify any of it.
A provider may advertise 100 million or 150 million IPs, but that total does not reveal how many IPs are available in the country you need, how many are currently online, how many remain usable, how much concurrency the country pool supports, how many sticky sessions can be maintained, how stable the supply is over time, or how much of the pool overlaps with other providers.
Stan did not pretend his own company is above the dynamic. Providers keep using global pool size because buyers respond to large headline numbers.
Almost nobody leads with it though, us included, because the market rewards the big number on the homepage.
So what should you look at instead?
For high-concurrency workloads, Stan said he would want to see approximately 50,000 to 100,000 unique IPs in the specific country required. That is his preferred benchmark rather than a universal threshold, but it reframes the question in the right direction: country-level usable density, not global totals.
6. Stop Measuring Proxy Success and Start Measuring Usable Data
A request can return HTTP 200 and still fail.
A technically successful request may deliver a block page, a CAPTCHA, an empty result, the wrong regional version, a different language, a different currency, a promotional price, or incomplete data.
This is particularly dangerous in price scraping. The scraper receives valid HTML, the parser works correctly, and the IP still causes the target to return a different regional or promotional result.
In price scraping it shows up as the same URL quietly returning a regional variant or a promo view, and nothing in your pipeline flags that as an error.
These silent failures can be more damaging than explicit blocks, because they enter the dataset without triggering an alert.
Stan's recommendation was to stop maintaining one global success rate and start logging the reason for every failure.
Log why a request failed, not just that it failed.
Useful categories include CAPTCHA, block page, empty response, wrong region, timeout, parser failure, session failure and invalid data. Results should then be segmented by provider, target, country, IP, session type, browser or HTTP client, and concurrency.
Once you log failures that way, the metric that matters changes too.
Watch cost per successful record instead of cost per gigabyte, because that is where bad IPs actually show up.
7. At Scale, Bandwidth Is Rarely the First Thing That Breaks
Ask what breaks first when scraping workloads scale up, and most people guess bandwidth.
Almost never bandwidth. Usually it is concurrency against the pool in the specific country you need.
Stan identified three bottlenecks that hit before bandwidth does.
Country-level concurrency. A provider's global network may be large, but the usable pool in the required country can be relatively small. Your workload competes for that smaller pool, not the homepage number.
Sticky-session capacity. Long-running sessions reserve IPs and prevent them from being immediately recycled. This becomes increasingly important with browser scraping. A single page can generate dozens of related document, image, XHR and API requests that should all leave through the same IP.
Retry amplification. A modest block rate can trigger repeated attempts, increasing proxy traffic, browser initialization, compute consumption, pressure on the country pool and cost per successful record.
That last one is the quiet killer, because you build it yourself.
Your own retry logic turns a small block rate into a traffic amplifier and burns your budget without failing loudly.
The customer's own retry logic can create an expensive scaling problem without producing an obvious infrastructure failure.
8. Public Proxy Pricing Is Only the Opening Offer
The price on the website is not the price serious buyers pay.
Published pricing is basically the list price for small plans, and anything at real volume is negotiated.
According to Stan, public rates primarily act as list prices for small plans, and small plans are the relatively expensive part of the market. Large terabyte-scale contracts are negotiated, and similar customers can receive different prices. A buyer arriving with a competing quote may receive a better offer.
He was unusually candid about how that plays out:
Two customers with similar usage can absolutely end up at different rates, because one asked and one did not, or one came in through a competitor's quote and one came in cold.
There is still a floor. Residential devices and nodes have a real acquisition cost, and Stan noted that margins on large contracts are thin across the industry.
He also warned that unlimited plans can involve a quality tradeoff when providers rely on cheaper supply to make the economics work. Somebody always pays for the IPs, and if it is not you, it may be coming out of the quality.
9. The Next Proxy Battle Will Be Over Where the IPs Came From
Residential providers have spent years competing on pool size.
The next major differentiator may be defensible sourcing, consent and auditability.
The starting point is an admission most providers avoid making. Providers using peered supply generally rely on their suppliers' consent flows rather than personally reviewing every opt-in event.
For the majority of the pool I am relying on my suppliers' consent flows rather than my own screens.
Stan did not dress it up:
I am not going to sit here and tell you I personally watched every consent screen, because nobody in this industry can honestly say that about a peered pool.
What a provider can control is who it buys from and on what terms. Stan said NodeMaven requires suppliers to provide visible opt-in disclosure, a functioning opt-out and a named application or sourcing partner. Suppliers that cannot answer those questions do not stay suppliers.
Looking ahead, he expects enterprise procurement teams to ask more sourcing questions, certifications and audit trails to become increasingly important, unaudited third-party supply to face greater scrutiny, some third-party-heavy providers to consolidate or leave the market, defensibly sourced residential supply to become tighter, and clean IPs to become more valuable rather than cheaper.
Sourcing becomes the main competitive line over the next couple of years.
His longer-term prediction goes further. Commodity data may become intentionally machine-accessible while commercially valuable information remains protected. In that environment, proxy infrastructure may shift from helping customers access data toward helping them verify whether the data is correct and representative.
Conclusion: Evaluate the Provider Behind the Pool
A residential proxy provider should not be evaluated simply as a seller of IP addresses.
It should be evaluated as the operator of a residential IP supply chain, a real-time quality-control system, a routing network, a session-management layer, an abuse-control system and a technical support function.
The most useful questions are not "How many IPs do you claim?", "Are you a reseller?" or "What is your generic success rate?"
They are:
- What supply do you actually control?
- How do you decide which IPs reach customers?
- How much usable capacity exists in my country?
- How does the network perform on my target?
- What does one correct record actually cost?
- Can you explain where the residential nodes came from?
As Stan summarized:
The marketing story and the benchmark disagree pretty quickly.
The practical conclusion is simple: trial several providers, test them against your real workload and trust the results more than the homepage.