Codex trouble guide

Codex作業後に500エラーが出た時の確認

Codex作業後に500エラーが出た時の確認方法を整理します。PHPエラー、.htaccess、構文ミス、ログ確認、すぐ戻す判断を扱います。

このページは非公式の実務ガイドです。重要な判断は人間が行い、最新情報は提供元の情報も確認してください。

trouble-check.md

stop:
  - unclear_cause
  - risky_change
check:
  - public_url
  - changed_files
  - rollback_scope

このページで分かること

Codex作業後に500エラーが出た時の確認方法を整理します。PHPエラー、.htaccess、構文ミス、ログ確認、すぐ戻す判断を扱います。

ページが真っ白になる、Internal Server Errorが出る、HTMLではなくサーバー側の処理や設定変更後に表示できない状態です。

500エラーの鉄則は「調べるより先に、戻せるかを考える」です。原因究明に時間をかけている間、サイトは止まり続けます。バックアップがあるなら、まず直前の状態に戻して復旧させ、原因調査は落ち着いてから行うのが正解です。

確認	やり方	そこから分かること
直前に変更したファイルを確認	作業ログ・バックアップと突き合わせ、最後に触ったファイルを特定	500は「直前の変更」が原因のことが圧倒的に多い
.htaccessを触っていないか	変更一覧に.htaccessが含まれるか確認	.htaccessの1文字のミスでもサイト全体が500になる。最有力容疑者
PHP等の構文ミスがないか	変更したPHPファイルの構文チェック（php -l など）	閉じ忘れ・セミコロン抜けなど、機械的に見つかるミス
エラーログを確認	サーバーのエラーログで該当時刻のメッセージを見る	原因ファイルと行番号が直接書かれていることが多い
戻す判断を先にする	バックアップからの復元にかかる時間と、調査時間を比較	復旧が5分で済むなら、調査より復旧が先

静的HTML中心のサイトで500が出た場合は、ほぼ.htaccessかサーバー設定です。逆にHTMLファイルの中身だけを変えた作業で500は基本的に起きないので、「触っていないはずの設定ファイルが変わっていないか」を疑ってください。

Codex作業後に500エラーが出ています。直前に変更したファイル、構文ミス、.htaccess、ログ、戻すべき範囲を確認し、危険なら修正を続けず停止して報告してください。

500エラーは、404と違ってサイト全体が見られなくなることがあります。優先度の考え方が他のトラブルとは異なります。

3行目が重要です。500が出ている間は、原因究明より復旧が優先です。直前に触ったファイルを元に戻せば、多くの場合その場で復旧します。原因は、正常な状態に戻してから落ち着いて調べれば済みます。

500は「サーバー側で処理に失敗した」という意味なので、原因はファイルの中身か設定にあります。

切り分けのコツは、「直前に何をしたか」から逆算することです。500は突然自然発生するものではなく、何かの変更が引き金になっています。心当たりがない場合でも、自動処理が動いた可能性を含めて、直近の変更を確認してください。

500は影響が大きいため、原因がすぐ特定できない場合は直前変更を戻す判断を優先します。