500 Internal Server Error の原因と対処法 — 原理からWordPress対策まで徹底解説

2025年12月28日 最終更新日時 : 2025年12月28日 エバープレイ編集部

はじめに：500 Internal Server Errorとは何か

「500 Internal Server Error」は、HTTPレスポンスステータスコードの一つで、サーバー側で何らかの問題が発生したためにリクエストを正常に処理できなかったことを示します。クライアント（ブラウザやAPIクライアント）には問題の詳細が返されないため、原因の特定にはサーバー側のログや設定の確認が必要です。本コラムでは、発生メカニズム、典型的な原因、診断手順、具体的な対処法、WordPress環境での注意点、予防策までを詳しく解説します。

HTTPステータスコードにおける位置づけ

500は5xx系のサーバーエラーに属します。5xxはサーバー自身に起因する問題を示し、代表的なコードに502（Bad Gateway）、503（Service Unavailable）、504（Gateway Timeout）などがあります。500はその中でも「汎用的なサーバー内部エラー」を表すため、原因は多岐にわたり、診断に工夫が必要です。

500エラーが発生する主な原因

  • アプリケーション例外（未処理のエラー、例外のスロー）
  • PHPやスクリプトの構文エラー・致命的エラー（未定義関数の呼び出し、メモリ不足など）
  • Webサーバー設定エラー（.htaccessの誤記、ディレクティブの衝突など）
  • パーミッションや所有者の不整合（ファイル/ディレクトリに読み書き権限が無い）
  • バックエンド（データベースやAPI）の障害や接続タイムアウト
  • プロセスマネージャ（PHP-FPM、FastCGI、uWSGIなど）の異常終了や過負荷
  • モジュールや拡張（Apacheモジュール、PHP拡張）の不整合
  • リソース制限（メモリ、CPU、同時接続数、open file 限界）
  • セキュリティ制御（WAFやmod_securityによるリクエストブロック）

診断手順：まず見るべき場所

  • Webサーバーのエラーログ（Apache: error_log、Nginx: error.log）を確認する。タイムスタンプとエラー内容から原因を絞れることが多い。
  • アプリケーションログやフレームワークのログ（例：Laravel、Django、WordPressのデバッグログ）を確認する。
  • PHPのエラーログ（display_errorsを本番でONにしないこと。ただし一時的な診断時はログ出力を有効にして詳細を確認する）
  • ブラウザの開発者ツールでレスポンスヘッダを確認（Server、X-Powered-By、Retry-Afterなど）
  • curlやwgetでヘッダを取得（例：curl -I https://example.com）し、ステータスやヘッダを調べる
  • リソース利用状況の把握（top、htop、vmstat、iostatなど）を確認して負荷やメモリ枯渇を検出する
  • バックエンド（DB、外部API）の接続状況を確認し、タイムアウトや認証エラーがないかを調べる

環境別の具体的原因と対処例

Apache + PHP（mod_php / PHP-FPM）

.htaccessの記述ミスで500が返ることは定番です。Allow/Deny、RewriteRule、php_value/ini_setなどのディレクティブが無効なホストではエラーになります。対処法は該当ディレクティブを削除するか、サーバー設定（httpd.confやApacheの仮想ホスト）に移すことです。PHP側なら致命的エラー（メモリ不足、構文エラー）が原因のことが多く、error_logに「PHP Fatal error: ...」が出ています。

Nginx + PHP-FPM

502/504と似ていますが、PHP-FPMのプロセスが落ちているかソケットの権限不正で500が返る場合があります。/var/log/php-fpm.logやNginxのerror.logを調べ、php-fpmが稼働しているか（systemctl status php-fpm）を確認してください。ソケット（unix:）の場合はwww-data等のユーザー権限を見直します。

CGI/Perl/Python系スクリプト

スクリプトの先頭に正しいシバン（#!）がない、実行権限がない、出力ヘッダが不正（Content-Typeがない等）な場合に500エラーになります。スクリプトの実行権限と出力フォーマットをチェックしてください。

WordPress環境での典型的な原因と対応

