Nginx/Apacheのログ場所と見方：access/errorで何が分かる？

Nginx/Apacheのログ場所と見方：access/errorで何が分かる？
読了時間: 約12分 難易度: 中級

この記事で解決できること

  • Ubuntuで Nginx / Apache のログファイルの場所が分かります
  • 「500/502/503/504」「403」「404」などの原因を ログから切り分け できるようになります
  • ログ調査の"型"（見る順番・絞り込み・再現・確認）が身につきます
  • ログ肥大（ディスク逼迫）にも繋がるので、再発防止の観点も押さえられます

結論（最短）

Webが壊れたら、まずこの順番で見れば迷いません。

  1. systemctlで生死確認：systemctl status nginx|apache2
  2. error log を見る：tail -n 200 .../error.log
  3. access log で発生箇所/ステータスを特定：grep " 500 " .../access.log
  4. 時間を絞って再現→直後のログを見る（これが最強）
  5. 502/503系なら upstream（アプリ側）へ波及

前提（対象環境）

  • OS：Ubuntu
  • Webサーバ：Nginx または Apache
  • sudo 可能
  • "新人が迷わない" ために、手順を固定化して書きます

1. まずどっちを使っているか確認（Nginx? Apache?）

結論: systemctl status nginx/apache2でどちらがactiveか確認し、両方activeならリバプロ構成を疑う。

既に分かっているなら飛ばしてOKです。

1-1. サービス状態で確認

$ sudo systemctl status nginx
$ sudo systemctl status apache2
  • nginx が active → Nginx を見ればOK
  • apache2 が active → Apache を見ればOK
  • 両方 active → リバプロ構成の可能性（まず外側のログから）

1-2. ポート待受で確認（補助）

$ sudo ss -lntp | grep ':80 '
$ sudo ss -lntp | grep ':443 '

2. ログの場所（Ubuntuの典型パス）

結論: Nginxは/var/log/nginx/、Apacheは/var/log/apache2/にerror.logとaccess.logが置かれている。

Ubuntuではだいたいここです。

2-1. Nginx

  • error log：/var/log/nginx/error.log
  • access log：/var/log/nginx/access.log
$ ls -la /var/log/nginx

2-2. Apache（apache2）

  • error log：/var/log/apache2/error.log
  • access log：/var/log/apache2/access.log
$ ls -la /var/log/apache2

3. まず "error log" を見る（ここが最短）

結論: error.logに原因（スタックトレース/設定エラー/上流死）が出るためtail -n 200で直近を確認し再現しながらtail -fで追うのが最強。

アクセスログ（access.log）は「何が起きたか」を見つけるのに良いですが、原因（スタックトレース/設定エラー/上流死） が出るのは error.log です。

3-1. 直近200行を見る（最初の一手）

# Nginx
$ sudo tail -n 200 /var/log/nginx/error.log

# Apache
$ sudo tail -n 200 /var/log/apache2/error.log

3-2. 再現しながらリアルタイム追跡（最強）

# Nginx
$ sudo tail -f /var/log/nginx/error.log

# Apache
$ sudo tail -f /var/log/apache2/error.log

これを開いたまま、別タブでブラウザ/curl で再現すると、原因に直行できます。「ログ見たけど分からない」は、再現とセットにしていないことが多いです。

4. access log で「どのリクエストが死んだか」特定する

結論: grep " 500 " access.logのようにステータスコードやパスで絞り込み、どのリクエストが障害を起こしているか特定する。

4-1. 500だけ拾う

$ sudo grep " 500 " /var/log/nginx/access.log | tail -n 50

4-2. 404だけ拾う

$ sudo grep " 404 " /var/log/nginx/access.log | tail -n 50

4-3. 特定パスだけ拾う（例：/api/）

$ sudo grep " /api/" /var/log/nginx/access.log | tail -n 50

5. ステータスコード別：だいたいこう切り分ける

結論: 500はアプリ/設定エラー、502/503/504はupstream障害、403は権限/アクセス制御、404はルーティング不備として次の調査先が変わる。

