Why Is My Proxy Getting Blocked? 1,600 Requests Tested

When a scraper starts returning CAPTCHAs or block pages, teams often blame the proxy provider first. Spoiler: replacing proxy isn’t always the fix. In our Walmart and Amazon tests, Walmart reacted much more strongly to the browser setup, while Amazon results varied across both browsers and proxy pools without revealing a repeatable solution.
We used NodeMaven’s open-source proxy-benchmark to compare 4 residential proxy providers across 2 browser setups. Every provider faced the same targets and request sequence during the same run, which let us see whether the result followed the browser, proxy pool, or session.
This article breaks down the results and why a blocked scraping request should not automatically be treated as a proxy problem.
Results at a glance
We counted a page as delivered only when it contained the expected search results. A CAPTCHA or block page did not pass, even when the server returned an ordinary HTTP response.
| Поиск | What the test found |
| Changing the browser improved Walmart delivery | CloakBrowser delivered 74 of 80 first pages, while Patchright delivered 0 of 80 across the same four proxy providers |
| One successful page did not validate the session | With CloakBrowser, delivery fell from 93% on the first page to 22% on pages 2-5 |
| Amazon had no repeatable browser fix | Patchright delivered 21% and CloakBrowser 14% in this run, but earlier runs reversed their order |
| Changing providers did not solve every block | Walmart remained at 0% with Patchright across all four providers; every Amazon browser-provider combination stayed below 34% |
| Block pages still consumed traffic | A Walmart CAPTCHA used 1.45 MB, compared with 2.37 MB for a results page |
Browser setup was the clearest observed difference on Walmart. Amazon varied across browsers and sampled proxy pools, but neither browser supplied a dependable fix.

