How to Handle PerimeterX (Now HUMAN) When Scraping

You hit a PerimeterX wall and the block page tells you what it is: a request to enable JavaScript, or a button asking you to press and hold to prove you are human. The scraper that ran clean an hour ago now meets that button on every request, and swapping proxies does not clear it. If a fresh IP did not help, the IP was never the whole story. PerimeterX, which is now HUMAN Bot Defender after HUMAN Security acquired the company, does not count your requests. It builds a trust score for each visitor from several signals and decides, before it ever shows you a button, whether you look like a person.

One caveat up front, the same as with F5: HUMAN publishes what Bot Defender does but not how its sensor works, and the client script is obfuscated. Where this guide names a cookie, a script property or a score weight, that detail is community-documented rather than vendor-confirmed, and it is flagged as such rather than presented as fact.

Can residential proxies get past PerimeterX?

Partly, and this is one of the rare cases where the vendor is fairly explicit about why the IP matters. PerimeterX gives residential addresses a head start, but it scores your fingerprint and behavior on top of that, so the IP alone does not settle it. Residential proxies remove the largest and easiest signal working against you. They do not touch the sensor or your behavior.

What PerimeterX actually checks

HUMAN's own documentation describes Bot Defender as "a behavior-based bot management solution" that "uses a combination of fingerprinting, behavior-based and predictive methods to detect bots and stop hyper-distributed attacks". Several signal groups feed it, and they stack: a weak signal on its own might pass, but two or three together tip you into a challenge or a block.

IP reputation and type

PerimeterX classes your IP as residential, mobile, or datacenter and weighs its history: prior bot-network association, location, and ISP reputation. Residential and mobile addresses start ahead of datacenter ranges, because they are the addresses ordinary people browse from and they cost real money to obtain. Datacenter ranges start negative. HUMAN does not publish the weights, so treat that ordering as reported rather than official.

TLS and HTTP/2 fingerprint

Your TLS handshake produces a JA3 or JA4 fingerprint, and the shape of your HTTP/2 frames is a second one. PerimeterX compares both against the browser your User-Agent claims. A raw client's handshake matches no browser, and that contradiction is a signal on its own, before any JavaScript runs.

The JavaScript sensor

PerimeterX injects a client-side sensor. HUMAN's documentation says its machine-learning detector "processes numerous data signals collected by the HUMAN sensor" and builds "behavioral fingerprints to detect anomalies", without listing what the sensor reads. The specifics that follow are community-documented rather than vendor-confirmed. It reads JavaScript runtime details, hardware capabilities, operating system details and browser details. It probes for automation through browser Web APIs, checking properties such as window.chrome and window.document.__selenium_unwrapped. It does canvas and WebGL fingerprinting to identify the device, browser and OS combination, and it tracks events, meaning mouse movements, clicks and key presses. The sensor's output is written into HUMAN's first-party _px cookies (the token cookie is commonly documented as _px3, with a _pxhd cookie tied to the client), which carry the scored session forward.

Behavior

Beyond the single-request fingerprint, PerimeterX watches how you move through the site over time. Requesting pages in a rigid order at machine intervals, with no cursor movement and no dwell, reads as automation even when the IP and fingerprint are clean.

The press-and-hold challenge

When the trust score comes up short, PerimeterX serves the block page with its press-and-hold button. The hold is not decoration. It is a behavioral test that samples your input and timing while you hold, which a script that just fires a click event cannot reproduce convincingly. It is the visible end of a system that was scoring you silently the whole time. This is why the durable fix is never to solve the button faster: it is to raise your score high enough that the button never appears.

Where residential proxies fit, and where they do not

Residential proxies route through real consumer connections, so PerimeterX classes your exit as the kind of address ordinary people use and gives it the positive trust weight residential ranges are widely reported to carry. Datacenter IPs start in the hole and rarely recover. This is the foundation, and it is why every serious attempt starts here.

