Цепочка редиректов: как проверить и убрать лишние 301 и 302

Расскажу историю, которая до сих пор меня немного злит. Прошлой весной мучился с лендингом одного клиента: на компе летает, а с телефона открывается так, будто его через болото тащат. Бэкенд шустрый. Картинки пожаты. CDN подключён. А первый байт на мобиле всё равно приходит позже, чем хочется. Я день потратил, грешил на что угодно — от провайдера до фазы луны.

А причина оказалась глупой до обидного. Если зайти на сайт по http:// и без www, человека перекидывало четыре раза подряд, прежде чем он вообще видел страницу. На офисном вай-фае эти прыжки не чувствуешь. А на 4G где-нибудь в метро каждый добавлял по полсекунды. Вот тебе и «медленный сайт».

Короче, эта статья — как вытащить на свет всю цепочку редиректов по любой ссылке, понять, где в ней лишнее, и сократить до одного перехода. Не теория из учебника, а то, что я сам делаю, когда чувствую: сайт вроде живой, но что-то не то.

Сразу команда, если некогда читать

curl -sILk http://example.com | grep -iE "^HTTP|^location"

-L гонит curl по всем редиректам до конца, -I берёт только заголовки, grep оставляет коды и Location. Получаете весь маршрут как на ладони: сколько прыжков, какими кодами, куда. Правило простое — если строк HTTP больше двух, цепочка есть, и почти наверняка её стоит подрезать.

Ниже — как это всё читать, что считать лишним и чем лечить на nginx и Apache. По порядку.

Что я вообще называю цепочкой

Это когда адрес ведёт не на страницу, а на другой адрес. Тот — на третий. И понеслось. Вот типичное, вижу такое через раз:

http://example.com  →  https://example.com  →  https://www.example.com  →  https://www.example.com/

Каждая стрелочка — это отдельный ответ сервера с кодом 3xx и новый запрос браузера. Формально-то всё ок: до страницы человек доедет. Но четыре прыжка вместо одного — это и есть лишний жир. Если хочется занудного разбора кодов 301/302/307/308 и теории про вред — это есть на странице инструмента проверки редиректов, повторяться не буду. Я тут про руки.

Чем смотреть цепочку: три моих способа

Их у меня ровно три, и выбираю по ситуации.

curl, когда хочется быстро

Та самая команда сверху. Покажу, как читать живой ответ:

HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/2 301
location: https://www.example.com/
HTTP/2 200

Сверху вниз: зашли на http://, получили 301 на https://, оттуда ещё 301 на www, и только третьим ответом — 200, сама страница. Два редиректа. Не смертельно. Но www-прыжок, если он вам по делу не нужен, я бы выкинул.

Ещё трюк, которым пользуюсь постоянно — приклеить замер времени:

curl -sILk -o /dev/null -w "итог: %{time_total}s, код: %{http_code}\n" http://example.com

DevTools, когда цепочка капризничает

Иногда редиректы зависят от того, кто пришёл. Мобилку кидает на m.example.com, баннер про куки добавляет ещё переход, и так далее. curl такое не увидит — он же не браузер, ему на куки и юзер-агент в целом плевать, пока сам не подскажешь. Тогда открываю DevTools, вкладку Network, и — это важно — ставлю галку Preserve log. Без неё записи о редиректах сотрутся, как только страница перескочит, и будете смотреть в пустоту. Дальше грузим страницу и читаем все 3xx с их Location.

Онлайн-проверка, когда нужен взгляд снаружи

Бывает, сайт за корпоративным прокси. Или это вообще чужой ресурс. Или просто лень открывать терминал и хочется картинку. Тогда — онлайн-проверка цепочки редиректов: она стучится на адрес со стороны, не из вашей сети, и рисует каждый шаг с кодом и временем. Я ей обычно перепроверяю себя после правок на сервере. Потому что у себя в браузере половина редиректов закеширована, и легко увидеть не то, что увидит поисковый бот.

Где именно лишнее: разбираю по случаям

Сразу оговорюсь: цепочка сама по себе — не зло. Один редирект http → https обязан быть, и это правильно. Беда начинается, когда они наслаиваются друг на друга. Иду от частого к редкому.

Случай 1. http → https → www → слеш

Самый массовый и при этом самый безобидный с виду. Откуда четыре звена? Да оттуда, что правила писались в разное время и разными руками: сначала кто-то включил https, потом кто-то решил, что канон — это www, потом добавили слеш в конце. Каждый по отдельности прав. А вместе — эстафета.

Лечу одним правилом, которое сразу отправляет на финальный адрес. На nginx держу отдельный блок, который ловит http и «неправильные» хосты и делает ровно один 301:

# Один прыжок вместо четырёх: http и голый домен сразу на https://www со слешем
server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate и остальное опускаю

    if ($scheme = http) { return 301 https://www.example.com$request_uri; }
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
}

Идея ровно одна: любой кривой вход попадает на правильный адрес за один прыжок. Не по эстафете.

Случай 2. Поставили 302, а нужен был 301

302 — это «временно». Поисковик при нём держит в индексе старый URL и не спешит передавать вес на новый. А теперь представьте: вы переехали навсегда — сменили домен, ушли на https — и отдаёте 302. По сути вы говорите Яндексу и Google: «да я ненадолго, не переиндексируйте». И они слушаются. Так что проверьте коды в выводе curl: для постоянного переезда должно быть 301, ну или 308, если для вас принципиально не потерять метод запроса. Разница расписана на странице инструмента.

