Error establishing a Redis connection в WordPress: как мы восстановили сайт на Beget

Redis: Включен

Несмотря на зелёный статус, журнал WordPress подтверждал, что в момент сбоя Redis не принимал подключения.

Удалось ли установить точную причину

Нет, точную внутреннюю причину остановки Redis установить не удалось.

Для этого потребовались бы серверные журналы самого процесса Redis и инфраструктуры Beget. Владелец обычного хостингового аккаунта не всегда имеет к ним доступ.

Мы можем уверенно сказать только следующее:

• WordPress использовал правильный адрес и порт;
• Redis не принимал подключение;
• превышения памяти Redis по статистике не было;
• после перезапуска сервиса соединение восстановилось.

Поэтому корректная формулировка причины выглядит так:

Сайт стал недоступен из‑за отказа соединения с Redis. В момент ошибки процесс Redis не принимал подключения на 127.0.0.1:6379. Точная причина остановки или зависания процесса не была установлена.

Нельзя утверждать, что Redis остановился из‑за переполнения памяти или накопления ключей: подтверждений этому не обнаружено.

Почему отказ Redis заблокировал весь WordPress

Redis использовался на сайте как постоянный объектный кэш через плагин Redis Object Cache.

Плагин создаёт файл:

/wp-content/object-cache.php

Этот файл загружается на очень раннем этапе запуска WordPress.

В результате цепочка выглядела так:

Запуск WordPress
↓
Загрузка object-cache.php
↓
Попытка подключения к 127.0.0.1:6379
↓
Connection refused
↓
Остановка WordPress

Таким образом, необязательный сервис кэширования превратился в критическую зависимость. Из‑за недоступности Redis перестали открываться:

• публичная часть сайта;
• административная панель;
• WordPress Cron;
• фоновые задачи;
• автоматизации плагинов.

Первый шаг: временно отключили Redis

Чтобы восстановить доступ к WordPress, через файловый менеджер Beget был открыт каталог:

/public_html/wp-content/

Файл:

object-cache.php

был переименован в:

object-cache.php.disabled

После этого WordPress перестал обращаться к недоступному Redis и смог загрузиться со стандартным объектным кэшем PHP.

Это действие не удаляет:

• базу данных;
• страницы и записи;
• пользователей;
• заявки;
• контакты FluentCRM;
• задачи Fluent Boards;
• настройки сайта.

Сайт просто временно начинает работать без Redis.

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

Второй шаг: перезапустили Redis в Beget

После восстановления доступа к сайту была открыта страница:

Beget → Сервисы → Redis

На ней Redis отображался включённым. Для фактического перезапуска процесса была нажата кнопка:

Перезагрузить

Перезапуск выполняет следующие действия:

1. Завершает старый или зависший процесс Redis.
2. Запускает новый процесс.
3. Заново открывает порт 6379.
4. Восстанавливает приём подключений.
5. Делает Redis доступным WordPress.

Именно перезапуск сервиса фактически восстановил работу Redis.

Изменения в конфигурации WordPress сами по себе не могли запустить остановленный процесс. Они были добавлены после перезапуска, чтобы явно закрепить правильные параметры подключения и улучшить управление кэшем.

Третий шаг: добавили настройки в wp-config.php

Настройки Redis добавляются не в redis.php, а в основной файл конфигурации WordPress:

/public_html/wp-config.php

Строки необходимо размещать до:

/* That's all, stop editing! Happy publishing. */

Для сайта была подготовлена следующая конфигурация:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

define('WP_REDIS_MAXTTL', 604800);

Адрес Redis

define('WP_REDIS_HOST', '127.0.0.1');

Указывает локальный адрес Redis, предоставленный Beget.

Порт Redis

define('WP_REDIS_PORT', 6379);

Должен совпадать с портом на странице сервиса Redis в Beget.

Уникальный префикс

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

Префикс отделяет ключи этого сайта от ключей других проектов.

Для каждого сайта необходимо использовать собственное значение:

define('WP_REDIS_PREFIX', 'client-site.ru:');

Нельзя копировать один префикс на несколько сайтов.