Methodology: how we compared browsers and proxy providers
We ran the experiment with NodeMaven’s open-source proxy-benchmark. The measurement tool records the browser, provider, target, session, verdict, timing, and traffic for each attempt. It also separates a website refusal from a proxy or browser error.
The test covered:
- 1,600 Walmart and Amazon search-page requests;
- 4 residential proxy providers: Decodo, NodeMaven, Oxylabs, and Proxy-Cheap;
- US residential IPs, with providers interleaved inside the same run;
- CloakBrowser and Patchright under the same selected settings;
- 100 requests for every provider, browser, and target combination;
- 20 sessions per test cell, with one sticky IP making five consecutive searches.
The providers alternated throughout the run. Running provider A in the morning and provider B four hours later would have mixed provider performance with whatever changed at the target during those four hours.
Why is my proxy getting blocked when scraping?
A CAPTCHA doesn’t tell you which part of the setup triggered it. Websites can react to the exit IP, browser environment, cookies, repeated navigation, request timing, or signals created by the connection itself.
Our Walmart results make the browser problem easy to see. Every proxy provider returned first-page results through CloakBrowser, while every Patchright session met a CAPTCHA immediately. On Amazon, the evidence was mixed. Results differed across provider pools, yet both browsers failed to retrieve a single usable page in most sessions.
Community reports show the same diagnostic problem. In one SeleniumBase discussion, a developer said a Walmart scraper’s CAPTCHA rate rose from roughly 10% to 90% while the code and use of residential proxies stayed similar. That example shows why a proxy change can become an expensive guess, that might not change the results.
Walmart results: the browser changed the outcome
First-page delivery changed from 0% to 85-100%
| Поставщик | CloakBrowser | Patchright |
| Decodo | 18 of 20 (90%) | 0 of 20 (0%) |
| NodeMaven | 19 of 20 (95%) | 0 of 20 (0%) |
| Oxylabs | 20 of 20 (100%) | 0 of 20 (0%) |
| Proxy-Cheap | 17 of 20 (85%) | 0 of 20 (0%) |
| All providers | 74 of 80 (93%) | 0 of 80 (0%) |
Changing providers would not have fixed Patchright in this test. Walmart showed a CAPTCHA from the first request in all 80 Patchright sessions. CloakBrowser retrieved most first pages through every provider, including 19 of 20 through NodeMaven.
The first page did not predict the full session
CloakBrowser looked excellent on the first search, however the next four pages gave a different result.
| Position in the session | Delivered pages |
| First page | 74 of 80 (93%) |
| Pages 2-5 | 70 of 320 (22%) |
Delivery dropped for all four providers after the first request, so testing only one Walmart page would have overstated their performance.
CAPTCHA pages still consume paid traffic
A valid Walmart results page used 2.37 MB in this test. The CAPTCHA page used 1.45 MB, about 61% as much.
Patchright downloaded CAPTCHA pages for all 400 Walmart requests. Multiplying the measured page size by those requests gives approximately 580 MB of traffic without one usable result.
Price per GB misses the cost of blocked responses, so a better measure is proxy cost per usable page. A recent Reddit discussion about Walmart scraping questioned success rates that never define success; our test shows the problem, as Patchright loaded only CAPTCHAs while CloakBrowser fell from 93% delivery on the first page to 22% on later pages.
Amazon results: changing browsers did not provide a stable fix
Amazon produced a much smaller browser gap than Walmart. CloakBrowser delivered 56 of 400 pages, or 14%. Patchright delivered 84, or 21%.
| Browser | Delivered pages |
| CloakBrowser | 56 of 400 (14%) |
| Patchright | 84 of 400 (21%) |
Patchright did better in this run, but earlier runs had placed CloakBrowser ahead. That reversal rules out a lasting conclusion that switching to Patchright fixes Amazon delivery.
Amazon results by provider and browser
| Поставщик | CloakBrowser | Patchright | Both browser cells |
| Decodo | 8 of 100 (8%) | 12 of 100 (12%) | 20 of 200 (10%) |
| NodeMaven | 15 of 100 (15%) | 20 of 100 (20%) | 35 of 200 (17.5%) |
| Oxylabs | 21 of 100 (21%) | 33 of 100 (33%) | 54 of 200 (27%) |
| Proxy-Cheap | 12 of 100 (12%) | 19 of 100 (19%) | 31 of 200 (15.5%) |
| All providers | 56 of 400 (14%) | 84 of 400 (21%) | 140 of 800 (17.5%) |
Заметка: Don’t use this table as a permanent Amazon provider ranking. Test more exit IPs with the same browser and repeat the comparison before switching providers.
Most Amazon sessions returned no usable page
Across the two browser arms, 108 of 160 sessions returned no usable page. Amazon usually returned its “too many requests” response. Only 21 of 160 first pages arrived, compared with 119 of 640 pages at positions 2-5.
Changing the browser still left most sessions without a usable page, so the test did not isolate a single cause.
Amazon results also changed by test window. In our larger study of what affects web scraping success, all compared premium pools improved or declined at the same time, so testing providers at different times can produce a misleading ranking.
For a separate test of eight browser automation setups on Amazon, see our browser automation benchmark.
What is the best proxy for Walmart or Amazon scraping?
No provider won across both targets. The results instead show what a buyer should test before choosing one.
| Target | What to test first |
| Walmart | Browser compatibility, then delivery across several pages in one session |
| Amazon | Several exit IPs across repeated, overlapping test windows |
| Оба | Connection reliability, location accuracy, session continuity, and cost per usable page |
For Walmart, all four providers delivered most first pages with CloakBrowser and none with Patchright. Buying another proxy subscription without changing the browser would have repeated the failure.
Amazon needs a broader sample. Test several exits, keep the browser fixed, and repeat the run at another time of the day. A quality-filtered residential pool gives the collector a better operating base: connections should reach the target, locations should match the request, and sticky sessions should hold when the workflow needs them. The browser still has to work with that route.
Нодемавен резидентские прокси для веб-скрапинга provide location controls, rotation, and sticky sessions. If you want a managed browser rather than another local setup to maintain, the Браузер для скрейпинга supports browser workflows for Amazon and Walmart. Our Amazon scraping guide covers the collection side in more detail.
How to compare proxy providers fairly
Start with the production workflow. A test against an IP checker says whether the proxy connects; it says little about five Walmart searches in one session.
- Use the exact target and page type your collector needs.
- Keep the browser build and settings fixed across providers.
- Interleave providers during the same collection window.
- Use the same country, session length, request order, and sample size.
- Classify the returned content as a result, CAPTCHA, block, empty page, or connection error.
- Report the first page separately when later requests share its session.
- Repeat the experiment before committing to a large plan.
Proxy-benchmark was built for this kind of comparison. It supports several providers, browser engines, countries, sticky-session settings, and target-specific verdicts. Every attempt becomes a JSONL row rather than disappearing into one average success rate.
Before spending traffic on a target benchmark, use our proxy testing guide to confirm that the proxy connects and returns the intended location.
What to change after a blocked run
| Observed result | Next variable to test |
| Every provider fails in one browser but works in another | Browser setup |
| One provider falls behind in the same browser and window | Proxy path and a larger sample of exits |
| The first page works but later pages fail | Request sequence, pacing, and session behavior |
| Every provider rises or falls together | Target behavior and test window |
| No target response arrives | Credentials, DNS, proxy connection, or transport |
| A response arrives without results | CAPTCHA, throttle page, or browser signals |
Change one variable, repeat the same requests, and check whether the result follows it. Replacing the proxy, browser, headers, and request timing together produces a new setup, not an explanation.
For the browser branch, our руководство по скрапингу с Playwright explains how to connect a local script to managed browser infrastructure.