5-1. 500（Internal Server Error）

  • アプリ内部エラー（PHP/Node/Ruby等）
  • 設定ミス（FastCGI設定など）
  • 権限/パス（Permission denied）の可能性も

次に見る：error.log（最優先）、アプリログ、journalctl -u

5-2. 502 / 503 / 504（Bad Gateway / Service Unavailable / Gateway Timeout）

  • Nginx/Apache が 上流（upstream） に繋げない/応答が遅い/死んでる

次にやる：

$ nc -vz 127.0.0.1 3000
$ curl -I http://127.0.0.1:3000

5-3. 403（Forbidden）

  • Basic認証、IP制限、WAF、ディレクトリ権限、ファイル権限

次に見る：error.log に "permission denied" や "client denied" が出る

5-4. 404（Not Found）

  • ルーティング/ファイルが存在しない
  • SPAのリライト設定不足

6. "ログ場所が違う"時の見つけ方

結論: nginx -Tでaccess_log/error_logのパスを全設定から抽出でき、Apacheはapache2ctl -Sで確認する。

6-1. Nginxの実設定を全部出す

$ sudo nginx -T 2>&1 | grep -E "access_log|error_log" | head -n 50

6-2. Apacheの構成確認

$ sudo apache2ctl -S

7. 調査を速くする「絞り込みのコツ」

結論: 再現しながらtail -fで追うのが最強で、キーワードgrepを組み合わせることで調査時間を大幅に短縮できる。

7-1. 今この瞬間に起きているものだけ見たい

最強は「再現→tail -f」です。

7-2. キーワードで絞る（例：upstream）

$ sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 50

8. 失敗例と読み解き（error.logでよく出るやつ）

結論: Connection refused/timeout/permission deniedなどパターンごとに原因が異なりerror.logから次の調査先が決まる。

8-1. connect() failed (111: Connection refused) while connecting to upstream

意味：upstream先が待ち受けていない/落ちている

$ nc -vz 127.0.0.1 <upstream-port>
$ sudo systemctl status <app-service>

8-2. upstream timed out (110: Connection timed out)

意味：upstreamが遅い/詰まっている（負荷・DB・I/Oなど）

8-3. permission denied

意味：ファイル/ディレクトリ権限、SELinux/APPArmor絡みもあり得る

8-4. client intended to send too large body

意味：アップロードサイズ制限（nginxのclient_max_body_size等）

9. やってはいけないこと

結論: ログ確認なしのrestart連打・access.logだけで完結・ログ肥大放置の3つがNginx/Apacheトラブル調査の典型的な失敗パターン。

やってはいけない1：ログ見ずに restart を連打する

ログを見ない再起動は、原因を隠すだけで時間を溶かします。まず error.log / journalctl を見てから。

やってはいけない2：access.logだけ見て満足する

原因が出るのはだいたい error.log です。accessは「どのリクエストか」特定用。

やってはいけない3：ログ肥大を放置する

アクセスが増えるとログは増えます。ディスク逼迫（No space left）に繋がるので、容量監視やローテーション（logrotate）は必須。

コピペ用：ログ調査テンプレ（Nginx例）

# サービス生死
sudo systemctl status nginx

# エラー（まずここ）
sudo tail -n 200 /var/log/nginx/error.log

# 再現しながら追う（最強）
sudo tail -f /var/log/nginx/error.log

# どのリクエストが死んだか
sudo grep " 500 " /var/log/nginx/access.log | tail -n 50
sudo grep " 502 " /var/log/nginx/access.log | tail -n 50
sudo grep " 403 " /var/log/nginx/access.log | tail -n 50
sudo grep " 404 " /var/log/nginx/access.log | tail -n 50

まとめ

  • まず error.log、次に access.log
  • 再現しながら tail -f が最短
  • 502/503/504 は upstream（アプリ）へ。ポート疎通の型に戻る
  • ログはディスクを食う。No space left の原因にもなる

次に読む