スティッキーセッション

スティッキーセッションは、関連するリクエストに1つの出口IPを維持するようプロキシサービスに求めます。割り当てが有効で出口が使える間、アプリはそのアドレスでページを開き、データを送り、結果を受け取れます。タスクが終われば、次のタスク用に別セッションを開始できます。

一般には、ローテーションプールのアクセス方式の1つです。全体の比較は固定IPプロキシとローテーションプロキシで説明しています。ここでは、1つのタスクでアドレスを保つ方法、割り当て期間、中断の原因を取り上げます。

選択したIPをサービスが維持する方法

サービスは、どの接続が同じタスクに属するかを識別する必要があります。よく使うのはプロキシ設定内のセッション識別子です。最初の接続で出口を選び、識別子に結び付けます。その後、同じセッション設定の接続は、セッションが有効な間、その出口を使います。

たとえばブラウザーテストで、セッション名task1を使います。最初の接続に、例の出口IP 198.51.100.27が割り当てられます。同じ有効な割り当てで次のページを開いたりフォームを送ったりすると、同じアドレスを使います。名前は割り当てを識別し、IPを符号化するものでも永久に確保するものでもありません。

識別子はプロキシのユーザー名に追加したり、APIで選んだり、設定したポートで表したりします。個別名のないデフォルトセッションを提供するサービスもあります。割り当ての管理方法が異なるため、共通のユーザー名形式やポート番号はありません。

スティッキーセッションは複数のネットワーク接続にまたがって利用できます。単に開いた接続を再利用するのとは異なります。通常の同じTCP接続内では、リクエストはもともと出口IPを保ちます。接続をまたいで維持するかは、同じセッション設定で新しい接続を開いたときの動作を見ると分かります。

複数のリクエストに1つのIPが必要な場面

複数手順のブラウザーテストが分かりやすい例です。ログイン、設定ページを開く、変更を送る、結果確認と進みます。特にサイトがアドレスをセッション確認の1つに使う場合、送信元IPを安定させることで、テスト中の不要な変化を除けます。

購入や予約のテストも、地域ごとの一貫した体験が必要な場合があります。同じ出口から検索し、選択し、次の段階を確認します。手順間でネットワーク地域を揃えやすくなりますが、サイトはアカウント設定、配送情報、Cookieも表示の判断に使う場合があります。

別の例は、関連操作を一定の送信元アドレスから行うことを接続先サービスが期待する、一連のAPI呼び出しです。停止と再試行を含む全手順を割り当て期間に収めます。一方、無関係な公開ページの照会は同じIPが不要な場合があります。維持が役立つのは継続性が必要なときであり、アドレスの評判改善やサイトの受け入れ保証ではありません。

プロキシセッションはサイトのログインを保たない

プロキシサービスは出口アドレスを制御します。サイトは、ログイン状態、カート、フォームの進行状況といった自分のセッションを管理します。ブラウザーやHTTPクライアントは通常、Cookieや認証トークンでその状態を運びます。同じセッションという言葉でも、保持する情報は違います。

したがって、出口IPが同じでもログインは失効できます。Cookieを消すと、プロキシの割り当てに影響せず、サイトが利用者を認識しなくなる場合があります。逆に、IP変更後も有効なログインを受け入れるサイトもあります。動作はサイトのルール次第です。

HTTPライブラリのセッションオブジェクトは、多くの場合Cookieを保存し、接続を再利用します。作成するだけでプロキシのスティッキーアクセスが有効になるわけではありません。完全なワークフローでは、サイトの状態と目的のプロキシ割り当てを併せて保つ必要があります。タスク間でCookieを共有してはいけない場合は、個別のブラウザープロファイルや分離したクライアント状態が引き続き必要です。

セッション時間の実際の意味

どちらもセッション時間と呼ばれる2種類のタイマーがあります。固定の有効期間は、開始から割り当てが存在できる時間を制限します。非アクティブタイムアウトは、最後の対象リクエストからの休止時間を制限します。新しいリクエストで非アクティブタイマーをリセットしても、別の固定有効期間は延びません。

