Linuxサーバーで一般的なサイトの問題をトラブルシューティングする方法

getdocs

3年前

序章

誰もが自分のWebサーバーやサイトに問題を抱えています。問題に遭遇したときにどこを見ればよいか、どのコンポーネントが原因である可能性が高いかを知ることは、フラストレーションを減らしてこれらの問題をすばやく修正するのに役立ちます。

このガイドでは、これらの問題をトラブルシューティングして、サイトを通常どおりに稼働させる方法について説明します。

典型的な問題の種類は何ですか？

時折発生する可能性のある非定型の問題がいくつかありますが、サイトを立ち上げて実行しようとしたときに発生する問題の大部分は、非常に予測可能な範囲に分類されます。

これらについては、以下のセクションで詳しく説明しますが、今のところ、調べる項目の簡単なチェックリストを次に示します。

Webサーバーはインストールされていますか？
Webサーバーは実行されていますか？
Webサーバー構成ファイルの構文は正しいですか？
構成したポートは開いていますか（ファイアウォールによってブロックされていません）？
DNS設定が正しい場所に誘導していますか？
ドキュメントのルートはファイルの場所を指していますか？
Webサーバーは正しいインデックスファイルを提供していますか？
ファイルとディレクトリ構造の権限と所有権は正しいですか？
構成ファイルを介したアクセスを制限していますか？
データベースバックエンドがある場合、それは実行されていますか？
サイトはデータベースに正常に接続できますか？
Webサーバーは動的コンテンツをスクリプトプロセッサに渡すように構成されていますか？

これらは、サイトが正しく機能していないときに管理者が遭遇する一般的な問題の一部です。正確な問題は通常、さまざまなコンポーネントのログファイルを確認し、ブラウザに表示されるエラーページを参照することで絞り込むことができます。

以下では、サービスが正しく構成されていることを確認できるように、これらの各シナリオについて説明します。

ログを確認してください

やみくもに問題を追跡する前に、Webサーバーと関連コンポーネントのログを確認してください。これらは通常、サービスに固有のサブディレクトリの/var/logにあります。

たとえば、UbuntuサーバーでApacheサーバーを実行している場合、デフォルトではログは/var/log/apache2に保持されます。このディレクトリ内のファイルをチェックして、生成されているエラーメッセージの種類を確認してください。問題を引き起こしているデータベースバックエンドがある場合は、ログが/var/logにも保持される可能性があります。

その他のチェック事項は、サービスの開始時にプロセス自体がエラーメッセージを残すかどうかです。 Webページにアクセスしてエラーが発生した場合、エラーページにも手がかりが含まれている可能性があります（ただし、ログファイルの行ほど具体的ではありません）。

検索エンジンを使用して、正しい方向を示すことができる関連情報を見つけようとします。以下の手順は、さらにトラブルシューティングするのに役立ちます。

Webサーバーはインストールされていますか？

Webサイトを正しく提供するために最初に必要なのは、Webサーバーです。

ほとんどの人はこの時点に到達する前にサーバーをインストールしていますが、他のパッケージ操作を実行するときに実際にサーバーを誤ってアンインストールした可能性がある場合があります。

UbuntuまたはDebianシステムを使用していて、Apache Webサーバーをインストールする場合は、次のように入力できます。

sudo apt-get update
sudo apt-get install apache2

これらのシステムでは、Apacheプロセスはapache2と呼ばれます。

UbuntuまたはDebianを実行していて、Nginx Webサーバーが必要な場合は、代わりに次のように入力できます。

sudo apt-get update
sudo apt-get install nginx

これらのシステムでは、Nginxプロセスはnginxと呼ばれます。

CentOSまたはFedoraを実行していて、Apache Webサーバーを使用したい場合は、これを入力できます。 rootとしてログインしている場合は、「sudo」を削除できます。

sudo yum install httpd

これらのシステムでは、Apacheプロセスはhttpdと呼ばれます。

