症状

nginx の worker process が予期せず終了する、または繰り返しクラッシュする。

結論：まずこれを確認

  1. sudo journalctl -u nginx --since "1 hour ago" でエラーログを確認
  2. dmesg | grep -i nginx でカーネルログ（OOM Killer、segfault）を確認
  3. nginx -t で設定ファイルの構文エラーを確認

トラブルシューティングフロー

    flowchart TD
    A[worker processが異常終了] --> B{エラーログを確認}
    B -->|signal 11 SIGSEGV| C[セグメンテーション違反]
    B -->|signal 9 SIGKILL| D[OOM Killerの可能性]
    B -->|設定エラー| E[nginx -t で確認]
    B -->|ログなし| F[dmesg を確認]
    
    C --> G[モジュール/バージョン確認]
    D --> H[メモリ使用量確認]
    E --> I[設定ファイル修正]
    F --> J{dmesgに記録あり?}
    J -->|OOM| H
    J -->|segfault| G
    J -->|なし| K[リソース上限確認]

よくある原因

  • OOM Killer による強制終了 - メモリ不足でカーネルがプロセスを kill
  • セグメンテーション違反（SIGSEGV） - バグのあるモジュールや破損したバイナリ
  • 設定ファイルの構文エラー - reload 時に worker が異常終了
  • worker_connections の上限超過 - 同時接続数がシステム制限を超過
  • サードパーティモジュールの不具合 - lua-nginx-module など外部モジュールのバグ
  • ファイルディスクリプタ上限 - ulimit -n の設定不足
  • 共有メモリゾーンの枯渇 - proxy_cache や limit_req_zone のサイズ不足

確認手順

ステップ1: nginx エラーログを確認する

    # デフォルトのエラーログ
sudo tail -100 /var/log/nginx/error.log

# systemd 経由のログ
sudo journalctl -u nginx --since "1 hour ago" --no-pager

🔍 チェックポイント: worker process XXX exited on signal XX の記載を探す

  • signal 11（SIGSEGV）→ ステップ4へ
  • signal 9（SIGKILL）→ ステップ2へ
  • signal 6（SIGABRT）→ ステップ4へ

ステップ2: OOM Killer の発動を確認する

    # カーネルログで OOM を検索
dmesg | grep -i "out of memory"
dmesg | grep -i "killed process"

# 特定のプロセス名で検索
dmesg | grep -i nginx

🔍 チェックポイント: Out of memory: Killed process XXXX (nginx) が表示されれば OOM Killer が原因

OOM が確認された場合：

    # 現在のメモリ使用状況
free -h

# nginx のメモリ使用量
ps aux | grep nginx | awk '{sum+=$6} END {print sum/1024 " MB"}'

ステップ3: 設定ファイルの構文を確認する

    sudo nginx -t

🔍 チェックポイント: syntax is ok と test is successful が表示されれば設定は正常

エラーが表示された場合：

    # 設定ファイルの該当行を確認
sudo nginx -T 2>&1 | head -50

ステップ4: セグメンテーション違反の詳細を確認する

    # coredump の有無を確認
ls -la /var/crash/ 2>/dev/null || ls -la /var/lib/systemd/coredump/ 2>/dev/null

# dmesg でセグフォルトの詳細を確認
dmesg | grep -i segfault | tail -10

🔍 チェックポイント: segfault のアドレスやモジュール名が記録されている場合がある

モジュール一覧の確認：

    nginx -V 2>&1 | tr ' ' '\n' | grep module

ステップ5: リソース上限を確認する

    # nginx の実行ユーザーを確認
ps aux | grep "nginx: worker" | head -1 | awk '{print $1}'

# ファイルディスクリプタ上限（nginx ユーザーで実行）
cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "Max open files"

# システム全体の上限
sysctl fs.file-max

🔍 チェックポイント: Max open files が worker_connections の設定値より大きいことを確認

nginx.conf の設定確認：

    grep -E "(worker_connections|worker_rlimit_nofile)" /etc/nginx/nginx.conf

ステップ6: 共有メモリの使用状況を確認する

    # 共有メモリゾーンの設定を確認
grep -rE "(proxy_cache_path|limit_req_zone|limit_conn_zone)" /etc/nginx/

🔍 チェックポイント: zone のサイズが小さすぎないか確認（目安: 10m 以上）

NG行動（やってはいけないこと）

  • ログを確認せずに nginx を再起動する - 原因が特定できなくなる
  • OOM 発生時にスワップを無効化する - 状況が悪化する可能性がある
  • segfault 発生時にそのまま運用を続ける - データ破損やセキュリティリスクがある
  • worker_processes を過剰に増やす - メモリ消費が増え OOM の原因になる
  • エラーログレベルを warn 以下にする - 重要な情報が記録されなくなる

よくある質問（FAQ）

Q1: worker process が数時間おきにクラッシュする場合は？

A: メモリリークの可能性がある。worker_shutdown_timeout を設定し、定期的に graceful restart する運用を検討する。メモリ使用量の推移を監視ツールで記録する。

Q2: 特定の URL アクセス時だけクラッシュする場合は？

A: アップストリームの応答や特定のモジュール処理が原因の可能性がある。該当 URL のアクセスログとエラーログを突合し、リクエスト内容を確認する。

Q3: nginx のバージョンアップ後にクラッシュするようになった場合は？

A: サードパーティモジュールとの互換性問題の可能性がある。変更前のバージョンに戻すか、問題のモジュールを無効化して切り分けを行う。

関連するエラー・症状

  • （関連記事準備中）
  • （関連記事準備中）
  • （関連記事準備中）
  • （関連記事準備中）

解決しない場合

確認すべきログファイル：

  • /var/log/nginx/error.log
  • /var/log/syslog または /var/log/messages
  • journalctl -u nginx
  • dmesg

次に調べるキーワード：

  • nginx coredump 解析
  • nginx debug ログ有効化
  • gdb nginx backtrace