Detection run, September 2026 - Cloudflare, DataDome, PerimeterX

This is the second run in the series, and the first to meet Cloudflare's managed challenge and PerimeterX. Two of those three walls cleared. PerimeterX did not, and on one target it never cleared once - that row is in the table with everything else.

Conditions

A profile created for this run and thrown away after it. Default settings, nothing tuned, no warming, no per-site history. Engine runtime Chrome 153, macOS, headful.

One condition is different from August and worth stating plainly, because it is the one people actually care about: the browser was driven by Playwright over the DevTools protocol for every check below. Nothing was clicked by hand. A debugger was attached while each page loaded and while each wall ran its sensor.

What is new this month

August covered Whoer, CreepJS, DataDome and Kasada. September adds:

Cloudflare's managed challenge - three targets that answer a plain request with cf-mitigated: challenge
PerimeterX - two targets
TLS and HTTP/2 fingerprints - what the handshake looks like from the far side of the proxy

About the PerimeterX failure

Read those rows, because they are the interesting ones.

wayfair.com held its press-and-hold wall on every attempt where the navigation completed: six different residential exits, a flagged exit, and repeat visits down both. Zero passes. That is not an address problem and we are not going to describe it as one.

fiverr.com, behind the same vendor, passed four cold visits out of six and then blocked on rapid repeat visits from the same address. Both readings are in the table.

The summary is that PerimeterX is not a wall we clear today, which is why you will not find it named anywhere else on this site.

Two corrections to our own method

Both produced wrong numbers before they were caught, and both are the kind of mistake that makes a detection report worthless.

Matching strings in the page source scored passes as blocks. Cloudflare leaves its challenge script on every page it has already cleared, and the PerimeterX sensor sits on pages that loaded perfectly. A check that greps the HTML for either finds them on a page rendering a full storefront. The first pass of this run called four passes blocks for exactly that reason. Every verdict published here reads rendered text instead, and looks for the site's own content first - a page is examined for a wall only when its content is absent.

Sampling once at a fixed delay scored challenges that were still clearing as blocks. A managed challenge routinely needs more than ten seconds over a residential link. Every check now polls for the site's own content for up to 45 seconds, and a pass records how long it took.

One exit address is not a sample

DataDome blocked three times out of three down one French residential exit, and its block page named that address. Six other French exits, same profile settings and same session, passed on the first visit with a 200 and no challenge at all.

Had we stopped at the first exit, this page would say we do not clear DataDome. The opposite is true, and the variable was the address, not the browser. Every reputation-sensitive check in this run is therefore one fresh profile and one cold visit per exit, across many exits. The blocked rows stay in the table.

The caveat cuts our way too. One segment of this run went through an exit whose entire pool is listed as proxy addresses. Cloudflare cleared it anyway - but DataDome and PerimeterX weight address reputation heavily, so that segment should be read as measuring an address, not a browser.

Does attaching a debugger change the answer?

DataDome's block page lists "use of developer or inspection tools" among its possible reasons, which reads like a debugger detection. So we measured it rather than assuming.

The same profile and the same sticky exit loaded leboncoin.fr twice: once with Playwright attached for the whole load, once with the address handed to the browser at startup and nothing connected while the page loaded. Both rendered the real site. On this target, with this profile, attaching a debugger did not change the outcome. That list on the block page is boilerplate, not a finding.

What we did not measure

WebRTC, timezone against exit, navigator languages, OS against user agent. August covers these and said they were on the list for September. This run did not repeat them.
A baseline. August paired the profile against a stealth-plugin Playwright on the same targets. That comparison was not repeated, so nothing on this page is a competitive claim.
Kasada, Whoer and CreepJS. Not re-run this month.

Every row is in the dataset, blocked and errored ones included, and the free tier is enough to repeat any of it.

Detection run, September 2026 - Cloudflare and DataDome cleared, PerimeterX did not