CentOSまたはFedoraを実行していて、Nginxを使用したい場合は、これを入力できます。繰り返しますが、rootとしてログインしている場合は、「sudo」を削除します。

sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
sudo yum install nginx

これらのシステムでは、Nginxプロセスはnginxと呼ばれます。

Webサーバーは実行されていますか？

サーバーがインストールされていることを確認したので、サーバーは実行されていますか？

サービスが実行されているかどうかを確認する方法はたくさんあります。かなりクロスプラットフォームである1つの方法は、netstatコマンドを使用することです。

これにより、サーバー上のポートを使用しているすべてのプロセスがわかります。次に、探しているプロセスの名前をgrepできます。

sudo netstat -plunt | grep apache2

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2

「apache2」をサーバー上のWebサーバープロセスの名前に変更する必要があります。上記のような行が表示されている場合は、プロセスが稼働中であることを意味します。出力が返されない場合は、間違ったプロセスを照会したか、Webサーバーが実行されていないことを意味します。

この場合は、ディストリビューションの推奨される方法を使用して開始できます。たとえば、Ubuntuでは、次のように入力してApache2サービスを開始できます。

sudo service apache2 start

CentOSでは、次のように入力できます。

sudo /etc/init.d/httpd start

Webサーバーが起動したら、netstatを再度確認して、すべてが正しいことを確認できます。

Webサーバー構成ファイルの構文は正しいですか？

Webサーバーが起動を拒否した場合、これは多くの場合、構成ファイルに注意が必要であることを示しています。 ApacheとNginxはどちらも、ファイルを読み取るためにディレクティブ構文を厳密に順守する必要があります。

これらのサービスの構成ファイルは通常、プロセス自体にちなんで名付けられた/etc/ディレクトリのサブディレクトリ内にあります。

したがって、次のように入力することで、Ubuntu上のApacheのメイン構成ディレクトリにアクセスできます。

cd / etc / apache2

同様に、CentOSのApache構成ディレクトリもそのプロセスのCentOS名をミラーリングします。

cd / etc / httpd

構成は多くの異なるファイルに分散されます。サービスの開始に失敗した場合は、通常、構成ファイルと問題が最初に見つかった行を示します。そのファイルにエラーがないか確認してください。

これらの各Webサーバーには、ファイルの構成構文を確認する機能もあります。

Apacheを使用している場合は、apache2ctlまたはapachectlコマンドを使用して、構成ファイルの構文エラーを確認できます。

apache2ctl configtest

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

上記のように、構成の詳細に関する情報メッセージを受け取りましたが、エラーはありませんでした。これはいい。

Nginx Webサーバーを使用している場合は、次のように入力して同様のテストを実行できます。

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

ご覧のとおり、このプロセスは構文もチェックします。ファイルの行から終了セミコロンを削除すると（Nginx構成の一般的なエラー）、次のようなメッセージが表示されます。

sudo nginx -t

nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18
nginx: configuration file /etc/nginx/nginx.conf test failed

Nginxはステートメントを終了するためのセミコロンを探すため、引数の数が無効です。見つからない場合は、次の行にドロップダウンし、それを最後の行の追加の引数として解釈します。

これらのテストを実行して、ファイルの構文上の問題を見つけることができます。テストに合格するファイルを取得できるようになるまで、参照する問題を修正します。

構成したポートは開いていますか？

通常、Webサーバーは通常のWebトラフィックの場合はポート80で実行され、TLS/SSLで暗号化されたトラフィックの場合はポート443を使用します。サイトに正しくアクセスするには、これらのポートにアクセスできるようにする必要があります。

ローカルマシンのnetcatを使用して、サーバーのポートが開いているかどうかをテストできます。

次のように、サーバーのIPアドレスを使用して、確認するポートを指定する必要があります。

sudo nc -z 111.111.111.111 80