What a proxy cannot change is what the sensor sees. The proxy forwards your bytes untouched, so if the sensor finds window.document.__selenium_unwrapped, a canvas fingerprint that screams headless, or an HTTP/2 signature no browser sends, a residential IP just means PerimeterX distrusts a residential IP. The proxy makes your IP believable; the sensor and your pacing make the rest of you believable, and PerimeterX scores them together. The same logic runs through every vendor, from DataDome to Cloudflare.

Sticky sessions and a warm start

Two habits move the score more than another proxy would.

• Hold a sticky session. The sensor ties its verdict to your _px cookies, your IP, and your fingerprint. Keep one residential or ISP IP for a logical session and carry the cookies with every request in it. Rotating mid-session throws the trust away and looks abnormal by itself, the same trap covered in how websites detect proxies.
• Warm up before the target. The widely reported guidance is to visit the homepage before the page you actually want. A visitor who lands cold on a deep endpoint with no history looks like it teleported in. A short, natural entry path builds the behavioral trail the sensor rewards.

A setup that actually gets through

1. Route through rotating residential or mobile IPs, sticky per session. This earns the positive reputation weight.
2. Run a fortified real browser. The tooling people report success with is a hardened automation browser: Nodriver, SeleniumBase in undetected mode, Camoufox, or a stealth-patched Puppeteer or undetected-chromedriver. The goal is a browser that runs the sensor and hides the automation tells it looks for.
3. Match TLS, HTTP/2, headers, and User-Agent to one real browser, consistently, so the fingerprint and the story agree.
4. Warm the session and pace like a person. Enter through the homepage, add randomized delays, and keep per-IP volume modest.
5. Persist the _px cookies on the same sticky IP so the sensor keeps the trust it granted you.

Test before you scale

Prove one identity before you point a job at thousands of URLs. Confirm the exit is alive and residential with the proxy checker, then load a fingerprint test page in your automation browser and confirm your JA3 matches the browser you claim and that the obvious automation flags are gone. If the IP is clean but the sensor can still see webdriver or a headless canvas, you have found your block before PerimeterX does. Fixing one full identity end to end tells you which signal is failing, instead of buying proxies to fix a fingerprint problem.

Necessary, not sufficient

PerimeterX, now HUMAN Bot Defender, scores your IP, your TLS and HTTP/2 fingerprint, its JavaScript sensor, and your behavior into one trust number, and shows the press-and-hold button only when that number is low. Residential proxies earn a genuinely positive weight here, more openly than with most vendors, and they are the foundation. But they are one input. A real browser that survives the sensor, a fingerprint that matches your User-Agent, a warm entry path, and human pacing are what carry the rest. Treat residential proxies as necessary and not sufficient, get the sensor and behavior right on top of them, and the press-and-hold button stops showing up.

When the wall is not your problem to solve

The techniques above are the right answer when you have no other route to the data. Often there is one. Where the target is a platform we already run, our scraper APIs return the same content as structured JSON from one request and keep the HUMAN challenge on our side of the line, which is a very different maintenance story to owning a bypass yourself.

Sources

• HUMAN Bot Defender overview, HUMAN Security, read 9 September 2026: "HUMAN Bot Defender is a behavior-based bot management solution that protects your web and mobile applications and APIs from automated attacks", "Bot Defender uses a combination of fingerprinting, behavior-based and predictive methods to detect bots and stop hyper-distributed attacks", and the machine-learning detector that "processes numerous data signals collected by the HUMAN sensor" and builds "behavioral fingerprints to detect anomalies".
• HUMAN does not publish the sensor's internals, the cookie names, or the score weights. The _px3 and _pxhd cookie names, the browser Web API probes, the canvas and WebGL checks and the residential-over-datacenter ordering described above are community-documented, and the text flags them as reported rather than official.
• JA3 (Salesforce) and JA4 (FoxIO): the TLS fingerprints PerimeterX compares against your User-Agent.