Imperva / Incapsula

Imperva / Incapsula 是 Imperva 的反爬平台挑战（分级升级）。正常访问无感。触发防护时会看到一个短暂的中间页（「Please wait... we are checking your browser」一类），或者直接被拒。Imperva 的特点是**分级升级**：先看你支不支持 cookie，再上 JavaScript 挑战，最后才是可见验证。

也叫 Incapsula（Imperva 的旧品牌名，大量文档与报错里仍这么写）。调用时 type 一律传 imperva。

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

接口规格

项目	值
type	`imperva`
必填参数	`website_url`
可选参数	`proxyuser_agent`
返回	一串 Cookie（`solution.cookie`）
怎么用这个解	带回请求的 Cookie 串（含 `___utmvc` 等）
价格	$3.06 / 1K 次 —— 按成功计费，没解出来退款
厂商文档	Imperva 官方文档

参数去页面哪里取

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

必填 website_url，`proxy` 是可选的（这一点与同族的几条不同——Anubis、PerimeterX、5 秒盾都强制要）。

怎么确认是 Imperva

看 Cookie 前缀：

document.cookie.split('; ').filter(c => /^(visid_incap_|incap_ses_|nlbi_|___utmvc)/.test(c))

`visid_incap_<siteid>` —— 访客标识，<siteid> 是数字站点 ID
`incap_ses_<n>_<siteid>` —— 会话 cookie
nlbi_<siteid> —— 负载均衡
`___utmvc` —— JS 挑战产出的那个（⚠ 三个下划线开头，容易被看成 Google Analytics 的 __utm*，两者无关）

旧名仍在流通

拦截页与报错信息里 Incapsula 这个旧品牌大量存在（页面常带 Powered by Imperva 或 Incapsula 的 Request ID）。搜资料时两个名字都要试。

`proxy` 传不传

不传也能受理；但一旦传了，就必须是你后续请求要用的那个出口——解出来的 cookie 与 IP 绑定。

调用示例

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

请求

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

响应

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

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

边缘先下一个 cookie 挑战验证客户端是否接受 cookie，通过后再下 JS 挑战；解出来的结果写回一组 cookie，后续请求带着它们放行。凭证与出口 IP 绑定。

容易搞混的

报错页容易和其他 WAF 的中间页混淆。判据是 cookie 前缀：visid_incap_ / incap_ses_ 是 Imperva；_abck / bm_sz 是 Akamai；__cf_bm / cf_clearance 是 Cloudflare；TS 开头八位十六进制的是 F5。

去看 Akamai 那一条 →

常见部署场景

电商与零售站点
金融、保险类企业站
政府与公共服务门户
任何用 Imperva Cloud WAF / 原 Incapsula CDN 的站点

已知的坑

`___utmvc` 是三个下划线，和 Google Analytics 的 __utm*（两个）不是一回事，别搞混。

`proxy` 可选，但传了就必须一致——传一个和后续请求不同的出口，比不传更糟。

旧名 Incapsula 仍大量出现在报错页和文档里，Incapsula 在我们这里是同一条能力的别名。

产出绑定求解时的出口 IP —— 传 proxy 时必须是你后续要用的那个出口

常见问题