We Knocked on 47 Front Doors With 20 Free Proxies Each: Who Challenges, Who Blocks, Who Stalls

Every "proxies for X" page we write now carries a measured front door, because a claim about a site's defenses is worth nothing without a request behind it. After two batches of those pages the measurements added up to something bigger than any one of them: 47 consumer sites, each knocked on the same evening with the same method, and a pattern that repeats across delivery apps, fast-food chains, grocers, pharmacies, big-box retailers and fuel sites. This is that atlas, with the method first, the table in full, and the five lessons that fall out of it.

Method

On 24 August 2026, in two runs starting at 01:36 and 04:17 UTC, we did the following for each site from one datacenter server in Germany:

1. One direct GET of the homepage with a current Chrome user-agent and a 25-second timeout, following redirects, recording the HTTP status, the page title, the Server header, and any bot-defense vendor markers in the response cookies and script references.
2. The same GET through each of 20 elite HTTP proxies taken live from our free proxy list minutes earlier, one request per proxy, 12-second timeout, recording status and title.

Each run used its own set of 20 proxies. No logins, no forms, no second pages, no JavaScript: a bare client on purpose, because a bare client is what every free-proxy tutorial hands you, and the point was to see what each door does with it. 940 proxied requests and 47 direct ones in total; one site (Whole Foods Market) answered our client with a redirect it never resolved and is excluded rather than guessed at.

We name a vendor only where the marker is unambiguous: Cloudflare's cf-ray header and /cdn-cgi/ paths, Akamai's _abck and bm_sz cookies or its edge server signature, Imperva's incap_ses cookies, PerimeterX's px-cloud script hosts, the Queue-it script, AWS WAF's characteristic HTTP 202 interstitial, and the "Request Rejected" wording of F5's application firewall. Strings like "shape" or "f5" also appear in ordinary CSS, so they were not counted.

The five door types

Every one of the 47 direct responses fits one of five shapes.

A JavaScript challenge (8 sites). Cloudflare's "Just a moment..." page with HTTP 403 on DoorDash, Uber Eats, Gopuff, Lieferando and GasBuddy; an HTTP 202 with an empty body, AWS WAF's challenge interstitial, on Swiggy, Glovo and Amazon. A real browser on a decent address passes these routinely. A bare client never does, and a scraper that treats the 202 as success records empty pages all night.

A block or rejection (11 sites). Cloudflare's "Attention Required!" page on Just Eat, iFood, Talabat, Dunkin' and Dairy Queen; an Akamai-fronted 403 with no body on CVS, Kroger, Home Depot and Pizza Hut; a "Request Rejected" page on Dollar General; a bare 403 on Panera. These are verdicts, not tests. No browser solves them; only an address the rule does not match does. Two of them (iFood and Talabat) refused our German server and still served the real page to four and five of the free proxies that connected, which says the rule matches networks or countries rather than proxies as such.

A geographic or network landing page (2 sites). Grubhub served "Grubhub food delivery is not available in your country" with HTTP 200. Publix served "International | Publix Super Markets", also with HTTP 200, to our German server and to a US cloud exit alike, while refusing four other US cloud exits with 403. A 200 is not a page; check the title.

A silent stall (2 sites). McDonald's and Best Buy completed the TLS handshake, accepted the request, and never answered before the timeout, for our server and for every proxy. A stall looks like a network fault, so a scraper that retries on timeout retries forever. Treat it as a block.

An open homepage (24 sites). The page came back. On eight of them it came with a scoring script that decides what happens on page two: Akamai's _abck sensor on Taco Bell, Walgreens, Dollar Tree and Costco (which also runs Queue-it), PerimeterX on Target and Deliveroo, both PerimeterX and Imperva on 7-Eleven, and Akamai plus PerimeterX on Walmart. On the other sixteen we saw no scoring marker at all, which means only that the defense, if any, sits deeper than the homepage.

The table

Direct is the response to our server. Connected is how many of the 20 free proxies completed a request; page is how many of those got the site's real page rather than a challenge, block, landing page or empty body.

Totals: 940 proxied requests, 174 connected, 93 real pages. The first run's proxy set connected on 119 of 480 requests and the second's on 55 of 460, which is the spread you should expect from any free list on any given minute.

Five lessons

A status code is not a page. Grubhub and Publix answered 200 with a landing page. Swiggy, Glovo and Amazon answered 202 with nothing. McDonald's and Best Buy answered with silence. A scraper that logs status codes as success will report a perfect night and collect nothing. Log the title, or a fingerprint of the body, with every response.

A challenge and a block are different jobs. The eight challenges are passable: a real browser executes the JavaScript, a residential address gets the challenge served rarely, and the session proceeds. The eleven blocks are not passable by any client; they are verdicts on the address or the network, and the only fix is an address the rule does not match. Knowing which one you face decides whether the answer is "add a browser" or "change the address". Scraping past Cloudflare covers both of that vendor's pages.

Dead is the list's problem, not the site's. Fourteen to twenty of every twenty free proxies never completed a request, before any site had a say. That number moved between the two runs with the proxy set, not with the target. Our free proxy data study measures the churn behind it; the practical reading is that the honest per-site figure is "of the proxies that connected, how many got the page", and that a job which starts from a free list starts from almost nothing.

Open is not undefended. Eight of the 24 open homepages carried a scoring script (Akamai's sensor cookie, PerimeterX, Imperva). Those sites let the first request through and decide on the second, on sensor data a bare client cannot produce. The setup for an open-and-scored door is the same as for a challenge: a real browser on a residential address. How the _abck cookie works explains the most common of those scripts.

The door is a per-site choice, even inside one company. DoorDash's three brands showed three doors: a Cloudflare challenge on doordash.com, PerimeterX behind an open Cloudflare edge on Deliveroo, and an open CloudFront shell on Wolt. Just Eat Takeaway.com's two brands showed a block in the UK and a challenge in Germany. The same firm, the same evening, different rules. Measure each site; do not infer from the parent.

What this does not say

It does not rank the sites by how hard they are to scrape, and it does not say what a real browser on a residential address would meet on page two; those are different tests. It is one evening, one origin in one country, two proxy sets, and a client that never runs JavaScript. Rules change: a site that is open tonight may challenge tomorrow, and a block that matches our server's network may not match yours. What the atlas is good for is the question every setup starts with, which is what kind of door this is, and for that a single request and its title are enough.

The per-site pages in the use cases section carry each of these measurements with the jobs, the setup and the limits for that site, and we intend to re-run the atlas on a schedule so the table stays current rather than becoming another frozen number.

Sources

• HProxy measurement, 24 August 2026, two runs from a datacenter server in Germany: 47 direct requests and 940 requests through fresh elite HTTP proxies from our free proxy list, one per proxy per site, 12-second timeout, browser user-agent, status and title recorded. Vendor markers taken from response cookies and script references.
• HProxy, free proxy data study, for the pool size, composition and lifetimes behind the "never connected" numbers.