Бесплатный онлайн-чекер цепочки HTTP-редиректов

Проверка редиректов

Покажем всю цепочку HTTP-переадресаций по ссылке: коды 301/302/307/308, время каждого шага, заголовки, переход на HTTPS и подозрительные сценарии. Без регистрации, за 1–5 секунд.

URL для проверки

Если протокол не указан, добавим http:// — реальный сайт всё равно выведет на свой канонический URL через редирект. Поддерживаются только http/https; приватные адреса (RFC1918, 127.0.0.1, 169.254.x) автоматически отклоняются.

Цепочка редиректов
URL
Шаг 1 (HEAD)
Шаг 2 (HEAD)
Шаг 3 (HEAD)
HTTPS

Как работает чекер

1

Шлём HEAD-запрос

Отправляем минимальный HEAD-запрос на исходный URL — это не качает тело страницы и быстрее GET. Если сервер не понимает HEAD (405/501) — автоматически переключаемся на GET.

2

Идём по Location

Если ответ 3xx и есть заголовок Location — берём оттуда следующий URL и повторяем. На каждом шаге заново проверяем, что хост резолвится в публичный IPv4. Лимит — 20 шагов.

3

Анализируем цепочку

Считаем длину цепочки, проверяем переход на HTTPS, ищем смешение 301/302, петли, нежелательные cookie на редиректах. Итог — оценка 0–100 и вердикт.

Что проверяет инструмент

Все коды 3xx

301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect — отображаем код и расшифровку для каждого шага.

Время каждого шага

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

Переход на HTTPS

Отдельно отмечаем шаг, на котором цепочка поднимается с HTTP на HTTPS. Если финальный URL остался на HTTP — предупреждаем: это небезопасно и SEO-фактор.

Петли и обрывы

Если URL уже встречался в цепочке — фиксируем петлю и прекращаем обход. Также сигнализируем, если пройден лимит 20 редиректов или сервер вернул сетевую ошибку.

Заголовки ответа

Server, Content-Type, Set-Cookie, Cache-Control, Strict-Transport-Security — на сохранённой странице результата раскрываются полные заголовки каждого шага.

User-Agent на выбор

Дефолтный, Chrome-десктоп, Safari-iPhone или Googlebot. Многие сайты редиректят разные User-Agent в разные места — переключайте, чтобы поймать cloaking или мобильную версию.

Частые вопросы

Зачем вообще проверять цепочку редиректов?

Несколько причин. Во-первых, длинная цепочка тормозит загрузку сайта — каждый редирект это полный round-trip к серверу. Во-вторых, поисковики передают вес ссылки только на 1–2 редиректа подряд: 5 переходов 302→302→302→302→200 = почти полная потеря SEO-веса. В-третьих, при работе с трекинговыми ссылками (Bitly, рекламные сети, ESP) важно понимать, куда в итоге уходит пользователь. И, наконец, для безопасности: цепочка должна заканчиваться на HTTPS, без cookie-стаффинга и без переходов через подозрительные домены.

Чем отличаются 301, 302, 307 и 308?

301 Moved Permanently — постоянный редирект, поисковики передают вес и кешируют решение. 302 Found / 303 See Other — временный, вес передаётся слабее, кеша нет. 307 Temporary Redirect — как 302, но строго сохраняет HTTP-метод (POST останется POST'ом). 308 Permanent Redirect — как 301, но также сохраняет метод. Для постоянных переадресаций по правилам — 301 на всех шагах; смешение 301 и 302 в одной цепочке часто индикатор кривой настройки сервера.

Как формируется итоговая оценка?

Старт — 100 баллов. Штрафы: за каждый шаг сверх трёх — минус 10. Цепочка только из 302/303 — минус 8. Смешение 301 и 302/303 — минус 5. Финал на HTTP, не HTTPS — минус 15. Cookie на редиректах — минус 2 за каждое (но не больше 8). Финал 4xx/5xx — минус 25. Петля или сетевая ошибка — score 0 и вердикт loop/error. Итог: clean (90–100), ok (70–89), caution (50–69), problematic (30–49), bad (0–29).

Почему вы используете HEAD, а не GET?

HEAD возвращает те же заголовки, что и GET, но без тела ответа — это в разы быстрее и не качает потенциально большие страницы. Около 95% серверов корректно обрабатывают HEAD; если конкретный сервер отвечает на HEAD кодом 405 Method Not Allowed или 501 Not Implemented, чекер автоматически переключается на GET для этого шага. В отчёте видно, каким методом был сделан каждый запрос.

Почему ваш чекер видит другую цепочку, чем мой браузер?

Самые частые причины: разный User-Agent (попробуйте переключить на Chrome или Safari в форме), разные cookie (мы не отправляем cookie, в отличие от браузера), разный геоисточник (мы запрашиваем с серверов в РФ — некоторые сайты редиректят по гео). Если сайт даёт разные ответы боту и человеку — это cloaking, его как раз удобно ловить переключением User-Agent.

Можно ли проверить внутренний URL вроде localhost или 192.168.x.x?

Нет — мы намеренно режем все приватные диапазоны (RFC1918: 10/8, 172.16/12, 192.168/16), loopback (127/8), link-local (169.254/16), любые .local-домены и т. п. Без этого инструмент превратился бы в SSRF-прокси для сканирования инфраструктуры. Проверка происходит на каждом шаге цепочки — даже если первый URL публичный, но редиректит на внутренний адрес, мы это увидим и остановимся.

Сколько хранится результат и как поделиться?

Каждая проверка получает уникальный токен и сохраняется на 24 часа. Кнопка «Скопировать ссылку» даёт постоянный URL — отправьте коллеге или приложите к тикету. На сохранённой странице раскрываются полные заголовки каждого шага. Повторная проверка того же URL с тем же User-Agent в течение суток возвращает кэш мгновенно.

Почему капча и какие лимиты?

Опрос произвольных URL — самый «лакомый» сценарий злоупотребления для ботов: можно сканировать чужие сайты, делать массовый probing редиректов, искать SSRF-уязвимости. Без капчи инструмент быстро бы попал в чёрные списки. Лимит — 5 проверок в минуту и 30 в сутки с одного IP. Для корпоративного использования рассмотрите интеграцию по API.


Остались вопросы?

  • Сергей Шаульский Сергей

Спросите нас! Мы рады помочь вам с любой проблемой или вопросом.

Связаться с нами