Основной сайт отправляет телефон на m.example.com, а мобильный домен возвращает его обратно. Ошибка может зависеть от User-Agent, cookies и признака HTTPS на прокси. Чтобы найти причину, повторяйте переходы по матрице условий и сохраняйте каждое значение Location.
Снимите цепочку до первого повторения адреса
Для каждого домена определите конечное ожидаемое назначение. Разделите выбор версии сайта и перевод на HTTPS. Условия прокси должны отражать исходный протокол посетителя; иначе один слой будет отменять решение другого.
Серверные перенаправления задают переход посредством HTTP-ответа и заголовка Location. Официальная документация.
В Network включите сохранение журнала и откройте основной адрес заново. Выпишите каждый документный запрос, статус и Location до первого повторения URL. При цикле браузер может показывать только итоговую ошибку, поэтому цепочка важнее скриншота. Укажите точный адрес входа и условия сеанса. Если сервер меняет только протокол, смотрите HTTPS-правила; если хост, смотрите выбор версии. Эти причины могут сочетаться. Не увеличивайте лимит переходов как предполагаемое исправление: повторение адреса показывает конфликт решений, который нужно устранить.
Матрица устройства, cookie и протокола
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| Desktop без cookie | Основная версия | Проверить конечный хост | Нет возврата |
| Mobile без cookie | Мобильная политика | Записать цепочку | Нет цикла |
| Mobile с desktop-cookie | Выбор пользователя | Сохранить намерение | Проверить исключение |
| HTTP через прокси | Перевод на HTTPS | Сверить исходную схему | Не повторять редирект |
Проверьте desktop и mobile User-Agent в чистом сеансе, затем с cookie ручного выбора. Добавьте HTTP и HTTPS вход на оба домена. Для каждой комбинации задайте ожидаемое конечное место до изменения правил. Так видно, возникает ли петля только на телефоне или после сохранённого предпочтения. Если мобильная версия больше не используется, это должно быть отдельным подтверждённым архитектурным решением. Нельзя просто удалить её правило, считая любой вход на основной домен правильным. Матрица сохраняет намерение продукта и помогает оценить границы исправления.
Проверьте обработку исходной схемы за прокси
Проверьте desktop и mobile User-Agent, чистую и сохранённую cookie, HTTP и HTTPS вход. Запишите последовательность хостов и схем. Сравните правила приложения, CDN и веб-сервера на месте первого повторения адреса.
При TLS-терминации на CDN или reverse proxy приложение может получать внутренний HTTP и ошибочно считать посетителя незащищённым. Проверьте предусмотренные заголовки передачи исходной схемы и доверие к конкретному прокси. Не включайте безусловное доверие произвольному клиентскому заголовку: его значение должно формироваться вашей инфраструктурой. Сравните публичный вход и журнал приложения, не раскрывая приватные данные. Если HTTPS-редирект повторяется независимо от мобильного домена, сначала локализуйте этот конфликт. Выбор устройства и исправление исходного протокола являются разными частями маршрутизации.
Учебная петля основного и мобильного домена
Учебная петля появляется только у mobile без cookie: основной домен выбирает m., а m. принудительно возвращает основной домен. Успешный desktop-прогон поэтому не является приёмкой исправления.
Учебный основной домен отправляет mobile на m.example.com, а мобильный домен имеет общее правило возвращения на example.com. После второго ответа адрес повторяется. Зафиксируйте эту пару отдельно от длинной истории переходов. Затем измените одну конфликтующую политику на тестовой копии и проверьте тот же mobile-запрос без cookie. Desktop-прогон мог быть успешным и до изменения, поэтому он не подтверждает устранение исходного сбоя. Добавьте прямой вход на m.: он должен иметь предусмотренное назначение, а не снова создавать ту же петлю.
Назначьте одного владельца выбора версии
Уберите конфликт условий и выберите единственного владельца маршрутизации версии. Исправление начинайте с воспроизводимой пары переходов. После устранения цикла проверьте обычное открытие обеих версий и ручное переключение.
Определите, какой слой решает выбор основной или мобильной версии: CDN, сервер или приложение. Другие слои должны согласовываться с его результатом. Сохраните нужный переход на HTTPS, но не дублируйте устройство-зависимое правило в двух местах. Проверьте порядок точных исключений и общего обработчика. Если нужна миграция m. на адаптивную основную версию, подготовьте соответствие путей как отдельную работу. Устранение цикла не даёт оснований автоматически изменить архитектуру всего сайта или заменить карточки главной страницей.
Проверьте ручное переключение и сохранённый выбор
Удаление всех мобильных правил может скрыть цикл и сломать предусмотренный доступ. Сначала выясните архитектуру сайта; переход на адаптивный дизайн — отдельная задача.
Пользователь может намеренно выбрать desktop на телефоне. Проверьте переключатель, срок и область действия соответствующей cookie, а затем обновление страницы и возврат по сохранённой ссылке. Не исправляйте петлю удалением любого выбора пользователя без понимания интерфейса. Убедитесь, что cookie доступна нужному домену по предусмотренной политике и не содержит лишних приватных значений. Если механизм использует параметр URL, проверьте, что редирект сохраняет его смысл. Результат ручного переключения входит в приёмку, поскольку именно этот сценарий часто создаёт отличия между сеансами.
Приёмка всех входов в чистом сеансе
После релиза повторите все комбинации матрицы, начиная с чистых данных. Запишите конечный URL и число переходов, а не только отсутствие сообщения браузера. Проверьте конкретную внутреннюю страницу на обоих доменах, чтобы путь не потерялся в исправленном правиле. Затем повторите ручной выбор и обычную навигацию. Если петля исчезла только в авторизованном сеансе владельца, работа ещё не завершена. Итоговая карта должна показывать конечное назначение каждой принятой комбинации и отдельно отмечать сценарии, которые не удалось воспроизвести на доступном устройстве.
Критерии завершения проверки
Ни одна комбинация контрольных условий не возвращается к уже посещённому адресу. Пользователь получает нужную версию, ручное переключение сохраняется, HTTPS определяется согласованно.
- Desktop без cookie: Нет возврата. Зафиксируйте фактический результат и адрес проверенного сценария.
- Mobile без cookie: Нет цикла. Зафиксируйте фактический результат и адрес проверенного сценария.
- Mobile с desktop-cookie: Проверить исключение. Зафиксируйте фактический результат и адрес проверенного сценария.
- HTTP через прокси: Не повторять редирект. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Как исправить бесконечный цикл редиректов и Как использовать reChecker для анализа редиректов. Отдельные проверки сайта собраны на странице технического аудита reChecker.