PerimeterX / HUMAN Security

PerimeterX / HUMAN Security 是 HUMAN Security (PerimeterX) 的无感打分/滑块。绝大多数访问完全无感 —— sensor 在后台跑，用户什么都看不到。被判定为风险时跳到一张拦截页：「Please verify you are a human」，中间一个按钮要求**按住不放**（press & hold）约 3–5 秒再松开，期间有进度动画。少数站点配的是纯说明页（Access to this page has been denied），底部给一串 Reference ID / blockScript 引用，没有可交互的挑战。站点可以自定义 logo（window._pxCustomLogo）和整页样式，所以外观差异很大，但 DOM 里的 px-captcha-error-* 类名是共通的。

正在查询可用性…$3.06 / 1K 次按成功计费，失败退款

接口规格

项目	值
type	`perimeterx`
必填参数	`website_urlproxy`
可选参数	`user_agentwebsite_key`
返回	一串 Cookie（`solution.cookie`）
怎么用这个解	带回请求的 Cookie 串
价格	$3.06 / 1K 次 —— 按成功计费，没解出来退款
厂商文档	HUMAN Security (PerimeterX) 官方文档

参数去页面哪里取

下面全部是可以直接照做的定位方法 —— DOM 属性名、JS 全局变量名、script 上的 query 参数。

要复制的 website_key 就是 App ID，它是一个页面级全局变量：`window._pxAppId`。 格式为字面前缀 PX + 8–10 位大小写字母数字。

一行命令（拦截页和正常页都能跑）：

({appId: window._pxAppId, vid: window._pxVid, uuid: window._pxUuid,
  host: window._pxHostUrl, jsClient: window._pxJsClientSrc,
  firstParty: window._pxFirstPartyEnabled, mobile: window._pxMobile})

实测输出（zillow.com 拦截页，2026-08-30）：

appId: "PXHYx10rg3"  hostUrl: "/HYx10rg3/xhr"
jsClient: "/HYx10rg3/init.js"  firstParty: true
uuid: "cce30591-a3d2-11f1-8eac-300ab9bc7c1b"

walmart.com 实测为 PXu6b0qd2S。

变量取不到时的兜底扫描：

window._pxAppId ||
(document.documentElement.innerHTML.match(/PX[A-Za-z0-9]{8,10}/) || [])[0] ||
[...document.scripts].map(s=>s.src).find(s=>/perimeterx\.net|px-cdn\.net/.test(s))

