sql >> データベース >  >> RDS >> Database

トラブルシューティング：リダイレクトが多すぎます

    「リダイレクトが多すぎます」というエラーは、Webサイトが決して完了しない方法で異なるアドレス間でリダイレクトされ続けることを意味します。多くの場合、これは競合するリダイレクトの結果であり、1つはHTTPS（SSL）を強制しようとし、もう1つはHTTP（非SSL）にリダイレクトしようとするか、URLのwww形式と非www形式の間で行われます。

    WordpressやMagentoなどのCMSを使用している場合は、 base_urlを利用します。 またはサイト内のURLタイプの構成では、コードまたはデータベースの構成が.htaccessファイルのリダイレクトと競合する可能性があります。これらの競合するリダイレクトは、フロップを前後に反転し、完了することはありません。

    ブラウザは、特定の数（多くの場合10程度）のリダイレクトのみを許可してから、「リダイレクトが多すぎます」というエラーメッセージを報告することで、これからユーザーを保護します。これは、Chrome、Firefox、およびその他のブラウザ間で異なって表示されます。

    Firefox

    ページが正しくリダイレ​​クトされていません。 <ドメイン>への接続中にエラーが発生しました

    Chrome

    このページが機能していません<ドメイン>が何度もリダイレクトされました

    テストユーティリティでさえcurl デフォルトで50回のリダイレクト後にあきらめます。

    カール： 最大（X）リダイレクトが続きます 

    curl -svILk https://www.example.com
 ....
 * Maximum (50) redirects followed

    最初のステップ：キャッシュとCookie

    上記のブラウザエラーに示されているように、これらのループリダイレクトは、古いリダイレクトをキャッシュしているブラウザのCookieによっても発生する可能性があります。テストの最初のステップは、ブラウザのキャッシュとCookieをクリアすることです。ブラウザのキャッシュとCookieをすでにクリアしている場合は、さらに高度なトラブルシューティングに移りましょう。

    リダイレクトループ用の開発者ツールの使用

    これらの種類のリダイレクトループのトラブルシューティングの次のステップは、FirefoxまたはChromeの開発者ツールを使用することです。これらのツールは通常、F12キーを押すことで開きます。必ずネットワークを選択してください これらのいずれかでタブを押してから、問題が発生しているページをリロードします。

    ページをリロードすると、新しいウィンドウに一連のリダイレクトが一覧表示されます。リダイレクトを見ると、それらがいくつかの異なるものの間でリダイレクトされているのか、同じものにリダイレクトされているのかがわかります。いずれにせよ、エンドユーザーのブラウザエラーだけでなく、エラーに至るまでの手順を確認できます。

    Firefoxの開発者ツール

    リダイレクトループにcURLを使用する

    この記事の執筆の一環として、 curlを使用するUnixライクなシステムで使用できる非常に単純なBashスクリプトをまとめました。 指図。 curlを使用すると、ブラウザと同じようにキャッシュされないため、トラブルシューティング時に異なる視点が得られる場合があります。

    以下をお好みのテキストエディタにコピーして、 redirects.shとして保存します。 。

    #!/bin/bash
 echo
 for domain in $@; do
 echo --------------------
 echo $domain
 echo --------------------
 curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
 echo
 done

    次に、 redirects.shにマークを付けます 実行可能ファイルとしてのファイル。

    chmod +x redirects.sh

    以下の例のように、スクリプト名の後にドメインを追加することで、スクリプトを実行できます。複数のドメインをチェックすることもでき、各URLのリダイレクトをチェックして、テストされた別々のドメイン間にヘッダーを配置します。

    出力例 
    ./redirects.sh liquidweb.com
 --------------------
 liquidweb.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://liquidweb.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.liquidweb.com/
 HTTP/1.1 200 OK
    HTTPからHTTPSへの無限リダイレクトの例 
    ./redirects.sh http://www.example.com
 --------------------
 http://www.example.com
 --------------------
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 ....
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: http://www.example.com/
 HTTP/1.1 301 Moved Permanently
 -> Location: https://www.example.com/
    リダイレクトタイプに関する補足

    カールを見る 上記の出力から、HTTP応答コードが301であることがわかります。301リダイレクトは「永続的な」リダイレクトです。つまり、何かが永続的に移動したため、現在および将来の両方で、新しい場所でそれを検索する必要があります。 302リダイレクトは「一時的な」リダイレクトであり、今のところ何かが移動したことを意味しますが、常に新しい場所にあるとは限りません。

    301リダイレクトは、多くの場合、.htaccessファイルのリダイレクトまたはリライトエントリとして書き出されます。ただし、302リダイレクトは、設計または慣例により、Webサイトのコード内で生成されることがよくあります。したがって、経験則として、301は.htaccessファイルにあり、302はサイトコードにあります。これは常に正しいとは限りませんが、覚えておくとよいでしょう。

    .htaccessファイルでリダイレクト

    .htaccessファイルは、Webサイト/サーバー上のディレクトリごとにApacheサーバーの動作を変更するために使用される構成ファイルです。これはユーザーレベルの構成ファイルであり、リダイレクトが一般的に使用されていますが、ここで編集できるのは一部のApache構成のみです。

    一連のディレクトリにカスケードする複数の.htaccessファイルを持つことができます。親ディレクトリに.htaccessがあり、サブディレクトリに別の.htaccessがある場合、それらは両方ともサブディレクトリに影響します。このような場合、異なるレベルの.htaccessファイル間の競合を防ぐために、.htaccessファイルがある場所とない場所を覚えておくことが重要です。

    以下は一連のリダイレクトの例であり、.htaccessファイルでリダイレクトを識別するのに役立ちます。これらの種類のリダイレクトを行う方法はこれらだけではありませんが、最も一般的なリダイレクトがどのように見えるかを示して、作業中の.htaccessファイルにあるかどうかを認識できるようにする必要があります。

    HTTPSを強制する

    以下の.htaccessコードは、最初にリクエストがHTTPまたはHTTPSを使用してサーバーに届いたかどうかを確認します。リクエストでHTTPSが使用されなかった場合、設定により、以前にリクエストされたのと同じWebサイトとURLのHTTPSバージョンにリダイレクトするようにブラウザに指示されます。

    RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    HTTPSを強制する：ロードバランサーまたはプロキシの背後にある場合（CloudFlare / Incapsula / Sucuriなど）

    ロードバランサーなどのプロキシや、CloudFlare、Incapsula、SucuriなどのWebファイアウォールを使用している場合があります。これらは、フロントエンドでSSLを使用するように構成できますが、バックエンドでSSLを使用することはできません。これを正しく機能させるには、リクエスト内のHTTPSだけでなく、プロキシがHTTPのみを使用して元のHTTPSリクエストをサーバーに渡したかどうかも確認する必要があります。この次のルールは、リクエストがHTTPSから転送されたかどうかを確認し、転送された場合は、追加の時間をリダイレクトしようとはしません。

    RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteCond %{HTTP:X-Forwarded-Proto} =http
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    非wwwを強制する

    このリダイレクトは、ドメイン名の先頭にwwwが付いたWebサイト名が要求されたかどうかのみをチェックします。 wwwが含まれている場合は、リクエストが書き換えられ、www以外のバージョンのドメイン名にリダイレクトするようブラウザに指示されます。

    RewriteEngine On
 RewriteCond %{HTTP_HOST} ^www\. [NC]
 RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    強制www

    この最後のリダイレクトは、ドメイン名の先頭にwwwが付いたWebサイト名が要求されていないかどうかを確認します。 wwwが含まれていない場合は、リクエストが書き換えられ、ブラウザにwwwバージョンのドメインにリダイレクトするように指示されます。

    RewriteEngine On
 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

    WordPress

    WordPress CMSは、.htaccessファイルを使用してURLを index.phpに書き換えます。 ファイルですが、WebサイトのURLをデータベースの値として定義します。サイトで使用されているデータベースの名前がわからない場合は、WordPressのメイン構成（ wp-config.php ）で検索できます。 。

    テキストエディタでファイルを開いてこれらの値を探すこともできますが、SSH接続からプログラム grepを使用できます。 。これにより、データベース名だけでなく、データベース名が次に行う必要のある作業にとって最も重要になります。

    grep DB wp-config.php

