Redis キャッシュに御用心・Wordpress管理の落とし穴
先日、運営していたWordPressサイトで恐ろしい事態が発生しました。
wp-login.phpにアクセスすると
「このページを表示する権限がありません。」の表示（ログで見る限りは 500 エラー）
が発生し、管理画面に一切アクセスできなくなったのです。
しかも厄介なことに、一般のサイト訪問者には全く影響なし。サイト自体は正常に表示されるため、問題に気づくのが遅れてしまいました。
最初の勘違い：プラグインが原因？
やってみたけど効果なしの対処法
エラーログを見ると、こんな警告が出ていました：
PHP Notice: Function _load_textdomain_just_in_time was called incorrectly.
Translation loading for the check-email domain was triggered too early.
「あー、check-emailプラグインの問題ね」と思って：
- ✗ check-emailプラグインを無効化（フォルダごと移動）
- ✗ wp-cliをインストールして調査
- ✗ WordPress のDEBUGオプションを有効化
全部ダメ。まったく効果ありませんでした。
意外な犯人：Redisキャッシュプラグイン
諦めかけた時、ふと思い立って Redisキャッシュプラグインを無効化してみたところ...
あっさり解決！
管理画面にスムーズにログインできるようになりました。
なぜこんなことが起きたのか？
真の原因：サーバー管理の落とし穴
調査を進めた結果、根本原因が判明しました：
php-pecl-redis拡張機能がサーバーから消えていた
おそらく以下のような経緯だったと推測されます：
- セキュリティアップデートでRedis拡張機能に問題発生
- システム管理者が安全のため拡張機能を削除
- 削除後の動作確認が不十分
- WordPressは動き続けるが、管理機能だけ死亡
なぜ気づきにくいのか？
この問題の恐ろしいところは：
- 一般ページは正常表示 → 通常の監視では検出不可能
- 管理画面のみ影響 → 管理者しか気づかない
- WordPressのDEBUGが役に立たない → ログに有用な情報が出ない
WordPressの設計上の問題点
キャッシュシステムの危険な仕様
今回の件で分かったWordPressの構造的問題：
1. 初期化タイミングの問題
WordPress読み込み順序：
1. wp-config.php
2. object-cache.php（Redisがここで動く）← 問題発生箇所
3. 認証システムの初期化 ← 手遅れ
2. エラーハンドリングの欠如
- キャッシュが死んでもエラーメッセージが出ない
- 認証エラーとして表示されるため原因が分からない
- 緊急回避手段が用意されていない
他の人も同じ問題で困っている？
興味深いことに、Google検索でこの組み合わせの問題を調べてもほとんど情報が見つからないんです。
これは以下の理由が考えられます：
- 環境固有の問題で発生例が少ない
- 管理者しか気づかないため報告されにくい
- Redis拡張機能の依存関係が複雑で原因特定が困難
予防策：同じ轍を踏まないために
サーバー管理で気をつけること
システム更新後のチェックリスト：
- 管理画面へのログイン確認
- 必要なPHP拡張機能の動作確認
- キャッシュシステムの接続テスト
- エラーログの確認
WordPress側の対策
安全なキャッシュ設定：
// wp-config.php での除外設定例
// ログインページはキャッシュしない
if (strpos($_SERVER['REQUEST_URI'], 'wp-login.php') !== false) {
define('WP_CACHE', false);
}
まとめ：隠れた時限爆弾に要注意
今回の問題は：
- サーバー管理の不備 × WordPressの構造的脆弱性 の組み合わせ
- 一般ページは正常なので発見が遅れる
- 標準的な監視方法では検出不可能
- 復旧にはサーバーレベルの知識が必要
教訓：Redisなどのキャッシュシステムを使っている場合は、システム更新後に必ず管理画面の動作確認を行いましょう。そして可能であれば、管理画面アクセスの監視も導入することをお勧めします。
最後に
この問題、意外と他の人も遭遇している可能性があります。もし同じような症状で困っている方がいたら、一度キャッシュプラグインを疑ってみてください。
WordPressのキャッシュ周りはまだまだ改善の余地がありそうですね。開発コミュニティでの議論が活発になることを期待しています！
Discussion