これにより、111.111.111.111のサーバーでポート80が開いているかどうかがチェックされます。開いている場合、コマンドはすぐに戻ります。 開いていない場合、コマンドは継続的に接続を試みますが、失敗します。ターミナルウィンドウでCTRL-Cを押すと、このプロセスを停止できます。

Webポートにアクセスできない場合は、ファイアウォールの構成を確認する必要があります。ポート80またはポート443を開く必要がある場合があります。

DNS設定が正しい場所に誘導していますか？

ドメイン名ではなくIPアドレスを使用してサイトにアクセスできる場合は、DNS設定を確認する必要があります。

訪問者がドメイン名を介してサイトにアクセスするには、DNS設定でサーバーのIPアドレスを指す「A」または「AAAA」レコードが必要です。次のコマンドを実行して、ドメインの「A」レコードを照会できます。

 host -t example.com

  example.com アドレス93.184.216.119を持っています

返される行は、サーバーのIPアドレスと一致している必要があります。「AAAA」レコード（IPv6接続の場合）を確認する必要がある場合は、次のように入力できます。

 host -t AAAA example.com

  example.comのIPv6アドレスは2606：2800：220：6d：26bf：1447：1097：aa7です。

DNSレコードに加えた変更は、伝播するのにかなり長い時間がかかることに注意してください。リクエストは、まだすべてが最新ではないさまざまなサーバーにヒットすることが多いため、変更後にこれらのクエリに対して一貫性のない結果を受け取る可能性があります。

DigitalOceanを使用している場合は、ここでドメインのDNS設定を構成する方法を学ぶことができます。

構成ファイルもドメインを正しく処理することを確認してください

DNS設定が正しい場合は、Apache仮想ホストファイルまたはNginxサーバーブロックファイルをチェックして、ドメインの要求に応答するように構成されていることを確認することもできます。

Apacheでは、仮想ホストファイルのセクションは次のようになります。

 ServerName example.com ServerAlias  www.example.com  ServerAdmin管理者 @例 .com DocumentRoot / var / www/html。 . .

この仮想ホストは、ドメインexample.comのポート80での要求に応答するように構成されています。

Nginxの同様のチャンクは、次のようになります。

