Magento のリダイレクトループは、おそらく VPN のせいではありません

アクセスログに 302 が見え、ストアフロントが VPN 経由で読み込まれないとき、結論はひとりでに書かれてしまいます。その結論はたいてい、興味深い形で間違っています。リダイレクト応答が記録するのはブラウザに指示された行き先であり、トンネル、証明書、アプリケーションのどれが問題を生んだかは何も語りません。ログの一行は調査の出発点であって、結論ではありません。

302 は「どこへ」を語り、「なぜ」は語らない

アクセスログの一行はリクエスト、ステータス、サイズを記録しますが、重要な Location ヘッダーはたいてい書き漏らします。単一のリダイレクトは、正規のホスト名、末尾スラッシュの正規化、HTTPS への切り替えといった、まったく正常なこともあります。必要なのは順序であり、一度の跳躍とループは別の障害で、持ち主も違うからです。スキーム間を繰り返し跳ぶのは URL とスキームの扱いに向いています。ブラウザが解決できない名前に跳ぶのは、まったく別の場所に向いています。

どちらも VPN についての証拠にはなりません。トンネルは経路であり、リダイレクトはアプリケーションが書いた指示です。

ログの一行ではなく、連鎖を記録する

ブラウザのネットワーク表示を使い、跳躍ごとに、要求 URL、ステータス、Location ヘッダー、時刻の四項目を記録します。興味深いのは決して完了しない跳躍なので、最後は最終応答か接続エラーで締めます。これを動く経路で一度、失敗する経路で一度、同じアカウントと同じ操作で行います。二つの連鎖を比べることは、ログのどの一行よりも価値があります。

その記録は非公開にしてください。URL はセッション識別子を運び、保存したブラウザアーカイブは思った以上に多くを運びます。チケットに貼る前にクエリ文字列を削除してください。

アプリケーションが考える自分の URL

Magento は設定から絶対 URL を生成し、ウェブサイトやストアビューごとに範囲を定めます。bin/magento config:show web/secure/base_url はアプリケーションが信じている値を出力しますが、それはブラウザが使った名前ではなく、ビルドや移行から残ったホスト名であることがよくあります。そこに内部ホスト名があれば、ブラウザは行けない場所へ送られており、トンネルを変えても直りません。

安全なベース URL と安全でないベース URL を、目の前の公開名と比べてください。どちらかに食い違いがあれば、まさにあなたが見ているリダイレクトが生まれます。

信頼されたプロキシヘッダーは契約です

TLS がロードバランサーで終わると、アプリケーションには平文の HTTP が見え、そうではないと伝える必要があります。オフローダーヘッダーの設定は、たとえば転送プロトコルのようにプロキシが設定するヘッダー名を指定し、アプリケーションはスキームの判断でそれを信頼します。

その信頼は一つのプロキシとの契約であり、一般的な許可ではありません。任意のクライアントからヘッダーを受け入れると誰でもスキームを主張できてしまうため、指定されたプロキシが設定する場所にだけ置くべきものです。ヘッダー名とプロキシの挙動が食い違えば、アプリケーションはブラウザが一度も使っていないスキームへのリダイレクトを生成し、ループが閉じます。プロキシの設定とアプリケーションの設定を合わせて確認し、変更を反映させるために設定キャッシュを消去してください。

ループが経路ではなくセッションである場合

必ずサインインに戻る連鎖は、たいてい Cookie の問題です。セッション Cookie がブラウザの実際に使ったホスト名に対して発行されたか、ブラウザが安全とみなす接続で安全と印を付けられたかを調べます。誤ったドメインに紐づいた Cookie は、ルーティング障害とまったく同じに見えるログインループを生みます。

実証された食い違いを、ベース URL、Cookie のドメイン、プロキシの契約のいずれであっても、その持ち主のもとで直し、一つの 302 が消えるのを見守るのではなく、操作全体をやり直して検証します。ループを断つために HTTPS の要件を切るのは、リダイレクトをより悪い問題と交換するだけです。変更が終わったら、既知の非公開リソースを要求して届くことを確かめ、次のリダイレクトに比べるためのきれいな基準ができるよう、トンネルを別に確認します。