ウェブサイトがプロキシを検出する方法: すべてのシグナルとその対策
プロキシ検出は一つのチェックではなく、複数のチェックの積み重ねです。そして、多くの「検出されない」設定は、最初に地味なチェックで失敗します。ここでは、サイトがプロキシを見つけるために使用するすべてのシグナルと、それぞれの対策を紹介します。
サイトは単一の巧妙なトリックでプロキシを検出するわけではありません。独立したチェックの積み重ねを実行し、接続はそれらすべてを通過しなければなりません。したがって、「検出されない」と呼ばれる設定は通常、最初に地味なシグナルで失敗します: リークしたヘッダー、データセンターIP、ブラウザと一致しないTLSフィンガープリント。ウェブサイトがプロキシを検出する方法を層ごとに理解することが、どのシグナルを実際にクリアできるかを考える唯一の方法です。ここに完全なシグナルスタックとそれぞれの対策があります。
シグナル1: IPアドレスとそのASN
最初で最も安価なチェックは、IPをデータベースで調べることです。商業サービス - MaxMind、spur.us、IP2Proxy、IPHub、proxycheck.io - はアドレスをその自律システム番号（ASN）、IPが属するブロックによって分類します。データセンターおよびホスティングASNは簡単にフラグされるため、クラウドサーバーIPは他のチェックが実行される前にブロックされます。住宅およびモバイルIPは消費者ISPのASNに属しているため、デフォルトでこのゲートをクリアします。この単一のシグナルが、住宅プロキシがデータセンターIPが到着時に死んでいるところで成功する理由です - ASNは「家庭用ブロードバンド」と言い、「AWS」とは言いません。リバースDNSは関連するチェックです: ホスティングプロバイダーを指すPTRレコードはもう一つの手がかりです。
シグナル2: プロキシを示すHTTPヘッダー
不適切に構成されたプロキシはリークします。Via、X-Forwarded-For、Forwarded、Proxy-Connectionのようなヘッダーは、トラフィックが中間者を通過したことを宣言するために存在し、これらを転送する透明なプロキシはサイトに告白を手渡します。ヘッダーの順序と一貫性も重要です: Chromeを主張するリクエストがChromeではない順序でヘッダーを送信する場合、それはフィンガープリントの不一致です。修正は、転送ヘッダーを注入しないプロキシと、模倣しているブラウザと一貫したヘッダーセットを送信するクライアントです。
シグナル3: TLSとJA3フィンガープリント
HTTPが送信される前に、TLSハンドシェイクはクライアントが提供する正確な暗号スイートと拡張から構築されたフィンガープリント（JA3/JA4）を露出します。PythonやGoのHTTPライブラリはChromeとはまったく異なるハンドシェイクを生成します - したがって、Chromeのユーザーエージェントを持つリクエストがPythonのTLSフィンガープリントを持つ場合、それは即座に不一致であり、プロキシはそれを修正できません。なぜなら、それはプロキシ層の下で起こっているからです。これが、クリーンなIPがまだブロックされる理由です: IPは通過しましたが、TLSは通過しませんでした。JA3/JA4 TLSフィンガープリントに関する私たちの詳細な調査は、クライアントのハンドシェイクを実際のブラウザに一致させる偽装ライブラリをカバーしています。
シグナル4: DNSとWebRTCリーク
完璧なIPを持っていても、実際の場所が横からリークする可能性があります。DNSがプロキシを通じてではなくマシン上で解決される場合、リゾルバーの場所があなたを裏切ります - これがまさにSOCKS5ユーザーがsocks5hスキームを使用してDNSがトンネルを通過するようにする理由です。実際のブラウザでは、WebRTCはさらに悪化します: メディアAPIを通じてページに直接、真のローカルおよびパブリックIPを明らかにすることができます。アンチディテクト設定はこの理由でWebRTCを無効にするか、プロキシを通じてルートします。どちらも「サイドチャネル」リークです - プロキシは問題ありませんが、その周りの何かが問題です。
シグナル5: レイテンシー、地理的および行動の一貫性
より微妙なチェックは、合わないものを探します。プロキシは追加のネットワークホップを挿入し、研究技術（学術的な「BadPass」スタイルのレイテンシー分析）は往復時間を比較して2ホップのシグネチャを見つけます - ただし、これは低レイテンシーの住宅出口やモバイルIPに対しては劣化します。実際には地理的一貫性がより重要です: IPがドイツを示しているが、ブラウザのタイムゾーン、言語ヘッダー、ロケールがニューヨークを示している場合、その不一致は強いフラグです。モバイルIPは最もブロックが難しいものであり、キャリアグレードNATは一つのアドレスが一度に何千もの実際のユーザーと共有されることを意味します - それをブロックすると本物の顧客を排除することになります。これがモバイルプロキシが信頼される理由の背後にある論理です。
まとめると: 一貫性が単一のトリックを打ち負かす
一貫性が鍵です。検出は一つの壁ではなく、同意するかしないかの独立した観察のセットです。リークしたプロキシヘッダーを持つ住宅IPはまだ失敗します。PythonのTLSフィンガープリントを持つクリーンなIPはまだ失敗します。勝利する設定は、ISPが割り当てたIP、転送ヘッダーなし、ブラウザに一致するTLSハンドシェイク、トンネルを通じてルートされたDNSとWebRTC、および同じ場所を指す地理/タイムゾーン/言語スタックの端から端まで一貫して退屈です。難しいターゲットをスクレイピングする前に、エグジットをチェッカーでテストして、どのシグナルがリークしているかを確認してください。IPの評判とデバイスフィンガープリントの比較では、最初に修正すべき層をカバーしています。
また、検出はほとんどの場合、明確なイエスまたはノーではないことを知っておく価値があります。ほとんどのシステムはリスクスコアを割り当て、しきい値に基づいて行動します: わずかに疑わしいシグナルは、CAPTCHAやページの軽量版のように摩擦を追加するだけかもしれませんが、一連の赤いフラグは完全なブロックを引き起こします。したがって、単一の「検出されない」トリックを追い求めることは誤ったメンタルモデルです。閉じるたびにスコアが下がり、しきい値を下回ると、サイトは他の訪問者と同じように扱います。最大のシグナル（IPタイプ、その後にヘッダーとTLS）を最初に修正し、再テストすれば、通常は人々が夢中になるエキゾチックな対策を必要とせずに通過することができます。
よくある質問
ウェブサイトはどのようにプロキシを検出しますか？
彼らは一連のチェックを実行します: IPをASNによってプロキシデータベースで調べ、転送を示すHTTPヘッダーを検査し、TLSハンドシェイクをフィンガープリントし、DNSとWebRTCのリークを監視し、地理とレイテンシーの一貫性をテストします。接続はそれらすべてを通過しなければなりません。ほとんどの設定は、微妙なものが問題になる前にIPまたはヘッダーチェックで失敗します。
住宅プロキシは検出されることがありますか？
住宅プロキシはデータセンターIPを殺すASNチェックをクリアしますが、自動的に見えなくなるわけではありません。クライアントが転送ヘッダーをリークし、非ブラウザのTLSフィンガープリントを送信し、またはDNSやWebRTCを介して実際のIPを露出する場合、サイトはセッションをフラグすることができます。住宅IPは最大のシグナルを除去しますが、残りの一貫性があなたをクリーンに保ちます。
私のプロキシが検出可能かどうかをテストするにはどうすればよいですか？
エグジットIPを不正スコアまたはプロキシチェッカーで実行してください - それはASN分類、IPが既知のプロキシリストにあるかどうか、およびその評判を報告します。私たちの無料のIPチェッカーは、ターゲットサイトが見る不正スコアとプロキシフラグを示すので、焼けたIPがあなたの実行を焼く前に捕まえることができます。
なぜクリーンなIPがまだブロックされるのですか？
なぜなら、IPは単一のシグナルに過ぎないからです。新鮮な住宅IPがPythonまたはGoのTLSフィンガープリント、リークしたヘッダー、または地理/タイムゾーンの不一致と組み合わされると、それは不一致であり、サイトはアドレスではなく矛盾に基づいてブロックします。検出を修正するには、IP、ヘッダー、TLS、リークのすべての層を整列させる必要があります - より良いIPを調達するだけではありません。
プロキシ検出は一貫性を報いる一方で矛盾を罰します。データベースチェックをクリアするために住宅またはモバイルIPから始め、その周りの何も矛盾しないようにしてください - ヘッダー、TLS、DNS、WebRTC、地理がすべて同じストーリーを語るようにします。スケールする前にテストし、どのシグナルを修正するべきかを推測するのではなく、正確に知ることができます。