【Ubuntu】Nginx/Apacheのログ場所と見方：access/errorで何が分かる？（原因特定の最短ルート）
この記事で解決できること
- Ubuntuで Nginx / Apache のログファイルの場所が分かります
- 「500/502/503/504」「403」「404」などの原因を ログから切り分け できるようになります
- ログ調査の"型"（見る順番・絞り込み・再現・確認）が身につきます
- ログ肥大（ディスク逼迫）にも繋がるので、再発防止の観点も押さえられます
結論（最短）
Webが壊れたら、まずこの順番で見れば迷いません。
- systemctlで生死確認：
systemctl status nginx|apache2 - error log を見る：
tail -n 200 .../error.log - access log で発生箇所/ステータスを特定：
grep " 500 " .../access.log - 時間を絞って再現→直後のログを見る（これが最強）
- 502/503系なら upstream（アプリ側）へ波及
目次
前提（対象環境）
- OS：Ubuntu
- Webサーバ：Nginx または Apache
sudo可能- "新人が迷わない" ために、手順を固定化して書きます
1. まずどっちを使っているか確認（Nginx? Apache?）
既に分かっているなら飛ばしてOKです。
1-1. サービス状態で確認
$ sudo systemctl status nginx $ sudo systemctl status apache2
nginxが active → Nginx を見ればOKapache2が active → Apache を見ればOK- 両方 active → リバプロ構成の可能性（まず外側のログから）
1-2. ポート待受で確認（補助）
$ sudo ss -lntp | grep ':80 ' $ sudo ss -lntp | grep ':443 '
2. ログの場所（Ubuntuの典型パス）
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" を見る（ここが最短）
アクセスログ（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 で「どのリクエストが死んだか」特定する
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. ステータスコード別：だいたいこう切り分ける
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. "ログ場所が違う"時の見つけ方
6-1. Nginxの実設定を全部出す
$ sudo nginx -T 2>&1 | grep -E "access_log|error_log" | head -n 50
6-2. Apacheの構成確認
$ sudo apache2ctl -S
7. 調査を速くする「絞り込みのコツ」
7-1. 今この瞬間に起きているものだけ見たい
最強は「再現→tail -f」です。
7-2. キーワードで絞る（例：upstream）
$ sudo grep -i "upstream" /var/log/nginx/error.log | tail -n 50
8. 失敗例と読み解き（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. やってはいけないこと
やってはいけない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 の原因にもなる
検証環境
本記事のコマンドは Ubuntu 24.04 LTS / bash 5.2 で動作確認済みです。