プロキシのセッションアフィニティ：ひとつのリクエストか、ワークフロー全体か

ログイン、リダイレクト、レポートのダウンロードは三つのリクエストです。しかし利用者にとってはひとつの仕事です。リクエストごとに出口を切り替えると、各プロキシが動いていても、その仕事を理解しにくくなることがあります。

まず、経路を所有する単位を定義します。リクエスト単位の選択は独立した操作に向いています。そうした公開操作では、無料プロキシリストが、公開中継者を許可する場合に候補を提供しますが、固定セッションの契約は提供しません。ワークフロー単位の選択は、関連する手順を意図した経路に保ちます。ワークフローが終わるか、定義された復旧判断がそれを置き換えるまで続きます。

Cookie とプロキシのアフィニティは別の状態です

アプリケーションの Cookie はウェブサイトのセッション規則に属します。プロバイダーの固定セッション識別子は、提供される場合、そのプロキシサービスと文書化された接続またはアカウントの方針に属します。どちらもセッションという語を使うというだけでひとつの設定になるわけではありません。

通常の CONNECT 中継者は、ウェブサイトの暗号化された Cookie ヘッダーを読めませんし、それをルーティングの鍵にはできません。サービスが Cookie 駆動の挙動を約束する場合は、どの可視インターフェースがその Cookie を運ぶのか、そこで TLS が終端するのかを確認してください。ウェブサイトの非公開 Cookie がトンネルゲートウェイから自動的に利用できると決めつけないでください。

小さなワークフロー記録を残します。選んだエンドポイント、使った場合はプロバイダーのセッション識別子、アプリケーションのセッション識別子、アフィニティを終わらせる条件です。アカウントの秘密を日常的な記録キーに入れないでください。

厄介な場合を計画する

選んだ経路が途中で失敗した場合、ワークフローが別の出口で安全に続けられるのか、アプリケーションセッションを再確立する必要があるのか、停止しなければならないのかを決めます。失敗した応答は、送信した操作がまったく処理されなかったという意味とは限りません。

恒久的な固定も絶え間ないローテーションも、普遍的に正しいわけではありません。範囲はアプリケーションの整合性要件から選び、そのうえでリクエストのペースとサービスの制限をワークフロー全体に適用します。出口を増やしても、そうした要件は消えません。