define('DB_NAME', 'wordpress_database');
 define('DB_USER', 'wordpress_username');
 define('DB_PASSWORD', 'Password');
 define('DB_HOST', 'localhost');
 define('DB_CHARSET', 'utf8');
 define('DB_COLLATE', '');
    wp_optionsテーブル

    データベースの名前がわかれば、Wordpressデータベースのオプションテーブルを見て、データベースでURLが何に設定されているかを確認できます。オプションテーブルには、テーブル名の先頭に任意のプレフィックスを付けることができますが、多くの場合、 "wp_" デフォルトでは、オプションテーブルのフルネームは通常 wp_optionsです。 。重要な2つの行は、ホームです。 およびsiteurl オプションテーブルの行。これらはphpMyAdminを使用して見つけることができます 、または別のデータベース管理ユーティリティですが、コマンドラインから次の mysqlを実行することもできます。 コマンド。

    mysql -e 'show tables' wordpress_database | grep options

prefix_options
    構成済みURLの確認

    コマンドラインから、 homeの現在の値を確認できます。 およびsiteurl オプションテーブルの行。コマンドはあなたを送り、以下の例のように出力するはずです。重要な部分は、これらがほとんどの状況で互いに一致し、それらがあなたが期待するものであるということです。それらが期待したものでない場合は、それに応じて更新することをお勧めします。

    mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
 +-----------+-------------+----------------------------------+----------+
 | option_id | option_name | option_value                     | autoload |
 +-----------+-------------+----------------------------------+----------+
 |        36 | home        | http://www.example.com           | yes |
 |         1 | siteurl     | http://www.example.com           | yes |
 +-----------+-------------+----------------------------------+----------+

    構成済みURLの更新

    次のコマンドは、 wp_optionsの2つの行を更新します 特定のデータベースのテーブルを新しいURLに追加します。このコマンドは、Wordpressサイト用に構成されたURLを更新または修正する必要があるほとんどの状況に適しています。 base_urlsを更新しています Wordpressマルチサイトで構成することはこの記事の範囲を超えていますが、複数の wp_optionを更新する必要があります タイプテーブル。

    mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_database

    Magento

    Magentoデータベース名は、 local.xmlのいずれかのファイルで構成されます。 またはenv.php 。 Magentoデータベースのテーブル名のプレフィックスを構成することもできますが、通常は設定されません。したがって、データベースのメイン構成テーブルの予想される名前は、 core_config_dataです。 。

    # Version 1.x
 app/etc/local.xml

