绕过 Incapsula， 生成 reese84。

无需浏览器即可绕过 Incapsula（Imperva）。Takion 通过一个 POST 生成有效的 reese84 传感器和 ___utmvc cookie，让你的请求通过 Imperva，直达数据。

最后更新 · 覆盖能力已针对一个实时的 Incapsula / Imperva 目标测试。

被 Incapsula 拦住了？

Incapsula（Imperva）不会响应你，除非你的请求带有它所需的 cookie：一个已验证的 reese84 传感器或 ___utmvc 挑战 cookie，外加 incap_ses / visid_incap 这对会话 cookie。Takion 会在服务端根据实时挑战脚本生成它们，并返回整套可重放的结果。把这些 cookie 附加到你的请求上，Imperva 就会放行。

Incapsula 的工作原理

Incapsula（Imperva）提供两大类挑战：较早的 UTMVC 混淆 JS 挑战（会写入 ___utmvc cookie），以及较新的 reese84 传感器（向 /_Incapsula_Resource 端点 POST 一段加密 payload，换回一个已验证的 cookie）。两者都经过高度混淆并不断轮换，尤其是 reese84 payload 更是一个不断变动的目标，天真的重实现很容易被它打垮。

Takion 会同时生成两者（有效的 reese84 传感器和 ___utmvc cookie），并连同 incap_ses 和 visid_incap 会话 cookie 一起返回。一个 POST，无需浏览器，也无需手动反混淆 Imperva 的脚本；返回的整套 cookie 拿来即可重放到目标站点。

Imperva 还开始在部分 reese84 站点上叠加一层新的 WAF——在 ___utmvc 或 reese84 cookie 之上再加一道基于 GeeTest 的验证码（SmythsToys 就是其中之一）。这条路径 Takion 同样覆盖，且在同一个端点下。

  • Takion 覆盖的挑战
  • reese84 传感器生成
  • UTMVC 混淆 JS 挑战（___utmvc）
  • _Incapsula_Resource POST 流程
  • incap_ses / visid_incap 会话 cookie

一次调用返回什么

向 Incapsula 端点发送一次调用，即可返回已验证的整套 cookie——reese84 或 ___utmvc，再加上会话 cookie，可直接重放到你的目标站点。

reese84

已验证状态下的传感器 cookie

___utmvc

UTMVC 挑战 cookie

incap_ses / visid_incap

与传感器配套的会话 cookie

# reese84
curl -X POST https://incapsula.takionapi.tech/reese84 \
  -H "x-api-key: $TAKION_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "script": "<the reese84 challenge script>" }'
# → { "payload": "<reese84 cookie value>" }
#
# UTMVC: POST https://incapsula.takionapi.tech/utmvc with the challenge HTML → { "___utmvc": "..." }

阅读 Incapsula / Imperva 文档同一个密钥，通吃每一堵墙。同一种 JSON 结构，适配每一个厂商。

How the Incapsula bypass works, end to end

Two challenge paths, one endpoint. No browser, no de-obfuscating Imperva's script by hand.

  1. 1

    You hit the wall

    Instead of the page, Incapsula serves a challenge. Either the reese84 script (a JSON body with a token) or a _Incapsula_Resource script for the ___utmvc path.

  2. 2

    You grab the challenge script

    For reese84, read the challenge script response. For ___utmvc, pull the _Incapsula_Resource URL out of the page HTML and load it.

  3. 3

    You POST it to Takion

    Send the script text to /reese84, or the script content plus your current session cookies to /utmvc. One call, no SDK.

  4. 4

    We generate it server-side

    Takion runs the logic Imperva's obfuscated JS would have run and builds the encrypted reese84 payload or computes the ___utmvc value. No headless Chrome anywhere.

  5. 5

    You set the cookie and replay

    For reese84, POST the payload we return to the site's reese84 endpoint and set the token it hands back as your reese84 cookie. For ___utmvc, set the cookie directly. Send your request again through the same session and you are in.

The Incapsula cookies, decoded

Two sensors, a session pair, and a captcha layer. Here is what each one is:

reese84
the sensor cookie, generated from an encrypted payload you POST back to the site. Imperva's main gate on ticketing sites like Ticketmaster
___utmvc
the older challenge cookie, computed from the _Incapsula_Resource obfuscated script. Validates browser-specific signals
incap_ses / visid_incap
the session and visitor cookies Imperva pairs with the sensor. They tie your requests to one session
GeeTest WAF
the newer captcha layer on some reese84 and ___utmvc sites (SmythsToys). The ___utmvc path sets incap_sh_xxx cookies on top

Why request-based beats a headless browser here

reese84 is heavily obfuscated and it rotates. The browser way to beat it is a fleet of headless Chrome instances, each running Imperva's script, building the sensor payload, and hoping the fingerprint holds. It works until Imperva re-obfuscates, and it costs you a browser farm, constant patching, and seconds per request.

Takion reverses the challenge and generates the payload directly. A solve is one HTTP round trip instead of a full page render. No Chrome farm to babysit, no Selenium retries when a container dies mid-challenge. You send the script, you get the payload or the cookie back. Same story for the ___utmvc path.

What gets an Incapsula session flagged

A valid cookie is necessary, not sufficient. Imperva watches for these the moment you replay:

  • User-Agent drift. The most common failure. Your User-Agent has to be identical on the challenge fetch, the Takion call, and the final request. One mismatch and the sensor reads as a different client.
  • Proxy or TLS mismatch. Even a valid reese84 fails behind a bad proxy or a mismatched TLS stack. Keep the client consistent and the proxy clean.
  • Skipping the payload POST. reese84 is not the value we return. You POST our payload to the site, then set the token it answers with. Set our payload directly and it will not clear.
  • Missing session cookies. A reese84 or ___utmvc without the incap_ses / visid_incap pair reads as an incomplete session.
  • Bad-reputation proxies. Flagged datacenter ranges get blocked before the challenge even loads. Clean residential or ISP proxies clear the reputation gate first.

The one rule that kills most 403s

Keep one User-Agent across the whole session. Same UA on the challenge fetch, the Takion call, and the final request. Match it with a clean proxy and consistent TLS, and Imperva stays cleared.

部分使用 Incapsula 的网站

Incapsula / Imperva 守护着这些网站。Takion 在每一个上都能通过，所以绕过 smyths toys 和绕过任何其他防护墙一样，都是同一次 POST。

Smyths Toys

reese84 以及新的 GeeTest WAF

Incapsula 绕过常见问题

两者都做。Takion 覆盖较新的 reese84 传感器和较早的 ___utmvc 混淆 JS 挑战，并连同 incap_ses 和 visid_incap 会话 cookie 一起返回，让整套 cookie 干净地重放。
是的，Incapsula 就是 Imperva 的机器人防护产品。无论目标站点把它叫作 Incapsula 还是 Imperva，reese84 和 UTMVC 的流程都一样，Takion 在同一个端点下覆盖两者。
会。reese84 会不断轮换和重新混淆，所以我们每次调用都会针对实时脚本生成它，并对真实的 Imperva 目标运行回归测试，以尽早发现变化。
Imperva 已开始在部分 reese84 站点上叠加 GeeTest 验证码（SmythsToys 便是一例）。这种变体 Takion 同样支持，且在同一个端点下。
Incapsula / reese84 逆向工程技术文章

所有其他防护墙

DataDomePerimeterX / HUMANNuDataCastleAWS CognitoAkamai Bot ManagerCloudflarehCaptchaGeeTest

今天就上线你的 Incapsula 绕过方案。

免费试用，之后一个密钥通吃每一堵墙。一小时内完成首次调用。

免费试用定价