Ранее на сайте использовалась строка:

define('WP_CACHE_KEY_SALT', 'webmarketing-lab.ru_');

В актуальной версии Redis Object Cache эта настройка считается устаревшей. Вместо неё рекомендуется использовать:

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

Старую строку WP_CACHE_KEY_SALT после перехода на новый префикс можно удалить.

Тайм-ауты

define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Они ограничивают время ожидания подключения и ответа Redis одной секундой.

Максимальный срок хранения ключей

define('WP_REDIS_MAXTTL', 604800);

604800 секунд — семь дней.

Настройка задаёт максимальное время жизни ключей. Она помогает избежать бесконечного хранения объектов, которым WordPress или плагины не назначили собственный срок действия.

Дополнительная ошибка PHP-памяти

Во время диагностики поддержка Beget обнаружила ещё одну критическую ошибку:

Fatal error: Allowed memory size of 268435456 bytes exhausted

Ошибка находилась в FluentCRM:

/wp-content/plugins/fluent-crm/app/Services/Funnel/Benchmarks/ListAppliedBenchmark.php

Число 268435456 соответствует 256 МБ.

Важно различать:

Память PHP ≠ память Redis

PHP-память используется WordPress и его плагинами. Redis работает как отдельный сервис и имеет собственный лимит.

Поддержка предложила увеличить PHP-лимит до 3 ГБ. Для начала было выбрано более умеренное значение 512 МБ:

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

При поддержке соответствующей конфигурации PHP в .htaccess также была добавлена строка:

php_value memory_limit 512M

После этого ошибка нехватки памяти больше не повторилась.

Повышение PHP-лимита не восстановило Redis. Оно решило отдельную проблему FluentCRM.

Проверка Cron и базы FluentCRM

На сайте используется отдельная серверная Cron-задача Beget. Поэтому в wp-config.php присутствует:

define('DISABLE_WP_CRON', true);

Это допустимо только при наличии внешней Cron-задачи, которая регулярно вызывает wp-cron.php.

Встроенный монитор FluentCRM показал:

• лимит сервера 512 МБ;
• небольшое текущее потребление памяти;
• запланированную отправку email;
• запланированную обработку email;
• запланированную обработку автоматизаций.

Также были проверены критические индексы базы данных FluentCRM. Все они имели статус Healthy.

Проверка реальной автоматизации

После восстановления сайта была протестирована автоматизация:

Заявка с главной страницы
↓
Создание контакта во FluentCRM
↓
Назначение списка
↓
Запуск автоматизации
↓
Создание задачи во Fluent Boards

Для проверки форма была отправлена с новым адресом электронной почты.

Контакт успешно появился во FluentCRM и получил нужный список.

После этого новая задача появилась во Fluent Boards в колонке Open.

Это подтвердило, что после выполненных изменений работают:

• форма на главной странице;
• создание контакта;
• FluentCRM;
• назначение списка;
• автоматизация;
• Fluent Boards;
• фоновые процессы WordPress.

Как безопасно включить Redis Object Cache

После перезапуска Redis и добавления параметров в wp-config.php используется следующий порядок:

1. Убедиться, что Redis в Beget имеет статус «Включён».
2. Проверить адрес 127.0.0.1.
3. Проверить порт 6379.
4. Удалить или перенести старый object-cache.php.disabled.
5. Активировать Redis Object Cache.
6. Открыть «Настройки → Redis».
7. Нажать Enable Object Cache.
8. Проверить статус подключения.

Ожидаемый результат:

Status: Connected
Client: PhpRedis
Host: 127.0.0.1
Port: 6379

Если после включения снова появляется Connection refused, следует немедленно отключить объектный кэш и повторно проверить сервис Redis в панели Beget.

Аварийное отключение Redis

Redis Object Cache поддерживает специальный аварийный выключатель.

Вместо удаления object-cache.php можно добавить в wp-config.php:

define('WP_REDIS_DISABLED', true);

Эту строку необходимо разместить до:

/* That's all, stop editing! Happy publishing. */

После восстановления Redis строку следует удалить или изменить:

