How to Handle PerimeterX (Now HUMAN) When Scraping

PerimeterX, now HUMAN Bot Defender, scores every request. In HUMAN's words, its Detector "calculates a risk score for every request which is embedded into a cookie". The score comes from signals its sensor script collects in the browser. A residential proxy changes one input to that score: the address. On October 22, 2026, we sent a plain request with a Chrome user agent from a home internet connection to three stores HUMAN guards. Sam's Club redirected it to an "are you human" page. GNC and Wayfair answered with a page titled "Access to this page has been denied". Our server, on a datacenter address, got the same three answers.

This guide covers what HUMAN documents about its sensor, score, cookies and press-and-hold challenge. It shows how to read its refusals and what our requests in August and October showed. Then it covers where PerimeterX runs, which exit country to pick, and how to line up the rest. We sell residential proxies, so we have a stake in the address part. The rest of the problem is most of this page.

Can residential proxies get past PerimeterX?

Not on their own, and our own results show both sides of that answer:

In August the home address passed where the datacenter one did not, at two of the three stores. In October a plain client was turned away from both addresses at all three. These requests cannot tell why: a stricter policy, the history of our home address, or the client itself. The August requests from home and from the datacenter came from two separate clients. In our controlled test at Cloudflare stores, the client's TLS stack alone changed two answers while the address changed none. They do show the shape of the problem. The address moves the score, and a client that runs no script loses anyway.

How do you know PerimeterX refused you?

Our three plain requests from a home connection, with ids and cookie values cut:

The signs to look for:

• A _pxhd cookie on the response, and _px cookies once a browser runs the script.
• The title "Access to this page has been denied", with whatever status the site chose: GNC sent a 307 and Wayfair a 429.
• A redirect to an "are you human" page. Sam's Club sent the plain client to /are-you-human, where the press-and-hold button waits.
• Any server name. The refusal came from Varnish at GNC and from Cloudflare at Wayfair, because HUMAN's Enforcer runs inside the site's own stack. HUMAN lists 27 platforms for it, from Cloudflare Workers and Fastly to Akamai EdgeWorkers, NGINX and Varnish.

The most viewed Stack Overflow question on the subject, "How to avoid 'Please Verify you are a Human' with python webScraping?", has 9,043 views. It is the same wall from the other side.

What HUMAN checks

HUMAN's documentation describes Bot Defender as using "a combination of fingerprinting, behavior-based and predictive methods". Three parts do the work.

The sensor

A script in the page collects "hundreds of live signals" on the client. HUMAN names the families: "HUMAN ID (cookie-based), device features such as visual and audio rendering capabilities, traffic source and type, window objects, attacker specific signatures, browser plugins, and extensions." The script reports them to the Detector.

The score and the cookie

The Detector turns the signals into a risk score for every request and embeds it in a cookie. The Enforcer, installed on the site's CDN, load balancer or origin, reads the cookie and decides whether to allow or block. A plain client never holds a valid cookie. When the cookie is missing or invalid, the Enforcer asks the Detector for a score through HUMAN's Risk API "with data about the interaction". That is why the very first request of a scraper can be refused before any script could have run.

The handshake and behavior

Before any of that, your TLS handshake produces a fingerprint (JA3, or the newer JA4). A Python or Go client that claims to be Chrome contradicts itself there. Over a session, behavior feeds the "behavioral fingerprints" HUMAN's Detector builds. Our JA3 and JA4 explainer covers the formats.

The cookies, and why a session needs JavaScript

HUMAN publishes its cookies and their lifetimes:

Two consequences follow. A client that runs no script receives _pxhd, as our requests to GNC and Wayfair did, and never a working _px session. And the session cookie lasts five and a half minutes. Even a real browser keeps its standing only while the sensor keeps running and refreshing it. A scraper that loads one page in a browser and then replays the cookies from a plain client is on borrowed minutes.

The press-and-hold challenge

When the score is doubtful, HUMAN serves its HUMAN Challenge: "a simple, no-hassle 'press and hold' challenge". HUMAN built it against solvers. Its docs say the challenge is "difficult to solve through API calls, automation or CAPTCHA farms" and that it uses honeypots and fake tokens. They add: "We are able to detect and block callbacks that were made by headless browsers (for example, selenium) from the CAPTCHA's stack. Services such as '2captcha' are using this kind of mechanism." Our Wayfair guide covers the button from a shopper's side.