两种部署模式，脚本 URL 完全不同：
- 三方模式 — sensor https://client.perimeterx.net/<APP_ID>/main.min.js，采集 https://collector-<APP_ID>.perimeterx.net，挑战 https://captcha.px-cdn.net/<APP_ID>/captcha.js?a=c&m=0。
- 一方模式（first-party，现在更常见） — 全部走站点自己的域，且路径是 App ID 去掉 PX 前缀的那 8 位：/<去PX的ID>/init.js、/<去PX的ID>/xhr/*、/<去PX的ID>/captcha/*。此时页面里根本不出现 perimeterx.net 字样。

给接口用的最快办法： 对被拦的接口带 Accept: application/json 再请一次，PerimeterX 的 Advanced Blocking Response 会直接把参数以 JSON 吐给你，字段为 appId、jsClientSrc、firstPartyEnabled、vid、uuid、hostUrl、blockScript。

Cookie 指纹（DevTools → Application → Cookies，按 _px 前缀筛）：_px3（加密 risk cookie，核心）、_pxvid / pxvid（visitor ID）、_pxhd（PXHD，长期设备标识）、_pxcts（采集时间戳）。

挑战容器与回调： <div id="px-captcha"></div>；成功回调 window._pxOnCaptchaSuccess(isValid)；错误回调 window._pxOnError；拦截页 DOM 上有 .px-captcha-error、.px-captcha-error-header、.px-captcha-error-message、.px-captcha-error-button、.px-captcha-error-refid。

调用示例

一个端点解全部验证码类型 —— 换一种验证码只改 type 这一个字段。

请求

curl -X POST https://api.everyinfra.com/api/v1/captcha \  -H "Authorization: Bearer omg_你的KEY" \  -H "Content-Type: application/json" \  -d '{"type":"perimeterx","website_url":"<website_url>","proxy":"<proxy>"}'

响应

{  "solution": {    "cookie": "…"  },  "billing": { "charged": true, "credits": 220 }}

怎么确认目标站用的就是它

首屏注入 sensor JS，采集 Canvas / WebGL / 字体列表 / WebRTC / 屏幕与时区 / 鼠标与触摸轨迹 / 事件时序等上百个信号，加密后 POST 给 collector 端点。服务端算出风险分，写回一个加密的 risk cookie `_px3`。之后每个请求带着这个 cookie 回来，边缘的 enforcer（Nginx / Kong / CDN 插件等）本地解密验分：低分直接放行（无感），高分或 cookie 缺失/过期/无效则回源做一次 server-to-server 的 Risk API 调用，仍判高风险就返回拦截页。按住按钮那一步的本质是再采一段真实的人类行为样本（按压时长、抖动、压力曲线），通过后重新签发 `_px3`。

容易搞混的

最常和 DataDome 混淆 —— 两者都主打电商与票务、都是「平时无感、被拦时给个滑块/按住」。区分只看前缀：PerimeterX 认 window._pxAppId 和 _px3 / _pxvid / _pxhd 这一族 cookie；DataDome 认 datadome cookie 与 captcha-delivery.com 域。另一个坑是品牌名：公司已更名 HUMAN Security，官方文档在 humansecurity.com，但线上所有技术标识（cookie、变量、域名、SDK）仍然全是 px / perimeterx —— 按新名字去页面里搜「human」什么都搜不到。也别和 F5/Shape、Akamai Bot Manager 混，那两家不在页面上暴露 App ID 这类可复制的公开参数。

去看 DataDome 那一条 →

常见部署场景

Zillow（zillow.com，实测 App ID PXHYx10rg3，一方模式）
Walmart（walmart.com，实测 App ID PXu6b0qd2S）
Fiverr（fiverr.com，实测下发 _pxhd cookie）
StubHub
Texas Roadhouse
SHEIN
大量北美电商、票务、外卖与房产平台

已知的坑

一方模式下路径要去掉 PX 前缀。App ID 是 PXHYx10rg3，但 URL 里是 /HYx10rg3/init.js —— 把完整 App ID 塞进路径必然 404。反过来，从 /xxxxxxxx/init.js 这种八位路径反推 App ID 时要记得补回 PX。

App ID 大小写敏感，PXu6b0qd2S 和 PXU6B0QD2S 不是一回事。

HTTP 200 不代表没被拦。walmart.com 首页实测返回 200 却是 PX 页面 —— 判断依据要看 DOM 里有没有 #px-captcha 或 px-captcha-error-* 类名，不能看状态码。zillow.com 才是标准的 403。

_px3 与出口 IP、User-Agent、TLS/HTTP2 指纹强绑定。取 cookie 的环境和用 cookie 的环境有任何一项不同，服务端立即判无效并重新拦截。

同域按路径挂不同 policy 很常见：首页无感、登录/下单/搜索接口强挑战。在首页测出「这站没上 PX」经常是错的，要在真正要打的那条路径上测。

移动端走原生 SDK 而不是 cookie，window._pxMobile 为 true 时是另一条完全不同的链路，Web 的那套参数不适用。

靠域名判断会漏。一方模式下 client.perimeterx.net / collector-*.perimeterx.net 一个都不出现，只有 window._pxAppId 和 _px 前缀的 cookie 能认出来。部分站点还配了 first_party_prefix（如 /resources/<ID>/init.js），路径又多一层。

拦截页可能被站点完全自定义（custom_block_url），此时连 px-captcha-error-* 类名都没有，只剩 window._pxAppId 与 cookie 两条线索。

必须自带代理：不带代理的请求会被直接拒绝

厂商已更名 HUMAN Security，页面上两个名字都可能出现

常见问题