ローテーションプロキシ解説：IP切り替えの仕組みと処理が失敗する場面

毎晩数百の商品ページを調べる価格監視スクリプトが、何か月も正常に動いていました。頻度を上げ、2つ目の販売店を追加すると、ログは429応答やCAPTCHAで埋まりました。掲示板ではローテーションプロキシを勧められます。IPが多ければブロックが減るという考えは、半分だけ正しいのです。

固定ゲートウェイの背後で出口IPを変え、IP単位の制限を下回るよう通信を分散します。ただしログイン中にも変わり、認証済みセッションが続かないことがあります。1つの問題を解決して別の問題を作ります。

短いバージョン

• ホスト名とポートからなる単一ゲートウェイが、プール内のIPでリクエストを転送し、規則に従って出口IPを変えます。
• リクエストごとの切り替えは公開ページ取得などステートレスな処理向けです。ログインやカートには固定セッションか固定プロキシが適し、IPの継続性を確認するサイトでは特に重要です。
• 正しく切り替わっても、他の利用者が共有IPの評判を悪化させれば失敗します。プールの大きさより、対象に対するアドレスの新しさや共有の少なさが重要です。
• アカウント、トークン、Cookie単位の制限には効きません。少量の処理では、まず速度を落とし、待ち時間を示すRetry-Afterに従います。

ローテーションプロキシとは？

単一ゲートウェイがプール内のIPで転送します。切り替えはリクエストごと、時間ごと、セッションごとなど。接続先ホストとポートは一定で、対象が見るアドレスをゲートウェイが選びます。

リクエストの流れ：

1. クライアントは常に同じホスト名とポートに送ります。
2. ゲートウェイが規則を適用して出口IPを選びます。
3. そのIPから対象サイトへ送信されます。
4. 対象は出口IPを送信元として見ます。ゲートウェイがX-Forwarded-Forなどで転送しない限り、自分のIPは見えません。

プール、稼働確認、障害時の切り替えは提供元が管理するため、スクリプトが知るのはホストとポートだけです。この便利さがサービスとして売られる理由です。自前のプロキシで無料のローテーションが得られるわけではなく、通常は安定した出口IPが1つあるだけです。料金はプールの維持に対して支払います。

ゲートウェイとプールの組み合わせをバックコネクトプロキシと呼びます。MDNのプロキシサーバーガイドはゲートウェイをフォワードプロキシの別名として示しており、より平易な呼び方です。IPが住宅、データセンター、モバイルのどれかは切り替え頻度とは別の話です。

IPの切り替え時点は何で決まる？

規則と提供元によって、リクエスト単位、接続単位、固定時間、明示コマンドなどが選べます。クライアントや管理ツールが失敗やブロック後の再試行前に変える場合もあります。「リクエスト単位」の意味を確認してください。複数のHTTPSリクエストが同じトンネルとIPを共有することがあります。暗号化HTTPSを中継するゲートウェイは通常、対象のステータスコードを読んで自ら切り替えられません。

表は配分の判断です。分散は各IPを閾値以下に保ち、継続性は同じ訪問者としての認識を助けます。毎回切り替える方式は分散を最優先します。失敗時の方式は妥協案に見えますが、費用を隠しがちです。ログは再試行成功を示し続け、最後には何も通らなくなります。固定セッションは逆に、一定時間1つのIPを維持します。

固定セッションとローテーション、固定プロキシの違いは？

固定セッションは同じ訪問者に見せるため一時的にプールのIPを確保し、後で解放します。固定プロキシは利用中ずっと同じIPを提供します。毎回切り替える方式は確保しません。対象がリクエスト間で利用者を認識する必要があるかで選びます。

ステートレス取得では毎回切り替える方式が一般的です。ログインではIP維持の2方式を期間で選びます。固定セッションは借りて返し、固定プロキシは割り当てを保ちます。毎日同じIPで入ると再訪利用者に見えます。提供元の時間枠を最長処理と比較し、障害時も確認します。期限前に変える提供元もあれば、厳密な単一IPモードではリクエストを失敗させます。長い時間枠だけでは継続性を保証しません。

どんなとき処理が壊れる？

ログイン、2FA、カート、決済、多段階フォームの途中で変わると失敗し得ます。Cookie自体がIP変更で無効になるわけではありません。ただしIPに結び付けたセッションや不正対策のネットワーク検知により、ログアウト、再認証、警告の対象になります。

