WordPressをHTTPSへ移行した後にリダイレクトが多すぎる場合

このエラーの意味と見分け方

• HTTPS移行前はHTTPで正常に動作していたサイトに、「リダイレクトが多すぎます」と表示される。
• ブラウザーがHTTPとHTTPSを繰り返し切り替える、または同じHTTPSアドレスを何度もリクエストする。
• サイト全体が利用できなくなる場合もあれば、/wp-admin、ログインページ、特定のパスだけがループする場合もある。
• HTTPアドレスを開くと、期待されるHTTPSへのリダイレクトが1回発生した後、通常のレスポンスではなくリダイレクトが繰り返される。
• キャッシュされたリダイレクト、Cookie、サイトデータの違いにより、プライベートブラウジングや別のデバイスでは挙動が異なる場合がある。

可能性の高い順の主な原因

1. WordPressのURL設定がHTTPのままになっている。 WordPress Address (URL) または Site Address (URL) のいずれかがHTTPのままで、別のレイヤーがHTTPSを要求していると、WordPressがサーバーのポリシーと競合するスキームへリダイレクトすることがあります。
2. 複数のレイヤーでHTTPSが強制されている。 セキュリティプラグイン、wp-config.phpのロジック、.htaccessまたはNginxのルール、ホスティング設定、プロキシルールが重複したり、リクエストのスキームについて異なる前提を持ったりすることがあります。
3. CDNまたはリバースプロキシがTLSを終端している。 訪問者はHTTPSで接続していても、オリジンへの接続はHTTPになる場合があります。元のプロトコルが欠落している、正しくない、または安全に信頼できない場合、WordPressがリクエストを安全でないものと繰り返し判断することがあります。
4. プラグインまたはテーマが特定のパスをリダイレクトしている。 ログイン、管理画面、正規URL、セキュリティ、会員制サイト用のプラグインが、/wp-login.php、/wp-admin、または特定のページだけに影響することがあります。
5. 古いキャッシュ済みリダイレクトまたはブラウザーCookieが修正を隠している。 これが元の原因である可能性は低いものの、修正済みの設定が壊れたままに見えることがあります。
6. 古いHTTP参照がコンテンツや設定に残っている。 これらは通常、混在コンテンツの警告または追加のリダイレクトを引き起こしますが、サイト全体のリダイレクトループの原因にはなりません。まず主要なチェーンを修正した後で調査してください。

修正方法

1. リダイレクトチェーンを確認する

最初の確認にはプライベートブラウジングウィンドウを使用します。シェルにアクセスできる場合は、影響を受けているサイトの実際のHTTPSアドレスをシェル変数に設定し、次の読み取り専用リクエストを実行します。

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

すべてのステータスコードとLocation:ヘッダーを記録します。HTTPとHTTPSが交互に現れる場合は、スキーム検出またはリダイレクトルールの競合が通常の原因です。同じHTTPSアドレスが繰り返される場合は、正規URL、プラグイン、プロキシ、またはキャッシュされたリダイレクトの可能性が高くなります。認証情報、Cookie、認証ヘッダーは含めないでください。

2. WordPressの両方のURL設定を確認する

ダッシュボードを利用できる場合は、Settings → Generalを開き、WordPress Address (URL) と Site Address (URL) が、必要なサブディレクトリを含め、意図した同じHTTPSオリジンを使用していることを確認します。

ループによってダッシュボードにアクセスできない場合、SFTPまたはデータベースにアクセスできる承認済みの管理者は、wp-config.phpに一時的に次の値を定義できます。

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

まずファイルをバックアップし、管理された変更を1つだけ行います。これらの定数を定義している間は、対応するダッシュボードの項目よりも優先されるため、テスト後は意図を明確にして削除または管理してください。

3. TLSの終端場所を特定する

ブラウザーがWebサーバーへ直接接続しているのか、CDN、ロードバランサー、リバースプロキシを経由しているのかを確認します。プロキシがTLSを終端する場合、訪問者がHTTPSを使用していても、オリジンはHTTP接続を受け取る可能性があります。

元のプロトコルが一貫して転送され、意図した信頼済みプロキシからのものだけをWordPressが認識するよう設定されていることを、ホスティングまたはプロキシの管理者に確認してください。不特定のクライアントから送信されたX-Forwarded-Protoを無条件に信頼しないでください。検証されていない転送ヘッダーはセキュリティ上の問題を引き起こす可能性があります。

4. HTTPS強制を意図した1つのレイヤーに絞る

HTTPからHTTPSへリダイレクトする可能性があるすべての場所を一覧にします。

• CDNまたはロードバランサーのルール
• ホスティングパネルのSSL設定
• Apacheの.htaccessまたはNginx設定
• セキュリティまたはSSLプラグイン
• カスタムのwp-config.phpまたはテーマコード

ホスティング構成に適したレイヤー（一般的にはエッジまたはWebサーバー）に強制処理を残し、競合するアプリケーションレベルのリダイレクトを無効にします。サーバールールを変更する前に設定をバックアップし、管理者の承認を得てください。承認済みのリロードまたは再起動を行う前に設定を検証します。最初の診断手順として、本番Webサーバーを再起動しないでください。

5. ログインと管理画面のパスを個別にテストする

フロントエンドは動作するのに/wp-adminまたはログインだけがループする場合は、承認されたメンテナンス手順に従って、最近変更したセキュリティ、ログイン、正規URL、キャッシュの各プラグインを確認します。1つのパスだけがループする場合は、プラグインの競合である可能性が高くなります。テストのためにプラグインを無効にする場合は、変更を記録し、アクセス制御を維持したうえで、テスト後に再有効化または置き換えを行います。

6. キャッシュを削除して再テストする

元の挙動を記録し、管理された修正を行った後、ブラウザーのサイトデータを削除し、WordPressのページキャッシュまたはオブジェクトキャッシュに加えて、ホスティングとCDNのキャッシュを削除します。HTTPアドレス、HTTPSのホームページ、ログインページ、代表的な内部ページを再テストします。キャッシュされた301または302は、実際の設定を修正した後も残ることがあります。

7. 残っているHTTP参照を更新する

リダイレクトチェーンを修正した後、保存されているURLを変更する前にデータベースをバックアップします。信頼できるWordPress移行ツールまたはWP-CLIのsearch-and-replaceを、まずdry runで実行し、シリアライズされたWordPressデータを処理できるツールを使用します。古いサイトオリジンだけをHTTPSオリジンに置き換えます。すべてのhttp://値を無差別に置換しないでください。サードパーティーのURLや意図的に外部で使用しているリソースは、そのサイトに属していない可能性があります。

予防と修正確認

• サイトの正規HTTPSオリジンを記録し、移行時にWordPressの両方のURL設定を更新します。
• HTTPからHTTPSへのリダイレクトを設定する場所を1つ決めて文書化し、force-SSLプラグインを有効にする前に他のレイヤーを確認します。
• CDNまたはリバースプロキシがTLSを終端するかどうか、またオリジンが元のプロトコルをどのように認識するかを文書化します。
• HTTPS設定を変更するたびに、ホームページ、内部ページ、ログイン、ダッシュボードをテストします。
• wp-config.php、rewriteルール、保存されているURLを編集する前に、設定とデータベースをバックアップします。
• リダイレクトが動作したら、対象を絞ったHTTPS URL移行を実行し、混在コンテンツの参照を確認します。

よくある質問