define('WP_REDIS_DISABLED', false);

Это удобнее, чем каждый раз переименовывать файлы через файловый менеджер.

Почему не использовался flushall

Для профилактической очистки предлагалась команда:

redis-cli flushall

Мы не стали добавлять её в Cron.

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

Кроме того, FLUSHALL не решает ошибку Connection refused. Невозможно очистить Redis, если процесс не работает или не принимает подключения.

В данном случае проблема была устранена перезапуском сервиса, а не очисткой ключей.

Что делать, если ошибка повторится

Если снова появляется:

Error establishing a Redis connection

нужно действовать по следующему алгоритму.

Шаг 1. Вернуть сайт

Добавить в wp-config.php:

define('WP_REDIS_DISABLED', true);

Если это не помогает — переименовать:

/wp-content/object-cache.php

в:

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

Шаг 2. Проверить Beget

Открыть:

Beget → Сервисы → Redis

Проверить:

• включён ли сервис;
• адрес подключения;
• порт;
• график памяти;
• график нагрузки.

Шаг 3. Перезапустить Redis

Нажать:

Перезагрузить

Подождать одну-две минуты.

Шаг 4. Проверить журнал

Временно включить:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Проверить:

/wp-content/debug.log

Искать:

RedisException
Connection refused
Allowed memory size
PHP Fatal
zend_mm_heap

Шаг 5. Вернуть объектный кэш

После восстановления сервиса удалить аварийную строку:

define('WP_REDIS_DISABLED', true);

или изменить её на:

define('WP_REDIS_DISABLED', false);

Затем проверить статус Redis Object Cache.

Шаг 6. Выключить отладку

define('WP_DEBUG', false);

Итог: какую ошибку мы исправили

Ключевая ошибка выглядела так:

RedisException: Connection refused

WordPress использовал правильный адрес, но процесс Redis не принимал подключения.

Фактически были выполнены следующие действия:

1. Redis временно отключили от WordPress.
2. Сайт и административная панель снова открылись.
3. Сервис Redis перезапустили в Beget.
4. Redis снова начал принимать соединения на порту 6379.
5. В wp-config.php явно указали адрес и порт.
6. Добавили уникальный префикс сайта.
7. Добавили тайм–ауты подключения.
8. Ограничили максимальный срок жизни ключей.
9. Увеличили отдельный PHP-лимит с 256 до 512 МБ.
10. Проверили Cron, FluentCRM и базу данных.
11. Отправили тестовую заявку.
12. Убедились, что задача создаётся во Fluent Boards.

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

Мы установили непосредственную причину недоступности сайта — отказ соединения с Redis — и восстановили работу сервиса его перезапуском.

Главный практический вывод:

Если Redis используется только как кэш, его сбой не должен оставлять владельца без доступа к WordPress. Необходимо заранее знать, как отключить объектный кэш через WP_REDIS_DISABLED, контролировать работу сервиса и хранить готовый порядок восстановления сайта.

Краткая памятка

Рабочие параметры:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_MAXTTL', 604800);

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Аварийное отключение:

define('WP_REDIS_DISABLED', true);

Возврат Redis:

define('WP_REDIS_DISABLED', false);

Диагностика:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После диагностики:

define('WP_DEBUG', false);

Команду использовать не нужно:

redis-cli flushall

На сайте webmarketing-lab.ru возникла критическая ошибка подключения к Redis. Не открывалась административная панель WordPress.

В процессе диагностики выяснилось, что проблема состояла из двух отдельных сбоев:

1. WordPress не мог подключиться к Redis.
2. FluentCRM исчерпал PHP-лимит памяти 256 МБ.

Точную внутреннюю причину остановки Redis установить не удалось. Однако мы смогли восстановить сайт, перезапустить Redis, правильно настроить подключение и проверить работу CRM-автоматизации.

В статье подробно разберём, что произошло и какие действия помогли.

Как выглядела ошибка

При открытии сайта WordPress показывал:

Error establishing a Redis connection
Connection refused

Также отображалось пояснение:

WordPress is unable to establish a connection to Redis.

В журнале WordPress находилась следующая ошибка:

