Webサイトのお助け隊

サイトを開くと「500 Internal Server Error」とだけ書かれた画面が出て、管理画面にも入れない。ページによっては出たり出なかったりする。この画面は、サーバーが「処理の途中で止まった」と言っているだけで、なぜ止まったのかは書かれていません。理由が残っているのはエラーログのほうです。そして原因の候補はそれほど多くなく、頻度の高いものから順に潰していけば、たいていは短時間で場所が特定できます。復旧を請けた案件で実際に当たった原因を、確認の順番どおりに並べます。

推測の前に、ログを出す

最初にやるのはログの確保です。多くのレンタルサーバーには管理画面にエラーログの項目があり、直近のエラーが時刻付きで残っています。落ちた時刻の前後だけを見れば、ファイル名と行番号まで書かれていることがほとんどです。ここを見ずに設定をいじり始めると、原因が2つに増えるだけになります。

WordPress側でログを出すなら、wp-config.php に WP_DEBUG と WP_DEBUG_LOG を有効にし、WP_DEBUG_DISPLAY を false にします。エラーは画面ではなく wp-content/debug.log に書き出されます。公開中のサイトで画面に出す設定にすると、訪問者にファイルパスまで見えてしまうので、表示は切ったままログだけ取ります。ログの読み方はエラーログの見方と手順の側にまとめました。

ここで一つ分岐があります。ログに何も出ていない場合、PHPまで処理が届いていない可能性が高いということです。PHPが動いてから落ちたなら、たいていは何か残ります。何も残らないなら、その手前、つまりWebサーバーの設定や .htaccess、ファイルの権限を疑う段階に移ります。ついでに書いておくと、真っ白な画面と500は別の症状です。白い画面はPHPが動いた上で何も出力していない状態で、原因の探し方も変わります。詳しくはWordPressが真っ白になる原因と切り分け手順のほうを見てください。

.htaccess は真っ先に外して確かめる

500の原因として最も多いのが .htaccess です。書き方を1文字間違えただけでも、そのディレクトリ以下がまるごと500になります。切り分けは簡単で、.htaccess を _htaccess のような別名にリネームし、トップページを開き直すだけです。表示が戻れば犯人はこのファイルで、戻らなければ別を当たります。リネームしたあとにパーマリンクが効かなくなりますが、管理画面に入って設定のパーマリンクを保存し直せば、WordPressが標準の記述を書き戻します。

特に多いのが、PHPの設定を .htaccess に書き足した直後のケースです。画像のアップロード上限を上げたいという相談で、php_value upload_max_filesize 512M のような行を .htaccess に書く方法が広く紹介されていますが、この書き方が使えるのはPHPがApacheのモジュールとして動いている環境だけです。CGIやFastCGI、LiteSpeedで動いている環境では、この1行でサイト全体が500 Internal Server Errorになります。設定を書いたら必ずフロントページを開いて確認する、という手順にしておけば、原因不明の障害にはなりません。

サーバーを移した直後の500も、このファイルが絡みます。旧サーバーの絶対パスを指したままの記述が残っていると、移設先ではそのパスが存在しないため落ちます。移行のチェック項目に「.htaccess の中の絶対パス指定を書き換える」を入れておくと防げます。

PHPの設定は、効いている値を見る

メモリ不足でも500は出ます。ログに Allowed memory size of ... exhausted と出ていれば確定です。ここで確認したいのは、設定した値ではなく実際に効いている値のほうです。

管理画面のログイン情報が手元になくても、<?php phpinfo(); ?> と書いた1ファイルをFTPで置けば、現在の値をブラウザで確認できます。見るのは Local Value と Master Value の2列です。Local Value が .htaccess や php.ini、サーバーの管理画面で指定して実際に効いている値、Master Value がサーバー本体の既定値です。この2列の違いを知らないと、数字が2つ並んでいてどちらが本物か分からなくなります。確認が終わったら、置いたファイルは必ず削除します。放置するとサーバー構成がそのまま外部に見える状態になります。

もう一点、共用のレンタルサーバーでは、php_value をどれだけ大きくしてもサーバー本体の上限を超えられないことがあります。メモリ上限に 2000M、実行時間に 0（無制限）といった指定を受け取ることがありますが、共用環境では効かないほうが普通です。設定は入れた、ただしサーバー側の制限が優先される場合がある、という前提で次の手も考えておきます。アップロード上限のように複数の値が絡む設定では、upload_max_filesize、post_max_size、memory_limit、max_execution_time が揃っていないと、いちばん小さい値に引きずられます。

設定ファイルに紛れ込んだ、たった1文字

