あなたは403を受け取りました。通常、最初に行うことはプロキシを変更することです。時には効果がありますが、ほとんどの場合はありません。なぜなら、「アンチボット」は一つの技術ではなく、異なる検出メカニズムを持つ少なくとも6つの異なるシステムの組み合わせだからです。Impervaから守ってくれるものはKasadaには無意味です。2026年の状況を整理し、30秒でベンダーを特定し、各プロキシスタックで具体的に何を変更すべきかを見ていきましょう。
「単にプロキシを変更する」ことが機能しなくなった理由
従来の論理はシンプルでした：IPがブロックされたら、別のものを使う。これは、検出がアドレスの評判に基づいていた時は機能していました。今日では、IPは5つの層のうちの一つに過ぎず、異なるベンダーによってその重要性は根本的に異なります。
すべてのベンダーが何らかの形で使用している信号の一般的なセットは次の通りです：
- TLSフィンガープリンツ（JA3/JA4） — ハンドシェイクにおける暗号スイートと拡張の順序;
- HTTPヘッダーの順序と大文字小文字 — PythonクライアントのそれはChromeとは異なります;
- IPの評判 — ASN、データセンターへの所属、アドレスの履歴;
- ブラウザーフィンガープリンツ — canvas、WebGL、ハードウェアセンサー;
- 行動生体認証 — マウスの動き、スクロール速度、入力パターン。
このテーマを研究しているすべての研究者が繰り返す重要な結論は信号の一貫性が重要であるということです。ChromeのUser-AgentとPythonのTLSフィンガープリンツの組み合わせは、IPがどれほどクリーンであっても、どのベンダーでもあなたをボットとしてマークします。居住用アドレスは、穴の開いたブラウザーレイヤーを「覆い隠す」ことはできず、その逆も同様です。
ステップ1：足跡からベンダーを特定する
何かを変更する前に、レスポンスヘッダーとクッキーを確認してください。各システムは認識可能な署名を残します。これは、あなたが何に対処しているのかを理解する最も迅速な方法です。
- Cloudflare — ヘッダーCF-RAY、クッキーcf_clearanceおよび__cf_bm、challenge.jsが読み込まれます; 新しいビルドではヘッダーcf-mitigatedが見られます。
- DataDome — クッキーdatadomeおよび_dd_s、スクリプトtags.js。
- Akamai — クッキー_abck、リファレンスヘッダーakamai-grn。
- PerimeterX (HUMAN Security) — クッキー_px3、_pxvid、_pxhd、スクリプトpx.jsまたはd.js。
- Kasada — ヘッダーのファミリーx-kpsdk-*（ct — チャレンジトークン、dv — デバイス検証、cd — チャレンジデータ、v — バージョン）、クッキーKP_UIDz、スクリプトips.jsまたはp.js。
- Imperva (Incapsula) — クッキーincap_ses_*、visid_incap_*、reese84。
- AWS WAF — クッキーaws-waf-token、エンドポイント/challenge.jsの呼び出し。
- F5 / Shape Security — プレフィックスTSのついたクッキー（例：TS01a2b3c4）。
別のマーカーは拒否の性質そのものです。Kasadaは「裸の」429を応答し、レスポンスボディはありません：403または429とともにヘッダーx-kpsdk-*が見られる場合、問題は解決されます。DataDomeはCAPTCHAページとともに403を返すことが多いです。CloudflareはインタラクティブなチャレンジまたはTurnstileを提供します。
システムが実際にメカニズムで異なる点
署名は「誰」を示しますが、戦術は「どのように」によって決まります。アーキテクチャ的に、ベンダーは大きく異なります。
Cloudflare — ネットワークのエッジでのグローバルモデル
CDNエッジのレベルで機能します：リクエストがアプリケーションに到達する前に決定が行われます。モデルはグローバルで、ネットワーク全体のトラフィックに基づいて訓練されています — インターネットの約5分の1のサイトで。あなたにとってのプラス：行動は予測可能で、一つのサイトでの経験が他のサイトに移転されます。マイナス：ネットワークは同時に数千のリソースであなたのサブネットを見ており、評判は迅速に蓄積されます。
DataDome — 各サイトに対する個別モデル
主な違いは、プラットフォームが特定のサイトのトラフィックに基づいて訓練された約85,000のクライアントMLモデルを保持し、1日あたり5兆以上の信号を処理し、応答時間は2ミリ秒未満であることです。実際の結果はシンプルで不快です：保護された各サイトは別の課題です。Etsyのための作業リンクは、同じベンダーの他のリソースには移転できません。2025年にはインテント分析が追加され（訪問の目的を評価し、自動化の事実だけでなく）、LLMクローラーの個別の分類が行われました。
Akamai — TLSとテレメトリーに重点を置く
ハンドシェイクの信号を確認し、クッキー_abckを通じて行動テレメトリーを自社側で検証します。2026年の独立した測定によると、AkamaiとImpervaはデフォルトの自動化クライアントをCloudflareやDataDomeよりも少なくチャレンジしますが、これは「弱い」という意味ではありません：攻撃的に設定されている場合、回避には正しいTLS層が必要であり、IPの変更ではありません。
PerimeterX / HUMAN — ネットワークの評判
クライアントの評判はベンダーのネットワーク全体に広がります。一つのサイトで見つかれば、別のサイトではすでにマークされています。典型的なプラットフォームはeコマースや不動産です。
Kasada — 環境の積極的な尋問
最も厳しい大量システムです。単にフィンガープリンツを収集するのではなく、環境を積極的に尋問します：クライアントコードをFunction.prototype.toString()を通じて検査し、独自のスクリプトの逆コンパイルを適用します。総合的な評価において、複雑さに関して極端な評価を受け、検出の巧妙さや自己回避の労力においても同様です。チケットシステムや不動産に導入されています。
Imperva (Incapsula) — デフォルトのWAFロジック
IPとWAFルールに基づいています; 行動層はより高い設定で接続されます。典型的なプラットフォームは企業サイトや求人掲示板です。
誰が厳しいか：感覚の代わりに数字
独立したベンチマークScrapewayがあります：8つのサービスが11のターゲットに対して、1ターゲットあたり1000以上のリクエスト、月に2回のレポート。ターゲットはベンダーに固定されています — IndeedはCloudflareの下、EtsyはDataDomeの下、WalmartとZillowはPerimeterXの下、RealtorはKasadaの下です。
2026年の測定結果は次の通りです：
- 高い厳しさ — Cloudflare、DataDome、PerimeterX、Kasada：圧倒的多数のデフォルトの未設定の自動化クライアントがチャレンジを受けます。
- 中程度 — AkamaiとImperva：デフォルトのクライアントをチャレンジする頻度は明らかに少ないです。
- Cloudflareのターゲットに対しては、わずかな割合の未設定のクライアントが安定してページコンテンツを受け取っていました。
比較のために：プロファイルサービスの回避者は、これらのターゲットに対して94〜100％の成功率を維持しています — つまり、解決可能な課題ですが、デフォルトのクライアントや単なるIPの変更ではありません。
各ベンダーに合わせてプロキシスタックを変更するには
さて、実践です。以下は回避のレシピではなく、検出タイプに基づくインフラストラクチャの選定ロジックです。
- ImpervaとAWS WAF。 IPの重要性は高く、行動層はしばしばオフです。ここではデータセンタープロキシがまだ生きています — クリーンなサブネットと妥当なレートが条件です。ここから始めてください、これはトラフィックに対して最も安価です。
- Akamai。 プロキシはTLS層よりも効果が少ないです。最初にハンドシェイクとヘッダーの順序を整え、その後にIPのクラスを上げてください。歪んだJA4フィンガープリンツでプロキシを変更しても何も得られません。
- Cloudflare。 グローバルな評判は、サブネットが迅速に枯渇することを意味します。広範なプールと合理的なローテーションを持つ居住用プロキシが必要です：各リクエストごとに「新しいIP」を使用するのではなく、論理的なタスクの間セッションを維持する必要があります。さもなければcf_clearanceが崩れます。
- DataDome。 モデルは特定のサイトのトラフィックに基づいて訓練されているため、最も重要なのはそのサイトでの行動の一貫性です。居住用IPはポジティブなトラストスコアを提供しますが、ブラウザのフィンガープリンツを管理しない限り、何も保証されません。一つのサイトの設定を盲目的に他のサイトに移さないでください。このベンダーの具体的な詳細については、DataDome用のプロキシの分析を参照してください。
- PerimeterX / HUMAN。 既にネットワークの評判があるため、隔離は量よりも重要です：異なるプロジェクトには異なるプールが必要です。そうしないと、一つのプラットフォームからのマークが他のプラットフォームに引き継がれます。
- Kasada。 データセンターアドレスは入口でブロックされます。作業の最小限は居住用であり、より良いのはモバイルプロキシです：一つのモバイルIPの背後にはCGNATを介して数百の生きた加入者がいますので、システムがそのアドレスをブロックするのはコストがかかります。さらに、User-Agentは最新のブラウザバージョンに一致させる必要があります — 古い文字列は即座にバンドルを暴露します。
主な誤り：異種スタック
最初に始めたことを繰り返しましょう。これは「説明できない」バンの大多数の原因です。すべての6つのシステムは層間の不整合を捕捉します。ドイツの居住用IP + システムのタイムゾーンUTC + TLSフィンガープリンツcurl + User-Agentの新しいChrome — これは「ほぼ通過した」というものではなく、ボットの準備が整ったプロファイルです。プロキシは5つの層のうちの1つの層にのみ責任があります。他の4つはあなたのクライアントに存在します。
ここから実際の作業の順序が生まれます：最初に署名でベンダーを特定し、次にどの層が最も弱いかを評価し、それを修正します — 変更が簡単な層ではなく。スタックを整えた後もターゲットがアクセスできない場合、問題は「自分で構築するか、既製品に支払うか」という次元に移ります — この分岐については、プロキシ対スクレイピングAPIとウェブアンブロッカーの資料で詳しく説明しました。
まとめ
単一の「アンチボット」は存在せず、普遍的な回避策もありません — どの技術も同時にすべての8つのシステムに対して機能しません。クッキーとヘッダーでベンダーを特定し（これは30秒です）、そのメカニズムを理解してください — ImpervaのIPの重み、AkamaiのTLS、Cloudflareのグローバルな評判、DataDomeのサイトごとの個別モデル、PerimeterXのネットワークラベル、Kasadaの環境の積極的な尋問 — そしてそれに合わせてプロキシのタイプを選定し、無作為に選ばないでください。データセンターはIPを形式的に見る場所です; 居住用はトラストを考慮する場所です; モバイルはネットワークがすべてのサーバーを厳格にブロックする場所です。そして、すべての層の一貫性を監視してください：それこそが、正しく設定されたように見えるプロジェクトの大多数が崩れる理由です。
```