RedisException: Connection refused

WordPress пытался подключиться по адресу:

127.0.0.1:6379

Это стандартный локальный адрес Redis на хостинге Beget.

Что означает Connection refused

Ошибка Connection refused означает, что WordPress дошёл до указанного адреса, но на порту 6379 никто не принял соединение.

Это происходит до проверки пароля и до выполнения каких‑либо команд Redis.

Наиболее распространённые причины:

• Redis остановлен;
• процесс Redis завис;
• Redis неудачно перезапустился;
• сервис работает на другом адресе или порту;
• панель хостинга показывает сервис включённым, но процесс фактически не принимает подключения;
• произошёл кратковременный внутренний сбой хостинга.

В нашем случае адрес и порт были правильными:

Адрес: 127.0.0.1
Порт: 6379

Панель Beget при этом показывала:

Redis: Включен

Несмотря на зелёный статус, журнал WordPress подтверждал, что в момент сбоя Redis не принимал подключения.

Удалось ли установить точную причину

Нет, точную внутреннюю причину остановки Redis установить не удалось.

Для этого потребовались бы серверные журналы самого процесса Redis и инфраструктуры Beget. Владелец обычного хостингового аккаунта не всегда имеет к ним доступ.

Мы можем уверенно сказать только следующее:

• WordPress использовал правильный адрес и порт;
• Redis не принимал подключение;
• превышения памяти Redis по статистике не было;
• после перезапуска сервиса соединение восстановилось.

Поэтому корректная формулировка причины выглядит так:

Сайт стал недоступен из‑за отказа соединения с Redis. В момент ошибки процесс Redis не принимал подключения на 127.0.0.1:6379. Точная причина остановки или зависания процесса не была установлена.

Нельзя утверждать, что Redis остановился из‑за переполнения памяти или накопления ключей: подтверждений этому не обнаружено.

Почему отказ Redis заблокировал весь WordPress

Redis использовался на сайте как постоянный объектный кэш через плагин Redis Object Cache.

Плагин создаёт файл:

/wp-content/object-cache.php

Этот файл загружается на очень раннем этапе запуска WordPress.

В результате цепочка выглядела так:

Запуск WordPress
↓
Загрузка object-cache.php
↓
Попытка подключения к 127.0.0.1:6379
↓
Connection refused
↓
Остановка WordPress

Таким образом, необязательный сервис кэширования превратился в критическую зависимость. Из‑за недоступности Redis перестали открываться:

• публичная часть сайта;
• административная панель;
• WordPress Cron;
• фоновые задачи;
• автоматизации плагинов.

Первый шаг: временно отключили Redis

Чтобы восстановить доступ к WordPress, через файловый менеджер Beget был открыт каталог:

/public_html/wp-content/

Файл:

object-cache.php

был переименован в:

object-cache.php.disabled

После этого WordPress перестал обращаться к недоступному Redis и смог загрузиться со стандартным объектным кэшем PHP.

Это действие не удаляет:

• базу данных;
• страницы и записи;
• пользователей;
• заявки;
• контакты FluentCRM;
• задачи Fluent Boards;
• настройки сайта.

Сайт просто временно начинает работать без Redis.

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

Второй шаг: перезапустили Redis в Beget

После восстановления доступа к сайту была открыта страница:

Beget → Сервисы → Redis

На ней Redis отображался включённым. Для фактического перезапуска процесса была нажата кнопка:

Перезагрузить

Перезапуск выполняет следующие действия:

1. Завершает старый или зависший процесс Redis.
2. Запускает новый процесс.
3. Заново открывает порт 6379.
4. Восстанавливает приём подключений.
5. Делает Redis доступным WordPress.

Именно перезапуск сервиса фактически восстановил работу Redis.

Изменения в конфигурации WordPress сами по себе не могли запустить остановленный процесс. Они были добавлены после перезапуска, чтобы явно закрепить правильные параметры подключения и улучшить управление кэшем.

Третий шаг: добавили настройки в wp-config.php

Настройки Redis добавляются не в redis.php, а в основной файл конфигурации WordPress:

