成功率が対象で低下し、チャレンジページが表示され始めると、最初に浮かぶ妥当な考えはIPがBANされたというものだ。それが正しいこともある。しかし多くの場合はそうではなく、その違いは重要だ。なぜなら対応がまったく逆になるからだ。一方はアドレスの変更を求め、もう一方は速度を落とし、それ以外は何も変えないことを求める。
そしてこの問題全体を捉え直す構造的な論点がある。ローテーティングのレジデンシャルプールでは、アドレスを所有していないため、修復すべきアドレスというもの自体が存在しない。回復とは次のリクエストが受け入れられることを意味し、それを持続的に実現する唯一の方法は、直前のリクエストが拒否された原因を突き止めることだ。
まず、本当にBANかどうかを確認する
外から見ると似ているが、意味の異なる4つのものがある。
レート制限は一時的なもので、ペースに関するものだ。通常は429で表れ、時にはRetry-Afterを伴うこともあり、速度を落とせば自然に解消する。アドレスをローテーションして対応するのは典型的な誤りだ。なぜなら新しいアドレスから同じペースを維持することこそが、スロットリングを恒久的なものに変えてしまうパターンだからだ。
ブロックは、アドレスまたはセッションを狙った拒否である。チャレンジページ、持続する403、インタースティシャルなどがこれにあたる。これは新しいアイデンティティが実際に助けになるケースだ。
ソフトブロックは危険なものだ。なぜなら200を返すからだ。チャレンジページ、汎用的な結果、切り詰められたリスト、ランディングページへのリダイレクトはいずれもデータのように見えるものとして解析されてしまい、ステータスコードを数えるだけのパイプラインは何もデータを収集していないのに「健全」だと報告する。レスポンス本文を検証していなければ、ブロックまたは偽コンテンツの検出にあるように、これを成功とまったく区別できない。
自分自身のバグも早めに除外しておく価値がある。不正な形式のユーザー名フラグは407を返し、絞り込みすぎたフィルタは502を返し、パーサーの変更によって正常なページが空に見えることもある。これらはいずれもBANではない。
簡単なテスト方法は、まったく別のルート、できれば別の国から、かつ通常の接続で同じURLをリクエストすることだ。すべてが失敗するなら、対象側に問題があるか、リクエストの形が誤っている。本番のルートだけが失敗するなら、本物のアイデンティティの問題を抱えている。
次に、範囲を把握する
問題の規模が、原因の深さを教えてくれる。
1つのセッションだけが失敗し、他は成功しているのはよくあることだ。そのセッションを引退させ、新しい識別子を取得して続行すればよい。ローテーティングプールではこれは常時起きており、プロキシマネージャーの構築で説明されている自動的な引退処理以上の介入は不要だ。
1つのルートが劣化する、つまり対象と国の組み合わせの成功率が下がっている一方で他のルートは維持されている場合、それはその対象へのアプローチ方法に何か問題があることを示している。これがよくある、興味深いケースであり、以降の内容の主題となる。
ある対象へのすべてのルートが失敗するのは、対象が防御を変更したか、障害が起きていることを意味し、見た目を変えない限りローテーションではどうにもならない。来る場所を変えても意味はない。
すべての対象が一斉に失敗するのはBANであることはほとんどない。何よりもまず自分のデプロイ、認証情報、ネットワークを確認すべきだ。
ルート単位のヘルスこそが、この診断を推測ではなく迅速なものにしてくれる。これは大規模でのプロキシヘルス監視で述べられている論点だ。
即座の対応
あるルートが本当にブロックされているとき、直感的にはもっと強く押したくなる。しかし逆のことをすべきだ。
そのルートへの送信を停止する。 拒否している対象を叩き続けることは問題を悪化させ、使えないレスポンスに帯域を浪費し、新しく触れるアドレスもフラグを立てられていくことで被害が広がる。サーキットブレーカーは、人が気づくのを待つのではなく、これを自動的に行うべきだ。
積極的にリトライしない。 ブロックしている対象へのリトライの嵐は、狭い問題を広範囲な問題に変えてしまう最も速い方法だ。だからこそリトライにはループではなく予算と分類が必要だ。これはリトライとバックオフで述べている通りだ。
待つ。 ほとんどのブロックは時間で区切られている。数十分から数時間のクールダウンで状態が完全に解消することが多く、クールダウン中に再開すると時計がリセットされてしまう。
アドレスだけでなくアイデンティティを変える。 ブロックの原因が「どこから来たか」ではなく「どう見えるか」だった場合、アドレスだけを新しくしても、重要な部分は何も変わらない。
実際の原因を見つける
ブロックは4つの原因から生じ、その頻度順に確認していく価値がある。
ペース。 リクエストが多すぎ、規則的すぎ、アドレスが少なすぎる。完全に均等な間隔そのものがシグナルになる。人間のトラフィックはバースト的で不規則だからだ。対処法はアドレスあたりのレートを下げ、ジッターを加え、より広く分散させることだ。詳細はレート制限とスロットリングと、分散の計算については実際に必要なプロキシIPの数を参照。
リクエストの形。 自称しているブラウザと一致しないヘッダー、欠けているクライアントヒント、出口の国と矛盾するAccept-Language、User-AgentはChromeなのにTLSフィンガープリントはPythonだと示している、といったものだ。これらは欠落ではなく矛盾であり、検出は容易だ。適切なヘッダーの設定とジオ・タイムゾーン・ロケールの一致を参照。
振る舞い。 人間なら取らないような順序でエンドポイントを叩く、ブラウザなら読み込むはずのものを一切読み込まない、フローの途中でアイデンティティをローテーションする、ページネーションを機械的な速度でクロールする、といったことだ。スクリプトにしか意味をなさないシーケンスは、スクリプトとして認識されやすい。
アドレスの品質。 時には本当にプールに原因がある。レピュテーションの低いアドレスは振る舞いにかかわらずチャレンジを引き寄せ、レジデンシャルとされるプールにデータセンターのアドレスが混入していれば、それはデータセンターのアドレスとまったく同じように振る舞う。レジデンシャルを装ったデータセンターIPの見分け方を参照。
あるルートがブロックされていて、ペースもリクエストの形もどちらも妥当である場合、そのときこそアドレスの品質が最初の思い込みではなく、有力な仮説になる。
繰り返さずに再開する
うまく戻れないことこそが、解消したはずのブロックを繰り返す原因になる。
フルジョブではなくカナリアから始める。新しいセッションを通じた少数のリクエストを、正しく検証しながら送り、対象が再び受け入れているかを確認する。通過したら、以前のレートで即座に再開するのではなく、徐々に引き上げる。問題を引き起こしたペースにすぐ戻ることは、それ自体が認識されやすいパターンだからだ。再開前に何かを変える。ペース、ヘッダー、セッション戦略、地理的位置のいずれでもよい。まったく同じ状態で再開するのは、ブロックがランダムだったという賭けに等しい。そして引き上げている間は検証済みの成功率を監視する。翌朝ではなく最初の数分で気づくためだ。
こうしたすべてを経てもなお対象がしつこく敵対的であるなら、正直な選択肢は、その対象への野心を下げるか、異なるアプローチを取るか、コストに見合わないと受け入れることだ。これは強く保護されたサイトのスクレイピングで述べているエスカレーションの論理である。
結論
まずこの4つの類似ケースを見分けること。レート制限をローテーションで対応すると悪化し、ソフトブロックを成功としてカウントすると見えなくなる。次に範囲を確定すること。1つのセッションの失敗はよくあることであり、1つのルートの劣化は原因を探る価値があり、すべてが一斉に失敗するのは通常自分自身のデプロイの問題だ。あるルートが本当にブロックされているときは、押すのではなく止め、リトライで押し込まず、クールダウンを待ち、アドレスだけでなくアイデンティティを変える。そして可能性の高い順に原因を探る。ペース、リクエストの形、振る舞い、そして最後にプールの品質だ。カナリアと段階的な引き上げで再開し、何かを変えた上で、その間は検証済みの成功率を監視する。ローテーティングプールにおいて、アドレスは資産ではなかった。資産はアクセスであり、アクセスは普通に見えることによって得られる。
クリーンな状態から再開できる場所を提供するのがresidential proxiesであり、国や都市を指定できる本物の家庭グレードのアドレスの大規模なプールにより、引退したセッションは使い回されるのではなく置き換えられる。そしてper-GB pricingにより、規律ある回復のほうが意固地な回復よりも安価になる。