WordPress: слишком много перенаправлений при HTTPS

#Что означает ошибка

Ошибка «Слишком много перенаправлений» (ERR_TOO_MANY_REDIRECTS) в WordPress после перехода на HTTPS возникает из-за конфликта адресов siteurl/home, плагина редиректов, кэша или режима SSL в Cloudflare. Нужно найти слой, который гоняет браузер по кругу.

Если вы потеряли доступ к админке, исправления делаются через файл wp-config.php или базу данных.

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

Исправьте siteurl/home, настройте SSL в Cloudflare и проверьте плагины.

#Причины и решения

#Пошаговое решение

1. Сделайте резервную копиюСохраните резервную копию базы данных WordPress, wp-config.php, .htaccess и конфигурации прокси. Убедитесь, что копия доступна вне рабочего каталога; после этого в приватном окне браузера воспроизведите бесконечный переход и запишите пару URL, между которыми происходит цикл.
2. Задайте WP_HOME и WP_SITEURLОткройте wp-config.php через файловый менеджер и проверьте наличие define("WP_HOME", ...) и define("WP_SITEURL", ...). Если они явно заданы, сравните адреса с действительным доменом и HTTPS и измените только подтверждённо неверное значение. Переопределения в wp-config.php могут перекрывать значения базы; неверная правка лишит доступа к админке, поэтому нужен способ отката.
3. Проверьте режим SSL в CloudflareВ панели CDN/Cloudflare проверьте, где завершается TLS. Если сервер сам переводит всё на HTTPS, Cloudflare Flexible нередко создаёт цикл; Full (strict) допустим лишь при действительном сертификате на сервере-источнике. Сначала проверьте origin отдельно в пределах дозволенного доступа, затем изменяйте одну настройку и повторяйте проверку.
4. Отключите плагиныЕсли цикл появился после установки плагина перенаправления или безопасности, в доступной админке WordPress временно отключите именно его. При недоступной админке через файловый менеджер переименуйте папку одного подозрительного плагина после копирования и проверьте повторно; не отключайте все плагины и защиту без оценки последствий.
5. Пересоздайте .htaccessНа Apache сравните правила перенаправлений в .htaccess с настройками WordPress; сначала сохраните копию и после восстановления входа откройте «Настройки → Постоянные ссылки» и сохраните их. Для Nginx .htaccess не используется: анализируйте server/location, проверяйте sudo nginx -t и не создавайте обратные редиректы http↔https. После исправления очистите cookie только проблемного домена.

#Адреса сайта

Добавьте в wp-config.php (перед строкой «That's all»): define('WP_HOME','https://example.com'); и define('WP_SITEURL','https://example.com');. Это перекрывает значения в базе. Проверить значения можно через WP-CLI: wp option get siteurl, wp option get home; заменить: wp option update home https://example.com. Адреса должны иметь одинаковую схему и домен (с www или без — единообразно).

#Cloudflare и прокси

Если за сайтом Cloudflare, переключите «SSL/TLS → Обзор» в режим «Full (strict)» (при Flexible сервер видит HTTP и перенаправляет на HTTPS в бесконечном цикле). Либо добавьте в wp-config.php: if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }. Это нужно для любых обратных прокси и балансировщиков.

#Плагины, кэш и .htaccess

Переименуйте папку плагинов wp-content/plugins в plugins.off и проверьте сайт — если ошибка ушла, включайте плагины по одному (подозрительные: Really Simple SSL, Redirection, плагины кэша и SEO). Пересоздайте .htaccess: удалите файл и в админке «Настройки → Постоянные ссылки» нажмите «Сохранить». Проверьте, нет ли двух правил редиректа (в .htaccess и в nginx). Очистите кэш плагина, CDN и браузера.

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

Определите цепочку: curl -IL https://example.com. Если Location повторяется, смотрите заголовки: X-Redirect-By: WordPress указывает на WordPress, server: cloudflare — на CDN. Документация: wordpress.org/support.