上限が10分の2つの例を考えます。どちらも14:00に開始し、14:08に追加のリクエストを受けます。固定期間では期限は14:10のままです。非アクティブ方式では、そのリクエストで期限が14:18へ移ります。同じ時間表示でも、実行中の動作は大きく異なります。

両方の上限を適用するサービスもあります。その場合、どちらかに達すると割り当てが終わります。通常のデフォルト値と、設定可能な最長時間も異なり得ます。通信を続ければ非アクティブ失効を避けられる場合がありますが、別の最大有効期間はなくなりません。

期限で、元の出口への割り当てが終わります。同じセッション名でも、後の接続は別のアドレスを受け取る場合があります。開いている接続を完了させるか閉じるかは、サービス次第です。タイマーが未完了のTCP通信を別IPに移すことはありません。

タスク全体、遅い応答、予定の停止を含む時間枠を選びます。古い割り当ての終了間際に新しい処理を始めると、設定時間ほどの余裕はありません。休止中のセッション維持だけを目的としたリクエストも実通信であり、リクエスト数や通信量の枠に数えられる場合があります。

並行タスクを分けて管理する

独立タスクがそれぞれ安定したアドレスを必要とする場合、個別の識別子を与え、手順全体で維持します。次のページを読み込む処理は、毎回新しい名前を作らず、そのタスクのセッションを再利用します。再試行でも、無関係なプロキシ設定に気付かず変えてはいけません。

2つのブラウザーテストを同時実行するとします。最初はtask1、次はtask2を使い、Cookieもそれぞれ維持します。両方に同じセッション名を与え、ほかの設定も同じなら、割り当てを共有するよう求めることになります。通常の新規タブを開くだけでは、別のプロキシ設定やCookie保存領域は作られません。

異なる識別子は別々の割り当てを要求しますが、必ず異なる出口IPになる保証ではありません。アドレスの違いを約束するかは、別の製品属性です。また、共有プールの出口ならほかの利用者も使えるため、スティッキーアクセスでも自分のアカウント専用にはなりません。

対応していれば、複数の接続が同じセッションを同時に使えます。出口を共有し、アカウントの接続・用量上限も適用されます。名前を増やしても上限は増えません。本格実行前に、並行タスク数と、各タスクが開く接続数の両方を確認してください。

予想より早くアドレスが変わる理由

タイマーが有効でも、使えない出口を動かし続けることはできません。住宅用端末がオフラインになる、携帯回線のパブリックIPが変わる、サーバーに届かなくなる場合があります。指定時間は割り当ての時間ルールであり、それだけで元の出口の可用性を保証しません。

出口を失った際の対応は2つあります。後続リクエストを続けるために代わりを選ぶか、エラーを返して元の出口を使う要件を保つかです。選択できる製品もあります。自動交換は次の接続を優先し、エラーは別アドレスで続行する前にアプリが停止する機会を与えます。

名前が同じでも、ほかの設定が同じとは限りません。別ゲートウェイへの移動や国フィルター変更で、別割り当てになる場合があります。有効範囲はサービス次第で、名前さえ同じならどこでも使えるのではなく、特定のアカウント、製品、入口サーバーに属する場合があります。

途中でIPが変わったら、次はタスクの状態を判断します。読み取りだけの手順は安全に繰り返せる場合があります。注文送信やデータ変更は注意が必要です。応答を失っても、操作失敗の証明にはなりません。別出口で再開・続行する前に、どこまで完了したかを確認します。

一時的な継続性で足りる場面

始めと終わりが明確で、その実行中だけ1つのIPが必要なタスクに向いています。予定の休止を越えて維持できるか、全タスクを覆うか、出口喪失時に要件どおり処理するかをテストします。通常の休止後の新規接続も含めます。1本の開いた接続内で活動しても、次の接続まで割り当てが残る証明にはなりません。

同じアドレスをサーバーの許可リストに残す、または明日も使う必要があれば、その目的の固定割り当てを提供するサービスを使います。期限後に名前を再利用しても元IPは確実に戻りません。一時的維持と長期割り当ては、別の継続性要件を解決します。