先に結論
500は原因名ではなく、より具体的な5xxを返せない時の一般的なサーバーエラーです。発生範囲と時刻を固定し、直前変更→リソース→アプリ例外の順でログを追います。
最初の5分で証拠を残す
- 対象URL、エラー全文、発生時刻、リクエストIDを保存する。
- 全ページか特定URLだけか、ログイン有無や操作内容で差があるかを確認する。
- 直前30分のデプロイ、設定変更、プラグイン更新、PHP・ランタイム更新を列挙する。
- 同時刻のWebサーバー、アプリ、PHP、コンテナ・関数ログを確認する。
- CPU、メモリ、ディスク容量・inode、接続数、依存DB/APIの状態を保存する。
結論：全URLで同時に500なら共通基盤・設定・容量を優先し、特定URLや操作だけなら、そのリクエストを処理したアプリ例外と依存先を優先します。
観測結果から確認先を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| デプロイ直後から全体 | 設定・依存・互換性 | 差分、環境変数、起動ログ、直前版 |
| 特定URL・入力だけ | 未処理例外 | 追跡ID、stack trace、入力条件 |
| 負荷上昇後に断続 | OOM・接続枯渇 | メモリ、worker、DB pool、キュー |
| 書込やアップロードだけ | 容量・権限 | ディスク、inode、一時領域、実行ユーザー |
| CDN経由だけ | ヘッダー・経路差 | オリジン応答、WAF/CDNログ |
| 上流から無効応答 | gateway側 | 502/504を切り分け |
成功した1件との差分を追う
- エラー時刻と追跡IDで、アクセスログからアプリログへつなぐ。
- 同じURLの直前の成功リクエストを探し、ノード、版、入力、認証、依存先を比較する。
- 例外名と最初の発生箇所を確認し、秘密情報を除いて保存する。
- OOM、process restart、disk full、permission denied、DB timeoutを同時刻で確認する。
- 原因候補を一つだけ変更し、再現条件と監視値が改善したか確認する。
WordPressは変更前に復元手段を確保
WordPress公式は、破損した .htaccess、プラグイン、テーマ、PHPメモリなどを一般的な候補として案内しています。ただし、ファイル名変更や停止操作は本番機能へ影響します。バックアップ、管理画面またはホスティングの復元手段、直前変更を確保し、一度に一項目だけ検証します。
注意：
WP_DEBUG の詳細を公開画面へ表示しないでください。WordPress公式の例のようにログへ記録し、利用者には非表示にします。避ける操作
- ログ保存前に全ノードを同時再起動する。
- 本番で詳細な例外・パス・認証情報を利用者へ表示する。
- 原因を分けずに権限を777へ広げる、WAFを恒久停止する。
- バックアップ未確認でファイルやDBを上書き・初期化する。
公式情報
WORDPRESS / 復旧後の判断
同じ運用を続けるかは、復旧後に分けて判断
障害中に移転を始めると、原因と移行差分が混ざります。まず復旧と証拠保存を優先し、その後に停止損失・復旧工数・移転費を同じ条件で比較します。
移転比較が近い売上・問い合わせへの影響があり、同種障害が反復。復元や保守の負担が大きく、30〜90日内に移転を判断したい。
まだ移転しない単発の設定・プラグイン原因で復旧済み。正常なバックアップと復元手順があり、停止損失も小さい。
先に確定する月間訪問、停止1時間の損失、現行費用、復旧工数、容量・帯域、移転期限をそろえる。
よくある質問
500エラーは利用者の端末で直せますか？
通常は直せません。500はサーバー側が予期しない状態に遭遇したことを示す一般的な応答です。運営者が同時刻のサーバー・アプリログと直前変更を確認します。
まずサーバーを再起動すべきですか？
ログやプロセス状態が消えるため、発生時刻、対象URL、リクエストID、メモリ・ディスク、直前変更を保存してから判断します。冗長構成なら影響ノードだけを切り離します。
WordPressの500は.htaccessが原因ですか？
候補の一つですが断定できません。WordPress公式は.htaccess、プラグイン、テーマ、PHPメモリなど複数の確認項目を挙げています。バックアップと変更履歴を確保し、一度に一要因だけ検証します。