/public_html/wp-config.php

Строки необходимо размещать до:

/* That's all, stop editing! Happy publishing. */

Для сайта была подготовлена следующая конфигурация:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

define('WP_REDIS_MAXTTL', 604800);

Адрес Redis

define('WP_REDIS_HOST', '127.0.0.1');

Указывает локальный адрес Redis, предоставленный Beget.

Порт Redis

define('WP_REDIS_PORT', 6379);

Должен совпадать с портом на странице сервиса Redis в Beget.

Уникальный префикс

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

Префикс отделяет ключи этого сайта от ключей других проектов.

Для каждого сайта необходимо использовать собственное значение:

define('WP_REDIS_PREFIX', 'client-site.ru:');

Нельзя копировать один префикс на несколько сайтов.

Ранее на сайте использовалась строка:

define('WP_CACHE_KEY_SALT', 'webmarketing-lab.ru_');

В актуальной версии Redis Object Cache эта настройка считается устаревшей. Вместо неё рекомендуется использовать:

define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');

Старую строку WP_CACHE_KEY_SALT после перехода на новый префикс можно удалить.

Тайм-ауты

define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

Они ограничивают время ожидания подключения и ответа Redis одной секундой.

Максимальный срок хранения ключей

define('WP_REDIS_MAXTTL', 604800);

604800 секунд — семь дней.

Настройка задаёт максимальное время жизни ключей. Она помогает избежать бесконечного хранения объектов, которым WordPress или плагины не назначили собственный срок действия.

Дополнительная ошибка PHP-памяти

Во время диагностики поддержка Beget обнаружила ещё одну критическую ошибку:

Fatal error: Allowed memory size of 268435456 bytes exhausted

Ошибка находилась в FluentCRM:

/wp-content/plugins/fluent-crm/app/Services/Funnel/Benchmarks/ListAppliedBenchmark.php

Число 268435456 соответствует 256 МБ.

Важно различать:

Память PHP ≠ память Redis

PHP-память используется WordPress и его плагинами. Redis работает как отдельный сервис и имеет собственный лимит.

Поддержка предложила увеличить PHP-лимит до 3 ГБ. Для начала было выбрано более умеренное значение 512 МБ:

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

При поддержке соответствующей конфигурации PHP в .htaccess также была добавлена строка:

php_value memory_limit 512M

После этого ошибка нехватки памяти больше не повторилась.

Повышение PHP-лимита не восстановило Redis. Оно решило отдельную проблему FluentCRM.

Проверка Cron и базы FluentCRM

На сайте используется отдельная серверная Cron-задача Beget. Поэтому в wp-config.php присутствует:

define('DISABLE_WP_CRON', true);

Это допустимо только при наличии внешней Cron-задачи, которая регулярно вызывает wp-cron.php.

Встроенный монитор FluentCRM показал:

• лимит сервера 512 МБ;
• небольшое текущее потребление памяти;
• запланированную отправку email;
• запланированную обработку email;
• запланированную обработку автоматизаций.

Также были проверены критические индексы базы данных FluentCRM. Все они имели статус Healthy.

Проверка реальной автоматизации

После восстановления сайта была протестирована автоматизация:

Заявка с главной страницы
↓
Создание контакта во FluentCRM
↓
Назначение списка
↓
Запуск автоматизации
↓
Создание задачи во Fluent Boards

Для проверки форма была отправлена с новым адресом электронной почты.

Контакт успешно появился во FluentCRM и получил нужный список.

После этого новая задача появилась во Fluent Boards в колонке Open.

Это подтвердило, что после выполненных изменений работают:

• форма на главной странице;
• создание контакта;
• FluentCRM;
• назначение списка;
• автоматизация;
• Fluent Boards;
• фоновые процессы WordPress.

Как безопасно включить Redis Object Cache

После перезапуска Redis и добавления параметров в wp-config.php используется следующий порядок:

1. Убедиться, что Redis в Beget имеет статус «Включён».
2. Проверить адрес 127.0.0.1.
3. Проверить порт 6379.
4. Удалить или перенести старый object-cache.php.disabled.
5. Активировать Redis Object Cache.
6. Открыть «Настройки → Redis».
7. Нажать Enable Object Cache.
8. Проверить статус подключения.

