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.
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
PerimeterX builds what Scrapfly describes as a trust score from a combination of fingerprinting methods and connection analysis. 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, as ScrapeOps documents. In Scrapfly's words, residential IP addresses "provide a positive trust score as these are mostly used by humans and are expensive to acquire." Datacenter ranges start negative.
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 that, per Scrapfly, reads JavaScript runtime details, hardware capabilities, operating system details, and browser details. ScrapeOps adds the specifics: it probes for automation through browser Web APIs (checking properties like window.chrome and window.document.__selenium_unwrapped), it does canvas and WebGL fingerprinting to identify your 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 Scrapfly describes. 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
_pxcookies, 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. Scrapfly's 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
- Route through rotating residential or mobile IPs, sticky per session. This earns the positive reputation weight.
- Run a fortified real browser. Scrapfly points to hardened automation browsers (Nodriver, SeleniumBase in undetected mode, Camoufox); ScrapeOps points to the same idea with stealth-patched Puppeteer or undetected-chromedriver. The goal is a browser that runs the sensor and hides the automation tells it looks for.
- Match TLS, HTTP/2, headers, and User-Agent to one real browser, consistently, so the fingerprint and the story agree.
- Warm the session and pace like a person. Enter through the homepage, add randomized delays, and keep per-IP volume modest.
- Persist the
_pxcookies 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.
The honest bottom line
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.
Sources
- Scrapfly: How to Bypass PerimeterX (HUMAN) Anti-Scraping: the rebrand to HUMAN Bot Defender, the trust score from fingerprinting plus connection analysis, the JavaScript signals the sensor collects, the "enable JavaScript" and press-and-hold block pages, the positive trust score for residential IPs, and warming up via the homepage.
- ScrapeOps: How to Bypass PerimeterX: IP reputation scoring, the browser Web API checks (
window.chrome,window.document.__selenium_unwrapped), canvas and WebGL fingerprinting, mouse, click, and keypress tracking, and residential or mobile proxies with a fortified browser as the working setup. - JA3 (Salesforce) and JA4 (FoxIO): the TLS fingerprints PerimeterX compares against your User-Agent.