「表示がおかしい」「ヘッダーに見覚えのない記号が出る」という症状から入って、最終的にサイトが止まった案件があります。原因は wp-config.php に混入した1文字でした。PHPの終了タグ ?> の後ろに文字があると、それはPHPのコードではなくHTMLとしてそのまま出力されます。ヘッダーより前に出力が始まってしまうため、リダイレクトやクッキーの処理が失敗し、環境によっては致命的なエラーになります。

この種の混入を疑う順番は決まっています。wp-config.php のPHPタグの外、テーマの functions.php の末尾、プラグインファイルの同じ場所、そしてBOM付きで保存されたPHPファイル。数文字の混入だけでサイト全体が止まるので、設定ファイルを編集したら差分を確認する習慣を持つのが確実です。編集前にコピーを取り、編集後に差分だけを見れば、この種の事故は一瞬で見つかります。

目に見えない文字が原因のこともあります。複製したPHPファイルだけが動かないという相談で、原因がNBSP（U+00A0）だった案件がありました。見た目は半角スペースと区別が付かず、エディタで眺めても分かりません。ブラウザ経由でコードをコピーして貼り付けると混入します。grep -nP 'xc2xa0' file.php でNBSP、grep -nP 'xefxbbxbf' でBOMを探せます。動くファイルと動かないファイルが両方あるなら、まず diff を取るのが最短です。この案件では、ファイルの権限表示が他と違うという見た目の差異に引きずられて調査が遠回りになりました。目立つ違いが原因とは限りません。

コアファイル、テーマ、プラグイン

ログのパスがWordPress本体のディレクトリを指しているなら、ファイルの取り違えを疑います。wp-includes/functions.php とテーマの functions.php は名前が同じで、FTPやファイルマネージャーで階層を見誤ると簡単に上書きできてしまいます。実際に本体側がテーマ用のコードで丸ごと置き換えられていた案件があり、このときは同じバージョンの正規ファイルで上書きするだけで復旧しました。原因の調査より、正規版に戻して直るかを先に試すほうが早い場面です。

プラグインが原因なら、wp-content/plugins/ の中の該当ディレクトリをリネームすれば無効化されます。どれか分からないときは plugins ごとリネームして全部止め、表示が戻ってから1つずつ有効化します。ファイルの権限が原因のこともあり、PHPファイルに書き込み権限を広く与えすぎている環境では、それだけで500を返す設定になっています。ファイルは644、ディレクトリは755が基本です。

症状から見る場所を決める

直ったあとに、もう一度やること

止めて表示が戻った時点で終わりにすると、同じ原因で再発します。プラグインを無効化して復旧した場合、なぜそのプラグインが落ちたのかは残ったままです。PHPのバージョンとの相性なのか、他のプラグインとの競合なのか、そこまで見て初めて再発が止まります。応急処置と根本の対処は別物として、後者を予定に入れておくのが安全です。

作業の進め方でひとつ決めておきたいのが、FTPやSSHが使えない状態で管理画面のファイルエディタからPHPを編集しないことです。編集した内容が原因で落ちれば管理画面にも入れなくなり、戻す手段がなくなります。接続手段がない環境では調査までにとどめる、という線引きにしています。

データベースに接続できない場合は、500ではなく別のメッセージが出ます。症状が違えば見る場所も変わるので、データベース接続確立エラーが出た時の手順のほうを参照してください。管理画面にだけ入れない、ログイン後にループするといった症状も、原因の系統が異なります。こちらはwp-adminに入れない時の対処にまとめています。

よくある質問

500エラーと503エラーは違うものですか

違います。500は処理の途中でエラーが起きたという意味で、原因はサイト側にあることがほとんどです。503はサーバーが一時的に応答できない状態で、アクセス集中やサーバー側の作業、リソース制限で出ます。共用サーバーで急に503が続く場合は、自分のサイトの問題ではないこともあるため、まずサーバー会社の障害情報を見るのが早道です。

サーバーの管理画面だけで直せますか

PHPのバージョンやメモリ設定が原因なら、サーバーの管理画面から戻すだけで復旧します。ただし .htaccess やPHPファイルの中身が原因の場合はファイルを触る必要があるため、FTPかファイルマネージャーが要ります。復旧の可能性を上げるという意味では、まずPHPのバージョンを直前の値に戻してみるのが、管理画面だけでできる中では効果の高い一手です。

復旧を依頼するとき、何を渡せば早いですか

サーバーのFTPまたはSSHの接続情報、WordPressの管理者アカウント、そして「落ちる直前に何をしたか」の3つです。3つめが特に効きます。更新したのか、設定を書き換えたのか、サーバーで何か操作したのか。ここが分かっていれば、確認する場所が最初から絞れます。心当たりがない場合でも、いつから見えなくなったかの時刻だけは伝えてください。ログを見る範囲が決まります。復旧の進め方は障害復旧の対応内容にまとめてあります。