【Webサーバー】Nginxが正常に起動されているか確認する


投稿日 2019年5月29日 >> 更新日 2024年7月10日

概要

構成ファイルのテストを実行したり、エラーログを確認します。プロセス・ポートが起動しているか、バックエンド側のhttpサーバーに誤りが無いか確認します。

実行環境

実行環境
CentOS7
Nginx 1.20.1
Python 3.6.8

「502 Bad Gateway」が表示されているか確認

nginxの設定は終えていると仮定して、直接ブラウザからIPアドレスもしくはドメインを検索して、以下のように表示される。

ターミナルでcurlコマンドを打ち、urlのページ詳細を確認できます。

# ページ全体のhtml取得
$ curl https://example.com

Nginxの詳細な情報

nginxコマンドのオプション「-h」を実行することで、構成ファイルに間違いが無いかのテストをする為のオプションや構成ファイルの場所、そしてエラーログの在り処等を確認することができます。

$ nginx -h
nginx version: nginx/1.20.1
Usage: nginx [-?hvVtTq] [-s signal] [-p prefix]
             [-e filename] [-c filename] [-g directives]

Options:
  -?,-h         : this help
  -v            : show version and exit
  -V            : show version and configure options then exit
  -t            : test configuration and exit
  -T            : test configuration, dump it and exit
  -q            : suppress non-error messages during configuration testing
  -s signal     : send signal to a master process: stop, quit, reopen, reload
  -p prefix     : set prefix path (default: /usr/share/nginx/)
  -e filename   : set error log file (default: /var/log/nginx/error.log)
  -c filename   : set configuration file (default: /etc/nginx/nginx.conf)
  -g directives : set global directives out of configuration file

構成ファイルのテスト

nginx.confの構文チェックをしてみる。

$ 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のエラーログの在り処はnginxコマンドのオプション「-h」で確認できる通り、「-e」節にデフォルトで配置されているディレクトリを確認できます。

私の環境だと「/var/log/nginx/error.log」にエラーログファイルが保存されています。

# catコマンドにて内容を確認
$ sudo cat /var/log/nginx/error.log

下記のエラーが発生している場合、nginx ではなくバックエンドのサービスに問題があります。

upstream timed out
connect() failed (111: Connection refused). Connecting to upstream, 

アプリケーションサーバーを確認してみましょう。

例えば、Gunicornであれば起動しているコマンドと引数に間違いが無いか確認します。

systemdのユニットファイルを作成している場合は、以下のように記述していると思います。

[Service]
...
ExecStart=/usr/local/bin/gunicorn --bind 127.0.0.1:8000 app.wsgi:application

パッケージを入れ直したりする際に起こるのが、パッケージの管理場所がいつの間にか変わってしまい「/usr/local/bin/gnicorn」だったのが、「/usr/bin/gnicorn」になっていた、なんてこともあります。

「which 」コマンドでパッケージの場所を調べて、ユニットファイル等の記述と整合性はあるのか確認します。

$ which gunicorn
/usr/local/bin/gunicorn

以下のようなメッセージが出力されていれば、Python の記述ミスを疑いましょう。

Python Parse error:  syntax error, unexpected

TEBUGを「True」にするなどしてエラー内容を確認します。

プロセス・ポートが起動しているか確認

サーバーへログインしてnginxプロセスの存在を確認する。psとgrepコマンドを組み合わせると便利。

$ ps ax | grep nginx
 2195 ?  Ss  0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
22678 ?  S   0:03 nginx: worker process

設定にもよるが、masater process と worker process があれば OK 。
worker process の数は環境によって異なるので複数存在していても問題なし。

nginx が利用するポートについても確認しておきます。

サーバーが待受中のポートを ss -natu コマンドで表示し、grep で絞り込みます。

$ ss -natu | grep LISTEN
tcp    LISTEN     0      128   :::80   :::*

HTTP の場合は「80」番ポート、HTTPS の場合は「443」番ポートがあるかを確認。

nginx に原因がある場合は、サーバー側の設定で対応できることが殆どです。

サーバー内のプロセス状況・ポート使用状況に注意して調査しましょう。

最後までご覧いただきありがとうございます。