サーバー{リッスン80default_server; リッスン[::]：80 default_server ipv6only = on; ルート/usr/ share / nginx / html;  index index.html index.htm; サーバー名 example.com  www.example.com  ;  。 . .

このブロックは、上記で説明したのと同じタイプの要求に応答するように構成されています。

ドキュメントのルートはファイルの場所を指していますか？

もう1つの考慮事項は、Webサーバーが正しいファイルの場所を指しているかどうかです。

Apacheの各仮想サーバーまたはNginxのサーバーブロックは、特定のディレクトリを指すように構成されています。これが正しく構成されていない場合、ページにアクセスしようとするとサーバーはエラーメッセージをスローします。

Apacheでは、ドキュメントルートはDocumentRootディレクティブを介して構成されます。

サーバー名 example.com  ServerAlias  www.example.com  ServerAdmin管理者 @例 .com DocumentRoot / var / www/html 。 . .

この行は、/var/www/htmlディレクトリでこのドメインのファイルを検索する必要があることをApacheに通知します。ファイルが他の場所に保存されている場合は、正しい場所を指すようにこの行を変更する必要があります。

Nginxでは、rootディレクティブは同じことを構成します。

サーバー{リッスン80default_server; リッスン[::]：80 default_server ipv6only = on; ルート/usr/ share / nginx / html;  index index.html index.htm; サーバー名 example.com  www.example.com  ;  。 . .

この構成では、Nginxは/usr/share/nginx/htmlディレクトリでこのドメインのファイルを探します。

Webサーバーは正しいインデックスファイルを提供していますか？

ドキュメントルートが正しく、サイトまたはサイトのディレクトリの場所に移動したときにインデックスページが正しく提供されない場合は、インデックスが正しく構成されていない可能性があります。

訪問者がディレクトリを要求すると、通常、サーバーは訪問者にインデックスファイルを提供する必要があります。これは通常、構成に応じてindex.htmlファイルまたはindex.phpファイルです。

Apacheでは、仮想ホストファイルに、特定のディレクトリに明示的に使用されるインデックスの順序を構成する行が次のように表示される場合があります。

DirectoryIndex index.html index.php

つまり、ディレクトリが提供されているとき、Apacheは最初にindex.htmlというファイルを探し、最初のファイルが見つからない場合はバックアップとしてindex.phpを提供しようとします。

mods-enabled/dir.confファイルを編集して、サーバー全体のインデックスファイルを提供するために使用される順序を設定できます。これにより、サーバーのデフォルトが設定されます。サーバーがインデックスファイルを提供していない場合は、ファイル内のオプションの1つと一致するインデックスファイルがディレクトリにあることを確認してください。

Nginxでは、これを行うディレクティブはindexと呼ばれ、次のように使用されます。

サーバー{リッスン80default_server; リッスン[::]：80 default_server ipv6only = on; ルート/usr/ share / nginx / html;  index index.html index.htm; サーバー名 example.com  www.example.com  ;  。 . .

権限と所有権は正しく設定されていますか？

Webサーバーがファイルを正しく提供するには、ファイルを読み取って、ファイルが保存されているディレクトリにアクセスできる必要があります。これは、ファイルとディレクトリのアクセス許可と所有権によって制御できます。

ファイルを読み取るには、コンテンツを含むディレクトリがWebサーバープロセスによって読み取り可能で実行可能である必要があります。 Webサーバーの実行に使用されるユーザー名とグループ名は、ディストリビューションごとに異なります。

UbuntuとDebianでは、ApacheとNginxの両方がwww-dataグループのメンバーであるユーザーwww-dataとして実行されます。

CentOSおよびFedoraでは、Apacheはapacheグループに属するapacheというユーザーの下で実行されます。 Nginxは、nginxグループの一部であるnginxというユーザーの下で実行されます。

この情報を使用して、サイトのコンテンツを構成するディレクトリとファイルを確認できます。

ls -l / path / to / web / root

ディレクトリは、Webユーザーまたはグループが読み取りおよび実行可能である必要があり、ファイルは、コンテンツを読み取るために読み取り可能である必要があります。コンテンツをアップロード、書き込み、または変更するには、ディレクトリがさらに書き込み可能である必要があり、ファイルも書き込み可能である必要があります。ただし、セキュリティ上のリスクが生じる可能性があるため、ディレクトリを書き込み可能に設定する場合は十分に注意してください。

ファイルの所有権を変更するには、次のようにします。

sudo chown user_owner ： group_owner / path / to / file

これは、ディレクトリに対しても実行できます。 -Rフラグを渡すことにより、ディレクトリとその下にあるすべてのファイルの所有権を変更できます。

sudo chown -R user_owner ： group_owner / path / to / file

Linuxパーミッションについて詳しくは、こちらをご覧ください。

構成ファイルを介したアクセスを制限していますか？

提供しようとしているファイルからのアクセスを拒否するように構成が設定されている可能性があります。

Apacheでは、これはそのサイトの仮想ホストファイルで構成されるか、ディレクトリ自体にある.htaccessファイルを介して構成されます。

これらのファイル内では、いくつかの異なる方法でアクセスを制限することができます。 Apache 2.4では、ディレクトリを次のように制限できます。

AllowOverrideなしすべて拒否する必要があります

この行は、このディレクトリの内容に誰もアクセスできないようにWebサーバーに指示しています。 Apache 2.2以下では、これは次のように記述されます。

AllowOverrideなし注文拒否、すべてからの拒否を許可

アクセスしようとしているコンテンツを含むディレクトリに対してこのようなディレクティブが見つかった場合、これは成功を妨げます。

Nginxでは、これらの制限はdenyディレクティブの形式を取り、サーバーブロックまたはメイン構成ファイルに配置されます。

場所/usr/share{すべて拒否;  }

データベースバックエンドがある場合、それは実行されていますか？

サイトがMySQL、PostreSQL、MongoDBなどのデータベースバックエンドに依存している場合。それが稼働していることを確認する必要があります。

これは、Webサーバーが実行されていることを確認したのと同じ方法で実行できます。ここでも、実行中のプロセスを検索して、探しているプロセスの名前を選択できます。

 sudo netstat -plunt |  grep mysql

  tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356 / mysql d

ご覧のとおり、サービスはこのマシンで実行されています。サービスを検索するときは、サービスが実行されている名前を知っていることを確認してください。

別の方法は、サービスが実行されているポートを知っている場合は検索することです。データベースのドキュメントを参照して、データベースが実行されているデフォルトのポートを見つけるか、構成ファイルを確認してください。

データベースバックエンドを使用している場合、サイトは正常に接続できますか？

データベースバックエンドの問題のトラブルシューティングを行う場合の次のステップは、正しく接続できるかどうかを確認することです。これは通常、サイトが読み取るファイルをチェックしてデータベース情報を見つけることを意味します。

たとえば、WordPressサイトの場合、データベース接続設定はwp-config.phpというファイルに保存されます。サイトをデータベースに接続するには、DB_NAME、DB_USER、およびDB_PASSWORDが正しいことを確認する必要があります。

次のような方法を使用して手動でデータベースに接続しようとすると、ファイルに正しい情報が含まれているかどうかをテストできます。

mysql -u DB_USER_value -p DB_PASSWORD_value DB_NAME_value

ファイルで見つけた値を使用して接続できない場合は、正しいアカウントとデータベースを作成するか、データベースのアクセス許可を変更する必要があります。

Webサーバーは動的コンテンツをスクリプトプロセッサに渡すように構成されていますか？

データベースバックエンドを使用している場合は、ほぼ確実にPHPなどのプログラミング言語を使用して、動的コンテンツの要求を処理し、データベースから情報をフェッチして、結果をレンダリングしています。

この場合、スクリプトプロセッサにリクエストを渡すようにWebサーバーが正しく構成されていることを確認する必要があります。

Apacheでは、これは通常、mod_php5がインストールされて有効になっていることを確認することを意味します。これは、UbuntuまたはDebianで次のように入力することで実行できます。

sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo a2enmod php5

CentOS / Fedoraシステムの場合、次のように入力する必要があります。

sudo yum install php php-mysql
sudo service httpd restart

Nginxでは、これはもう少し複雑です。 Nginxには有効にできるPHPモジュールがないため、構成でphp-fpmがインストールされて有効になっていることを確認する必要があります。

UbuntuまたはDebianサーバーで、次のように入力してコンポーネントがインストールされていることを確認します。

sudo apt-get update
sudo apt-get install php5-fpm php5-mysql

CentOSまたはFedoraでは、次のように入力してこれを行います。

sudo yum install php-fpm php-mysql

PHPプロセッサはNginxの一部ではないため、PHPファイルを明示的に渡すように指示する必要があります。このガイドのステップ4に従って、PHPファイルをphp-fpmに渡すようにNginxを構成する方法を学びます。また、PHPプロセッサの構成を扱うステップ3の部分も確認する必要があります。これは、ディストリビューションに関係なくほぼ同じであるはずです。

他のすべてが失敗した場合は、ログをもう一度確認してください

ログを確認することは実際には最初のステップであるはずですが、さらに助けを求める前の最後のステップでもあります。

自分でトラブルシューティングする能力が終わりに達し、（友人から、サポートチケットを開くなどして）助けが必要な場合は、ログファイルとエラーメッセージを提供することで、より関連性の高いヘルプをより早く得ることができます。経験豊富な管理者は、必要な情報を提供すれば、何が起こっているのかを理解できるでしょう。