こんにちは。たいら(@tairaengineer2)です。
ConoHa WINGで運営している複数のWordPressサイトで、突然
|
1 |
507 Insufficient Storage |
というエラーがでました。
この記事では、時系列で
- 何が起こったか
- どういう調査をしたのか
- 何が原因だったのか
を書いていきます。
- 2026年8月6日：507エラー発生
- 2026年8月8日：507再発
- 2026年8月9日：複数サイトで507＋DB接続エラー
- 2026年8月10日：WordPress作業中にも507
- 2026年8月10日：ConoHa側から重要な情報
- 2026年8月10日：SSHでファイル調査
- 2026年8月12日：Broken Link Checkerが浮上
- 2026年8月12日：Broken Link Checker 2.4.9の不具合と一致
- 2026年8月12日：Broken Link Checker停止
- 2026年8月12日：Broken Link Checker停止後、サイトが明らかに安定
- 2026年8月12日：ただし、停止後にも507が発生
- 2026年8月13日：507が0件
- 2026年8月13日：WordPress 7.0.4へ自動更新
- 2026年8月14日：507 0件を継続
- 2026年8月14日：ABSPATHエラーをアクセスログと突合
- 2026年8月14日：最終的な判断
- おまけ：今回ChatGPTを使って感じたこと
2026年8月6日：507エラー発生
ConoHa WINGで運営している複数のWordPressサイトで、突然
|
1 |
507 Insufficient Storage |
が表示されるようになりました。
しかも、同じConoHa WING環境上の複数サイトで、です。
その影響ですべてのサイトで
- サイト表示
- 記事更新
- 画像アップロード
- 管理画面操作
ができたり、できなかったりブログ運営に支障をきたしました。
507は、サーバーにリクエストを処理するための十分な容量やメモリがないことを示すHTTPステータスコードです。
なので、Conoha Wingにログインしてこの時点でディスク使用量を確認したところ、
約219.96GB / 500GB
だったので、容量オーバーなのは考えにくいと判断。
原因を特定するべく、ConoHaへ問い合わせました。
初回回答をまとめると
サーバー側の障害は確認できない
ディスク容量にも余裕がある
WordPress本体、プラグイン、設定、不正アクセス等も含めたサイト側の要因が考えられるが、WordPress内部のコンテンツ調査自体はサポート対象外
という回答でした。
なぜ発生するのかの原因がこの段階では分かりませんでした。
2026年8月8日：507再発
01:46ごろ、再び507が再発しました。
一方のサイトが先に復旧するなど、発生・復旧のタイミングにもばらつきがありました。
同日の早朝にはBackWPupのバックアップ成功ログも確認しました。
このあたりから、
「常時壊れているわけではなく、何かのタイミングで一時的にサーバー処理が詰まっているのでは？」
という疑いが出てきます。
ただし、まだ証拠はありませんでした。
2026年8月9日：複数サイトで507＋DB接続エラー
再び複数サイトで507再発です。
さらに、とあるサイトでは一時的に
「データベース接続確立エラー」も発生です。
サーバーログでは、
|
1 2 3 |
autoindex:error authz_core:error Akismetのreadme.txtへのアクセス拒否 |
なども確認しました。
ただし、この時点では507との因果関係はわかりませんでした。
2026年8月10日：WordPress作業中にも507
09:35ごろ、複数サイトで507が発生です。
約10分前までは普通にWordPressの更新作業ができていたのに、507になってしまうというシーンが多発しました。
管理画面で記事を編集している最中にも突然507になるため、
「単にアクセスの多い時間帯だけ起きているわけではなさそう」
と考え始めました。
このころから、原因を切り分けるため、ブログ側の大きな変更はなるべく控えて調査を進めました。
2026年8月10日：ConoHa側から重要な情報
同日ConoHaから、507発生時について
Webサイトの同時処理数が上限に達しており、新たなリクエストを処理できない状態
という重要な回答をいただきました
ここで初めて、507の直接的な発生理由は「ディスク不足」ではなく、同時処理数の上限到達と分かりました。
ただし、
「では、なぜ同時処理数がそこまで増えたのか？」
はまだ不明でした。
ConoHaからは、複数の不審なファイルの存在や外部アクセスの可能性についても指摘があり、
- 不正アクセス
- 攻撃
- キャッシュ設定
- WordPress／プラグイン
などを調査することになります。
2026年8月10日：SSHでファイル調査
ConoHa WINGでSSH接続を設定してログを調査することにしました。
ここでは本番環境なので、基本的に
見るだけ。
使ったのも主に、
|
1 2 3 4 5 6 7 8 9 |
pwd ls find grep zgrep awk wc sed cat |
などの参照系コマンドだけです。
調べた範囲では即座に「改ざんされたファイル」と断定できるものは発見できませんでした。
最近更新されたPHPファイルも、多くはWordPress本体・プラグイン・言語ファイル等。
ConoHaには改めて、
「不審と判断した具体的なファイルパスと、どのようなスキャンで検出したのかを教えてほしい」
と問い合わせしました。
2026年8月12日：Broken Link Checkerが浮上
アクセスログを調べたところ、
|
1 |
WPMU DEV Broken Link Checker Local Engine |
というUser-Agentから、サイト内ページへのアクセスが大量に発生していました。
しかも、そのリクエストに対して507が返っている記録を発見。
さらにPHPエラーログを見ると、8月12日20時台に大量のエラー。
20:10〜20:19ごろのログ38件のうち、35件がBroken Link Checker関連でした。
決定的だったのがこれです。
|
1 2 3 |
WordPress database error Duplicate entry '' for key 'url_hash' for query ALTER TABLE wp_blc_links ADD UNIQUE KEY url_hash (url_hash) |
呼び出し元には、
|
1 2 |
blc_init blcDatabaseUpgrader::upgrade_database |
など、Broken Link Checkerの処理が並んでいました。
2026年8月12日：Broken Link Checker 2.4.9の不具合と一致
ここで使用中のBroken Link Checkerのバージョンを確認したところ、2.4.9でした。
調べると、Broken Link Checker 2.4.9では、DB更新時のurl_hash関連で問題が起きる事例があり、今回の
|
1 |
Duplicate entry '' for key 'url_hash' |
とかなり近かったです。
こちらのスレッドをご参考ください。
その後のバージョンではDBアップデート関連の修正も行われていました。
ここで、
Broken Link Checker 2.4.9がDBのアップグレード処理を繰り返し、負荷を上げているのでは？
という有力な仮説が立ちます。
2026年8月12日：Broken Link Checker停止
Broken Link Checkerを導入しているサイトで、プラグインを停止しました。
以降、調査条件を変えないため、アップデートして再有効化することはせず、停止したまま観察することにしました。
「最新版に更新したら直りました！」をやると、
- 停止したから直ったのか
- アップデートしたから直ったのか
分からなくなるので、まず停止だけ実施しました。
2026年8月12日：Broken Link Checker停止後、サイトが明らかに安定
Broken Link Checker停止後、
- サイト表示
- 記事更新
- 画像アップロード
- 管理画面操作
が普通にできるようになり、サイトが明らかに安定しました。
そして、
BLC由来のPHPエラーは8月12日20:57以降0件。
ここでかなり
「BLC怪しいぞ」
となりました。
2026年8月12日：ただし、停止後にも507が発生
ログを確認したところ8月12日23:33〜23:34ごろ、Broken Link Checker停止後にも507が25件発生していました。
なので、
Broken Link Checkerを停止したら507は100%消えた
とは言えません。
この時間帯のアクセスログを分析すると、IP
34.125.xxx.xxx
から約2分間に264リクエスト。
内訳は概ね、
- 404：205
- 507：25
- 200：17
- 403：15
- 301：2
アクセス先は、
|
1 2 3 4 5 6 |
/wp-config.php /config/database.yml /.flaskenv /config/master.key AWS関連設定 service-account関連 |
など。
明らかにWordPressだけを見ている通常のユーザーではなく、様々なWebアプリの機密ファイルを探している自動スキャンでした。
User-Agentも、
- ChatGPT-User
- Amazonbot
- Google-Extended
- ClaudeBot
- GPTBot
などを短時間に切り替えていたため、正規の各Botが一斉に来たというより、User-Agentを偽装したスキャナの可能性が高いと判断。
507は、
- 23:33:52 → 3件
- 23:34:06 → 7件
- 23:34:19 → 11件
- 23:34:32 → 4件
のように短時間に集中です。
その後は再び404や200を返せる状態に戻っていました。
つまり、
外部からの大量アクセスでも同時処理数の上限に達する可能性
が確認できました。
2026年8月13日：507が0件
翌日のアクセスログを確認したところ、507は0件でした。
Broken Link Checker関連PHPエラーもなく、サイトも正常に操作できました。
2026年8月13日：WordPress 7.0.4へ自動更新
この観察中に、すべてのサイトのWordPressが7.0.4へ自動更新されました。
そのため厳密には、BLC停止だけが環境変化ではなくなりました。
ただし後日ConoHaから、WordPress 4.7.0〜7.0.3に影響する脆弱性について案内があり、7.0.4は修正版だったことを確認しました。
なので、この自動更新を戻すようなことは当然しませんでした。
2026年8月14日：507 0件を継続
8月14日も、
- 507：0件
を確認できました。
Broken Link Checker関連エラーも引き続き0件でした。
ただし、PHPエラーログに3件のFatal errorが記録されていたため、内容を確認しました。
|
1 |
Fatal error: Undefined constant "ABSPATH" |
が記録されていました。
対象は/wp-settings.phpへの直接アクセス。
2026年8月14日：ABSPATHエラーをアクセスログと突合
エラー時刻とアクセスログを照合したところすべて、
外部IPが/wp-settings.phpを直接GETしていた時刻と完全一致しました。
さらに同じIPは、
|
1 2 3 |
/k.php /profile.php /shell.php |
など、多数の怪しいPHPファイル名を試していたことも確認できました。
つまり、このABSPATHエラーも
WordPressが通常動作中に壊れて発生したものではなく、外部スキャナがWordPressコアファイルを直接叩いたことで出たもの
と判断しました。
2026年8月14日：最終的な判断
ここまでの調査から、
Broken Link Checker 2.4.9の不具合によってサーバー負荷が増大し、同時処理数の上限に達しやすい状態になっていた可能性が高いと考えています。
ただし、プラグイン停止後にも外部からの大量アクセス時に507が発生しているため、すべての507がBroken Link Checkerだけによって発生したとは断定できません。
と結論付けました。
ConoHaへ調査協力へのお礼と一連の経緯を連絡し、調査を終了しました。
なお、Broken Link Checkerはいまだに停止中ですｗ
おまけ：今回ChatGPTを使って感じたこと
今回の調査では、SSHコマンドの作成やログの分析、原因候補の整理だけでなく、「次に何を確認するか」「この操作は本番環境で実行して大丈夫か」「どこまで断定してよいか」といった判断にもChatGPTをかなり活用しました。
自分は提案された内容を確認しながら実際の環境で操作し、結果をまたChatGPTに返して次の調査につなげる、という形で進めました。
1人で調べていたらかなり時間がかかったと思うので、AIを使った障害調査のスピードには正直かなり驚きました。
改めて生成AIというか、ChatGPTがすごいなと感心しました。
コメント