# Version 2.x
 app/etc/env.php
    core_config_dataテーブル

    構成できる潜在的なURLは多数ありますが、それらにはすべて " base_urlがあります。 " データベースの行の一部として。構成されるプライマリURLは安全なURLと安全でないURLですが、画像やテーマファイルのURLを設定したり、サイトの管理領域に別のURLを設定したりすることもできます。これらはデータベース管理ユーティリティを使用して見つけることができますが、コマンドラインから次のようなものを実行できます。

    mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
 +-----------+---------+----------+-----------------------+----------------------------+
 | config_id | scope   | scope_id | path             | value |
 +-----------+---------+----------+-----------------------+----------------------------+
 |         3 | default |        0 | web/unsecure/base_url | http://www.example.com     |
 |         4 | default |        0 | web/secure/base_url   | http://www.example.com   |
 +-----------+---------+----------+-----------------------+----------------------------+

    base_urlsを更新するには Magentoデータベースでは、次のコマンドのようなものを実行します。 Magentoマルチサイトのbase_urlsを更新することもこの記事の範囲を超えていますが、特定の scope_idを追加で参照する必要があります。 Magentoデータベースで構成された特定のWebサイトまたはストアの値。

    mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_database

    すべてをまとめる

    上記のように、データベースにURLが構成されている場合、これらのCMSはサイトコード内で独自のリダイレクトメソッドも提供することに注意してください。たとえば、データベース内のURLと一致しないURLにリダイレクトする.htaccessリダイレクトがある場合、前述のように無限のリダイレクトループが発生する可能性があります。ただし、これで、いくつかの一般的な.htaccessリダイレクトがどのように見えるか、およびいくつかのCMSソフトウェアデータベースで構成されたURLを見つける場所がわかりました。また、これらが協調して機能しているか、相互に機能しているかをテスト、調査、確認し、それらを解決するためのいくつかの手順を実行するための十分な準備が整っています。


    1. MySQLでテーブルを表示する

    2. RUNAS / NETONLY機能を（C＃/。NET / WinForms）プログラムに組み込む方法は？

    3. WordPress –舞台裏、パート1

    4. コマンドラインを使用してデータベースをエクスポートする方法