顧客との会話で最も多いのはこれです。「レジデンシャルプロキシがフラグ付けされているに違いない、ブロックされている」。確認すると、IPはクリーンで、高評価のレジデンシャルアドレスです。問題はプロキシではありません。リクエストの送信方法にあります。
レジデンシャルIPが与えてくれるものは一つだけです。クリーンなネットワークアイデンティティです。クリーンなリクエストまでは与えてくれません。アンチボットシステムは数十種類の信号を見ており、IPはその最初の一つに過ぎません。トラフィックに関するその他すべて、ヘッダー、タイミング、フィンガープリント、セッションの振る舞いが「オートメーション」だと告げているなら、完璧なレジデンシャルIPでも救われません。レジデンシャルプロキシの検出のほとんどは、IPの失敗ではなく、設定レベルでの自傷行為です。
本記事は、優れたレジデンシャルプロキシがそれでも検出されてしまう原因となる間違いと、それぞれの修正方法についての実践者向けガイドです。
1. セッション途中でのIPローテーション
最も多く見られる間違いであり、最も自滅的なものです。あるIPでログインし、その次のリクエスト、つまりログイン後のページを取得するリクエストが別のIPから送信される。サイト側から見れば、認証済みのセッションが突然新しいアドレスに瞬間移動したことになります。これは即座にフラグが立てられ、IPの品質では解決できません。
修正方法：ローテーションモードをタスクに合わせることです。複数ステップのフロー（ログイン、ナビゲーション、チェックアウト）にはスティッキーセッション、つまり一連の流れ全体で一つのIPを維持する仕組みが必要です。リクエストごとのローテーションは、状態を持たない独立したフェッチのためのものです。これらを混同し、固定すべき場面でローテーションしてしまうことが、「レジデンシャルプロキシが検出された」の単一最大の原因です。（どちらをいつ使うべきかはスティッキー対ローテーティングを参照してください。）
2. 一つのIPへの過度な負荷
正反対の間違いです。一つのスティッキーIPを固定し、短時間で何千件ものリクエストをそこに集中させる。本物のレジデンシャルユーザーは1分間に5,000ページも読み込みません。リクエスト量が人間離れしていれば、どれほど汚れのないIPでも自動化されているように見えます。
修正方法：負荷をプール全体に分散させることです。スティッキーセッションは、そのフローが本当に一つのアイデンティティを必要とする間だけ使用し、その後はローテーションします。IPごとのリクエストレートは人間的な範囲に保ちます。大規模なプールの意義は、単一のIPが疑わしい負荷を担わないことにあります。それを台無しにすれば、プールそのものを無駄にしていることになります。
3. IPと矛盾するジオ信号
ドイツのレジデンシャルIPを経由させているにもかかわらず、リクエストはAccept-Language: en-USを送信し、ブラウザのタイムゾーンはAmerica/New_York、ロケール設定は米国のままです。IPはドイツだと言っているのに、それ以外のすべてが米国だと言っています。この矛盾は典型的な検出信号であり、しかも完全にあなたのコントロール下にあるものです。
修正方法：すべてのジオ信号をIPと一致させることです。ある国をターゲットにする場合、Accept-Language、タイムゾーン、ロケール、さらには通貨・地域設定もそれに合わせます。ある場所のレジデンシャルIPは、リクエストの残りの部分もその場所に属している場合にのみ説得力を持ちます。
4. オートメーションを露呈するフィンガープリント
IPはレジデンシャルですが、リクエストはpython-requests/2.xによって送信され、3つのヘッダーの順序が間違っており、TLSハンドシェイクは実際のブラウザのどれとも一致しません。アンチボットシステムはUser-Agent、ヘッダーの組み合わせと順序、TLS/JA3フィンガープリントを読み取ります。これらの間にミスマッチがある場合（PythonのTLSフィンガープリントの上に「Chrome」のUser-Agentが乗っている、など）、それは決定的な露呈につながります。IPはレジデンシャルですが、クライアントは明らかにスクリプトです。
修正方法：一貫性のある、ブラウザと整合したフィンガープリントを送信することです。現実的なUser-Agentを使用し、実際のブラウザが送信するヘッダーの完全なセットを正しい順序で送信し、名乗っているブラウザとTLSフィンガープリントが一致するクライアントを使用します。プロキシのフィンガープリントではこのレイヤーを詳しく解説しています。これは検出回避において最も過小評価されている半分です。
5. DNSの漏洩（socks5対socks5h）
これは微妙な問題です。socks5h://の代わりにsocks5://を使用すると、リクエストがプロキシを経由する前に、あなたのマシンがターゲットのホスト名をローカルで解決してしまいます。このDNSルックアップは実際のネットワークから発生するため、本当の位置情報が漏洩する可能性があり、また構成によっては、DNS解決と接続が異なる場所から来ていることでプロキシが使われていることが露呈する場合もあります。
修正方法：DNSをプロキシ側で解決することです。socks5h://（h付き）を使用するか、HTTPプロキシの場合はクライアントが事前解決を行っていないことを確認します。これにより、ルックアップを含むリクエスト全体がレジデンシャルの出口から発信されるようになります。（詳細はオートメーションのためのSOCKS5を参照してください。）
6. 人間らしくないリクエストパターン
完璧なIPとフィンガープリントであっても、振る舞いが正体を明かしてしまうことがあります。正確で機械的に規則的な間隔で発射されるリクエスト。アクション間の思考時間がゼロ。一つのセッションから10人の「ユーザー」が完全に並行して同じエンドポイントにアクセスする。クッキーなし、アセットの読み込みなし、JavaScriptなし、人間のブラウザが単独で生成することのない生のHTMLフェッチのみ。
修正方法：人間らしく振る舞うことです。ランダムな遅延を加え、タイミングを変化させ、完全に均等な間隔でリクエストを発射せず、一つのアイデンティティのもとで不可能な並行処理を行わないようにします。IPとフィンガープリントのチェックを通過した後、スクレイパーを捕捉するのは行動検出であることが増えています。
7. 一つのアイデンティティを多数のIPで運用する
間違い#1の対をなすものです。一つのIPでセッションクッキーを取得し、負荷を分散させるためにその同じクッキーを数十の異なるIPで再利用する。サイト側から見れば、一つのログイン済みアカウントが、異なる都市の20のアドレスから同時に接続していることになります。本物のユーザーはそのようなことをしません。
修正方法：アイデンティティとIPを結びつけたまま保つことです。一つのセッションには、そのセッションの寿命の間、一つのスティッキーIPを使います。IPをローテーションする場合は、新しいセッションを開始し、古いアイデンティティのクッキー、ローカルストレージ、トークンを新しいアドレスに引き継がないようにします。
8. ソフトブロックを無視して盲目的にリトライする
CAPTCHAや429に遭遇し、スクレイパーが同じIPで同じレートのまま、同じリクエストを即座にリトライする。リトライするたびに、サイトに対してあなたが自動化されていることを確認させることになり、フラグは「CAPTCHAを表示する」から「このIPをブロックする」へと段階的に強化されていくことが多いです。
修正方法：ソフトブロックをノイズではなく信号として扱うことです。後退し、IPをローテーションし、速度を落とし、チャレンジを引き起こしたパターンを再考します。盲目的なリトライは、回復可能なソフトブロックをハードブロックに変えてしまいます。（一般的な対処法はブロックを回避する方法を参照してください。）
9. プールが崩壊するまでジオを過度に制約する
国＋州＋都市＋ASNをターゲットにする。精密であればあるほど良いはずですよね？ しかし今、マッチするプールはごく小さくなり、ゲートウェイは同じ一握りのIPを何度も繰り返して割り当てることになります。巨大で多様なレジデンシャルプールを、5つのアドレスだけのローテーションに変えてしまい、それぞれが負荷全体を担うことになり、あっという間に消耗してしまいます。
修正方法：タスクが必要とする範囲でのみターゲットを絞ることです。サイトが国だけを重視するなら、都市＋ASNではなく国をターゲットにします。過度な制約はプールの多様性を縮小させ、フットプリントを集中させてしまいます。これはレジデンシャルプロキシの目的とは正反対です。（狭いジオ指定をIPローテーション経由で行うのは、ターゲットが本当にそれを必要とする場合に限りましょう。）
10. ブラウザオートメーションの漏洩
レジデンシャルプロキシを介して実際のブラウザ（Puppeteer、Playwright、Selenium）を操作する場合、ブラウザ自体が正体を明かしてしまうことがあります。WebRTCはプロキシの背後にある実際のIPを露呈させる可能性があります。ヘッドレスモードの痕跡、欠落しているまたはオートメーション特有のプロパティ、デフォルトのオートメーションフラグは、出口IPがどれほどクリーンであっても、すべてボットであることを示す信号となります。
修正方法：ブラウザを強化することです。実際のIPが漏洩しないようにWebRTCを無効化またはルーティングし、ヘッドレスの痕跡を取り除き、オートメーションフレームワークを通常のブラウザとして提示するように設定します。明らかにオートメーション化されたブラウザの前にあるレジデンシャルIPは、無駄になったレジデンシャルIPです。
これらすべての背後にあるパターン
上記のすべての間違いには同じ根本原因があります。レジデンシャルIPを、変装の一つのレイヤーとしてではなく、変装そのものとして扱ってしまうことです。検出は全体的なものです。アンチボットシステムはIP、フィンガープリント、ジオ信号、セッションの振る舞い、タイミングから一つの姿を組み立て、矛盾にフラグを立てます。PythonのフィンガープリントとUSのヘッダー、機械的なタイミング、共有されたクッキーを持つレジデンシャルIPは、レジデンシャルユーザーではありません。それはレジデンシャルIPをまとったスクリプトであり、現代の検出はそれを見抜いてしまいます。
IPを正しく整えること（クリーンで、レジデンシャルで、適切に管理されていること）、そしてその他すべての信号をそれに一致させること。それがこの技術の全体です。
FAQ
IPがクリーンなのに、レジデンシャルプロキシが検出されるのはなぜですか？ IPは一つの信号に過ぎないからです。フィンガープリント（User-Agent、ヘッダー、TLS）、ジオ設定、セッションの振る舞い、リクエストのタイミングがレジデンシャルIPと矛盾している場合、アンチボットシステムはその矛盾にフラグを立てます。レジデンシャルプロキシの検出のほとんどは、IPの問題ではなく設定の問題です。
最も多いレジデンシャルプロキシの間違いは何ですか？ セッション途中でIPをローテーションすること、つまりログインとその後のリクエストの間でアドレスを切り替えてしまうことで、認証済みのセッションがIP間を飛び移っているように見えてしまうことです。複数ステップのフローには必ずスティッキーセッションを使用してください。
レジデンシャルプロキシはフィンガープリントを隠してくれますか？ いいえ。レジデンシャルプロキシが変更するのはIPだけで、他は何も変わりません。User-Agent、ヘッダーの順序、TLS/JA3フィンガープリント、ブラウザのプロパティは変わらないままなので、別途一致させる必要があります。IPとフィンガープリントは独立したレイヤーです。
ジオの不一致によってレジデンシャルプロキシがブロックされることはありますか？
はい。あるIPが一つの国のものである一方で、Accept-Language、タイムゾーン、ロケールが別の国のものである場合、これは典型的な検出信号です。すべてのジオ信号をIPの位置と一致させてください。
ジオの過剰なターゲティングがなぜ悪影響を及ぼすのですか？ 国＋州＋都市＋ASNまで絞り込むと、マッチするプールが縮小し、同じ少数のIPを再利用することになり、フットプリントが集中して、それらのIPを急速に消耗させてしまいます。タスクが必要とする精度でのみターゲットを絞ってください。
CAPTCHAの後、すぐにリトライすべきですか？ いいえ。同じIPでの即座のリトライはオートメーションであることを確定させ、ソフトブロックをハードブロックへと段階的に強化してしまいます。後退し、ローテーションし、速度を落とし、チャレンジを引き起こしたパターンを再考してください。
結論
レジデンシャルIPは人間らしく見えるために必要ですが、それだけでは決して十分ではありません。実践者たちを最も苛立たせる検出、「良いプロキシを使っているのに、それでもブロックされる」は、ほとんど常に自傷行為です。ローテーションの間違い、フィンガープリントの不一致、ジオの矛盾、あるいは人間らしくないタイミング。これらを修正すれば、クリーンなIPがついにその役割を果たせるようになります。
IPそのものが問題である可能性を疑うなら、それを検証する価値もあります。IPレピュテーションではプールの評価方法を解説しています。しかし、修正が必要なのは接続のあなた側であることのほうがはるかに多いです。まずIPレイヤーを確実なものにするために、高品質なレジデンシャルネットワークから始め、その上でリクエスト内のその他すべての信号をそれに一致させましょう。プロキシは、あなたが与えた変装しか運ぶことができません。