How Incapsula scores a request
Incapsula checks a visitor in two stages. Layer 1 runs before any code executes: it inspects your TLS fingerprint (the signature pattern your encryption handshake produces), your IP and ASN reputation (how trustworthy your network is), how fast you are sending requests, and your static User-Agent against a known-bot blocklist. A datacenter IP or an obviously-scraper UA gets blocked right here, before any JavaScript runs. Layer 2 is a lightweight JavaScript challenge served in an iframe with the message "Request unsuccessful. Incapsula incident ID: …" — the script sets the incap_ses_* cookie after running and then reloads the page. Once you hold that cookie, later requests pass.
The X-Iinfo response header carries a 4-segment debug code (e.g. 8-12345678-12345678 NNNN RT(...)) that reveals which security policy fired. It is handy for debugging, but it is also a dead giveaway that you are behind Incapsula — no other CDN emits this header.
How the two layers behave
Layer 1 (TLS and IP). Because the first layer reads the client's TLS fingerprint and IP reputation, a datacenter IP or a default Python requests TLS profile (whose JA3 fingerprint — a hash of the TLS handshake — does not match a real browser) is filtered before any JavaScript runs. The incap_ses_* cookie is also bound to a single IP, so it is not portable across addresses.
Layer 2 (JS challenge). When a deployment serves the lightweight JavaScript challenge, a real browser session satisfies it; there is no behavioural ML (machine-learning scoring of mouse and timing patterns) involved, which is one way Incapsula differs from newer products.
Compared with DataDome or Akamai, Incapsula's infrastructure is older and its model is simpler. Many deployments pair the WAF with an aggressive request-rate rule, so when you are authorized to access a service, request pacing matters as much as a consistent browser configuration.
Telling Incapsula apart from generic WAFs
The X-Iinfo header alone identifies Incapsula. Even when it isn't visible, an incap_ses_* or visid_incap_* name on a Set-Cookie is diagnostic — these cookie names are unique to Incapsula and have been stable for years. The "Request unsuccessful. Incapsula incident ID" block page is a third tell. Older deployments also expose X-CDN: Incapsula.