Создание полезных сайтов
Как исправить цикл перенаправлений на сайте
Найдите повторяющийся переход и ответственное правило, затем проверьте, что читатель попадает на нужную страницу.
1. Запишите переходы до изменения настроек
ERR_TOO_MANY_REDIRECTS означает, что браузер прекратил следовать перенаправлениям. Начните с одного неработающего публичного URL. Запишите полный адрес, выполнен ли вход в аккаунт и повторяется ли ошибка в новой сессии браузера. Предел может быть достигнут и в цикле, и в длинной цепочке; одно сообщение не указывает на виновное правило.
В настольном Chrome откройте DevTools → Network, включите Preserve log и перейдите по неработающему адресу. Выберите каждый запрос документа и посмотрите Request URL, статус и заголовок ответа Location в Headers. Сохраните порядок запросов. HTTP-перенаправление указывает другой адрес; сравните его со следующим запросом. Относительный Location вычисляется от URL запроса.
Запишите короткую цепочку: запрошенный URL → статус → адрес назначения. Найдите первый повтор адреса с учётом протокола, хоста, пути и параметров. Повтор — подсказка; убедитесь, что последовательность продолжает повторяться, а не завершается после изменения состояния сессии. Не включайте cookies и токены входа в публичный отчёт об ошибке.
2. Сравните браузер с простым GET-запросом curl
В терминале Linux или macOS следующая команда для публичной страницы выводит заголовки первого ответа и отбрасывает тело. Замените пример на неработающий URL. Это GET-запрос; добавление -I заменило бы его на HEAD, который может обрабатываться иначе.
curl -q -sS --max-time 20 -D - -o /dev/null 'https://example.com/start'
Чтобы пройти ограниченное число перенаправлений и вывести заголовки ответов по пути, выполните:
curl -q -sS --max-time 20 -L --max-redirs 5 -D - -o /dev/null 'https://example.com/start'
Здесь -L включает следование HTTP-перенаправлениям, --max-redirs 5 ограничивает число переходов, -D - выводит заголовки в терминал, а -o /dev/null отбрасывает тело ответа. -sS скрывает индикатор загрузки, сохраняя сообщения об ошибках. Заголовки могут содержать приватные данные сессии; храните исходный вывод непублично. Первый параметр -q отключает чтение стандартного файла настроек curl; --max-time 20 задаёт общее ограничение в 20 секунд. Истечение времени отличается от превышения числа переходов.
Команда не копирует cookies браузера и не выполняет JavaScript. Считайте её отдельным контекстом запроса. Успех curl не доказывает, что браузер после входа в аккаунт работает. В нашем локальном опыте превышение предела дало код завершения curl 47 и для настоящего цикла, и для длинной цепочки, которая при большем пределе закончилась ответом 200. Увеличение предела помогает различить эти ситуации, но не исправляет повторяющееся правило.
3. Найдите конфликтующие правила по повторяющемуся изменению
Coru проверил специально настроенный локальный сервер 21 октября 2026 года. Это управляемые примеры, а не измерения вашего хостинга. Конечная цепочка /finite-start (301) → /finite-middle (302) → /article (200) привела к нужной странице. Цикл /loop-a (302) → /loop-b (302) → /loop-a повторялся до остановки curl. Отдельный цикл со слешем чередовал ответы 308 и 301. Полезным доказательством было повторяющееся изменение URL, а не только итоговая ошибка.
Например, /guide → /guide/ → /guide повторяет решение о нормализации пути. Найдите правило, добавляющее слеш, и правило, удаляющее его. Выберите один публичный URL и согласуйте участвующие уровни. Замена 301 на 302 не устраняет два противоречащих адреса назначения.
Так же исследуют переходы example.com ↔ www.example.com или http ↔ https. Проверьте правила CDN или прокси, веб-сервера, приложения и CMS. Исходите из наблюдаемого перехода; не отключайте все перенаправления. Старый URL по-прежнему должен приводить к полезной замене.
- Чередуются слеш или хост: сравните правила нормализации на каждом уровне и публичный адрес в настройках приложения.
- Чередуются HTTP и HTTPS либо один HTTPS-адрес постоянно перенаправляет на себя: проверьте соединение прокси с исходным сервером и способ определения исходного протокола приложением.
- Чередуются вход и личный кабинет: сравните один маршрут с проблемной сессией и без неё, затем изучите авторизацию и обработку cookies.
4. Отдельно проверьте HTTPS за прокси и состояние сессии
Cloudflare описывает конкретный пример: в режиме Flexible пограничный сервер соединяется с исходным по HTTP; принудительный переход на HTTPS на исходном сервере может создать цикл. В других SSL-режимах цикл возможен, если исходный сервер отправляет HTTPS обратно на HTTP. Применяйте документированное исправление для фактического режима и возможностей исходного сервера. Отключение публичного HTTPS не является общим решением.
За обратным прокси приложение может видеть соединение, отличающееся от исходного соединения посетителя. X-Forwarded-Proto может передавать исходный протокол. Проверьте настройки доверенных прокси в своём фреймворке и то, что действительно передаёт доверенный прокси; нельзя безусловно доверять заголовку, присланному напрямую произвольным клиентом. Рабочий CDN или фреймворк в локальном опыте мы не проверяли.
В отдельном примере сессии мы использовали намеренно некорректную cookie: чистый запрос открывал страницу входа, а проблемная сессия повторяла переходы между входом и личным кабинетом. Новый контекст браузера тоже открывал страницу. Это подтвердило зависимость от конкретной cookie в нашем примере, а не универсальное исправление удалением cookies.
На своём сайте сначала сравните записанные цепочки. Если сбоит только существующая сессия, изучите срок действия, путь и домен cookies, а также правила входа и выхода приложения. Удаление cookies этого сайта может проверить гипотезу, но может завершить сеанс входа; оно не исправляет правило сервера, которое заново создаёт проблемную сессию. Не начинайте диагностику с удаления всех данных браузера.
5. Если curl заканчивает на 200, а браузер переходит дальше
HTTP-перенаправления описывают только часть браузерной навигации. Страница может вернуть 200, а затем перейти по другому адресу через скрипт или HTML-директиву обновления. В нашем примере с JavaScript curl остановился на первом ответе 200, а Chromium перешёл на вторую страницу, тоже со статусом 200. Цепочки HTTP Location между ними не было.
Оставьте Preserve log включённым и изучите следующий запрос документа и его инициатор. Проверьте предыдущий ответ на скрипт или инструкцию обновления. Прежде чем считать причиной JavaScript, также сравните cookies и точный начальный URL. MDN различает HTTP-перенаправления и переходы через HTML и JavaScript. Различие между браузером и curl требует собственного объяснения.
6. Проверьте исправление с исходного адреса входа
Измените минимальное правило, на которое указывает цепочка, затем повторно откройте исходный публичный URL в проблемной и новой сессиях браузера. Подтвердите нужное содержимое и итоговый адрес, а не только статус 200: страница входа или ошибки тоже может вернуть 200. Проверьте применимые варианты HTTP/HTTPS, хоста и завершающего слеша, а также реальную старую ссылку, которая должна перенаправляться.
Сохраните запись ремонта: начальный URL → состояние сессии → повторяющийся переход → ответственное правило → изменение → итоговый адрес и содержимое. Полезный результат — читатель попадает на нужную страницу без повторяющейся навигации, а корректные старые ссылки продолжают работать.
Если после исправления настроек браузер ещё использует старое перенаправление, сравните новый контекст и проверьте кеширование, прежде чем менять другое правило. Связанное руководство об устаревшей странице поможет отличить старый ответ от текущей конфигурации. Наш опыт охватывает заданные локальные маршруты, одну сборку curl и одну сборку Chromium; он не подтверждает работоспособность вашего кеша, авторизации или прокси.