WordPressにおける500エラーは多くの運用者が直面します。代表的な原因と対処を示します。

  • プラグインやテーマの不具合：最近追加・更新したプラグインを無効化して挙動を確認。FTPでwp-content/pluginsのフォルダ名を変更すると全プラグインが無効化されます。
  • .htaccessの破損：WordPressのパーマリンク設定を再保存すると.htaccessが再生成されます。手動で元に戻す場合は標準設定に修正。
  • PHPメモリ不足：wp-config.phpに define('WP_MEMORY_LIMIT', '256M'); を一時的に追加して確認。ただしホスティングの制限もあるためphp.iniやホスティング管理で調整が必要。
  • wp-config.phpの誤記：構文ミスや bom（BOM）によるヘッダ送信前の出力でエラーが出ることがある。編集時はUTF-8 without BOMで保存する。
  • ファイル/ディレクトリの権限問題：通常ファイルは644、ディレクトリは755、wp-config.phpはさらに厳格に保護する（440/400など）

トラブルシューティングの実践的チェックリスト

  • エラーログ確認（タイムスタンプを起点に該当リクエストのエントリを探す）
  • 直近のデプロイや設定変更をロールバックして差分を確認
  • プラグイン/テーマの一時無効化（WordPress）
  • PHP/アプリケーションの一時的なデバッグ出力（本番での機密情報出力は避ける）
  • リソース監視（メモリ、ディスク、open file、プロセス数）
  • 外部依存（DB、API）の到達性と認証情報の確認
  • Webサーバーの設定ファイルを構文チェック（apachectl configtest、nginx -t）
  • プロセス管理の再起動（サービスの再起動を行う前にログを採取する）

ログ例と読み方（よく見るパターン）

ログには原因を示すキーワードが出ることが多いです。例：

  • "PHP Fatal error" → コードレベルの致命的エラー（行番号とファイルが出力される）
  • "permission denied" → パーミッションや所有者の問題
  • "premature end of script headers" → CGIの出力が不正、スクリプトが正しくヘッダを出さない
  • "connection refused" や "connect() failed" → バックエンドやソケットが応答していない

本番対応の注意点とセキュリティ配慮

詳細なエラーメッセージやスタックトレースをそのままクライアントに出力してはいけません。攻撃者に内部情報を与える可能性があります。代わりに内部ログへ詳細を出力し、ユーザーには適切なカスタムエラーページ（500.html）を返すのが安全です。また、WAFの挙動やログも確認し、誤検知でブロックされていないか確認してください。

予防策と運用改善

  • 監視とアラート：ログ収集（ELK/EFK）、APM（New Relic、Datadog）、監視ツールでエラー率やレスポンス異常を検知する。
  • 自動回復：プロセスマネージャ（systemd、supervisord、containerの再起動ポリシー）で落ちたプロセスを自動復旧。
  • ステージングでの検証：本番へ反映する前にステージング環境で統合テストを行う。
  • ロールバック戦略：デプロイ時のリリース管理（リリース間で迅速にロールバック可能にする）
  • 容量計画とスケーリング：負荷時にプロセス数やインスタンスを拡張できるようにする。

事例：よくあるワンショット解決フロー

例：WordPressで500が発生した場合の簡易フロー

  • 1) 直近の変更履歴（プラグイン/テーマ/更新）を確認
  • 2) error_logを確認して該当時刻のエントリを抽出
  • 3) WP_DEBUGを一時的に有効化して詳細ログを生成（本番ではログ出力のみ）
  • 4) 問題のプラグインをFTPで無効化し、復旧するか確認
  • 5) 復旧したら原因プラグインをアップデートまたは開発元に報告し、代替策を検討

まとめ

500 Internal Server Errorは「サーバー内部で何かが壊れている」ことを示す汎用的なエラーです。ログを最優先で確認し、環境（Webサーバー、アプリケーション、バックエンド、リソース）ごとに切り分けを行うことが解決の近道です。WordPressのようなCMSではプラグイン・テーマや.htaccess、PHP設定が原因になることが多いので、まずは最近の変更を疑い、段階的に無効化して特定してください。最後に、本番環境では詳細情報を公開せず、ログ収集・監視・自動回復を整備することが再発防止になります。

参考文献

カテゴリー
IT
前の記事
KLPGA完全ガイド：歴史・仕組み・注目選手と未来展望New!!
2025年12月28日
次の記事
Epson Tour完全ガイド：LPGAへの登竜門としての歴史・仕組み・観戦ポイントNew!!
2025年12月28日