Сайт не открывается и показывает ошибку ERR TOO MANY REDIRECTS? Разбираем причины циклической переадресации и способы её устранения. Пошаговые инструкции по проверке cookies, HTTPS, WordPress, OpenCart и серверных настроек.
При попытке открыть сайт браузер показывает ошибку ERR TOO MANY REDIRECTS (ERR_TOO_MANY_REDIRECTS), а вместо нужной страницы появляется сообщение «Страница недоступна» или «Сайт выполнил переадресацию слишком много раз»? Это означает, что браузер неоднократно переходил с одного адреса на другой, но так и не смог открыть конечную страницу.
Ошибка может возникнуть в Google Chrome, Яндекс Браузере и других браузерах. Иногда её вызывает неправильная работа cookies, однако нередко причина находится на стороне сайта: конфликтуют настройки HTTPS, правила перенаправления, конфигурация WordPress, OpenCart или веб-сервера.
В этой инструкции разберём, что значит ERR TOO MANY REDIRECTS, как определить причину циклической переадресации и восстановить доступ к сайту. Начнём с простых действий для обычных пользователей, а затем перейдём к пошаговой диагностике для владельцев сайтов.
ERR TOO MANY REDIRECTS переводится с английского как «Слишком много перенаправлений». В Chrome и некоторых других браузерах технический код может отображаться как ERR_TOO_MANY_REDIRECTS или NET::ERR_TOO_MANY_REDIRECTS. Смысл сообщения одинаковый: браузер не смог завершить последовательность переходов между адресами.
Чтобы понять причину, сначала разберём, как работает обычная переадресация.
Например, посетитель открывает адрес http://example.com. Сервер сообщает браузеру, что сайт теперь работает по защищённому протоколу HTTPS, и перенаправляет посетителя на https://example.com.
Браузер переходит по новому адресу, получает страницу и показывает её пользователю. Это нормальная работа перенаправления, или редиректа.
Проблема возникает, когда настройки противоречат друг другу. Один компонент сайта отправляет пользователя с HTTP на HTTPS, а другой возвращает его обратно.
В результате получается замкнутый цикл:
http://example.com/
↓
https://example.com/
↓
http://example.com/
↓
https://example.com/
↓
Повторное перенаправлениеБраузер несколько раз выполняет переходы, после чего прекращает попытки загрузки и показывает сообщение об ошибке.
Важно: ERR TOO MANY REDIRECTS - это сообщение браузера, а не отдельный HTTP-код сервера. В проблемной цепочке обычно присутствуют ответы 301, 302, 307 или 308, указывающие на необходимость перейти по другому адресу.
При этом не всякая длинная цепочка перенаправлений является бесконечным циклом. Например, сайт может последовательно перенаправлять посетителя через несколько страниц авторизации. Если количество переходов превышает ограничение браузера, он также может показать ошибку.
Причины ошибки ERR TOO MANY REDIRECTS можно разделить на две группы: проблемы на стороне посетителя и неправильные настройки самого сайта.
На стороне пользователя ошибка может возникать из-за устаревших cookies, повреждённых данных сайта, неправильной работы расширений браузера или особенностей сетевого подключения.
На стороне сайта возможных причин больше:
Внешне все эти ситуации могут выглядеть одинаково. Поэтому не стоит сразу удалять системные файлы, отключать SSL или переустанавливать CMS. Сначала необходимо установить, где именно возникает цикл.
Если сайт вам не принадлежит, вы не сможете самостоятельно исправить ошибки его серверной конфигурации. Однако перед обращением к администрации сайта стоит выполнить несколько простых проверок.
Если страница недоступна только в вашем браузере, переходите к следующим трём способам. Если проблема воспроизводится на разных устройствах и у других посетителей, вероятнее всего, её должен устранять администратор сайта.
Cookies - небольшие файлы, с помощью которых сайты сохраняют информацию о посещении, настройках и авторизации пользователя.
Например, сайт может перенаправлять неавторизованного посетителя на страницу входа. Если браузер отправляет некорректные или устаревшие данные сессии, приложение иногда начинает многократно переключаться между страницей входа и личным кабинетом.
В таких ситуациях удаление cookies может помочь устранить ошибку ERR TOO MANY REDIRECTS.
Обратите внимание: после удаления cookies может потребоваться повторная авторизация на сайте. Также могут сброситься настройки, сохранённые браузером для этого ресурса.
Необязательно удалять cookies всех сайтов сразу. Сначала очистите данные конкретного домена, на котором возникает ошибка.
Подробности приведены в официальной инструкции Google Chrome по удалению cookies.
Если расположение нужных пунктов отличается, воспользуйтесь поиском по настройкам браузера. В разных версиях Яндекс Браузера названия разделов и расположение элементов интерфейса могут меняться.
Если после очистки данных ошибка возникает снова, не повторяйте процедуру бесконечно. Возможно, проблема связана не с браузером, а с правилами перенаправления на сервере.
Если ошибка возникает только после входа в аккаунт, дополнительно проверьте работу сайта без авторизации. Такой результат стоит сообщить владельцу ресурса: он поможет определить, связана ли неисправность с пользовательской сессией.
Иногда сообщение ERR TOO MANY REDIRECTS появляется только в определённом браузере, хотя тот же сайт нормально открывается в другом.
Для начала запустите приватное окно. В Chrome и Яндекс Браузере обычно используется сочетание Ctrl + Shift + N, в Firefox - Ctrl + Shift + P.
Откройте проблемный адрес и сравните результат с обычным окном.
Если сайт заработал, проверьте расширения браузера, cookies и другие сохранённые данные. Учтите, что отдельные расширения могут работать и в приватном режиме, если пользователь разрешил им такой доступ.
Некоторые расширения блокируют cookies, изменяют заголовки запросов, перенаправляют адреса или вмешиваются в загрузку страниц.
Временно отключите подозрительные расширения и проверьте работу сайта. Если ошибка исчезла, включайте их по одному, чтобы определить конфликтующий компонент.
После проверки верните необходимые настройки защиты браузера. Не стоит постоянно отключать защитные расширения ради открытия одного сайта.
Браузер может сохранять результаты некоторых постоянных перенаправлений. Если настройки сайта недавно изменились, старые данные иногда мешают проверить новую конфигурацию.
Попробуйте обновить страницу с повторной загрузкой ресурсов. В Windows и Linux в большинстве браузеров можно использовать Ctrl + F5. Если это не помогает, удалите сохранённые данные только проблемного сайта.
Важно учитывать, что обычная очистка кеша не всегда устраняет последствия ранее сохранённых правил HSTS. Если браузер принудительно использует HTTPS, необходимо проверить корректность HTTPS на самом сайте, а не просто пытаться открыть его по HTTP.
Если ERR TOO MANY REDIRECTS появляется только при подключении к определённой сети Wi-Fi, проверьте сайт через другое соединение.
Например, откройте страницу на смартфоне сначала через домашний Wi-Fi, а затем через мобильный интернет.
Если результат отличается, проверьте использование VPN, прокси, сетевых фильтров и других промежуточных сервисов, которые могут изменять запросы и ответы.
Сам по себе Wi-Fi не является причиной циклической переадресации. Однако в некоторых сетях используются промежуточные страницы авторизации, фильтрация трафика и дополнительные правила перенаправления.
Если проблема возникает в гостинице, общественной сети или другом Wi-Fi с обязательной авторизацией, проверьте, завершён ли вход в сеть.
Не нужно сразу сбрасывать все сетевые настройки, менять DNS-серверы или переустанавливать браузер. Эти действия не исправят конфликтующие редиректы на самом сайте.
Следующие инструкции предназначены прежде всего для владельцев сайтов и специалистов, которые занимаются их обслуживанием.
Чтобы исправить циклическую переадресацию, необходимо увидеть последовательность HTTP-ответов и определить, между какими адресами происходит повторяющийся переход.
Перед изменением конфигурации сохраните резервную копию файлов сайта и текущих настроек сервера. Если проблема появилась после недавнего обновления, зафиксируйте, какие изменения выполнялись.
В Chrome или Яндекс Браузере нажмите F12 либо Ctrl + Shift + I. Перейдите на вкладку Network («Сеть»).
Включите параметр Preserve log («Сохранять журнал»), чтобы браузер не удалял историю запросов при переходах между страницами.
Откройте проблемный адрес и дождитесь появления ошибки ERR TOO MANY REDIRECTS.
На вкладке Network найдите запросы основного документа. Проверьте HTTP-статусы 301, 302, 307 и 308, а также заголовок Location, в котором сервер указывает следующий адрес.
Например, вы можете обнаружить такую последовательность:
https://example.com/
301 → https://www.example.com/
https://www.example.com/
301 → https://example.com/
https://example.com/
301 → https://www.example.com/В этом случае проблема заключается в противоречащих друг другу правилах, которые добавляют и удаляют www.
Если один компонент постоянно перенаправляет с HTTP на HTTPS, а другой - обратно, необходимо проверять настройки HTTPS, CDN и обратного прокси.
Не все переходы обязательно будут видны как обычные ответы сервера. Браузер может использовать сохранённые перенаправления или локально переходить на HTTPS по правилам HSTS. Поэтому для подтверждения причины полезно дополнительно проверить ответы сервера отдельным HTTP-клиентом.
Если у вас есть терминал на компьютере или доступ к серверу, можно использовать утилиту curl.
Сначала отправьте запрос без автоматического перехода по перенаправлениям:
curl -I https://example.com/Параметр -I запрашивает заголовки ответа. Если сервер возвращает перенаправление, найдите HTTP-статус и заголовок Location.
Например:
HTTP/2 301
location: https://www.example.com/Затем выполните запрос к адресу, указанному в Location, и сравните результат.
Для просмотра цепочки переходов можно выполнить:
curl -L -I -v --max-redirs 10 https://example.com/Параметр -L разрешает переходы по редиректам, -I запрашивает заголовки, -v выводит подробности обмена, а --max-redirs 10 ограничивает число переходов десятью.
Если после нескольких переходов адрес начинает повторяться, вы обнаружили цикл.
Важно: запрос HEAD, который выполняется с параметром -I, некоторые приложения обрабатывают иначе, чем обычный GET. Если результат отличается от поведения браузера, проверьте цепочку обычным GET-запросом:
curl -L -v --max-redirs 10 -o /dev/null https://example.com/Эта команда предназначена для Linux и macOS. На Windows можно воспользоваться подходящим терминалом или выполнить запрос без параметра сохранения результата.
Не передавайте в сторонние сервисы проверки приватные URL, авторизационные cookies и ссылки с секретными токенами.
После получения цепочки проверьте, где формируется каждый переход: в самой CMS, в конфигурации Apache или Nginx, на уровне хостинга, CDN либо обратного прокси.
Например, если сайт использует Cloudflare, сравните поведение запросов через CDN и непосредственно к исходному серверу. Выполняйте прямую проверку только при наличии разрешённого доступа к серверу и понимания его конфигурации.
Если цикл возникает только для авторизованных пользователей, проверьте логику входа и работу сессий. Если ошибка появляется только на конкретном URL, ищите правило, которое затрагивает именно этот адрес.
Одна из распространённых причин ERR TOO MANY REDIRECTS - неправильная настройка перенаправления между HTTP и HTTPS.
HTTPS обеспечивает защищённое соединение между браузером и сайтом. Чтобы использовать его корректно, на сервере необходимо настроить TLS и соответствующий сертификат.
При этом сам сертификат не создаёт циклическую переадресацию. Проблема возникает, когда разные компоненты сайта по-разному определяют используемый протокол или выполняют противоречащие друг другу перенаправления.
Откройте сайт по адресам:
http://example.com/
https://example.com/Для сайта, полностью переведённого на HTTPS, нормальная схема обычно выглядит следующим образом: запрос по HTTP перенаправляется на HTTPS, после чего защищённая версия возвращает содержимое страницы со статусом 200 OK.
Если HTTPS-версия снова перенаправляет посетителя на HTTP, необходимо найти и исправить правило обратного перехода.
Не отключайте HTTPS только ради устранения ERR TOO MANY REDIRECTS. Это может нарушить защищённое соединение и работу авторизации, платёжных форм и других функций.
Убедитесь, что на исходном сервере корректно настроен HTTPS, сертификат не просрочен и соответствует используемому доменному имени.
Если сайт работает через CDN, дополнительно проверьте сертификат, который используется между CDN и исходным сервером. Сертификат для посетителей и сертификат исходного сервера могут быть разными.
Ошибка сертификата обычно имеет собственное сообщение в браузере или отдельный код ошибки CDN. Поэтому не стоит считать, что любой сбой HTTPS автоматически вызывает ERR TOO MANY REDIRECTS.
Выберите основной адрес сайта, например https://example.com/, и убедитесь, что все остальные варианты приводят к нему.
Правильная схема может выглядеть так:
http://example.com/
↓
https://example.com/
http://www.example.com/
↓
https://example.com/
https://www.example.com/
↓
https://example.com/Сам по себе выбор версии с www или без www не является причиной ошибки. Важно, чтобы правила не возвращали посетителя с основного адреса обратно на дополнительный.
После проверки HTTP и HTTPS, если сайт использует Cloudflare или другой CDN, переходите к следующему разделу.
Если сайт подключён к Cloudflare, ошибка ERR TOO MANY REDIRECTS может возникать из-за конфликта настроек SSL/TLS и правил перенаправления на исходном сервере.
Cloudflare располагается между посетителем и сервером сайта. Поэтому протокол, по которому посетитель подключается к Cloudflare, не всегда совпадает с протоколом соединения Cloudflare с исходным сервером.
В режиме Flexible посетитель может подключаться к Cloudflare по HTTPS, а Cloudflare обращается к исходному серверу по HTTP.
Если на исходном сервере действует правило принудительного перенаправления всех HTTP-запросов на HTTPS, возникает конфликт:
Посетитель → HTTPS → Cloudflare
↓
HTTP → Сервер
↓
Редирект на HTTPS
↓
Cloudflare
↓
HTTP → Сервер
↓
Повторение циклаБраузер получает повторяющиеся перенаправления и прекращает загрузку сайта.
Важно: нельзя просто переключить любой сайт в режим Full (strict), не проверив сертификат исходного сервера. Если сертификат отсутствует, недействителен или не соответствует домену, вместо ошибки переадресации может появиться ошибка защищённого соединения.
Режим Full позволяет использовать HTTPS между Cloudflare и исходным сервером без полноценной проверки доверия к сертификату, однако для постоянной конфигурации следует настроить действительный сертификат и использовать Full (strict).
Дополнительно проверьте раздел SSL/TLS → Edge Certificates и настройку Always Use HTTPS, а также правила Redirect Rules и Page Rules, если они используются.
Если Cloudflare перенаправляет HTTP на HTTPS, а исходный сервер выполняет обратный переход, устраните противоречие. Не требуется отключать все перенаправления подряд: необходимо найти конкретное конфликтующее правило.
Официальные инструкции: ERR TOO MANY REDIRECTS в Cloudflare и настройка режима Full (strict).
На WordPress циклическая переадресация часто связана с неправильными URL сайта, настройками HTTPS, обратного прокси или расширениями, которые управляют авторизацией и перенаправлениями.
Если ошибка появилась после обновления WordPress, подключения SSL-сертификата, переноса сайта или установки нового плагина, начните с проверки последних изменений.
Перед редактированием конфигурации создайте резервную копию файлов и базы данных. По возможности проводите диагностику на тестовой копии сайта.
Если административная панель доступна, откройте «Настройки» → «Общие».
Найдите поля «Адрес WordPress (URL)» и «Адрес сайта (URL)».
Обычно, если WordPress установлен непосредственно в корневом каталоге домена, оба адреса совпадают:
https://example.com
https://example.comПроверьте правильность протокола, домена, наличия www и пути установки.
Важно: если WordPress установлен в отдельном подкаталоге, адрес WordPress и адрес сайта могут намеренно различаться. Не делайте их одинаковыми без проверки структуры конкретной установки.
Если значения указаны неправильно, исправьте их и сохраните настройки.
Если административная панель недоступна, подключитесь к серверу через SFTP или файловый менеджер хостинга. Откройте файл wp-config.php, расположенный в корневом каталоге установки WordPress или на один уровень выше, если используется поддерживаемая конфигурация.
Проверьте, существуют ли в файле определения WP_HOME и WP_SITEURL.
Для обычной установки WordPress в корне домена значения могут выглядеть так:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Замените example.com на адрес своего сайта. Если WordPress установлен в подкаталоге, учитывайте фактическое расположение файлов движка.
Эти константы переопределяют соответствующие значения из базы данных, но не изменяют их непосредственно в таблицах.
Если параметры уже определены, измените существующие значения, а не добавляйте повторные определения.
Размещайте константы в разделе настроек до строки require_once ABSPATH . 'wp-settings.php';.
Если временное указание правильных URL восстановило работу, проверьте также значения home и siteurl в базе данных. Не оставляйте конфликтующие настройки без выяснения причины.
Подробная инструкция: изменение URL сайта в WordPress.
Если вы уверены, что ошибка связана с адресом сайта, но административная панель не открывается, проверьте настройки через phpMyAdmin или другой инструмент управления базой данных.
wp_options, но префикс может отличаться.Для проверки можно использовать SQL-запрос, заменив wp_options на реальное имя таблицы:
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('home', 'siteurl');Не выполняйте массовую замену URL во всей базе данных только ради исправления этих двух настроек. В WordPress некоторые данные хранятся в сериализованном виде, поэтому необдуманная замена строк может повредить настройки и содержимое.
Если ошибка появилась после установки или обновления плагина, который управляет HTTPS, авторизацией, кешированием или редиректами, временно отключите подозрительное расширение.
При доступной административной панели это можно сделать в разделе «Плагины».
Если административная панель тоже показывает ERR TOO MANY REDIRECTS, откройте файловый менеджер хостинга или подключитесь по SFTP.
Перейдите в каталог wp-content/plugins/, найдите папку предполагаемого проблемного плагина и временно переименуйте её, например:
redirect-plugin
↓
redirect-plugin-disabledПосле этого проверьте работу сайта.
Если ошибка исчезла, изучите настройки расширения и правила, которые оно создаёт. Не ограничивайтесь простым отключением плагина: он мог оставить постоянные перенаправления в .htaccess, настройках сервера или других компонентах сайта.
Если проблемное расширение неизвестно, на тестовой копии можно последовательно отключать плагины и проверять результат. На работающем интернет-магазине массовое отключение расширений может нарушить оформление заказов и оплату.
Если HTTPS завершается на балансировщике нагрузки, CDN или обратном прокси, а WordPress получает запросы по HTTP, движок может неправильно определять протокол соединения.
Например, посетитель открывает сайт по HTTPS, но WordPress считает соединение незащищённым и снова перенаправляет его на HTTPS. Если прокси продолжает передавать запросы приложению по HTTP, образуется цикл.
В такой конфигурации необходимо правильно передавать приложению информацию об исходном протоколе и настроить WordPress для работы за доверенным прокси.
Для этого часто используется заголовок X-Forwarded-Proto. Однако доверять этому заголовку можно только в том случае, если ваш прокси контролирует и корректно устанавливает его значение. Нельзя безусловно принимать произвольный заголовок от посетителя как подтверждение защищённого соединения.
Если сайт размещён на обычном виртуальном хостинге и вы не управляете прокси, обратитесь к хостинг-провайдеру за проверкой конфигурации.
Дополнительная информация приведена в официальной документации WordPress по HTTPS и работе за обратным прокси.
На OpenCart циклическая переадресация может появиться после включения HTTPS, переноса магазина на другой домен или хостинг, изменения конфигурационных файлов и установки SEO-модулей.
Особенности диагностики зависят от версии OpenCart, модификаций движка и установленного шаблона. Структура конфигурационных файлов и механизм формирования URL в OpenCart 1.5, 2.x, 3.x и 4.x различаются, поэтому не следует автоматически переносить настройки одной версии на другую.
Попробуйте открыть главную страницу магазина, категорию, карточку товара и административную панель.
Если циклическая переадресация возникает только в административной панели, проверьте настройки её URL, HTTPS и авторизации.
Если ошибка появляется только на карточках товаров или категориях, проверьте SEO-модули, правила обработки ЧПУ и канонизации адресов.
Если не открывается ни одна страница, начните с проверки общих настроек домена, протокола и веб-сервера.
На старых версиях OpenCart адреса витрины и административной части могут задаваться в файлах config.php и admin/config.php.
Например, для установки OpenCart 3.x можно встретить такие определения:
define('HTTP_SERVER', 'http://example.com/');
define('HTTPS_SERVER', 'https://example.com/');Это только пример структуры настроек. Фактические имена констант, их использование и расположение конфигурации необходимо проверять применительно к установленной версии OpenCart.
Убедитесь, что адреса указывают на правильный домен, учитывают фактический путь установки и не противоречат правилам принудительного HTTPS.
Если магазин перенесён с одного домена на другой, проверьте, не остались ли в конфигурации ссылки на старый домен.
Не меняйте HTTP_SERVER и HTTPS_SERVER на одинаковые значения автоматически: в разных версиях OpenCart эти параметры могут использоваться по-разному.
Если административная панель открывается, проверьте основные настройки магазина, адреса витрины и параметры HTTPS, предусмотренные вашей версией движка.
При использовании нескольких магазинов (мультимагазин OpenCart) отдельно проверьте домены и протоколы каждой витрины.
Если один магазин перенаправляет посетителей на адрес другого, а второй возвращает их обратно, необходимо исправить соответствующие настройки.
Если ошибка появилась после установки SEO-расширения, проверьте правила формирования ЧПУ, канонических URL и перенаправления дублирующихся адресов.
Особенно внимательно проверьте правила, которые автоматически добавляют или удаляют завершающий слеш, изменяют регистр URL, переключают www или изменяют HTTPS.
Например, одно расширение может перенаправлять адрес /catalog на /catalog/, а другое - выполнять обратный переход.
Если ошибка связана с конкретным модулем, отключите его предусмотренным вашей версией OpenCart способом, обновите модификаторы при необходимости и проверьте результат.
Не удаляйте наугад системные файлы и содержимое каталогов модификаторов. Сначала сохраните резервную копию и определите источник проблемного правила.
Если в настройках OpenCart используются правильные адреса, но ERR TOO MANY REDIRECTS сохраняется, проверьте .htaccess, Nginx, CDN и настройки HTTPS в панели хостинга.
Нередко редирект на HTTPS настроен одновременно в нескольких местах. Само по себе дублирование одинакового перенаправления не обязательно создаёт цикл, однако противоречащие условия и неправильное определение протокола способны нарушить работу магазина.
После исправления проверьте не только главную страницу, но и корзину, авторизацию, оформление заказа и административную панель.
Если сайт работает на Apache и использует файл .htaccess, циклическая переадресация может быть вызвана ошибкой в правилах RewriteRule, RewriteCond или Redirect.
Перед изменением файла создайте его резервную копию. Затем определите по цепочке HTTP-ответов, какое именно правило вызывает повторный переход.
Например, в конфигурации может существовать правило, перенаправляющее посетителя на HTTPS, а другой компонент может принудительно возвращать его на HTTP.
Аналогичная ситуация возникает, когда одно правило добавляет www, а другое удаляет его.
Исправлять необходимо сам конфликт, а не просто удалять все перенаправления из .htaccess.
Для обычного сайта на Apache, где TLS завершается непосредственно на том же веб-сервере, базовое правило может выглядеть следующим образом:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Замените example.com на свой домен. Пример предполагает, что выбран основной адрес без www и Apache корректно определяет защищённое соединение.
Важно: это правило нельзя без проверки применять к любому серверному окружению. Если HTTPS завершается на внешнем прокси, Apache может получать от него HTTP-запросы и считать, что соединение незащищено. В результате правило будет многократно перенаправлять посетителя на HTTPS.
При использовании обратного прокси настройте правильную передачу и обработку информации об исходном протоколе. Если вы не управляете конфигурацией сервера, попросите хостинг-провайдера проверить настройки.
Не заменяйте весь .htaccess случайным примером из интернета. В файле могут находиться необходимые правила ЧПУ, защиты каталогов, обработки PHP и другие настройки, без которых сайт перестанет работать.
Официальная документация: Redirecting and Remapping with mod_rewrite.
Если сайт работает на Nginx, необходимо проверить конфигурацию виртуального хоста, правила return и rewrite, настройки проксирования и определение протокола.
На виртуальном хостинге пользователь может не иметь прямого доступа к конфигурации Nginx. В таком случае проверьте доступные настройки домена в панели управления или обратитесь к хостинг-провайдеру.
Найдите конфигурацию нужного домена и проверьте, как обрабатываются HTTP- и HTTPS-запросы.
Для простого сайта, где Nginx непосредственно принимает HTTPS-соединения, перенаправление HTTP на HTTPS может быть настроено отдельным серверным блоком:
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}Это пример только HTTP-блока. Для полноценной работы сайта необходим отдельно настроенный HTTPS-блок с корректным сертификатом и обработкой запросов.
Если используется прокси или балансировщик нагрузки, правила необходимо адаптировать к фактической схеме соединения.
Проверьте, нет ли другого правила, которое возвращает запросы с HTTPS на HTTP или перенаправляет выбранный основной домен обратно на дополнительный.
Если Nginx передаёт запросы Apache, PHP-приложению или другому серверу, убедитесь, что промежуточный сервер получает правильную информацию об исходном протоколе и домене.
Если приложение считает, что запрос пришёл по HTTP, хотя посетитель открыл HTTPS-страницу, оно может многократно выполнять перенаправление.
Проверьте передачу заголовков Host и X-Forwarded-Proto, а также настройки доверенных прокси в самом приложении.
Не используйте произвольные значения заголовков, полученных непосредственно от посетителя, как подтверждение защищённого соединения.
Если у вас есть административный доступ к серверу, после редактирования конфигурации Nginx выполните проверку синтаксиса:
sudo nginx -tЕсли конфигурация корректна, примените изменения штатным способом:
sudo systemctl reload nginxКоманды приведены для типичного Linux-сервера с systemd и могут отличаться в зависимости от операционной системы и способа установки Nginx.
Если проверка синтаксиса завершилась ошибкой, не перезагружайте сервер с неправильной конфигурацией. Сначала исправьте указанную проблему.
После исправления конфигурации старая ошибка иногда продолжает появляться из-за сохранённых перенаправлений.
Проверьте кеш браузера, серверный кеш, кеширующие плагины и CDN. Если проблема связана с конкретным закешированным ответом, удалите его и повторно проверьте страницу.
Не очищайте весь кеш интернет-магазина без необходимости: это может временно увеличить нагрузку на сервер.
Если сайт работает через CDN, убедитесь, что актуальные правила перенаправления применяются на всех используемых уровнях инфраструктуры.
После миграции сайта на новый хостинг, сервер или домен необходимо проверить не только файлы и базу данных, но и правила перенаправления.
Например, после смены домена может остаться следующая конфигурация:
old-domain.example
↓
new-domain.example
↓
old-domain.exampleПервый редирект может находиться в настройках старого хостинга, а второй - в CMS, на новом сервере или в SEO-модуле.
Если старый домен должен перенаправлять посетителей на новый, проверьте, что обратный редирект отсутствует.
Для постоянного переноса обычно используется HTTP 301. При этом необходимо учитывать соответствие старых и новых URL, чтобы посетители попадали на подходящие страницы, а не перенаправлялись все подряд на главную.
После устранения ошибки проверьте, что старые URL завершаются корректной страницей нового сайта, а цепочки перенаправления не содержат лишних переходов.
Иногда главная страница сайта работает нормально, но после попытки авторизации появляется ошибка циклической переадресации.
Например, пользователь вводит логин и пароль, сайт перенаправляет его в личный кабинет, но затем снова возвращает на страницу входа.
Причиной может быть неправильная работа сессии, cookies или логики проверки авторизации.
Если ошибка сохраняется только после ввода логина и пароля, сообщите об этом администрации сайта.
Проверьте, создаётся ли сессия после авторизации и сохраняется ли она при следующем запросе. Убедитесь, что cookies имеют подходящие настройки Domain, Path, Secure и SameSite.
Если авторизация выполняется на одном домене, а личный кабинет расположен на другом, проверьте, передаются ли необходимые данные сессии при переходе.
Также проверьте совместимость настроек авторизации с HTTPS и конфигурацией обратного прокси.
На WordPress дополнительно проверьте плагины авторизации, безопасности и перенаправления пользователей. На OpenCart - настройки административной панели, пользовательских сессий и модулей, изменяющих процесс входа.
Если ошибка воспроизводится только для определённого пользователя, сравните последовательность редиректов в обычном режиме и после авторизации.
Циклическая переадресация мешает не только посетителям, но и поисковым роботам. Если робот не может получить конечное содержимое страницы, это способно нарушить её обход и индексирование.
Если проблема затрагивает главную страницу или большое количество URL, последствия могут быть заметнее, чем при ошибке на одной второстепенной странице.
Однако нельзя утверждать, что любой кратковременный сбой обязательно приводит к потере поисковых позиций. Последствия зависят от продолжительности ошибки, количества затронутых страниц и того, какие ответы получали поисковые системы.
Не закрывайте проблемные страницы от индексации и не создавайте новые редиректы только ради скрытия ошибки. Сначала необходимо устранить причину циклической переадресации.
Подробнее о перенаправлениях и индексировании можно прочитать в документации Google Search Central.
Это сообщение означает, что браузер выполнил слишком много перенаправлений и не смог открыть конечную страницу. Причиной может быть циклический переход между адресами, конфликт настроек HTTPS или неправильная работа авторизации.
ERR TOO MANY REDIRECTS - это сообщение браузера, а не отдельный стандартный HTTP-код. В цепочке перенаправлений обычно встречаются HTTP-ответы 301, 302, 307 или 308. Для диагностики необходимо посмотреть, какие URL указаны в заголовках Location и на каком этапе переходы начинают повторяться.
Это происходит, когда браузер не может завершить переходы между адресами. Например, сайт перенаправляет посетителя с HTTP на HTTPS, а другой компонент возвращает его обратно. Браузер прекращает загрузку после превышения допустимого количества перенаправлений.
Да, если ошибка связана с устаревшей авторизационной сессией или неправильными данными, сохранёнными в браузере. Однако очистка cookies не устранит конфликт правил перенаправления на сервере. Если проблема возникает у всех пользователей, владельцу сайта необходимо проверить его конфигурацию.
Яндекс Браузер может показывать эту ошибку по тем же причинам, что и другие браузеры на Chromium. Проверьте сайт в приватном режиме, удалите cookies конкретного домена и попробуйте открыть страницу в другом браузере. Если проблема воспроизводится везде, необходимо проверить настройки сайта.
Если сообщение появляется при открытии vk.ru или другого сайта, к которому у вас нет административного доступа, начните с проверки cookies, приватного режима, другого браузера и подключения через другую сеть. Если ошибка возникает только после авторизации, проверьте работу сайта без входа в аккаунт. Если проблема сохраняется на разных устройствах, обратитесь в поддержку соответствующего сервиса. Не нужно менять системные настройки своего устройства на основании одной ошибки отдельного сайта.
Да, проблема может воспроизводиться только в определённой сети, если используются промежуточные страницы авторизации, прокси или сетевые фильтры. Проверьте тот же адрес через мобильный интернет. Если ошибка возникает только в одной сети, необходимо выяснить, изменяет ли она запросы или перенаправления.
Возможно, новые правила перехода на HTTPS конфликтуют с существующими перенаправлениями в CMS, на сервере или в CDN. Проверьте последовательность переходов между HTTP и HTTPS, работу исходного сервера и настройки обратного прокси.
Проверьте адрес сайта в настройках CMS, конфигурационные файлы, правила старого и нового хостинга, настройки HTTPS и доменные перенаправления. Убедитесь, что старый домен ведёт на новый, а новый не перенаправляет посетителей обратно.
Да, если у вас есть доступ к файлам, базе данных или настройкам хостинга. Например, на WordPress можно проверить адреса сайта в wp-config.php и базе данных, а также временно отключить конкретный проблемный плагин. Если доступ к серверу отсутствует, обратитесь к администратору или хостинг-провайдеру.
Обычно начинать с переустановки не нужно. Сначала проверьте cookies, цепочку перенаправлений и настройки сайта. Если причина находится в неправильных правилах HTTPS, .htaccess, Nginx или конфигурации CMS, простая переустановка браузера не устранит неисправность.
Если сайт показывает ERR TOO MANY REDIRECTS, сначала проверьте, связана ли ошибка с конкретным браузером или воспроизводится у всех посетителей. В первом случае начните с удаления cookies проблемного сайта и проверки расширений. Во втором - изучите HTTP-ответы и найдите повторяющиеся адреса в цепочке перенаправлений.
Для владельца сайта наиболее важный этап - определить источник конфликта. Проверьте настройки HTTP и HTTPS, основной домен, конфигурацию CMS, правила сервера и параметры CDN. После исправления убедитесь, что все необходимые страницы открываются, авторизация работает и посетители не попадают в новые циклы перенаправления.
Не получается исправить ERR TOO MANY REDIRECTS самостоятельно? Я занимаюсь диагностикой и устранением технических ошибок на WordPress, OpenCart, Joomla, Drupal, MODX, DLE и самописных проектах. Могу найти источник циклической переадресации, исправить настройки HTTPS, серверные правила, конфигурацию CMS и связанные проблемы после переноса сайта. Подробнее об услуге - на странице исправления ошибок сайтов.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Переработал страницы онлайн-оплаты туров: убрал устаревшие даты и служебные элементы, сделал кнопку оплаты заметнее и создал единый шаблон для всех направлений.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.