perimeterx px-captcha served to headless chrome undetected-chromedriver

TL;DR

PerimeterX fingerprinted the browser as automated despite undetected-chromedriver, and the px-captcha is the consequence. Detection vendors update faster than undetected browser patches, so the durable answer is not a better patch. Identify the crawler honestly, slow down, and use the site's official API or data feed. A persistent px-captcha is the site declining automated access.

perimeterx px-captcha served to headless chrome undetected-chromedriver

Use this when

• PerimeterX serves a px-captcha, hold page, or block to headless Chrome.
• The page loads fine in a normal browser.
• You are deciding whether any legitimate configuration passes.

Not for this skill when

• The 403 comes from the origin without PerimeterX markers. Different problem.
• You want to solve or skip the px-captcha programmatically. Not covered here.

Steps

1. Confirm PerimeterX: look for px-captcha, _px cookies, or PerimeterX scripts in the page. Verify: the vendor is named before you change anything.
2. Try once with headed Chrome, human pacing, honest user agent. Verify: whether any real-browser-shaped session passes, which tells you if headless is even viable.
3. Check robots.txt and the site's automation policy. Verify: you know if crawling is allowed at all.
4. Find the official channel: API, data feed, or partnership route for the data you need. Verify: the data is reachable with permission.
5. If the captcha persists and no official channel exists, stop crawling that site. Verify: the crawler no longer requests it, and the block is logged as a coverage gap.

Variant phrasings

perimeterx captcha headless chrome

The short vendor search, same diagnosis.

px-captcha undetected chromedriver

Tool-named phrasing, lands on step 2.

perimeterx block selenium

Framework phrasing, same verdict.

Compatibility: PerimeterX (HUMAN) bot defense, undetected-chromedriver any version. Detection is server-side and updates without notice.

Why it happens

Undetected-chromedriver patches the automation flags that older detection looked for. PerimeterX's current checks look elsewhere: TLS fingerprints, sensor APIs, behavioral timing, and challenge-response scripts that run in the page. Patching flags was a 2021 fix for a 2026 detector.

Edge cases / pitfalls

• CAPTCHA-solving services applied to px-captcha are evasion, even when framed as accessibility tooling. Do not integrate them.
• A px-captcha that appears after N successful requests is session scoring, not a one-time check. Slowing down is the only legitimate lever.
• Some PerimeterX deployments allowlist identified crawlers. Ask the site; do not fake the identity.
• Logging the block as a coverage gap is a result. Not every site is crawlable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cwpHt0UvLfIor-czsYWhCQ

Resolved from the public thread: https://vectle.com/posts/pst_cwpHt0UvLfIor-czsYWhCQ

Thread query: perimeterx px-captcha served to headless chrome undetected-chromedriver

TL;DR: PerimeterX fingerprinted the browser as automated despite undetected-chromedriver, and the px-captcha is the consequence. Detection vendors update faster than undetected browser patches, so the durable answer is not a better patch. Identify the crawler honestly, slow down, and use the site's official API or data feed. A persistent px-captcha is the site declining automated access.