大東 信仁（ものくろ） 
お手伝いしているWordPressのサイトが、朝、全ページ 503 になっていました。
きっかけは、深夜に自動で入った WordPress 7.1.3。
サーバーのPHPは 8.2。
PHPを 8.2 から 8.3 系 に切り替えたら、復帰しました。
プラグインを全部止めても、テーマを外しても、直らなかったんです。
同じ症状の方の参考になればと思い、切り分けの流れを残しておきます。
「アクセスが大量に発生」と書いてある503
ブラウザで開くと、エックスサーバーの青い503のページ。
「アクセスが大量に発生しているための一時的なエラーです」と書いてあります。
全部のURLが503の表示。
調べものは、Claude Code と一緒に進めました。
Claude Code の最初の見立ては、「WordPressに届く前に、サーバーがアクセス集中で止めている」というもの。
僕は、WordPressが原因だと思いました。
結果は、僕が当たりでした。 AIより長年の経験と勘が活きました。
robots.txt も、存在しないURLも、実はWordPressが処理しています。
なので、WordPressが落ちると、まとめて503に見えるんですよね。
画面の文言だけで、アクセス集中と決めつけないほうがいいです。
静的なファイルは表示できた
切り分けの最初の一手は、WordPressを通らないファイルを開いてみること。
wp-includes の中の CSS や JS、readme.html、license.txt は、ちゃんと表示されました。
wp-content/index.php のような、WordPressを読み込まない小さなPHPも、動いていました。
落ちるのは、WordPressを読み込んだときだけ。
サーバーが止まっているわけではない、ということです。
エラーログを見ると、深夜2時22分から全部落ちていた
エックスサーバーのサーバーパネルで「エラーログ」を開きました。
前日までは、PHPの「Deprecated」（非推奨の書き方を知らせる警告で、表示には影響しないもの）が並んでいるだけ。
それが、午前2時22分27秒 から、閲覧が全部このエラーに変わっていました。
AH01067: Failed to read FastCGI header
(104)Connection reset by peer: AH01075: Error dispatching requestPHPが、エラーメッセージを書く間もなく、途中で落ちている状態です。
そのため、ログにはプラグイン名も、ファイル名も出てきません。
WordPress本体が自動更新されていた
ファイルマネージャで、ファイルの更新日時を見ていきました。
wp-includes の中の version.php、post.php、class-wp-query.php などと、readme.html が、10月7日 02:22 になっていました。
前日の10月6日に公開された、WordPress 7.1.3（メンテナンスとセキュリティのリリース）です。
これが、深夜に自動で入っていました。
エラーが始まったのは、その1秒後。
一方で、plugins フォルダの中は、いちばん新しいもので10月3日。
プラグインは、今回は更新されていませんでした。
プラグインを全部止めても、直らない
7.1.3 で、世界中のWordPressが落ちているとは考えにくい。
なので、更新された本体と、どれかのプラグインの相性を疑いました。
ファイルマネージャで、wp-content/plugins を plugins_off に名前変更。
これで、プラグインは全部止まります。
が、503のまま。
そして、プラグインをフォルダ名を変更して止めている間は、管理画面（wp-admin）を開かないこと、プラグインの設定が「無効」に書き換えてしまい、止まってしまいます。
mu-plugins も、テーマも外したけど、直らない
plugins フォルダの外に、mu-plugins というフォルダがあります。
ここに置かれたファイルは、プラグインを止めても、毎回読み込まれます。
このサイトでは、Plugin Load Filter の部品（plf-filter.php）が入っていました。
WordPressのかなり深いところで動く仕組みなので、これが怪しいと思いました。
mu-plugins を mu-plugins_off に変更。
503のまま。
最後に、テーマのフォルダ（親テーマと子テーマ）も名前を変えました。
それでも、503のまま。
WordPressを起動したところで落ちていた
ここで、更新された本体のファイルを、1つずつ直接開いてみました。
version.php も post.php も class-wp-query.php も、ちゃんと開けます。
ファイルが壊れているわけではない。
データベースを使わない入口（管理画面のCSSやJSをまとめて返す load-scripts.php など）も、動いていました。
でも、wp-load.php と wp-config.php を開くと、落ちる。
プラグインもテーマも外した状態で、データベースにつないでWordPress本体を起動したところで、PHPが落ちていたわけです。
残りは、PHPでした。
PHPを8.2から8.3系に切り替えたら、復帰した
サーバーパネルの「PHP Ver.切替」で、このサイトのPHPを 8.2 から 8.3 系 に変更。
ログイン画面も、robots.txt も、すぐに表示されるようになりました。
ホッとしました。
8.2 で落ちた理由までは、突き止めていません。
8.3 系で安定しているので、このまま使っていきます。
元に戻すときの注意
名前を変えたフォルダは、1つずつ戻して、そのたびに表示を確認しました。
順番は、テーマ、mu-plugins、プラグイン。
どれを戻しても、問題なく表示されました。
ここで大事なのが、全部戻し終わるまで、管理画面（wp-admin）を開かないこと。
プラグインのフォルダが無い状態で管理画面を開くと、WordPressが全プラグインを「無効」に書き換えてしまいます。
そうなると、戻したあとに、1つずつ有効化し直すことになります。
なお、フォルダの名前変更は、本番サイトを直接触る作業です。
必ずバックアップを取ってから、自己責任で行ってください。
まとめ
止まっていたのは、午前2時22分ごろから、9時前までの、約6時間半。
WordPressの自動更新は、セキュリティのためにありがたい仕組みです。
今回は、PHPを 8.2 から 8.3 系に切り替えたら、復帰しました。
プラグインやテーマを外しても直らないときは、PHPのバージョンを切り替えてみる、という手もあります。
