ログイン後の取得失敗を切り分ける：Cookieとプロキシ経路の検証手順

ログインには成功するのに、次のページで再認証を求められたり取得に失敗したりしても、直ちにプロキシのIP固定不足とは判断できません。まずCookieの保存・送信条件と通信経路を別々に観測し、どの操作の直後に状態が変わったかを確認します。

先にCookieの送信条件を確認する

HTTPでは、サーバーがSet-CookieでCookieを渡し、クライアントが保存済みの属性などを基に、後続リクエストのCookieヘッダーへ含めるかを判断します。RFC 6265

特に確認したいのは次の3点です。

• Domain：省略されたCookieは、原則として発行元サーバーだけに返されます。ログイン後に別のサブドメインへ移動する構成では、送信先ホストとCookieの対象範囲を照合します。RFC 6265
• Path：リクエストURIのパスがCookieのPath属性に一致するときだけ送信対象になります。RFC 6265
• Secure：Secure付きCookieは、通常、TLS上のHTTPなど安全なチャネルへのリクエストに限って含まれます。RFC 6265

ログイン応答のSet-Cookieだけでなく、失敗したリクエストで実際に送ったCookieヘッダーも記録してください。「保存されたか」と「対象リクエストへ送られたか」を分けて見るのが要点です。

curlではCookie jarを明示する

curlでは-b／--cookieでCookieエンジンを開始でき、-c／--cookie-jarで処理後のCookieをファイルへ書き出せます。curl HTTP cookies --cookie-jar自体もCookieエンジンを有効にし、Cookieの記録と利用を行います。curl man page

ただし、Cookie jarを作成・書き込みできない場合でも処理全体が失敗せず、通常は明確なエラーが出ないため、ファイルの存在、更新時刻、権限、内容を別途確認します。curl man page

また、curlとlibcurlはJavaScriptを実行しません。対象サイトがJavaScriptでCookieを設定する場合、curlだけではそのCookieを検出・利用できません。curl HTTP cookies この条件に当たるなら、プロキシプランを変更する前に、利用するクライアントが必要な処理を再現できるかを確認します。

時系列で行う検証手順

許可を得た管理下のHTTPS環境で、次の順に試します。

1. ログイン前後の時刻、URL、HTTP状態、Set-Cookie、送信したCookie、出口IPを記録する。
2. 同一ホスト内のページへ移動し、Cookie jarと送信ヘッダーを比較する。
3. サブドメイン移動、パス変更、リダイレクトを一つずつ加える。
4. 同じCookie jarのまま接続を再確立し、出口IPと応答の変化を記録する。
5. 待機時間だけを段階的に変え、変化が起きた最初の操作を特定する。

比較時は一度に変える条件を一つにします。Cookieが対象外ならDomain・Path・HTTPS利用やクライアント実装を見直し、必要なCookieが送られているのに出口IPの変化と同時に失敗するなら、その観測結果をプロキシ提供元へ示し、固定条件を確認する、という順序が実務的です。

デメリットと向いていない条件

この検証には、ヘッダーやCookieを安全に記録できる環境と、条件を変えて反復する時間が必要です。認証情報やCookieを不用意にログへ残せない運用では、値を秘匿した識別子で比較してください。

Cookieの不保存、属性の不一致、JavaScript非対応が原因なら、固定セッション型プロキシへ変更してもクライアント側の問題は解消しません。反対に、公開ページを単発取得するだけで継続状態を使わない処理では、セッション固定の検証や追加費用が目的に見合わない場合があります。観測結果から必要性を確認してから契約条件を選ぶことが、過剰な構成を避ける判断軸になります。