Диагностика Redis Object Cache после миграции WordPress

Как понять, что проблема связана с Redis

На persistent object cache стоит обратить внимание, если после миграции часть сайта продолжает показывать старые данные, хотя соответствующие записи в базе уже изменены. Типичные примеры: старые настройки в админ-панели, прежняя конфигурация плагина, некорректное меню, ошибки входа или разное поведение сайта для разных пользователей.

При этом не каждая проблема с кешем связана с Redis. HTML-кеш на уровне веб-сервера, CDN, кеш страниц в плагине и кеш браузера работают по другим механизмам. Поэтому сначала нужно выяснить, использует ли WordPress именно persistent object cache.

• Проблема появилась сразу после смены сервера, домена или хостинга.
• После очистки кеша данные временно становятся корректными, но затем снова устаревают.
• В логах есть ошибки подключения к Redis: authentication required, connection refused или timeout.
• На новом сервере используются другие host, port, пароль, Unix-сокет или база Redis.
• На сайте остался object-cache.php, скопированный из старой установки.

Проверка persistent object cache в WordPress

Выполняйте команды из корневого каталога WordPress и от имени того же системного пользователя, под которым работает сайт или WP-CLI. Это важно: CLI может использовать другое окружение, другую версию PHP или другие переменные среды, чем PHP-FPM.

Команда wp cache type показывает тип активного object cache. Если используется persistent cache, обычно отображается соответствующий драйвер или плагин. Дополнительно проверьте наличие drop-in в каталоге wp-content.

• Файл wp-content/object-cache.php — это специальный drop-in WordPress, который загружается раньше многих обычных плагинов.
• Само имя файла не доказывает, что он относится именно к Redis: его могли создать разные кеш-плагины.
• Проверьте владельца, права доступа, дату изменения и фактическое содержимое файла.
• Если сайт работает в режиме multisite, проверяйте конфигурацию с учётом всей сети и команд, выполняемых для конкретного сайта.

wp cache type
ls -l wp-content/object-cache.php
file wp-content/object-cache.php
head -n 40 wp-content/object-cache.php

Что проверить в object-cache.php

Не редактируйте drop-in вслепую. Сначала определите, какой плагин его создал, и проверьте, есть ли в нём ссылки на классы Redis, константы или переменные для host, port, database и password. Одни плагины хранят эти параметры непосредственно в собственной конфигурации, другие читают их из wp-config.php или переменных среды.

Если drop-in остался от старого сервера, безопаснее переустановить или повторно активировать совместимый кеш-плагин согласно его документации, чем переносить файл вручную. Файл может относиться к другой версии плагина, содержать старый адрес Redis или требовать PHP-расширение, которого нет на новом сервере.

• Не копируйте object-cache.php из резервной копии, не проверив его источник.
• Не публикуйте в чатах и тикетах полный файл, если в нём есть пароль или токен.
• Проверьте, соответствуют ли версии PHP, плагина и Redis-клиента требованиям вашей конфигурации.

Проверка параметров подключения к Redis

После миграции сравните фактические параметры старого и нового окружения. Redis может работать на localhost, отдельном приватном хосте или через Unix-сокет. Также имеют значение порт, номер логической базы, пароль, пользователь ACL, TLS и имя сервиса контейнера.

Ищите эти значения в wp-config.php, файлах .env, конфигурации PHP-FPM, настройках кеш-плагина или переменных среды контейнера. Не предполагайте, что localhost означает одно и то же в разных окружениях: в Docker localhost внутри контейнера WordPress указывает на этот же контейнер, а не на контейнер Redis.

• Host: адрес или имя сервиса Redis.
• Port: стандартный порт не гарантирует, что именно он используется в вашем окружении.
• Database: номер логической базы Redis, если его задаёт клиент.
• Password или ACL: актуальные учётные данные и права пользователя.
• Socket или TLS: дополнительные параметры, которые могут отличаться после миграции.

grep -nE 'REDIS|WP_REDIS|CACHE' wp-config.php .env 2>/dev/null
redis-cli -h 127.0.0.1 -p 6379 ping

Как безопасно проверить доступ к Redis

Ответ PONG подтверждает, что Redis доступен по указанному адресу, но не гарантирует, что WordPress использует именно этот сервер или правильную базу. Если Redis защищён паролем или ACL, используйте способ авторизации, принятый в вашем окружении, и не передавайте секреты через историю shell-команд.

Ошибки connection refused и timeout обычно указывают на проблему с сетью, портом, firewall или неправильным host. Ошибка NOAUTH означает проблему с авторизацией. Если Redis доступен, но WordPress не подключается, проверьте PHP-расширение или библиотеку клиента, которые использует конкретный drop-in.

• Проверяйте Redis с сервера и от имени пользователя, под которым реально работает WordPress.
• Не открывайте Redis в публичный интернет только ради быстрой проверки.
• Если Redis используется несколькими сайтами, обязательно определите изоляцию ключей и баз.

