概要
構成ファイルのテストを実行したり、エラーログを確認します。プロセス・ポートが起動しているか、バックエンド側のhttpサーバーに誤りが無いか確認します。
実行環境 |
---|
CentOS7 |
Nginx 1.20.1 |
Python 3.6.8 |
nginxの設定は終えていると仮定して、直接ブラウザからIPアドレスもしくはドメインを検索して、以下のように表示される。
ターミナルでcurlコマンドを打ち、urlのページ詳細を確認できます。
# ページ全体のhtml取得
$ curl https://example.com
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 に原因がある場合は、サーバー側の設定で対応できることが殆どです。
サーバー内のプロセス状況・ポート使用状況に注意して調査しましょう。
最後までご覧いただきありがとうございます。