リダイレクトが多すぎる: このエラーの意味と修正方法
公開: 2022-09-27リダイレクト ループとも呼ばれる「リダイレクトが多すぎます」は、サーバーからコンテンツを取得するために従わなければならない無限の数のリダイレクトが原因で、要求された Web ページの読み込みに失敗した場合にブラウザーが返すエラーです。 リダイレクト ループは、多くの場合、サーバー側でのリダイレクトの競合または CDN の構成ミスが原因で発生する可能性があります。
「リダイレクトが多すぎます」エラーを修正するためのこの包括的なガイドでは、リダイレクトを構成できる場所、リダイレクト ループの背後にある最も一般的な理由、およびそれらに段階的に対処する方法について説明します。
リダイレクトとは何ですか?
Web サイトのリダイレクトは、要求された Web ページの場所を見つけるためにコンテンツ配信中に実行する必要がある手順として定義できます。 リダイレクト ルールで達成された変更は、ウェブサイトのアドレスがアドレス バーにどのように表示されるかのみを反映しているように見えるかもしれませんが、ブラウザはバックグラウンドで一連の操作を実行して、各リダイレクトがどこにつながるかを判断してから、リダイレクト パスによって定義された最終的な場所からのコンテンツ。
HTTPS の強制、ウェブサイトの www バージョン、または別のドメイン名の読み込み - リダイレクトはウェブサイトのホスティングで広く使用されており、コンテンツ配信をカスタマイズできます。 ドメイン リダイレクトを設定するには複数の方法があり、それらが正しく設定されている限り、作成したルールに従ってブラウザで問題が発生することはありません。
一時的および永続的なリダイレクト
構成できるリダイレクトには、一時的なものと永続的なものの 2 種類があります。 検出されたリダイレクトのタイプに応じて、Web サーバーは 302 または 301 HTTP ステータス コードを返します。
302 HTTP 応答コードは、特定の Web アドレスが一時的に別の場所にリダイレクトされていることを示しています。 ただし、Web サイトから永続的なリダイレクト ルールを削除したものの、そのキャッシュをフラッシュしていないため、変更が表示されない場合、一時的なリダイレクトが行われることがあります。
これは、WordPress キャッシュ プラグインの 1 つを含む、あらゆる種類のキャッシュ ソリューションを使用している場合に発生する可能性があります。 ブラウザーは、アクセスした Web サイトのキャッシュ バージョンも保存します。これには、古いリダイレクトが含まれます。
永続的なリダイレクトは 301 HTTP ステータス コードを返し、Web サイトまたはその特定のページが永続的に移動されたことを示します。これは、HTTPS または Web サイトの www バージョンへのリダイレクトの場合、必ずしもその場所がファイルシステムが変更されました。
最も一般的なリダイレクトとは?
HTTP から HTTPS Web プロトコルへのリダイレクトと、Web サイトの非 www から www バージョンへのリダイレクトは、構成されている最も一般的な 2 つのルールです。 HTTPS へのリダイレクトは、SSL 証明書を使用してすべての Web トラフィックを確実に暗号化します。一方、www へのリダイレクトは、CNAME レコードを使用してコンテンツ配信ネットワークを Web サイトに統合するためによく使用されます。
HTTP から HTTPS
HTTP から HTTPS へのリダイレクト (HTTPS の強制とも呼ばれます) を構成して、安全でない HTTP 接続を介して Web サイトの訪問者にコンテンツが配信されないようにすることができます。 有効な SSL/TLS 証明書が Web サイトにインストールされている場合、通常は手動で HTTPS を強制する必要はありませんが、そのようなリダイレクトを追加することは、混合コンテンツを処理する方法の 1 つになる可能性があります。
混合コンテンツ
Web サイト上の混合コンテンツは、ベース HTML ファイルが HTTPS 経由で読み込まれる状況として定義できますが、画像、Javascript、CSS ファイルなど、参照される他のリソースは HTTP 経由で訪問者に配信されます。 有効な SSL 証明書がインストールされていても、Web ページで混合コンテンツが識別された場合、ブラウザはセキュリティ警告を表示します。
混合コンテンツの問題に対処するためにリダイレクトを設定することは、通常、最善の解決策ではありません。 代わりに、Web サイトのデータベース内のすべての URL (Uniform Resource Locators) を更新して、HTTP ではなく HTTPS プロトコルを含める必要があります。 これは、WP CLI が提供する検索置換機能または WordPress プラグインを使用して手動で行うことができます。 他のコンテンツ管理システムの場合、phpMyAdmin などのデータベース管理ツールを使用するか、コマンド ラインから MySQL/MariaDB クエリを実行して、アドレスを変更する必要があります。
リダイレクトを構成できる 3 つの主な場所
リダイレクトは通常、次の 3 つの主要な場所のいずれかで構成できます。
- Web サーバー構成。 Web サーバーで使用されるグローバル構成ファイルには、ホストされているすべての Web サイトに通常適用される設定が含まれているため、そのうちの 1 つにリダイレクトを追加することはお勧めしません。 各 Web サイト用に個別に作成されたローカル構成ファイルを使用することは、サーバー側でリダイレクトを設定するための標準です。
- コンテンツ管理システムの構成。 コンテンツ管理システムは、Web サイトのアドレスを定数としてデータベースに保存します。これを使用して、HTTPS を強制したり、www バージョンをロードしたりできます。
- コンテンツ配信ネットワークの構成。 CDN は独自のリダイレクトを強制し、オリジン サーバーからコンテンツを正確に取得して Web サイトの訪問者に配信する方法を定義します。
Web サーバー構成ファイルのリダイレクト
Web サーバーが読み取る構成ファイルの 1 つで、リダイレクト ルールをローカルに設定できます。 Apache を Web サーバーとして使用する場合、リダイレクト ルールは通常、Web サイトのローカル .htaccess ファイルに設定されます。 NGINX が使用されている場合、リダイレクトは Web サイトのグローバル構成を表す NGINX サーバー ブロック内で構成されます。
以下に、.htaccess に追加できる 2 つのリダイレクトを示します。1 つは HTTPS を強制し、もう 1 つはすべての Web リクエストを Web サイトの www バージョンに送信します。 厳密な構文規則に従う必要があります。そうしないと、ローカル構成ファイルのいずれかで Apache が構文エラーを検出した場合に、Web サイトがダウンする危険があります。
WordPress のリダイレクト プラグインを使用している場合、リダイレクトをローカルの .htaccess ファイルにも書き込む可能性が最も高くなります。
WordPress 設定でのリダイレクト
WordPress やその他のコンテンツ管理システムは Web サイトのアドレスをデータベースに配置し、コンテンツが要求されるたびに設定が読み込まれます。 アドレスは、ドメイン名と Web プロトコル (HTTP または HTTPS) で構成される URL を表します。 データベースの URL を変更することで、Web サイトを www にリダイレクトしたり、SSL/TLS 証明書がインストールされている場合は HTTPS を強制したりできます。
WordPress は WP_HOME 定数を使用して WordPress アドレス設定と WP_SITEURL をサイト アドレスとして識別します。これらは wp_options テーブルに siteurl および home として保存されます。 WordPress アドレス設定は、WordPress インストールの場所を指し、サイト アドレスは、Web サイトを開くためにブラウザーのアドレス バーに入力する必要がある URL を表します。
CDN によって強制されるリダイレクト
コンテンツ配信ネットワーク構成は、要求された Web ページをオリジン サーバーから取得し、Web サイトの訪問者に配信する方法 (HTTP または HTTPS 経由) を定義します。 正確な手順は、選択した暗号化モードによって決まります。 最新のコンテンツ配信ネットワークで提供される主な暗号化タイプは 3 つあります。
- 完全またはエンドツーエンドの暗号化。 エンドツーエンドの暗号化により、コンテンツ配信のすべての段階で HTTPS が使用されます。 これは、ブラウザーから CDN へ、および CDN からオリジン サーバーへのすべての Web 要求が常に HTTPS 経由で送信されることを意味します。 エンド ツー エンドの暗号化には 2 つの SSL 証明書が必要です。1 つはオリジン サーバーにインストールされ、もう 1 つは CDN によって実装されます。
- 柔軟な、または部分的な暗号化。 部分暗号化は、CDN が HTTP 経由でオリジン サーバーに接続する一方で、ブラウザから CDN へのすべての接続を強制的に HTTPS 経由にします。 ただし、Web サイトは引き続きすべてのブラウザーで安全であると表示されます。
- 暗号化なし。 暗号化を無効にすると、コンテンツの配信は HTTP 経由で行われ、すべてのブラウザーで Web サイトの読み込み中にセキュリティ警告が表示されます。
CDN が HTTPS 経由で接続を開始しようとしているときに、Web サーバーが HTTPS 要求を HTTP にリダイレクトする場合、リダイレクト ループが作成され、Web サイトでリダイレクトが多すぎるというエラーが表示されます。
「Too Many Redirects」エラーは何を意味しますか?
リダイレクト ループと呼ばれることが多い「リダイレクトが多すぎます」は、競合する 2 つのリダイレクトによってコンテンツ配信中に競合が発生したことを示すエラー メッセージです。 リダイレクト ループが識別されると、最新のブラウザーは次のエラーのバリエーションのいずれかを返します。
- ページが正しくリダイレクトされていません。 このエラー メッセージは Firefox で表示されます。
- ページが機能していません。 ERR_TOO_MANY_REDIRECTS . リダイレクト ループでスタックすると、Google Chrome にこのエラーが表示されます。
- リダイレクトが多すぎるため、Safari でページを開くことができません。 このようにして、Safari は、Web サイトをロードする前に対処する必要があるリダイレクトの競合を知らせます。
リダイレクトが多すぎるというエラーを修正するには、.htaccess で構成され、コンテンツ管理システムによって強制されたリダイレクトを確認し、コンテンツ配信ネットワークで使用されている暗号化モードを確認する必要があります。
Web サイトでリダイレクト ループを引き起こす最も一般的な 3 つの設定ミスとその対処方法
すべてのリダイレクトを調べて競合を特定するのは簡単な作業ではありません。特に、一部が Web サーバーのグローバル構成に追加され、サーバー全体に適用される場合はなおさらです。 ただし、必然的にリダイレクト ループにつながるいくつかの非常に頻繁に見られる設定ミスがあります。
Web サイトで「リダイレクトが多すぎます」と表示される最も一般的な 3 つの理由は次のとおりです。
- 有効な SSL/TLS 証明書がありません。 SSL 証明書の有効期限が切れているか、その他の問題がある場合、リダイレクト ループが発生する可能性がありますが、Web サイトは引き続き HTTPS を強制しようとします。
- CMS Web サイトのアドレス設定が正しくありません。 WordPress または別のコンテンツ管理システムで使用される Web サイト アドレス設定で指定されたプロトコルが、構成されている他のリダイレクトと競合する場合、リダイレクトが多すぎるというエラーが発生します。
- 間違った CDN 暗号化モードが選択されています。 CDN 構成で完全な暗号化に切り替えると、リダイレクト ループが見られることが特に一般的です。 エンド ツー エンドの暗号化を使用するための要件がオリジン サーバーで満たされていない場合、問題が発生する可能性があります。
有効な SSL/TLS 証明書がありません
Web サイトにインストールされた有効な CA 署名付き SSL/TLS 証明書により、サーバーからブラウザーに配信されるときにすべての Web トラフィックが暗号化されます。 さらに、HTTPS はサーバー レベルで強制される可能性が高く、SSL 証明書の有効期限が切れて自動的に更新されなくなるまでは完全に機能します。 これは、次の理由で発生する可能性があります。
- SSL/TLS 証明書の自動更新が有効になっていません。 SSL が自動的に更新されていない場合は、新しい証明書を注文してインストールする必要があります。
- SSL ドメインの検証に失敗しました。 無料の証明書を提供する最も広く使用されている SSL プロバイダーの 1 つである暗号化または Sectigo は、新しい証明書を発行する必要があるドメイン名を管理していることを検証するために、さまざまなチャレンジを実装します。 ドメインの検証が失敗した場合、検証要求をブロックする問題に対処するまで、新しい証明書はインストールされません。
- ルートまたは中間証明書の 1 つが期限切れです。 それが発生した場合、SSL プロバイダー側で問題に対処したら、証明書を再インストールする必要があります。
対処方法
SSL チェッカーを使用して、Web サイトに有効な証明書がインストールされているかどうかを確認します。 有効期限が切れている場合、または SSL チェッカーが他の問題を示している場合は、証明書を再インストールしてください。 Let's Encrypt または Sectigo が無料の証明書を発行できない場合は、検証要求をブロックしている可能性があるものを確認する必要があります。
SSL ドメインの検証が失敗する理由の 1 つは、特に Let's Encrypt または Sectigo が最後に証明書を発行したときにまだ構成していなかった場合に、コンテンツ配信ネットワークが統合されていることです。 新しい無料の SSL 証明書をインストールする必要がある場合は、CDN を一時停止して、Web サイトがサーバーを直接指すようにし、コンテンツ配信ネットワークに属する IP アドレスではなく、メインの IP アドレスを返します。 このようにして、オリジンサーバーで証明書を更新して、エンドツーエンドの暗号化を引き続き使用できます。
CMS Web サイトのアドレス設定が正しくない
WordPress およびその他すべてのコンテンツ管理システムは、ウェブサイトのアドレスをデータベースに保存し、コンテンツが要求されるたびにそれをロードすることにより、HTTPS または www へのリダイレクトを強制できます。 サイト アドレス設定が正しく設定されていない場合 (間違ったプロトコルまたはドメイン名を使用している場合)、リダイレクト エラーが多すぎるなどの問題が発生します。
対処方法
SSL 証明書がインストールされている場合、特に CDN 構成によってエンド ツー エンドの暗号化が保証されている場合は、WordPress アドレスとサイト アドレスの両方の設定で HTTPS を使用します。 ウェブサイトを www バージョンにリダイレクトした場合、WP_SITEURL と WP_HOME の両方の参加者がそれを反映する必要があります。
WordPress ダッシュボードの [一般設定] メニューを開き、WordPress アドレスとサイト アドレスに割り当てられている値を必要に応じて修正します。 [変更を保存] をクリックして、WordPress にデータベースの設定を変更させます。
間違った CDN 暗号化モードが選択されている
オリジン サーバーで構成されたリダイレクトと、CDN で使用される暗号化モードとの間に競合が発生することはありません。そうしないと、任意のブラウザーで Web サイトを読み込もうとすると、「リダイレクトが多すぎます」というエラーが表示されます。 Web サイトのニーズにより適した正しい暗号化モードを選択してください。
コンテンツ配信ネットワークはサーバーとブラウザ間のトラフィックを常に暗号化するため、暗号化を完全に無効にしない限り、オリジン サーバーに SSL をインストールしないことを選択できます。 部分的な暗号化を選択し、サーバー レベルで HTTPS を強制しないようにして、HTTP 経由で CDN からの要求を受け入れる問題を回避します。
エンド ツー エンドの暗号化を選択した場合は、有効な SSL 証明書をオリジン サーバーにインストールして、CDN が HTTPS 経由で接続できるようにする必要があります。 新しい証明書を手動でインストールできない場合は、SSL の更新が必要になるたびに、CDN を一時的に一時停止して、ドメイン検証の問題を回避してください。
対処方法
現在の設定を確認し、選択する必要がある暗号化モードを決定します。 別の暗号化タイプに切り替えて、オリジンサーバーでのリダイレクトの競合、またはエンドツーエンドの暗号化をサポートするために必要な SSL の欠如によって引き起こされた Web サイトの「リダイレクトが多すぎます」エラーを修正します。
3 つのステップで「リダイレクトが多すぎます」を修正する方法
以下の手順では、競合するリダイレクトを特定し、Web サイトのリダイレクト ループをすばやく修正する方法を学習します。
ステップ 1. Web サイトのリダイレクト パスを確認する
多くの情報源は、リダイレクト ループのトラブルシューティングの最初のステップとして、ブラウザーのキャッシュをクリアすることを勧めています。 ただし、他のエラーと同様に、問題がサーバー上で解決されている場合にのみ機能しますが、ブラウザーは引き続き Web サイトの壊れたバージョンをキャッシュに保存します。 通常、Web サイトに変更を加えた後、そのキャッシュをフラッシュして変更を反映させたい場合があります。
「リダイレクトが多すぎる」を修正するための最初のステップは、Web サイトのリダイレクト パスをたどって、ブラウザが動かなくなっている正確な場所を確認することです。 これを行う最善の方法は、リダイレクト チェッカーの 1 つを使用することです。
すべてまたはほとんどのリダイレクト チェッカーは、さまざまなネットワーク プロトコルを使用してデータを転送するための優れたコマンド ライン ツールである cURL を使用します。 これを使用して、Web サイトを読み込もうとすると何が起こるかを正確に示す HTTP ヘッダー情報を取得できます。
SSH 経由でサーバーに接続したら、次の簡単な Bash スクリプトを redirects.sh という名前のファイルに保存します。 chmod +x redirects.sh を実行して実行可能にします。
スクリプトを Web サイトのドメイン名に渡して実行します。 たとえば、./redirects.sh wordpress.com です。
ステップ 2.競合するリダイレクトを特定する
上記のスクリプトを実行して得た出力を調べます。 ブラウザーが競合するルールに従うことをあきらめたときに、どの種類のリダイレクトが「リダイレクトが多すぎます」と表示されるかがわかります。 以下の出力では、HTTP および HTTPS からの無限リダイレクトがあることがわかります。
各リダイレクトのリターン ステータス コードに注意してください。 永続的なリダイレクトは多くの場合、Web サイトの .htaccess ファイルから発生しますが、一時的なリダイレクトは通常、Web サイトのコード内で生成されるため、WordPress または使用している他のコンテンツ管理システムによって制御されます。
ステップ 3. リダイレクト ループに対処する
特定した競合するリダイレクト ルールに応じて、ループする場所がわかります。 説明したように、チェックする主な項目は 3 つあります。それは、ローカルの .htaccess ファイル、CMS によって Web サイトのデータベースに保存された Web サイトのアドレス設定、および CDN 構成で選択された暗号化モードです。
ウェブサイトが HTTP と HTTPS の間でリダイレクトしようとしているときにリダイレクト ループが発生した場合は、有効な SSL/TLS 証明書がインストールされているかどうか、およびウェブサイトと統合している場合は CDN 構成でどの暗号化モードが選択されているかを確認してください。 Web サイトに指定され、WordPress データベースに保存されているサイト アドレスと WordPress アドレスを確認します。
ガイドの前のセクションに記載されている手順に従って、一般的な構成ミスに対処し、Web サイトの「リダイレクトが多すぎる」を修正します。
結論
リダイレクト ループとも呼ばれる「リダイレクトが多すぎます」というエラー メッセージは、多数のリダイレクトが続いたためにブラウザがコンテンツを読み込めなかったときに Web サイトに表示されます。 リダイレクト ループを修正するには、リダイレクト パスに存在する競合に対処する必要があります。
オンラインでのビジネスの運営には課題が山積しており、サーバー インフラストラクチャのセットアップとエラーの修正に何時間も費やすことは、常に可能であるとは限りません。 また、適切なソリューションを使用することで、問題なく Web サイトを稼働し続けるために専任チームを雇う必要がなくなる場合も、良い考えではありません。
約 100 万の WordPress Web サイトを保護している BackupBuddy と iThemes Security Pro は、アプリケーション レベルのセキュリティとデータ復旧のための業界をリードするソリューションです。 サイト スキャン機能によって提供される定期的な脆弱性チェックとマルウェア スキャンにより、攻撃対象領域を大幅に削減し、すべての既知の脆弱性から Web サイトを保護できます。 自動バックアップとワンクリックで簡単に復元 — BackupBuddy を使用すると、すべての悪意のある攻撃や一般的なエラーから回復できます。
WordPress を安全に保護するための最高の WordPress セキュリティ プラグイン
WordPress は現在、すべての Web サイトの 40% 以上で使用されているため、悪意のあるハッカーにとって格好の標的となっています。 iThemes Security Pro プラグインは、WordPress のセキュリティから当て推量を取り除き、WordPress Web サイトを簡単に保護および保護できるようにします。 これは、WordPress サイトを常に監視して保護するフルタイムのセキュリティ専門家がスタッフにいるようなものです。
Kiki は情報システム管理の学士号を取得しており、Linux と WordPress で 2 年以上の経験があります。 彼女は現在、Liquid Web と Nexcess のセキュリティ スペシャリストとして働いています。 それ以前は、Kiki は Liquid Web Managed Hosting サポート チームの一員であり、何百人もの WordPress Web サイト所有者を支援し、彼らがよく遭遇する技術的な問題について学びました。 彼女の執筆への情熱により、彼女は自分の知識と経験を共有して人々を助けることができます。 テクノロジーとは別に、キキは宇宙について学んだり、真の犯罪に関するポッドキャストを聞いたりすることを楽しんでいます。