これはプロキシ狙いではなく、サイトの役割だと考えます。Cookieは1分前と同じブラウザーだと主張し、IPは確認材料です。認証済みセッションのネットワーク移動は、盗難Cookieの別の場所での再利用に似ています。不正対策はこれを検知するためにあり、ログアウトや2FAは相応の反応です。

OWASPのセッション管理ガイドは、IPやUser-Agentの変化の確認を説明しています。サイトの対策によっては予期しない変化が警告や終了を招きます。

サイトはリクエスト間であなたを覚える必要がありますか。あれば1IPを維持し、なければ切り替えます。夜間の公開価格確認は不要ですが、管理画面に入ってレポートを出す処理は最初から最後まで同じIPが必要です。

実践のヒント：混合処理は分離します。ステートレス取得はローテーション、ログインと認証後の操作は固定セッションか固定IP。逆の要件を同じ規則で扱わないでください。

なぜ数日後にプールが使えなくなる？

正常に切り替えても失敗します。変わるのはIPで評判ではありません。共有IPは以前の活動を引き継ぎ、同じ対象での多用が警戒と成功率低下につながります。

プールは有限の共有資源です。各顧客がサイトでの評判を消費します。他の顧客が同じIPであなたの対象にアクセスすると、CAPTCHAやブロックという代償を払います。サポートではIP評判が、観測した活動に反応するサイトやブロックリストの生態系のように動くのを見ました。

広告しやすいプール規模の予測力は見た目ほど高くありません。成否を決めるのは：

• 同じ対象で直近に使われた時点。他の顧客が1時間前に使ったIPはすでに計上済みです。
• 共有する顧客数。処理が多いほど早く消耗します。
• ネットワークの多様性。少数の範囲に集中すると一括ブロックされます。
• 警戒済みかどうか。不正と判定されたIPを残すプールはそのまま配布します。

使い回された大きなプールは、対象に新しいIPを持つ小さなものより悪い場合があります。自分の対象で長期に成功率を比較してください。最初の成功は持続的性能の証明ではありません。

本当にローテーションプロキシが必要？

IP単位の制限内で分散できますが、制限や再試行指示を守る代わりにはなりません。MDNの429リファレンスによれば、通常はIPベースでも、認証やCookieがあれば利用者やアプリ単位の場合があります。アカウント制限は新IPを無視します。少量ならまずRetry-Afterに従います。

規格は429を定義したRFC 6585です。待ち時間を示すRetry-Afterを含められますが、利用者の識別や数え方は定めません。例は認証情報や状態を持つCookieでの識別です。

不適切な購入は3つ。アカウント、APIトークン、Cookie制限では全IPが同じ枠を消費して429が続きます。小さな処理なら夜間の数百ページを分散し、Retry-Afterを待ち、無料で指数バックオフで再試行できます。そして安定した識別情報が必要なログイン処理は固定IP向けです。

IP制限、量による価値、許可された範囲の独立リクエストという条件で有用です。それでも利用規約は有効です。サイトは接続レベルのクライアント情報や送信間隔も判断するため、切り替えだけでアクセスを保証できません。

購入前に制限文書と応答ヘッダーを確認します。同等の認証済み要求が429で同IPの匿名要求が成功しても、アカウントや認証制限の示唆であり証明ではありません。両方失敗ならIP、リソース、サーバー全体の可能性があります。同等のエンドポイントと速度で比較し、再テスト前にRetry-Afterを守ります。

よくある質問

VPNと同じですか？

いいえ。VPNは通常、機器全体の通信を単一サーバーへの暗号化トンネルに通し、接続中は出口IPを維持します。プロキシはアプリやリクエストごとに設定し規則で変えるため、1つのスクリプトが多数のIPを使えます。

匿名になれますか？

完全ではありません。対象からIPを隠しますが、提供元は元のアドレスと接続先を見ます。ログインや保存Cookieを送れば、対象は出口IPに関係なくアカウントやCookieで認識します。

サイトはブロックできますか？

はい。プロキシで複製されたサイトについてのHacker Newsスレッドの運営者が見たように、送信元IPが変わると個別ブロックは効かない場合があります。返信ではネットワークや範囲全体の遮断が提案されました。さらにリクエストの傾向を見るWAFも使えます。

どの頻度で変えるべき？

共通の間隔はありません。対象のIP制限次第です。ステートレスなら必要な頻度だけ、継続が必要なログインや決済のセッション内では変えません。