2026年8月5日

Nginxのアクセスログとエラーログの確認方法（場所の調べ方・読み方・よく出るエラー）

Webサーバー・Nginx

Nginxのログは、多くの環境で /var/log/nginx/access.log（アクセスログ）と /var/log/nginx/error.log（エラーログ）に書かれます。ただし設定で場所は変えられるため、まず実際の設定から場所を調べます。この記事では、ログの場所の調べ方、アクセスログの各項目の読み方、コマンドで集計する方法、エラーログによく出るメッセージと対処、ログを扱うときの注意点を説明します。

ログの場所を設定から調べる

ログの出力先は access_log と error_log の指定で決まり、サイト（server）ごとに別のファイルにしていることもよくあります。読み込まれている設定をすべて表示する nginx -T を使うと、インクルードされたファイルも含めて検索できます。

sudo nginx -T 2>/dev/null | grep -E '^\s*(access_log|error_log)'

何も指定していなければ、パッケージで入れたNginxは /var/log/nginx/ に書き込みます。Dockerの公式イメージでは、ログファイルが標準出力と標準エラー出力につながっているため、docker logs コンテナ名 で読みます。共用サーバーやマネージドな環境では、管理画面からログをダウンロードする形になっていることが多いので、提供元の案内に従います。

Nginx自体が起動しない場合は、エラーログより先にsystemdの記録を見ると原因が出ていることがあります。

sudo systemctl status nginx
sudo journalctl -u nginx --since "1 hour ago"

アクセスログの読み方

標準の書式（combined）では、1回のリクエストが次のような1行になります。

203.0.113.5 - - [18/Oct/2026:10:15:32 +0900] "GET /blog/hello/ HTTP/1.1" 200 5120 "https://www.google.com/" "Mozilla/5.0 (...)"

左から順に、接続元IPアドレス、認証ユーザー名（Basic認証を使っていなければ -）、日時、リクエストの内容（メソッド・パス・プロトコル）、ステータスコード、返したバイト数、参照元（Referer）、ブラウザの情報（User-Agent）です。

ステータスコードは、障害かどうかを見分ける一番の手がかりです。200番台は成功、301・302はリダイレクト、304はブラウザのキャッシュが使われたこと、404は存在しないURL、403は拒否、499はNginx独自の値で、応答を返す前にクライアントが接続を切ったことを表します。500番台はサーバー側の問題で、502・504はNginxの裏にあるPHP-FPMやアプリケーションへの中継で問題が起きたことを示します。

リバースプロキシやCDNの裏にNginxがある場合、先頭のIPアドレスはプロキシのものになります。本来の接続元を記録するには、ngx_http_realip_module で信用するプロキシを指定する設定が必要です。

コマンドで集計する

ログをリアルタイムで見るには tail -f を使います。ブラウザで問題のページを開きながら見ると、どの行が自分のアクセスかを対応づけられます。

sudo tail -f /var/log/nginx/access.log

障害の範囲や、アクセスが集中している相手を知りたいときは、項目の位置で集計します。combined 書式では、空白で区切った1番目がIPアドレス、7番目がパス、9番目がステータスコードです。

# ステータスコードごとの件数
sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# アクセスの多いIPアドレス上位10件
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 500番台を返したパスの上位10件
sudo awk '$9 ~ /^5/ {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# wp-login.php への POST が多いIPアドレス
sudo grep 'POST /wp-login.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

log_format を独自の書式に変えている場合は、項目の位置がずれるため、先に1行を見て何番目が何かを確かめます。ローテーションで圧縮された過去のログ（access.log.2.gz など）は、zcat や zgrep で展開せずに読めます。

集計の結果、特定のIPから wp-login.php への大量のPOSTが見つかった場合は、ログインへの総当たりの可能性があります。その場合はアクセス制限やレート制限を検討します。継続的に傾向を見たい場合は、GoAccessのようなログ解析ツールを使うと、集計を毎回コマンドで組み立てずに済みます。

エラーログの読み方とよく出るメッセージ

エラーログの1行には、日時、重要度（error・warn・crit など）、プロセス番号、メッセージ、そして関係するクライアントとリクエストが記録されます。error_log に書いた重要度より低いものは記録されません。既定は error です。

メッセージの中の括弧付きの番号は、OSのエラー番号です。これを手がかりに原因を絞り込みます。

**connect() failed (111: Connection refused) while connecting to upstream**: 502の原因として最も多いものです。PHP-FPMやアプリケーションが止まっているか、接続先のポートやソケットの指定が違います。systemctl status php8.3-fpm（バージョン番号は環境に合わせる）で起動状態を確認します。
**upstream timed out (110: Connection timed out)**: 504の原因です。バックエンドの処理が時間内に終わっていません。PHP側のスロー処理やデータベースの負荷を調べ、必要なら proxy_read_timeout や fastcgi_read_timeout を見直します。
**connect() to unix:/run/php/... failed (13: Permission denied)**: Nginxの実行ユーザーにPHP-FPMのソケットを開く権限がありません。PHP-FPMのプール設定の listen.owner・listen.group・listen.mode を確認します。
**FastCGI sent in stderr: "Primary script unknown"**: PHP-FPMに渡したファイルの場所が見つかっていません。root の指定と SCRIPT_FILENAME の組み立てを確認します。
**open() "..." failed (2: No such file or directory)**: 存在しないファイルへのリクエストです。404と対応し、多くは無害ですが、本来あるはずのファイルなら root の指定を確認します。
**client intended to send too large body**: アップロードが client_max_body_size（既定値1MB）を超えて413になっています。
**worker_connections are not enough**: 同時接続がワーカーの上限を超えています。events ブロックの設定を見直します。

PHPの致命的なエラーの多くは、Nginxのログではなく、PHP-FPMやWordPressのログ（WP_DEBUG_LOG を有効にした場合の wp-content/debug.log など）に出ます。Nginxのログで「どのリクエストで起きたか」を特定し、詳しい原因はPHP側のログで確認する、という順で見ると効率的です。

ログを扱うときの注意点

アクセスログには、訪問者のIPアドレスや閲覧したURL、場合によってはURLに含まれた検索語や識別子が残ります。ログファイルの権限を必要な人だけに絞り、他人に渡すときはIPアドレスを伏せるなどの加工をします。保存期間はlogrotateの設定で決まるため、調査に必要な期間とプライバシーポリシーに書いた内容が合っているかを確認しておきます。主なディストリビューションでは、Nginxのパッケージにlogrotateの設定が同梱されています（2026年10月現在）。

また、ログがディスクを使い切るとNginxやデータベースが正常に動かなくなります。df -h と du -sh /var/log/nginx で使用量を定期的に確認します。

まとめ

ログの場所は nginx -T で設定から調べます。標準は /var/log/nginx/ で、Dockerでは docker logs で読みます。
アクセスログはステータスコードを手がかりにし、awk・sort・uniq で件数や相手を集計します。
エラーログは括弧内のOSのエラー番号と upstream の文言から、502・504などの原因を絞り込みます。
PHPの詳しいエラーは、Nginxではなく PHP-FPMやWordPressのログで確認します。
ログには個人に関わる情報が含まれるため、権限と保存期間を管理します。