ERR_TOO_MANY_REDIRECTS: что значит и как исправить

Что сделать прямо сейчас

Если вы просто открываете сайт:

1. Откройте сайт в режиме инкогнито: Ctrl+Shift+N, на Mac — Cmd+Shift+N. В этом режиме сайт не получает файлы cookie, которые Chrome сохранил раньше.
2. Если в режиме инкогнито сайт открылся, удалите файлы cookie этого сайта. Как это сделать, написано в справке Chrome.
3. Если и в режиме инкогнито ошибка та же, дело на стороне сайта. Сообщите владельцу адрес страницы и код ошибки ERR_TOO_MANY_REDIRECTS.

Если сайт ваш, переходите к разделам «Как проверить» и «Как исправить» ниже: там все команды по шагам.

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

Перенаправление, или редирект, — ответ сервера «эта страница находится по другому адресу»: код 301, 302, 303, 307 или 308 и строка Location с новым адресом. Браузер сам переходит по нему. Если новый адрес снова перенаправляет на старый — или по цепочке возвращает к нему, — получается петля.

По кругу Chrome ходит недолго: в его исходном коде предел — 20 перенаправлений. Когда предел превышен, Chrome прекращает загрузку и показывает ошибку ERR_TOO_MANY_REDIRECTS. В исходном коде Chrome это ошибка -310.

Как выглядит в Chrome

Заголовок — «Страница недоступна», под ним — «Сайт example.com выполнил переадресацию слишком много раз.» Ниже — совет «Попробуйте удалить файлы cookie»: вся эта фраза — ссылка на справку Chrome. Внизу — код ERR_TOO_MANY_REDIRECTS и кнопка «Перезагрузить».

Причины

• Сайт перенаправляет сам на себя. Например, правило «переходи на https://» стоит в блоке server, который и так обслуживает https://. Посетитель уже на https://, а сервер снова отправляет его туда же.
• Два правила спорят. Одно перенаправляет с адреса с www на адрес без www, другое — обратно. Так бывает, когда одно правило задано в nginx, а другое — в настройках сайта или в панели хостинга.
• Сайт стоит за прокси или CDN. Посетитель приходит по https://, а прокси обращается к серверу сайта по http://. Сервер видит http:// и перенаправляет на https://, браузер снова идёт через прокси, прокси снова приходит по http:// — и так по кругу. В документации WordPress такая петля описана для сайтов за прокси, который сам принимает HTTPS.
• Файлы cookie. Сайт может перенаправлять посетителя в зависимости от cookie — например, со страницы входа в личный кабинет и обратно. Если сохранённый cookie устарел или испорчен, перенаправления могут пойти по кругу. Поэтому Chrome и советует удалить файлы cookie.

Как проверить

Шаги 1 и 2 выполните на своём компьютере: на Mac — в программе Терминал, в Windows — в командной строке. Если вы ни разу не открывали терминал, начните с инструкции Как открыть терминал: там всё по шагам. Скопируйте команду целиком, замените example.com на адрес своего сайта и нажмите Enter.

Шаг 1. Посмотрите, куда перенаправляет сайт

curl -sSIL --max-redirs 5 https://example.com/

Ключ -I просит у сервера только заголовки ответа, -L — переходить по перенаправлениям, --max-redirs 5 — остановиться после пяти переходов.

На каждый переход curl покажет блок строк. В первой строке блока — код ответа, например 301 или 302, в строке Location — адрес, на который сервер отправляет дальше. Если адреса в строках Location повторяются, это петля. После пяти переходов curl остановится и напишет:

curl: (47) Maximum (5) redirects followed

Если последний блок начинается с кода 200, по этому адресу петли нет.

Шаг 2. Проверьте адреса с http:// и с www

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

curl -sSIL --max-redirs 5 http://example.com/

curl -sSIL --max-redirs 5 https://www.example.com/

Если curl ни на одном адресе петли не нашёл, а в Chrome ошибка остаётся и в режиме инкогнито, проверьте страницу, на которой она появляется: укажите в команде её полный адрес.

Шаг 3. Найдите перенаправления в настройках nginx

Эту команду выполните на сервере. Если вы ещё не подключались к нему, начните с инструкции Как подключиться к VPS по SSH.

sudo nginx -T 2>/dev/null | grep -E 'configuration file|listen|server_name|return|rewrite'

Команда выберет из всех настроек nginx строки с путями к файлам настроек (configuration file), портами (listen), именами сайтов (server_name) и перенаправлениями (return и rewrite). Найдите блок, где рядом стоят listen 443 и имя вашего сайта. Если в этом блоке есть return 301 на https:// с тем же адресом, это и есть петля.

Как исправить

Перенаправление на https:// — только в блоке с портом 80

Правило «переходи на https://» должно стоять только в блоке server, который слушает порт 80. Блок с портом 443 должен отдавать сайт, а не перенаправлять на самого себя. Пример правильной схемы:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    # здесь сертификат и остальные настройки сайта
}

Откройте файл настроек сайта командой sudo nano /etc/nginx/sites-available/example.com — путь к своему файлу вы видели на шаге 3 в строке configuration file. Найдите блок с listen 443 и удалите из него строку return 301 https://…, которая ведёт на этот же адрес.

Сохраните файл — Ctrl+O, Enter, затем Ctrl+X — и проверьте настройки:

sudo nginx -t

В ответе должны быть слова syntax is ok и test is successful. Если вместо них сообщение об ошибке, в нём указаны файл и номер строки: исправьте строку и проверьте снова. Когда проверка прошла, примените настройки:

sudo systemctl reload nginx

Если команда ничего не ответила, настройки применены. Затем повторите шаг 1.

Если сайт за прокси или CDN

Есть два способа разорвать петлю:

• Настройте прокси или CDN так, чтобы он обращался к серверу сайта по https://.
• Или научите сайт узнавать, что посетитель пришёл по https://. Прокси может сообщать это сайту в заголовке X-Forwarded-Proto, если он так настроен.

Если прокси — ваш собственный nginx, проверьте, что в блоке location со строкой proxy_pass есть такая строка:

proxy_set_header X-Forwarded-Proto $scheme;

Для WordPress добавьте в файл wp-config.php в корне сайта, сразу после первой строки <?php, такой код — он сообщает WordPress, что посетитель пришёл по HTTPS:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Если петля зависит от cookie

Если ошибка пропадает после удаления cookie, проверьте в программе сайта перенаправления, которые зависят от входа: например, страница входа отправляет в личный кабинет, а кабинет — обратно на вход, потому что не принял cookie.

На обычном хостинге

Если перенаправление на https:// или на адрес с www (или без www) включено и в панели хостинга, и в настройках сайта, правила могут спорить друг с другом. Оставьте одно из них. Если не помогло, напишите в поддержку хостинга адрес сайта и код ошибки.

Соседние ошибки

Источники

• Исходный код Chromium: net_error_list.h — ошибка -310; url_request.h — предел в 20 перенаправлений; localized_error.cc — что Chrome пишет на странице ошибки.
• Документация curl — ключи -I, -L и --max-redirs.
• Документация nginx: return и proxy_set_header.
• Справка Chrome: как удалить файлы cookie.
• Документация WordPress: HTTPS — петля перенаправлений у сайта за прокси.

Проверено в Chrome 155 на локальном тестовом сервере 8 октября 2026 года.

Сверено 8 октября 2026 года.

Что почитать дальше

• 301 Moved Permanently — как настроить постоянное перенаправление.
• Бесплатный SSL-сертификат — как включить HTTPS на сайте.
• «Не удается получить доступ к сайту» — коды ошибок Chrome и что они значат.