reese84 クッキーとは結論から: reese84 は Imperva（旧 Incapsula）の JavaScript センサーがブラウザ上で走り、判定を通ったあとに発行されるクッキーです。寿命は短く、一般に 5〜15 分。発行したセッション、User-Agent、IP に紐づきます。かつての incap_ses / visid_incap の組に代わって、ボット判定の本命になりました。ただし今もその 2 つは Imperva 配下のサイトに現れます。
403 と Incapsula incident ID が出てここに来たなら 403 の節へ。実ブラウザを回すか解決 API を呼ぶかで迷っているなら 扱い方の 2 通りへ。
reese84 の値は不透明な文字列で、たいてい数百文字、URL セーフな base64 風（英数字と、ときどき + / =）です。読める形のタイムスタンプもユーザー ID も含みません。base64 デコードしても指紋が出るわけではなく、ノイズ以上のものは得られません。中身はサーバ側で鍵付きハッシュと突き合わせて検証されます。
実務上の帰結は 2 つです。
Chrome の DevTools なら Application → Cookies に、保護されたホストの下、Path は /、多くの場合（ただし常にではない）HttpOnly 付きで現れます。HttpOnly が付いていれば document.cookie では見えません。ページに注入した JavaScript ではなく、レスポンスヘッダかブラウザコンテキスト側から読んでください。ここを取り違えて「クッキーが取れない」と悩む例が非常に多いところです。
ページはセンサースクリプトを読み込みます。パスに _Incapsula_Resource を含むもの、あるいはサイト固有の UT.mvc URL が多いところです。スクリプトはブラウザの信号を集め、サイト固有の鍵で暗号化してエンドポイントに POST し、その応答として Set-Cookie が返ります。ここから 3 つの帰結が直接出ます。
プロジェクトが壊れるのは 3 番目です。このクッキーは bearer トークンではなく、特定のクライアントに貼られた判定です。別の IP、別の User-Agent、別の TLS スタックへコピーした瞬間に無効になります。
| 紐づけ先 | 破ったときの症状 |
|---|---|
| IP アドレス | 数秒後のリクエストでも再チャレンジになります。 |
| User-Agent と TLS フィンガープリント | クッキーは有効に見えるのに、エンドポイントは Imperva のブロックページを 403 で返します。 |
| クッキーの寿命（分単位） | 動いていたのに実行の途中で落ちます。長いジョブはキャッシュではなく更新が必要です。 |
| リクエスト頻度 | 早期に失効します。50 回は耐えた値が、200 回目で落ちます。 |
短い寿命は意図的です。5 分の窓は、あらゆる自動クライアントに「センサーを動かせること」を繰り返し証明させます。ボットファームが大規模にできないのはまさにそこです。スクレイパー側ではこれがアーキテクチャの要求に変わります。ログインではなく、更新ループです。
最適化の前にベンダーを確定してください。Imperva の対処法は Cloudflare や Akamai の対処法ではありません。
X-CDN: Incapsula、そして多くの場合コロン区切りのタプルを持つ X-Iinfo。_Incapsula_Resource への参照、UT.mvc のスクリプト URL。reese84、incap_ses_*、visid_incap_*、nlbi_* のいずれか。代わりに __cf_bm / cf_clearance が出ているなら Cloudflare です → cf_clearance。_abck / bm_sz なら Akamai です → _abck。_px3 なら PerimeterX です → _px3。datadome なら DataDome です。
Imperva のブロック応答は JSON のエラーではありません。HTTP 403 の完全な HTML ページで、Request unsuccessful. Incapsula incident ID: 123-000000000-000000000000000 のような incident ID を含みます。この ID は Imperva 側の相関用ハンドルで、ブロック事象を彼らの側で識別するためのもので、こちらから引けるコードではありません。分かるのはどの層が止めたかです。
| 403 の出どころ | たいていの直し方 |
|---|---|
reese84 がまったく無い | 一度解決して取得し、同じ IP から毎回のリクエストに付けて送ります。 |
reese84 はあるが古い | 取り直します。同じ値を再試行しても決定的に失敗します。 |
| クッキーがあり新鮮なのに止まる | フィンガープリントの不一致です。別クライアント向けに発行された値です。使う側のクライアントから解決し直してください。 |
| 動いたあと N 回で止まる | レートです。速度を落とすか出口を分散し、失効が早まることを前提に置きます。 |
incap_ses_* ― セッション識別子。1 セッションに 1 つ、ゾーンごとに接尾辞が付きます。visid_incap_* ― 訪問者識別子。寿命は長く、再訪者のスコアリングに使われます。nlbi_* ― ロードバランサのアフィニティ用。セキュリティ用ではありませんが、セッションの安定に効きます。__utmvc ― センサーの管理用。同じサイトで並んで現れることがあります。どれも出口 IP をキーにした 1 つのクッキージャーにまとめてください。2 回の解決で得たクッキーを 1 つのジャーに混ぜるのは、自分からブロックを招く典型的なやり方です。
自分でセンサーを動かす。 固定 IP の実ブラウザならチャレンジを通り、短い寿命のあいだクッキーを保持できます。スクレイピング用のブラウザプールがやっていることで、真っ当ですがコストはかかります。Playwright なら形はこうです。
ctx = browser.new_context(proxy=PROXY) # 毎回同じ出口 page = ctx.new_page() page.goto(url) # ここでセンサーが走る jar = await ctx.cookies() # reese84 が入っている # 以降の直接 HTTP 呼び出しも PROXY 経由のみ。 # 403 が出たらこのブロックをやり直す
避けるべき間違いは 2 つです。1 つのコンテキスト内でプロキシを回すこと（クッキーは発行した出口に紐づきます）、実行をまたいでクッキーをキャッシュすること（その時点で死んでいます）。
クッキーを要求する。 サイト URL（サイトが隠す場合はスクリプト URL も）を渡すと、新しい reese84 と、それを使うべきプロキシ出口を返す解決 API があります。SolveHub はこれを 1 つの REST エンドポイントで提供し、完了したタスク単位で課金します。肝心なのは、実リクエストもクッキーを生んだ同じ出口から出ることです。
見落とされがちな第 3 の道もあります。Imperva 保護のサイトでも、サイトマップ、RSS、静的ファイル、一部の JSON API は完全に無保護のことが多いです。欲しいデータがそこから取れるなら、クッキーはまったく不要です。
reese84 と incap_ses は同じものですか。 いいえ。incap_ses はセッション ID で、reese84 はセンサーが出したボット判定を運びます。
1 つのクッキーを多数の並列リクエストで使い回せますか。 同じ IP と同じフィンガープリントなら、ごく短時間だけ可能です。急なファンアウトはそれ自体が失効の引き金になります。
JSON を期待したエンドポイントがチャレンジ HTML を返すのはなぜですか。 クッキーが切れたか、セッションが変わったかです。同じ値を再試行せず、取り直してください。
requests や httpx だけでも通りますか。 生きている値があれば通ります。ただしその HTTP クライアントの TLS フィンガープリントとヘッダが、値を発行したクライアントと一致する場合に限ります。素の requests はたいてい一致しません。これが「クッキーが効かない」に見える現象の正体で、実際は不一致なだけです。
どのくらいの頻度で更新すべきですか。 安全側の上限を 6〜10 分と見てください。403 は再試行の合図ではなく、即時の更新の合図として扱います。
長寿命の reese84 はありますか。 まれにあります。すでに信頼済みの訪問者には長い窓を出すプロパティもありますが、コールドスタートからその状態には届きません。短い場合を前提に設計してください。