Основной сайт отправляет телефон на m.example.com, а мобильный домен возвращает его обратно. Ошибка может зависеть от User-Agent — строки с типом браузера, cookies — сохранённого выбора пользователя — и признака HTTPS на промежуточном сервере. Чтобы найти причину, повторите вход с телефона и компьютера, с cookie выбора версии и без неё. Сохраняйте адрес каждого перехода из служебного заголовка ответа Location.
Сохраните адреса до первого повторения
Серверные перенаправления задают переход посредством HTTP-ответа и заголовка Location. Официальная документация.
В Network включите сохранение журнала и откройте основной адрес заново. Выпишите каждый документный запрос, статус и Location до первого повторения URL. При цикле браузер может показывать только итоговую ошибку, поэтому цепочка важнее скриншота. Укажите точный адрес входа и условия сеанса. Если сервер меняет только протокол, смотрите HTTPS-правила; если хост, смотрите выбор версии. Эти причины могут сочетаться. Не увеличивайте лимит переходов как предполагаемое исправление: повторение адреса показывает конфликт решений, который нужно устранить.
В терминале разработчик может проверить правило для строки мобильного браузера:
curl -sS -L --max-redirs 10 -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' -D headers.txt -o response.html 'https://example.com/service/'При цикле curl остановится после десяти переходов и сообщит ошибку. В headers.txt ищите повторение адресов мобильного и основного доменов. Не увеличивайте лимит как исправление: повторяющуюся пару правил нужно устранить. Замените example.com своим доменом; этот GET не изменяет настройки сайта. Справка curl.
Код curl 47 означает достижение лимита редиректов. Найдите повтор адреса в сохранённых Location. Этот User-Agent помогает воспроизвести серверное правило, но сам по себе не делает запрос настоящим мобильным браузером.
Повторите вход с разными условиями
| Откуда входит посетитель | Какие правила действуют | Что исправить | Как подтвердить отсутствие цикла |
|---|---|---|---|
| Компьютер без сохранённого выбора | Основная версия | Проверить конечный хост | Нет возврата |
| Телефон без сохранённого выбора | Мобильная политика | Записать цепочку | Нет цикла |
| Телефон с выбором версии для компьютера | Выбор пользователя | Сохранить намерение | Проверить исключение |
| HTTP через прокси | Перевод на HTTPS | Сверить исходную схему | Не повторять редирект |
Проверьте HTTPS за доверенным прокси
Попросите разработчика проверить, не завершается ли HTTPS на промежуточном сервере перед приложением. Тогда приложение может получать внутренний HTTP и ошибочно считать посетителя незащищённым. Проверьте предусмотренные заголовки передачи исходной схемы и доверие к конкретному прокси. Не включайте безусловное доверие произвольному клиентскому заголовку: его значение должно формироваться вашей инфраструктурой. Сравните публичный вход и журнал приложения, не раскрывая приватные данные. Если переход на HTTPS повторяется независимо от мобильного домена, найдите и исправьте настройку, из-за которой приложение принимает HTTPS за HTTP. После этого снова проверьте переключение мобильного домена.
Воспроизведите конфликт двух доменов
Допустим, основной домен отправляет телефон на m.example.com, а мобильный домен имеет общее правило возвращения на example.com. После второго ответа адрес повторяется. Зафиксируйте эту пару отдельно от длинной истории переходов. На тестовой копии измените одно из двух конфликтующих правил и снова войдите с телефона без cookie. Успешный вход с компьютера недостаточен: там цикл мог не появляться и раньше. Добавьте прямой вход на m.: он должен иметь предусмотренное назначение, а не снова создавать ту же петлю.
Оставьте выбор версии в одном месте
Определите, какой слой решает выбор основной или мобильной версии: CDN, сервер или приложение. Уберите противоположные правила на других уровнях: CMS не должна отправлять назад посетителя, которого CDN перевёл на мобильный домен. Сохраните нужный переход на HTTPS, но не дублируйте устройство-зависимое правило в двух местах. Проверьте порядок точных исключений и общего обработчика. Если нужна миграция m. на адаптивную основную версию, подготовьте соответствие путей как отдельную работу. Устранение цикла не даёт оснований автоматически изменить архитектуру всего сайта или заменить карточки главной страницей.
Проверьте прямой вход на оба домена
Телефон без cookie открывает выбранную версию без возврата к уже посещённому URL. Повторите внутреннюю страницу на обоих доменах и ручное переключение: путь и выбор пользователя должны сохраниться. Правило HTTPS также не должно повторяться.
Читайте также: Как исправить бесконечный цикл редиректов и Как использовать reChecker для анализа редиректов. Проверки сайта доступны на странице технического аудита reChecker.