What is PerimeterX Bot Defender and how to recognise it
PerimeterX is now part of HUMAN Security, but the tooling, cookies and documentation still say PerimeterX or PX. The product that sits in front of scrapers is Bot Defender: a JavaScript sensor plus a cloud risk score per request, with models trained for each customer. Enforcement is a block page or a 403 that carries a PX reference id.
Most of the time it is invisible. When a visitor looks suspicious, the site shows a "Press & Hold to confirm you are human" page, sometimes a slide or image-match variant instead.
You recognise it by a _px3 or _px2 cookie on first load, a _pxAppId string in the page source, and requests to *.px-cloud.net, *.px-cdn.net or *.perimeterx.net. First-party deployments hide these behind an unexplained POST on every page.
The result is cookies: _px3 first, then _px2, _pxhd and _pxvid. The solution's token field carries the main cookie value, cookies the full set, and userAgent the user agent used during the solve.
Extension, API or automation?
SurSolver is an HTTP API: you call it from your own code, and there is no browser extension. You send the page URL, the app id and your proxy details, and get the cookies back. Your own client then replays them.
That fits any HTTP client, or Playwright, Puppeteer and Selenium when a real browser has to carry the session. There is nothing to compute in the page.
How to find the parameters
Send the full URL of the protected parent page from the address bar. Never use the URL of the challenge iframe, such as iframe.hsprotect.net or *.px-cdn.net; it renders only an empty stub outside the parent page, so it cannot give a working result.
For the app id, search the page source for _pxAppId or for the sensor script URL //client.perimeterx.net/<id>/main.min.js. The id is PX plus eight characters.
Two optional values help. The visitor id is the _pxvid cookie value in the Application panel, and the PX vid can be read by running window._pxhc.vid in the console; it often equals the visitor id. Finally, choose the proxy now, because the same one must be used for the solve and the replay.
Where the cookies go
Set every returned cookie on your HTTP client and replay through the same proxy IP. If the solution includes a user agent, send exactly that value. The cookies are tied to the IP that earned them.
In browser automation, add the cookies to the context with the same proxy server configured and, when one is returned, the solution user agent set at launch. Expect a 200. A 403 with a valid cookie means the IP or user agent changed, so solve again instead of retrying the same cookie.
Common mistakes
IP binding is absolute. Replaying from a different IP, user agent or proxy gives a 403 even with a valid cookie, so use one proxy and one user agent for the fetch, the solve and the replay. Datacenter proxies always fail the trust scoring; use residential, mobile or static ISP addresses, kept sticky for roughly 5 to 10 minutes.
Sending the iframe URL as the page URL is the second mistake, covered above. A captcha loop is a proxy reputation problem, not a solving problem; move to a cleaner IP range. A 429 is usually the site's own rate limit, and solving again will not help.
Cookie lifetime varies by site: some deployments rotate _px3 about every minute, so re-solve when you are blocked. PX also trains per-site models, so a result that works on one app id may fail on another, and TLS and header fingerprints are scored before any challenge, so replay with a client whose headers look like a real browser.
Solve it with SurSolver
Send the parent page URL, the app id and your proxy details to createTask with the task type AntiPerimeterXTask, adding the visitor id when you have it, then poll getTaskResult until the status is ready. This type has no proxyless form. The solution carries the cookies and, when the solver reports one, the user agent to replay them with. The accepted names and parameters are listed by the public catalog (GET /v1/task-types).