Случай 3. Кольцо (ERR_TOO_MANY_REDIRECTS)

A кидает на B, B обратно на A — браузер потанцует попыток двадцать и сдастся с ERR_TOO_MANY_REDIRECTS. В девяти случаях из десяти это спор двух мест, которые оба «лучше знают». Классика: nginx переводит на https, а приложение или CMS внутри гонит обратно на http, потому что не в курсе, что снаружи уже https — ему забыли пробросить X-Forwarded-Proto. Тот же curl -sILk сразу высветит повторяющуюся пару адресов, и видно, кто с кем пинг-понгует.

Случай 4. Цепочка только на телефоне или по гео

Вот это — самый подлый вариант. С рабочего компа всё чисто, не подкопаешься. А отдельная мобильная версия, или георедирект на языковую копию, или A/B-тест через перенаправление — добавляют звенья, которые вылезают только с нужного устройства или из нужной страны. Ловлю либо в DevTools с эмуляцией мобилы, либо curl'ом с подменой юзер-агента:

curl -sILk -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" http://example.com | grep -iE "^HTTP|^location"

Зачем вообще на это время тратить

Без занудства, по делу.

Скорость. Каждый редирект — это полный круг «запрос — ответ — снова запрос». На мобильной сети — 100–500 мс за круг. Вернёмся к моей истории из начала: четыре прыжка отъедали где-то полторы секунды ещё до того, как браузер начинал рисовать контент. Полторы секунды на пустом месте.

SEO. На длинных цепочках теряется часть ссылочного веса, а боты вообще ходят по перенаправлениям с оглядкой — Google обычно тянет до пяти, дальше может махнуть рукой. Спрятали важную страницу за цепочкой — не удивляйтесь, что она плохо индексируется.

И аналитика заодно. Лишние прыжки иногда сбивают Referer и UTM-метки, и потом ломаешь голову, откуда столько «прямых заходов».

Кому мало — подробности и рекомендации лежат на странице проверки редиректов.

FAQ

Сколько редиректов — это нормально?

В идеале один. Кривой вход (http или без www) должен за один 301 попадать на финал. Два — ладно, переживу, если есть зачем. Три и больше — это почти всегда наследие, которое просто никто не свёл воедино. Жёсткого порога у поисковиков нет, но Google на практике перестаёт идти по цепочке где-то после пятого звена.

301 или 302 — что ставить-то?

Навсегда — 301 (или 308). Это смена домена, переезд на https, новая структура ссылок. Временно — 302 (или 307): техработы, заглушка на час, A/B-тест. Самая дорогая ошибка тут — влепить 302 на постоянный переезд: вес на новый адрес не переедет, и позиции просядут.

А на Яндекс цепочка влияет?

Влияет, и логика та же, что у Google. Длинная цепочка размазывает сигналы и тормозит обход. Яндекс прямым текстом советует склеивать зеркала (http/https, www/не-www) одним постоянным редиректом и указывать главное зеркало. Если вместо этого у вас эстафета — робот жжёт на сайте лишний краулинговый бюджет и медленнее довозит ваши изменения до индекса.

Переезжаю на новый домен — как не накосячить?

Главное — не лепить переезд поверх старой цепочки. Если на старом домене уже было http→https→www, и вы цепляете новый редирект к последнему звену, получите хвост из четырёх-пяти прыжков. Сделайте так, чтобы любой адрес старого домена шёл на финал нового за один 301. И обязательно прогоните потом десяток типовых URL через curl — по выводу сразу видно, один прыжок или опять эстафета.

Почему цепочка вылезает только на телефоне?

Скорее всего, у вас отдельная мобильная версия или геозависимый редирект, который для десктопного юзер-агента просто не срабатывает. Смотрите либо в DevTools с эмуляцией устройства, либо curl'ом с мобильным User-Agent — пример я давал в четвёртом случае. С обычного компа такие звенья не видно, поэтому про них и узнают последними, обычно от злого пользователя.

Поправил — а на следующий день цепочка вернулась. Что за чертовщина?

Кеш, почти стопроцентно. Браузер, прокси или CDN запомнили старый 301 — а постоянные редиректы браузеры кешируют намертво и надолго. Проверяйте начисто: curl мимо кеша, инкогнито, или внешняя проверка, которой про ваш локальный кеш ничего не известно. Снаружи чисто, а у вас в браузере нет — значит, кеш, выдыхайте и сбрасывайте.

Что в итоге

Цепочка редиректов — это не пожар. Это тихий налог: на скорость, на индексацию и на нервы того, кто будет это потом распутывать. Хорошая новость — ищется она за полминуты одной командой curl -sILk, а чинится чаще всего одним правилом вместо разбросанных по конфигу костылей.

План такой, если совсем коротко: посмотреть всю цепочку (curl, DevTools или онлайн-проверка), найти лишние звенья, свести их в один 301 на финал, перепроверить снаружи. Если после этого сайт всё равно ведёт себя странно — спускайтесь по слоям, как в разборе «почему сайт не работает», и заодно гляньте, что TCP-соединение и порты живы.

А чтобы не возвращаться к этому руками, повесьте мониторинг доступности сайта — он пнёт вас, если редиректы вдруг сломаются или закольцуются, раньше, чем это сделает первый разозлённый посетитель. Проверено, увы, на себе.