После подключения Cloudflare WordPress иногда начинает вести себя странно: вместо сайта открывается сообщение о слишком большом числе перенаправлений. Ошибка выглядит сухо, но за ней почти всегда стоит вполне конкретная связка настроек, где один неверный переход по протоколу или домену запускает бесконечный круг.
Ситуация неприятна тем, что ломает доступ к сайту сразу и для посетителей, и для владельца. Хорошая новость в том, что в большинстве случаев причина находится быстро, если разбирать цепочку от Cloudflare до WordPress без суеты и лишних догадок.
Как работает эта ошибка и почему она появляется именно после подключения Cloudflare
Петля редиректов возникает тогда, когда сервер и сервис защиты по-разному понимают, по какому адресу должен открываться сайт. Один компонент отправляет пользователя на HTTPS, другой снова возвращает на HTTP или меняет домен, и браузер не может выбраться из этого круга.
С Cloudflare проблема часто всплывает после смены режима SSL, установки плагина для принудительного HTTPS или правок в настройках WordPress. Браузер видит слишком много ответов 301 или 302 подряд и останавливается с сообщением ERR_TOO_MANY_REDIRECTS.
На практике это нередко связано не с одной ошибкой, а с двумя настройками, которые конфликтуют между собой. Например, Cloudflare уже переводит трафик на HTTPS, а WordPress или сервер отдельно пытаются сделать то же самое по своему сценарию.
«В большинстве случаев бесконечный редирект появляется не из-за самой CDN, а из-за несовпадения ожиданий между прокси и приложением». — из практики системного администрирования
Самые частые причины: что проверять в первую очередь
Начинать лучше не с плагинов, а с базовых параметров. Именно они чаще всего создают петлю, которую потом долго ищут в расширениях и темах.
Есть несколько типичных источников проблемы. Они не требуют глубокого вмешательства, но каждый из них способен полностью закрыть доступ к сайту.
- неверный режим SSL в Cloudflare;
- конфликт между HTTP и HTTPS в WordPress;
- неправильные адреса сайта в настройках WordPress;
- принудительное перенаправление в .htaccess или конфиге сервера;
- плагин кеша или безопасности, который дублирует редирект;
- циклическая переадресация между www и без www.
Если говорить по опыту, самый частый сценарий выглядит так: сайт уже работает по HTTPS, а в Cloudflare включен режим Flexible. Внешне все кажется логичным, но именно эта комбинация очень часто вызывает петлю.
Еще одна тонкая точка связана с адресами в WordPress. Если в полях WordPress Address и Site Address стоят разные варианты домена, сайт легко уходит в постоянное переключение между ними.
Проверка SSL в Cloudflare: место, где часто все и ломается
Cloudflare предлагает несколько режимов SSL, и для WordPress это не просто формальность. От выбранного варианта зависит, как Cloudflare общается с вашим сервером и по какому протоколу идет запрос дальше.
Если на сервере уже установлен корректный SSL-сертификат, обычно нужен режим Full или Full (strict). В режиме Flexible Cloudflare обращается к серверу по HTTP, даже если пользователь открывает сайт по HTTPS, и именно здесь часто возникает петля перенаправлений.
| Режим SSL в Cloudflare | Когда уместен | Риск петли |
|---|---|---|
| Flexible | Если на сервере нет SSL | Высокий при принудительном HTTPS на сервере |
| Full | Если сертификат установлен, но без строгой проверки | Низкий при корректной настройке |
| Full (strict) | Если сертификат валиден и настроен правильно | Минимальный |
Если сайт уже обслуживается по HTTPS, обычно первым делом стоит проверить именно этот параметр. Переключение с Flexible на Full или Full (strict) часто решает проблему без дальнейших действий.
Полезно также посмотреть, не включено ли у вас правило Always Use HTTPS. Само по себе оно не вредно, но в связке с серверным редиректом или плагином может создать дублирующий переход и усилить петлю.
Настройки WordPress, которые нужно сверить вручную
Когда Cloudflare уже настроен, следующая точка проверки находится внутри самой админки WordPress. В разделе общих настроек есть два адреса, и они должны совпадать по схеме и доменному имени.
Оба поля лучше проверить особенно внимательно. Разница между http и https, а также между www и без www, может оказаться достаточной для запуска бесконечного цикла.
Если доступ к админке потерян, адреса можно исправить через файл wp-config.php. Обычно туда временно добавляют строки с WP_HOME и WP_SITEURL, чтобы зафиксировать корректный адрес сайта.
«Когда сайт не открывается после смены SSL-политики, сначала ищут не в теме и не в контенте, а в адресах, которые WordPress считает своими». — из заметок веб-разработчика
Не стоит забывать и о плагинах, которые отдельно управляют редиректами. Часто владелец сайта ставит SEO-расширение, плагин безопасности и еще одно решение для HTTPS, а потом все трое начинают тянуть трафик в разные стороны.
Серверные редиректы: .htaccess, nginx и конфликты с Cloudflare
Даже если Cloudflare настроен верно, сам сервер может продолжать отправлять пользователя по кругу. Особенно часто это происходит, когда в .htaccess или конфиге nginx уже прописан принудительный переход на HTTPS, а сверху его дублирует правило Cloudflare.
Для Apache стоит посмотреть, нет ли в .htaccess нескольких блоков с редиректами на один и тот же адрес. Для nginx важно проверить, не настроен ли отдельный серверный блок на 80 порт, который постоянно пересылает запрос туда, где уже включено другое принуждение к HTTPS.
Если сайт за Cloudflare определяет протокол запроса неправильно, сервер может считать, что соединение пришло по HTTP, хотя снаружи оно уже было защищено. Тогда WordPress или сервер начинают упрямо исправлять то, что уже было исправлено на уровне прокси.
В таких случаях помогает проверка заголовков, особенно если на сервере используются правила, завязанные на HTTPS. Иногда достаточно корректно учесть заголовок X-Forwarded-Proto, чтобы петля исчезла.
Плагины кеша и безопасности: невидимый источник повторяющихся переходов
Многие проблемы с редиректами рождаются не в основном коде WordPress, а в плагинах. Они стремятся помочь, но иногда работают слишком активно и начинают перенаправлять пользователя по собственным правилам.
Чаще всего в зоне риска оказываются плагины кеширования, защиты от атак и расширения для SEO. Один может заставлять сайт работать только на HTTPS, другой будет настаивать на каноническом домене, третий добавит еще одно правило для www.
Если доступ к сайту сломался сразу после установки или обновления расширения, это уже хороший ориентир. В такой ситуации полезно временно отключить плагины через файловую систему, а не через админку, если вход в нее недоступен.
В моей практике однажды проблема оказалась в плагине, который одновременно управлял редиректом на HTTPS и канонизацией домена. По отдельности настройки выглядели безобидно, но вместе создавали цикл между двумя почти одинаковыми адресами.
Пошаговая проверка, которая обычно помогает быстрее всего
Разбирать такую ошибку удобнее по порядку, не прыгая от одной догадки к другой. Это экономит время и не заставляет менять лишние настройки, которые потом трудно вернуть назад.
- Проверьте режим SSL в Cloudflare и при необходимости переключите его на Full или Full (strict).
- Сверьте адреса сайта в WordPress и убедитесь, что они одинаковы по протоколу и домену.
- Временно отключите принудительный HTTPS в плагинах и правилах сервера.
- Проверьте, не конфликтуют ли www и без www.
- Очистите кеш Cloudflare и локальный кеш WordPress.
- Если проблема не ушла, временно отключите плагины безопасности и кеширования.
После каждого изменения стоит проверять сайт в режиме инкогнито. Это простой способ исключить влияние старых cookies и кеша браузера, которые тоже умеют маскировать проблему.
Если сайт снова открывается, не спешите возвращать все назад разом. Лучше включать настройки по одной, чтобы увидеть, на каком шаге петля появляется снова.
Что делать, если редирект все еще не исчез
Иногда причина прячется глубже. Тогда полезно посмотреть ответы сервера через инструменты разработчика или любой онлайн-сервис проверки цепочки редиректов.
Если цепочка длинная, по ней обычно видно, кто именно отправляет запрос дальше. Это может быть сам WordPress, сервер, плагин или правило на стороне Cloudflare.
Отдельно стоит проверить SSL-сертификат на origin-сервере. Если сертификат просрочен, самоподписан или настроен с ошибкой, режим Full (strict) будет блокировать нормальную работу, а владелец сайта увидит нестабильное поведение вместо понятной причины.
Иногда помогает временное отключение проксирования в Cloudflare для записи DNS. Такой прием позволяет понять, связан ли цикл именно с прокси-слоем или проблема живет на самом сервере.
Как не вернуться к той же проблеме снова
После устранения ошибки полезно оставить конфигурацию в одном понятном состоянии. Для WordPress за Cloudflare лучше, когда SSL-настройка, адрес сайта и серверные правила не дублируют друг друга.
Если вы меняете что-то в HTTPS-политике, делайте это в одном месте за раз. Сначала проверьте сервер, потом Cloudflare, потом плагины. Когда изменения вносятся сразу везде, отследить источник петли почти невозможно.
Хорошо работает привычка фиксировать рабочую конфигурацию. Достаточно сохранить текущие значения SSL-режима, адресов сайта и ключевых правил редиректа. Потом это экономит часы, особенно если сайт обслуживает не один человек.
ERR_TOO_MANY_REDIRECTS после подключения Cloudflare к WordPress почти всегда лечится аккуратной проверкой нескольких узлов, а не поиском скрытой магии. Как только все части начинают говорить на одном языке, сайт снова открывается нормально и без лишних поворотов по кругу.