Очистка кеша после изменения конфигурации

После исправления параметров подключения очистите object cache через WordPress и повторно проверьте сайт. Это удалит старые объекты, которые могли сохраниться в правильной или неправильной базе Redis.

Команда wp cache flush может зависеть от активного object-cache drop-in. Если drop-in не работает или WordPress не может загрузить его из-за ошибки PHP, команда может завершиться с ошибкой. В такой ситуации сначала восстановите совместимый драйвер или временно отключите drop-in.

wp cache flush
wp cache type

Почему не стоит сразу запускать FLUSHALL

Команда FLUSHALL удаляет все ключи из всех Redis-баз конкретного Redis-сервера. Если один экземпляр используется несколькими сайтами, очередями или другими сервисами, это может вызвать проблемы далеко за пределами текущей миграции.

Даже FLUSHDB следует выполнять только после подтверждения, что выбранная база принадлежит нужному сайту. Сначала используйте wp cache flush или штатный механизм очистки плагина. Для общего Redis согласуйте очистку с администратором инфраструктуры и проверьте политику изоляции ключей.

• Не используйте FLUSHALL в production, не понимая чётко возможных последствий.
• Не очищайте Redis во время пиковой нагрузки без плана наблюдения.
• После очистки проверьте авторизацию, админ-панель, меню, корзину и критически важные формы.

Временное отключение Redis для локализации проблемы

Если сайт продолжает показывать старые данные или возникают ошибки, временно отключите object-cache drop-in. Перед этим создайте резервную копию файла и убедитесь, что у вас есть доступ к серверу. Переименование не удаляет файл и позволяет быстро вернуть его обратно.

После отключения проверьте сайт в приватном окне или с очищенной сессией. Просмотрите именно те действия, которые раньше вызывали проблему: вход, сохранение настроек, изменение меню, обновление записи или работу плагина.

cp wp-content/object-cache.php wp-content/object-cache.php.backup
mv wp-content/object-cache.php wp-content/object-cache.php.disabled
wp cache type

Как интерпретировать результат

Если без drop-in проблема исчезла, причина почти наверняка связана с конфигурацией Redis, несовместимым кеш-плагином, ошибкой клиента или оставшимся файлом object-cache.php. Это не означает, что Redis нужно отключить навсегда: после диагностики установите совместимую конфигурацию и повторно протестируйте сайт.

Если проблема сохраняется, ищите её в page cache, CDN, PHP-коде, базе данных, cookies или другом плагине. Возврат drop-in без проверки не поможет и может снова скрыть актуальные изменения.

• Возвращайте файл только после проверки его происхождения и параметров.
• После возврата очистите кеш и повторите функциональные тесты.
• Не оставляйте резервные копии с паролями доступными из web-каталога.

mv wp-content/object-cache.php.disabled wp-content/object-cache.php

Логи и типичные ошибки после миграции

Если базовые проверки не дали ответа, просмотрите журналы PHP-FPM, веб-сервера, контейнеров и самого кеш-плагина. Обратите внимание на время возникновения ошибки и сравните его с действиями в админ-панели. Одно сообщение в логе может относиться к другому процессу, поэтому важно проверять контекст.

Отдельно обратите внимание на права доступа. WP-CLI может запускаться от имени одного пользователя, а PHP-FPM — другого. В результате CLI видит одни переменные среды или имеет доступ к сокету Redis, а веб-запрос — нет.

• Connection refused: Redis не слушает указанный адрес или доступ блокирует firewall.
• Could not connect или timeout: ошибка маршрутизации, DNS, сети или неправильный host.
• NOAUTH или authentication required: неправильный пароль, пользователь ACL или отсутствующий параметр авторизации.
• Class not found или extension missing: на новом сервере нет необходимого PHP-расширения или библиотеки.
• Старые данные без ошибок: WordPress может подключаться к другому, но доступному экземпляру Redis.

Финальный чек-лист после восстановления

После исправления не ограничивайтесь проверкой главной страницы. Persistent object cache может влиять на разные части WordPress, включая настройки, пользователей, меню, запросы и данные плагинов.

Проведите контрольную проверку в том же окружении, где работают реальные пользователи, и убедитесь, что после повторного деплоя или перезапуска PHP-FPM конфигурация не исчезает.

• wp cache type показывает ожидаемый тип кеша.
• object-cache.php принадлежит нужному плагину и не содержит старых адресов или секретов.
• WordPress и PHP-FPM используют одинаковые host, port, database и параметры авторизации.
• wp cache flush завершается без ошибок.
• Проверены вход, выход, сохранение настроек, меню, записи и ключевые функции сайта.
• В логах не появляется новых ошибок Redis после нескольких реальных запросов.
• Redis не очищался глобально, если на этом экземпляре работают другие сайты или сервисы.