Сообщение о слишком большом числе перенаправлений часто появляется после подключения CDN, балансировщика или обратного прокси. Сертификат при этом может быть исправен: браузер устанавливает HTTPS-соединение, но до страницы не доходит. Причину нужно искать в последовательности ответов и в том, как приложение определяет исходный протокол посетителя.
Эта инструкция помогает собрать доказательства конфликта и выбрать слой для исправления. Она не требует отключать HTTPS, защиту входа или проверку сертификата. Любые изменения рабочей конфигурации сначала проверяют на отдельном стенде с доступным способом возврата.
Что именно образует цикл
Представим маршрут: посетитель обращается к HTTPS-адресу, внешний прокси принимает зашифрованное соединение и передаёт запрос серверу приложения. Если внутренний участок использует HTTP, WordPress должен корректно узнать, что внешнее соединение уже было защищено. Иначе приложение может снова направить браузер на тот же HTTPS-адрес. Следующий запрос проходит прежним маршрутом и получает прежний ответ.
Официальное руководство WordPress отдельно рассматривает HTTPS за reverse proxy. Конкретный способ передачи и обработки признака защищённого соединения зависит от инфраструктуры. Поэтому копировать фрагмент настройки без понимания доверенных прокси нельзя: заголовок, доступный для подмены внешним клиентом, не должен автоматически считаться достоверным.
Есть и другой случай: один слой выбирает адрес с www, другой возвращает вариант без www. Смена протокола тогда может вообще не участвовать в ошибке. Сначала нужно увидеть повторяющийся переход, а уже затем менять правило.
Подготовка: зафиксируйте маршрут и границы работ
- Запишите точный URL, на котором появляется ошибка, включая путь и параметры.
- Укажите время наблюдения и часовой пояс, чтобы сопоставить запрос с журналами.
- Нарисуйте маршрут: браузер, CDN, балансировщик, Nginx или Apache, PHP, WordPress. Отметьте точки завершения TLS.
- Сохраните действующие правила перенаправлений и значения адресов сайта. Не включайте пароли и содержимое пользовательских сессий в диагностический отчёт.
- Определите, кто управляет каждым слоем. Настройка на сервере не отменяет правило, которое раньше срабатывает на CDN.
Если проблема появилась сразу после одного изменения, это сильная зацепка, но ещё не доказательство. Например, подключение CDN могло одновременно изменить обработку HTTPS и использовать закешированный старый редирект. Эти причины проверяют отдельно.
Шаг 1. Получите ответы без автоматического перехода
Для публичной страницы выполните диагностический GET-запрос с выводом заголовков. Пример использует зарезервированный домен: замените его адресом проверяемого сайта.
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null http://example.com/Запишите код ответа и значение Location. Не добавляйте флаг отключения проверки сертификата: ошибка TLS — отдельный результат диагностики. Если curl сообщает о недоверенной цепочке, сначала разберите сертификат, а не маскируйте сообщение.
Не все приложения одинаково отвечают на HEAD и GET. Поэтому при расхождении с браузером полезнее изучить обычный GET без сохранения тела. Для защищённого личного кабинета публичный запрос не заменяет проверку авторизованной сессии.
Шаг 2. Проследите ограниченную цепочку
curl -sS -L --max-redirs 8 -D - -o /dev/null https://example.com/Ограничение числа переходов позволяет остановить цикл и сохранить последовательность. Сравнивайте не только домен и протокол, но и путь, завершающий слеш, параметры запроса. Переход на страницу входа может быть ожидаемым; постоянное возвращение между двумя адресами — повод искать конфликт правил.
| Наблюдение | Рабочая гипотеза | Следующая проверка |
|---|---|---|
| Один HTTPS-URL повторяется | Приложение неверно определяет внешний протокол | Схема TLS и доверенная передача протокола |
| www и адрес без www чередуются | Два разных канонических правила | CDN, virtual host, адреса WordPress |
| Петля только на входе | Особенность авторизации или защиты админки | Правила входа, cookie и журнал приложения |
| curl работает, старый браузерный профиль — нет | Локальное состояние или кеш | Чистая сессия и сохранённые редиректы |
Таблица формирует гипотезы, а не автоматически устанавливает причину. Один и тот же внешний симптом возможен на нескольких слоях. Для подтверждения сопоставьте цепочку с конфигурацией и журналом соответствующего запроса.
Шаг 3. Сверьте адреса WordPress
В настройках WordPress проверьте адрес установки и адрес сайта. Они не обязаны совпадать при установке ядра в подкаталоге. Важнее, чтобы значения соответствовали принятой схеме размещения и выбранному внешнему HTTPS-адресу.
При наличии штатного WP-CLI значения можно прочитать командами wp option get home и wp option get siteurl. Если в конфигурации заданы соответствующие константы, учитывайте их при разборе фактического поведения. Не выполняйте массовую замену URL в базе ради проверки одной гипотезы.
Отдельно найдите правила плагина перенаправлений, защитного плагина и панели хостинга. Несколько правил с одинаковой целью иногда лишь добавляют переходы, а правила с разными целями создают петлю. Исправление должно иметь понятного владельца и проверяемое основание.
Шаг 4. Проверьте доверие между прокси и приложением
Администратору инфраструктуры передайте схему маршрута и цепочку Location. Попросите проверить, каким способом приложение получает исходный протокол и может ли внешний клиент подставить тот же признак. Проверка должна учитывать несколько прокси, если они действительно есть, а также прямой доступ к origin-серверу.
Не публикуйте диагностическую страницу, выводящую все серверные переменные. В них могут находиться сведения о внутренней сети и авторизации. Достаточно ограниченного журнала конкретного тестового запроса с удалёнными чувствительными значениями.
Корректное решение согласует внешнее HTTPS-соединение, передачу признака протокола и обработку этого признака в WordPress. Универсальная вставка, безусловно объявляющая каждый запрос защищённым, затрудняет диагностику и не описывает реальную схему доверия.
Шаг 5. Исправьте один конфликт и повторите проверку
Сохраните исходное правило, внесите минимальную поправку на стенде и повторите те же запросы. Не меняйте одновременно CDN, конфигурацию веб-сервера и несколько плагинов: тогда исчезновение ошибки не покажет, какое действие помогло.
После успешной проверки выполните адресную очистку затронутого кеша. Проверьте HTTP, HTTPS, www, вариант без www, одну внутреннюю страницу и вход в админку. Для магазина дополнительно нужна безопасная проверка корзины и личного кабинета без реального платежа. Убедитесь, что canonical и ссылки ресурсов используют согласованный адрес.
Типичные ошибки
- Отключать HTTPS вместо устранения конфликта определения протокола.
- Считать любой заголовок клиента доказательством доверенного прокси.
- Проверять только главную, хотя петля возникает на вложенном пути.
- Удалять все редиректы и терять полезные старые адреса.
- Принимать исчезновение сообщения в одном браузере за полную проверку.
FAQ
Нужно ли перевыпускать сертификат?
Если TLS-соединение успешно и получены повторяющиеся HTTP-ответы, сама цепочка редиректов не доказывает проблему сертификата. Перевыпуск без подтверждённой ошибки не устраняет конфликт правил.
Почему очистка cookie иногда помогает?
Ошибка может зависеть от состояния входа. Сравнение чистой и действующей сессии полезно, но оно не заменяет проверку серверной последовательности ответов. Сохраните воспроизводимый сценарий до очистки данных.
Можно ли временно отключить CDN?
Такой тест требует подготовленного origin: сертификата, DNS-маршрута и понимания последствий для защиты и кеширования. Для первого этапа обычно достаточно чтения правил и журналов.
Вывод
Рабочий результат — конечная HTTPS-страница по согласованному адресу, исправный вход и отсутствие повторяющихся переходов на проверенных маршрутах. Сохраните цепочку до и после изменения: она полезнее предположения, что проблема была «в SSL».
Для смежных задач используйте инструкции HOSTIO: проверка HTTPS, разбор взаимодействия прокси и приложения, сбор журналов WordPress и PHP. Возможности размещения описаны в профиле Beget.
Техническое основание: WordPress: HTTPS и reverse proxy. Проверено 28.10.2026. Диагностический порядок и таблица гипотез — редакционная разработка HOSTIO; результаты испытаний какого-либо провайдера здесь не заявляются.