Ожидаемый результат:

Status: Connected
Client: PhpRedis
Host: 127.0.0.1
Port: 6379

Если после включения снова появляется Connection refused, следует немедленно отключить объектный кэш и повторно проверить сервис Redis в панели Beget.

Аварийное отключение Redis

Redis Object Cache поддерживает специальный аварийный выключатель.

Вместо удаления object-cache.php можно добавить в wp-config.php:

define('WP_REDIS_DISABLED', true);

Эту строку необходимо разместить до:

/* That's all, stop editing! Happy publishing. */

После восстановления Redis строку следует удалить или изменить:

define('WP_REDIS_DISABLED', false);

Это удобнее, чем каждый раз переименовывать файлы через файловый менеджер.

Почему не использовался flushall

Для профилактической очистки предлагалась команда:

redis-cli flushall

Мы не стали добавлять её в Cron.

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

Кроме того, FLUSHALL не решает ошибку Connection refused. Невозможно очистить Redis, если процесс не работает или не принимает подключения.

В данном случае проблема была устранена перезапуском сервиса, а не очисткой ключей.

Что делать, если ошибка повторится

Если снова появляется:

Error establishing a Redis connection

нужно действовать по следующему алгоритму.

Шаг 1. Вернуть сайт

Добавить в wp-config.php:

define('WP_REDIS_DISABLED', true);

Если это не помогает — переименовать:

/wp-content/object-cache.php

в:

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

Шаг 2. Проверить Beget

Открыть:

Beget → Сервисы → Redis

Проверить:

• включён ли сервис;
• адрес подключения;
• порт;
• график памяти;
• график нагрузки.

Шаг 3. Перезапустить Redis

Нажать:

Перезагрузить

Подождать одну-две минуты.

Шаг 4. Проверить журнал

Временно включить:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Проверить:

/wp-content/debug.log

Искать:

RedisException
Connection refused
Allowed memory size
PHP Fatal
zend_mm_heap

Шаг 5. Вернуть объектный кэш

После восстановления сервиса удалить аварийную строку:

define('WP_REDIS_DISABLED', true);

или изменить её на:

define('WP_REDIS_DISABLED', false);

Затем проверить статус Redis Object Cache.

Шаг 6. Выключить отладку

define('WP_DEBUG', false);

Итог: какую ошибку мы исправили

Ключевая ошибка выглядела так:

RedisException: Connection refused

WordPress использовал правильный адрес, но процесс Redis не принимал подключения.

Фактически были выполнены следующие действия:

1. Redis временно отключили от WordPress.
2. Сайт и административная панель снова открылись.
3. Сервис Redis перезапустили в Beget.
4. Redis снова начал принимать соединения на порту 6379.
5. В wp-config.php явно указали адрес и порт.
6. Добавили уникальный префикс сайта.
7. Добавили тайм–ауты подключения.
8. Ограничили максимальный срок жизни ключей.
9. Увеличили отдельный PHP-лимит с 256 до 512 МБ.
10. Проверили Cron, FluentCRM и базу данных.
11. Отправили тестовую заявку.
12. Убедились, что задача создаётся во Fluent Boards.

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

Мы установили непосредственную причину недоступности сайта — отказ соединения с Redis — и восстановили работу сервиса его перезапуском.

Главный практический вывод:

Если Redis используется только как кэш, его сбой не должен оставлять владельца без доступа к WordPress. Необходимо заранее знать, как отключить объектный кэш через WP_REDIS_DISABLED, контролировать работу сервиса и хранить готовый порядок восстановления сайта.

Краткая памятка

Рабочие параметры:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'webmarketing-lab.ru:');
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_MAXTTL', 604800);

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Аварийное отключение:

define('WP_REDIS_DISABLED', true);

Возврат Redis:

define('WP_REDIS_DISABLED', false);

Диагностика:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После диагностики:

define('WP_DEBUG', false);

Команду использовать не нужно:

redis-cli flushall