一般的な Nginx エラー メッセージを修正する方法: ステップバイステップ ガイド

NGINX エラーを修正するにはどうすればよいですか?

一般的な NGINX エラーのいくつかを確認したところで、「NGINX エラーを修正するにはどうすればよいですか?」という疑問が浮かんだかもしれません。

そうですね、答えは思っているほど難しいものではありません。 NGINX エラーに対して使用できるさまざまなトラブルシューティング方法があります。 ただし、これらのトラブルシューティング方法は初期段階のみに適用されることに注意することが重要です。 問題の正確な原因を特定するには、さらなる調査が必要です。

NGINX エラーのトラブルシューティングを開始するのに役立つコマンドは基本的に 3 つあります。

• 次のコマンドを使用して、エラー ログと問題の詳細を取得します: sudo cat /var/log/nginx/error.log
• Nginx のアクティブ ステータスを確認するには: sudo systemctl status nginx
• 構成ファイル内の構文エラーをチェックするには: sudo nginx -t

1. エラーログを使用した Nginx エラーのトラブルシューティング

NGINX で問題が発生した場合、NGINX エラーのほとんどは曖昧であり、実際の問題を単純に把握するのは簡単ではありません。 このエラーは、より大きな問題が原因で発生する場合もあれば、まったく関係ない場合もあります。

これはすべて、NGINX セットアップの構成方法と、直面している特定の状況によって異なります。

発生している NGINX エラーをより深く理解するには、コマンドを実行してこれらのエラーのリストを表示します。 コマンドは次のとおりです。

sudo cat /var/log/nginx/error.log

このコマンドを実行するには、特権ユーザーである必要があります。 root ユーザーを使用する代わりに sudo アクセス権を持つことをお勧めします。

このコマンドを使用すると、NGINX エラー ログが含まれる /var/log/nginx/error.log ファイルの内容全体を読み取ることができます。 これらのログはターミナル ウィンドウに表示されます。

このコマンドを実行すると、ログに記録された NGINX エラーのリストを確認できます。 ログにエラーが記録されていない場合は、コマンドを実行しても出力が表示されないことに注意してください。

参考までにエラーログの例を示します。

2023/05/31 10:15:23 [error] 1234#0: *1 open() "/var/www/html/missing-page.html"
failed (2: No such file or directory), client: 192.168.0.1, server: example.com,
request: "GET /nonexistent-page HTTP/1.1", host: "example.com"

2023/05/31 12:45:57 [error] 1234#0: *2 upstream timed out (110: Connection timed out)
while reading response header from upstream, client: 192.168.0.2, server:
example.com, request: "GET /api/data HTTP/1.1", upstream:
"http://127.0.0.1:8000/api/data", host: "example.com"

2023/05/31 15:22:10 [error] 1234#0: *3 rewrite or internal redirection cycle while internally redirecting to "/index.php", client: 192.168.0.3, server: example.com, request: "GET /category/products/ HTTP/1.1", host: "example.com"

この例では、各行は NGINX によってログに記録された個別のエラーを表しています。 提供された情報を分析してみましょう。

• タイムスタンプ: 各行の最初の部分には、エラーが発生した日時YYYY/MM/DD HH:MM:SS形式で表示されます。
• エラー レベル: [error]タグは、この行がエラーを表すことを示します。
• プロセス ID: #記号の後の数字 (例: 1234#0 ) は、リクエストを処理する NGINX プロセス ID を表します。
• エラー メッセージ: エラー メッセージには、特定のエラーに関する詳細が表示されます。 これには、ファイルまたはリソースへのアクセスの失敗、アップストリーム接続のタイムアウト、内部リダイレクトの問題などの情報が含まれます。
• クライアント IP: clientフィールドには、サーバーにリクエストを行っているクライアントの IP アドレスが表示されます。
• サーバー名: serverフィールドは、エラーが発生したサーバー名または仮想ホストを示します。
• リクエストの詳細: requestフィールドには、クライアントが使用する HTTP メソッド、リクエストされた URL、およびプロトコルのバージョンが表示されます。
• ホスト: hostフィールドは、リクエストで使用されるホスト名または IP アドレスを指定します。

各エラー ログ エントリは、エラーの種類、影響を受けるリソース、クライアント IP、その他の関連詳細に関する情報を提供することで、問題の診断とトラブルシューティングに役立ちます。

2. NGINX のステータスを確認してトラブルシューティングを行う

NGINX のトラブルシューティングを試行できるもう 1 つの方法は、NGINX のステータス、つまりアクティブかどうかを確認することです。 何らかの理由により、インストールプロセスが完了できなかったか、サービスがまだアクティブになっていない可能性があります。

NGINX サービスのステータスを確認するには、次のコマンドを使用します。

sudo systemctl status nginx

NGINX サービスがアクティブな場合、出力は次のようになります。

nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:
enabled)
Active: active (running) since Mon 2023-05-31 14:30:00 UTC; 5min ago
Docs: http://nginx.org/en/docs/
Process: 1234 ExecStart=/usr/sbin/nginx -g daemon on;
master_process on;
(code=exited, status=0/SUCCESS)
Main PID: 1234 (nginx)
Tasks: 2 (limit: 2319)
Memory: 3.9M
CGroup: /system.slice/nginx.service
├─1234 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
└─5678 nginx: worker process

NGINX ステータスが非アクティブの場合、 sudo systemctl status nginxコマンドの出力には、次のようにサービスが非アクティブであるか停止していることが示されます。

nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: http://nginx.org/en/docs/

その場合は、次のコマンドを使用して NGINX サービスを再起動するだけです。

sudo systemctl restart nginx

その後、status コマンドを再度使用して、NGINX サービスが現在アクティブかどうかを確認できます。

3. 構文エラーをチェックして NGINX のトラブルシューティングを行う

構文エラーは、スクリプト、コードを作成するとき、または Nginx ファイルを構成するときに発生する可能性のある一般的な問題です。

間違った構文構造を使用したか、特定の文字を省略したかにかかわらず、構文が間違っていると、コードや構成が正しく機能しなくなります。

Nginx 設定ファイルの場合、それらはさまざまなディレクティブで構成されており、適切に機能するにはそれぞれを正確に宣言する必要があります。 そうしないと、意図したとおりに動作しません。

Nginx 構成ファイル内の構文エラーを確認するには、次のコマンドを使用します。

sudo nginx -t

構文が正しいと判明した場合、出力は次のようになります。

nginx: configuration file /etc/nginx/nginx.conf test is successful

ただし、構文に問題がある場合、出力は次のように表示されます。

nginx: [emerg] unexpected end of file, expecting ";" or "}" in
/etc/nginx/nginx.conf:42
nginx: configuration file /etc/nginx/nginx.conf test failed

このチェックを実行すると、構文エラーを特定して修正できるため、Nginx 構成が正確で完全であることが保証されます。 構文エラーによって引き起こされる問題を避けるために、構成ファイルに変更を加えるたび、または Nginx を再起動する前にこのコマンドを実行することをお勧めします。