The durable fix is to keep the score high enough that the button never appears. Solving it faster is the weaker plan.

Where PerimeterX runs, and which exit country to pick

Wappalyzer, which detects the technology behind websites, tracks 60,000 live websites running PerimeterX. Among the most visited are ZoomInfo, Skyscanner, Fiverr, Webflow, Zillow, Roblox, Walmart and Wayfair. No other bot-defense vendor we looked at is as American:

For PerimeterX that settles the exit country: US residential for almost every target. Pick the state or city a store prices by when that matters. Every one of our residential pools targets by country, and Residential Premium adds state, city and ISP targeting. Set the browser's language and time zone to match the exit, too.

Sticky sessions and a warm entry

The session lives in cookies, and the _px ones expire in minutes unless the sensor refreshes them. Two habits follow from that:

• Hold one sticky exit per session. Keep one residential address for a browsing flow, so the cookies, the address and the browser stay together. For logged-in work, a static ISP proxy keeps the same exit for days. Rotate between sessions, never inside one. Our sticky and rotating sessions guide shows how sessions are set.
• Enter the way a person would. Load the homepage first and let the sensor run before you go to the page you want. A visitor who lands cold on a deep URL has no cookies and no history. That gives the Risk API nothing but the request to judge.

The half proxies cannot touch

A proxy forwards your bytes untouched. If those bytes carry a Python handshake and no sensor, a residential address means HUMAN refuses a residential address.

A setup that gets through

None of this is a single trick. Getting past a real HUMAN deployment means lining up every part:

1. Exit from a US residential address, in the right state or city when the store prices by location, with one sticky session per flow.
2. Run a real browser that runs the sensor. A hardened automation browser or an anti-detect browser produces genuine device signals. A stock headless build carries tells the sensor reads. That is the subject of Stack Overflow's "is there a way to bypass perimeterx detection for crawlers using Puppeteer?" (7,271 views).
3. Make everything agree. The user agent, the TLS fingerprint, the header order, the language, the time zone and the exit country should describe one plausible person.
4. Enter through the homepage and pace like a person. Randomized delays, real time on each page, modest volume per address.
5. Keep the browser running for the session, so the _px cookies stay fresh, and start a clean context for the next session.
6. Check what you received. Read the page title as well as the status: a refusal can arrive as a 307, a 403 or a 429.

Test before you scale

Before you point a real job at a PerimeterX site, confirm your exits are alive and residential with our IP lookup and proxy checker. Then run one full session against one page and read what came back: the status, the page title, and whether _px3 arrived beside _pxhd. A response that carries only _pxhd means the sensor never ran. One identity tested end to end tells you which part is failing, which is the only way to fix the right one.

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. If we already run the platform, our scraper APIs return the content as JSON from one request. The HUMAN challenge stays on our side of the line.

Limits of this guide

We ran no bypass tool, stealth browser or solver against PerimeterX, and we tested no proxy's success rate on it, ours included. Our requests were plain clients, so they show what fails, never what passes. The October results cover three stores on one day, and the August results two stores with both addresses reported. These requests cannot tell why the home address passed in August and failed in October. August's two requests also came from two separate clients. HUMAN does not publish its score weights. Wappalyzer's counts are its detections on the sites it crawls. We will re-read the sources by January 22, 2027.

Sources

• HUMAN Security docs, read October 22, 2026: Bot Defender overview. Detection Overview. About Enforcers. HUMAN Challenge. Use of cookies and web storage.
• Our requests: a plain curl request with a Chrome 141 user agent from a home line to samsclub.com, gnc.com and wayfair.com, October 22, 2026, 12:39 UTC. The same pages through our server's text reader that day. The retail bot-defense study of August 24, 2026, with the results published on each store's page.
• Wappalyzer, PerimeterX, Kasada, Akamai Bot Manager and DataDome technology pages, read October 22, 2026: live website counts, most visited sites and country splits.
• Stack Overflow questions about PerimeterX, read through the Stack Exchange API on October 22, 2026: views and dates as quoted.
• JA3 (Salesforce) and JA4 (FoxIO): the TLS fingerprints a sensor-backed defense compares with the browser you claim.