How Incapsula scores a request
Incapsula scores at two layers. Layer 1 inspects TLS fingerprint, IP/ASN reputation, request rate, and the static User-Agent against a known-bot blocklist. A datacenter IP or an obviously-scraper UA gets blocked before any JS runs. Layer 2 is a lightweight JavaScript challenge served as an iframe with the message "Request unsuccessful. Incapsula incident ID: …" — the script sets the incap_ses_* cookie after running and reloads. Subsequent requests with the cookie pass.
The X-Iinfo response header carries a 4-segment debug code (e.g. 8-12345678-12345678 NNNN RT(...)) that exposes the policy that fired. This is useful for debugging but also a clear vendor tell — no other CDN emits this header.
What works and what doesn't
Doesn't work: datacenter IPs (blocked at Layer 1 regardless of fingerprint), Python requests with default TLS (JA3 mismatch), reusing an incap_ses_* cookie across different IPs.
Works: curl_cffi with impersonate="chrome131" + residential proxy passes most Incapsula deployments without ever loading the JS challenge. For deployments that force the challenge, a real browser session is enough — there is no behavioural ML to defeat.
Incapsula is the friendliest "real WAF" target on this list. The infrastructure is older than DataDome or Akamai's and the detection model hasn't kept pace. The risk is rate-limit — Incapsula deployments often pair the WAF with an aggressive request-rate rule, so successful scraping needs slow pacing rather than fingerprint perfection.
Telling Incapsula apart from generic WAFs
The X-Iinfo header alone identifies Incapsula. Even when not visible, incap_ses_* or visid_incap_* on a Set-Cookie are diagnostic — these names are unique to Incapsula and have been stable for years. The "Request unsuccessful. Incapsula incident ID" block page is the third tell. Older deployments also expose X-CDN: Incapsula.
