500 Internal Server Error

このエラーの意味と見分け方

• ブラウザに、空白のページ、汎用的なページ、またはブランド固有の 500 Internal Server Error ページが表示される。
• それまで正常に動作していたページが、コード編集、プラグインやテーマのインストール、更新、デプロイ、設定変更の後に失敗する。
• サイトの他の部分は利用できる一方で、特定のURL、フォーム、管理画面、またはサイト機能だけが失敗する。
• PHP、アプリケーション、またはWebサーバーのログに、同じ時刻の致命的エラー、構文エラー、権限問題、依存関係の不足、リソース制限による失敗が記録される。
• リクエストを繰り返すと同じ500レスポンスが返る。ただし、リソース制限やアプリケーションの依存先が関係している場合は、一時的な障害が発生することもある。

可能性の高い順の主な原因

1. アプリケーションコード、プラグイン、テーマ、モジュールの障害 — 構文エラー、致命的エラー、互換性のない更新、または未処理の状態によって、リクエストを完了できなくなることがあります。
2. Apache設定の不備 — .htaccess内の形式不正または非対応のディレクティブや、無効化されたモジュールを必要とするルールによって、500レスポンスが発生することがあります。.htaccessはApacheベースの構成に適用されるもので、すべてのWebサーバーで使用されるわけではありません。
3. ファイルまたはディレクトリの権限・所有者の誤り — 手動アップロード、移行、デプロイによって、Webプロセスが必要なファイルを読み取れない状態になることがあります。
4. PHPのメモリまたは実行時間の枯渇 — 大規模なインポート、負荷の高いクエリ、リソースを大量に消費する拡張機能によって設定済みの制限を超えることがあり、その際に500を返す環境もあります。
5. デプロイ設定または依存関係の不足 — 変更されたデータベース認証情報、存在しない環境変数、利用できないパッケージ、互換性のないランタイムによって、アプリケーションが動作しなくなることがあります。
6. アプリケーションまたはCMSファイルの欠落・破損 — 更新が途中で中断すると、必要なコアファイルが欠落または破損することがあります。

修正方法

1. 範囲と発生時刻を確認する

500を返す正確なURLを再読み込みし、タイムゾーンを含む時刻を記録します。サイト全体が失敗しているのか、特定のルート、フォーム、管理画面、プラグイン機能、リクエスト種別だけが失敗しているのかを確認します。特定機能だけの障害であれば、その機能に関連する最近のコードや依存関係がより疑わしくなります。サイト全体の障害であれば、サーバー設定、デプロイ、コアファイルの問題である可能性が高くなります。

2. まず関連するログを確認する

ホスト上で利用できるPHPのerror_log、Webサーバーのエラーログ、アプリケーションまたはCMSのログを確認します。一般的な場所として、Apacheでは/var/log/apache2/error.log、Nginxでは/var/log/nginx/error.logがありますが、ホスティング環境によって異なります。エントリを障害発生時刻と照合し、ファイル、行番号、例外、上流サーバーからのメッセージ、設定ディレクティブを記録します。ブラウザに表示される汎用ページだけでは、原因を特定できません。

3. 最近のコードまたは拡張機能の変更を切り分ける

ログでファイル、プラグイン、テーマ、モジュール、デプロイの変更が特定された場合は、テスト可能な環境でその変更を元に戻すか、該当コンポーネントを無効にします。CMSでは、利用可能であれば管理画面を使用します。管理画面にアクセスできない場合は、SFTPまたはホスティングのファイルマネージャーで、該当コンポーネントのディレクトリ名を変更できることがあります。一度に1つのコンポーネントだけを変更し、失敗したURLを再テストします。エラーが解消した場合は、再度有効にする前に互換性、設定、利用可能な更新を調査します。

4. Apacheの場合のみ.htaccessをテストする

ログが.htaccessの解析エラーを示している場合、またはApacheルールの変更後に障害が始まった場合は、バックアップを作成し、SFTPまたはホスティングのファイルマネージャーで一時的に.htaccessを.htaccess.bakへ変更します。ページを再テストします。動作する場合は、ファイルを慎重に復元または作り直し、カスタムディレクティブを段階的に追加します。非対応のディレクティブや、Apacheモジュールの不足が根本原因である可能性があります。.htaccessをリクエスト設定に使用しないNginxのみの構成には、この手順を適用しないでください。

5. 権限と所有者を慎重に修正する

ログが権限または所有者のエラーを報告している場合は、対象パスを正常に動作するファイル、またはホスティング事業者が公開している設定と比較します。ファイルの644、ディレクトリの755は一般的な設定ですが、正しい値はホストとデプロイ方式によって異なります。SFTP、SSH、またはホスティングのファイルマネージャーで対象パスを修正し、近道としてファイルやディレクトリを誰でも書き込み可能な状態にしないでください。

6. PHPとアプリケーションのリソース制限を調査する

ログにメモリ不足、最大実行時間、または同様の制限が記録されている場合は、大規模なインポートや負荷の高いプラグイン処理など、リソースを消費している操作を特定します。ホストで許可されている場合に限り、該当するphp.ini、.user.ini、ホスティング設定、またはデプロイ設定でmemory_limitやmax_execution_timeを調整します。同時に、処理量を減らすか非効率な処理を修正してください。制限を引き上げるだけでは、障害を先送りするだけになる可能性があります。

7. デプロイ設定と必要なファイルを比較する

デプロイや移行の後に障害が始まった場合は、環境変数、データベース認証情報、ランタイムのバージョン、インストール済みの依存関係、ファイルパス、生成された設定を正常な環境と比較します。必要なファイルが存在し、アプリケーションが設定済みのデータベースまたはサービスに接続できることを確認します。無関係な設定を変更するのではなく、ログに記録された不足している変数、パッケージ、接続エラーを調査の出発点にします。

8. 証拠を保存してから破損ファイルを復元する

更新の中断またはコアファイルの破損が示唆される場合は、修復前に関連ログと現在のファイルのコピーを保存します。その後、正常なファイルを復元するか、利用可能であればバックアップを使用して、プラットフォームがサポートする更新プロセスを再実行します。元のURLを再テストし、一致する新たなエラーがログに記録されていないことを確認します。

予防と修正確認

• プラグイン、テーマ、モジュール、CMSコンポーネントをインストールまたは更新する前に、ファイルとデータベースの両方をバックアップします。
• 可能であれば、コードや.htaccessの変更をステージング環境でテストし、ロールバック用に正常な設定を保持します。
• 環境間で設定変数と依存関係を一貫してデプロイし、移行後に必要なファイルを確認します。
• 外部からの稼働監視だけに頼らず、PHP、アプリケーション、Webサーバーのエラーログを監視します。
• 一度に1つだけ変更し、変更内容を記録して、失敗した正確なURLを再テストします。
• 本番サイトでは、詳細な診断情報を訪問者に表示せず、サーバー側のログに記録します。

よくある質問