Возможность

Правила HTTP-редиректа

Управляйте переходами HTTP→HTTPS, миграциями доменов, перемещениями путей и редиректами при ошибках без изменения кода приложения.

TR7 HTTP Redirect Rules централизованно применяют наиболее распространённые потоки редиректов в веб-трафике на уровне ADC. Переходы HTTP-на-HTTPS, миграции со старого домена на новый, стандартизация www-на-apex или apex-на-www, редиректы на основе пути и резервные переходы при ошибках — всё управляется в единой модели правил. Командам приложений больше не нужно писать отдельную логику редиректов внутри каждого фреймворка. TR7 получает запрос на vService, оценивает условие и создаёт ответ редиректа с правильным HTTP-кодом статуса. Различные модели поведения редиректов — 301, 302, 307 и 308 — выбираются в соответствии с требованиями каждого сервиса. Правила редиректа можно объединять с условиями хоста, пути, заголовка, метода, IP источника, геолокации или FX-движка выражений. Это означает, что не только общее принудительное применение HTTPS, но и конкретные URL-поддеревья, устаревшие ссылки кампаний, сценарии обслуживания и редиректы, запускаемые кодами ошибок, — всё это может быть централизовано. Результат: TR7 убирает поведение HTTP-редиректов из кода приложений, файлов конфигурации серверов и разрозненных наборов правил и превращает его в проверяемую, версионируемую, ограниченную по сервису политику ADC.

Кода статуса редиректа: 301, 302, 307, 308

Основных типа действий: redirect_scheme, req_redirect_location, error_redirect

Центральная политика ADC — ноль изменений в коде приложения

Когда правила редиректов разбросаны по коду приложения, даже небольшое изменение URL становится операционным риском.

HTTP-редиректы выглядят просто на поверхности, но в продакшне быстро становятся сложными, когда миграции доменов, принудительный HTTPS, совместимость устаревших URL, SEO-поведение, сохранение метода и состояния ошибок сходятся воедино. Выбор неправильного кода статуса может нарушить индексацию поисковых систем, поведение кэша браузера, логику API-клиентов или потоки мобильных приложений.

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

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

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

TR7 HTTP Redirect Rules реализуют эту модель: переходы HTTP→HTTPS, редиректы полных URL, миграции доменов и путей, а также потоки редиректов, запускаемых кодами ошибок, — всё управляется в единой модели политики.

Наш подход

TR7 превращает HTTP-редиректы в управляемые правила, управляемые изменением схемы, полным URL-целью, условием ошибки и контекстом трафика.

Переход HTTP-на-HTTPS применяется с помощью одного правила редиректа

Действие `redirect_scheme` перенаправляет HTTP-трафик на HTTPS без изменения кода приложения или конфигурации веб-сервера, централизованно устанавливая стандарт защищённого соединения.

Редирект полного URL упрощает миграцию доменов и путей

Действие `req_redirect_location` перенаправляет запрос на конкретный URL. Устаревшие домены, старые пути или ссылки кампаний — всё может быть централизованно перенесено на новые адреса.

Пользователи перенаправляются на резервную страницу при условиях ошибок

Правило редиректа может срабатывать при тайм-аутах или кодах ошибок ответа, отправляя пользователей на страницу обслуживания, статуса или резервного сервиса вместо сырого ответа об ошибке.

Условные редиректы принимают решения на основе контекста трафика

Хост, путь, метод, заголовок, IP источника или FX-выражения могут управлять решением о редиректе. Различные URL-поддеревья в рамках одного vService могут применять различные модели поведения редиректов.

Возможности

Правила HTTP-редиректа консолидируют сценарии редиректов — от быстрого принудительного применения HTTPS до переадресации по кодам ошибок — под единой политикой ADC.

redirect_scheme быстро и централизованно переносит HTTP-трафик на HTTPS

HTTP-на-HTTPS-перенаправление — это базовое требование безопасности для большинства приложений. TR7 применяет изменение схемы как правило ADC, а не как код приложения. Запросы, поступающие по HTTP, перенаправляются на HTTPS-цель; запросы, уже использующие HTTPS, не генерируют лишний редирект. Это упрощает приведение устаревших приложений к стандартам безопасной публикации.

req_redirect_location поддерживает миграцию домена с полным URL-целью

Устаревший домен может перенаправляться на новый домен, старый путь — на новый, или временный адрес кампании — на постоянный пункт назначения. TR7 хранит полное определение целевого URL внутри правила. Эта структура критически важна в проектах миграции, ребрендинга и модернизации приложений — коду приложения никогда не придётся иметь дело со знанием старых URL.

Выбор кода статуса: 301, 302, 307 и 308

Не каждый редирект несёт одинаковую семантику. 301 и 308 сигнализируют о постоянном перемещении; 302 и 307 — о временном редиректе. 307 и 308 сохраняют исходный метод запроса, делая их правильным выбором для API-вызовов, метод которых не должен молча меняться на GET. TR7 делает выбор кода статуса явной частью правила, не оставляя места для неоднозначности в поведении редиректов.

Поведение сохранения или изменения строки запроса настраивается

То, будет ли строка запроса перенаправлена на цель редиректа, определяется для каждого правила. Устаревшие ссылки кампаний могут нуждаться в передаче параметров запроса для аналитики или отслеживания. Чувствительные с точки зрения безопасности параметры могут не принадлежать новой цели. TR7 делает это решение явно управляемым внутри центрального правила.

Сохранение метода снижает потерю данных в API-редиректах

API-клиенты могут отправлять запросы с методами POST, PUT или PATCH. Неправильный код статуса редиректа может заставить клиента молча понизить метод до GET, потеряв тело запроса. TR7 позволяет использовать поведение редиректов с сохранением метода, такое как 307 и 308. Это важно в сценариях модернизации API и миграции эндпоинтов.

Стандартизация домена www и apex применяется из единой точки

Между `www.example.com` и `example.com` может быть установлено каноническое направление. Эта согласованность полезна для SEO, области действия сертификата, домена cookie и пользовательского опыта. TR7 управляет стандартизацией домена без распределения логики на уровень приложения или веб-сервера — одно правило управляет всем поведением vService.

Устаревшие структуры путей могут условно мигрировать на новый URL-макет

В устаревших приложениях пути, такие как `/old/products/123`, могли переместиться на другую структуру в новом приложении. Условия путей TR7 позволяют перенаправлять старые URL-деревья на новые цели. Это предотвращает нарушение закладок и ссылок интеграций в процессе постепенной модернизации, обеспечивая контролируемую передачу новому приложению, пока старое ещё работает.

Тайм-ауты и ошибки менеджера трафика могут запускать редирект

Потоки, аналогичные `error_redirect_at_tm`, перенаправляют пользователей на альтернативный пункт назначения при тайм-ауте или ошибке управления трафиком — например, на страницу обслуживания, страницу статуса или резервный домен. Вместо того чтобы отображать сырую ошибку, доставляется контролируемый пользовательский опыт. Операционные сбои обрабатываются более изящно.

Коды ошибок ответа могут запускать редирект на альтернативную цель

При подходе `error_redirect_at_res` конкретные коды ошибок, возвращаемые backend, могут запускать редирект. При ответах 500, 502, 503 или 504 пользователи могут перенаправляться на другую страницу. Это особенно ценно для сценариев обслуживания и временной деградации сервиса — обработка ошибок становится независимой от приложения.

Условия трафика делают решения о редиректе контекстно-осведомлёнными

Хост, путь, метод, заголовок, IP источника или FX-выражения могут использоваться как условия редиректа. Например, только мобильные пути, только устаревшая версия API или только трафик из определённых регионов могут перенаправляться. Правило редиректа перестаёт быть грубым глобальным поведением и становится контролируемым, контекстно-чувствительным решением.

Централизованная политика снижает риск петли редиректа

Когда правила редиректов разбросаны по нескольким системам, вероятность петли возрастает. Поскольку правила TR7 находятся в одном месте, условия схемы, хоста и пути более видимы. Операторы могут более легко выявлять ошибки, такие как перенаправление уже HTTPS-запроса обратно на HTTPS или переход с нового домена обратно на старый — критическая защитная сетка для продакшн-изменений.

Аудит и версионирование делают изменения редиректов подотчётными

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

Операционная глубина

Правила HTTP-редиректа эксплуатируются совместно с выбором кода статуса, поведением строки запроса, сохранением метода, условиями ошибок, контролем петель и сценариями обслуживания.

Выбор кода статуса

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

Поведение строки запроса

Параметры запроса должны либо перенаправляться на цель редиректа, либо реконструироваться там. Параметры отслеживания могут нуждаться в сохранении; чувствительные параметры не должны перенаправляться. Это решение должно приниматься на основе требований безопасности и аналитики и должно быть явно указано в правиле, а не оставляться на усмотрение неявных значений платформы.

Сохранение метода

Некоторые коды статуса редиректа заставляют клиента менять свой метод. Для отправки форм или API-операций записи это создаёт риск потери данных или непреднамеренной обработки. Для сценариев, требующих сохранения метода, должен быть выбран подходящий код статуса.

Условие ошибки

Тайм-аут или код ошибки ответа может запускать редирект. Эти правила могут использоваться для контролируемого перенаправления на страницу обслуживания или статуса. Редиректы ошибок не должны маскировать основную проблему — они должны эксплуатироваться совместно с логированием и мониторингом, чтобы фактический источник ошибки отслеживался отдельно.

Контроль петли

При написании правила редиректа оператор должен убедиться, что целевой URL не может повторно запустить то же условие. Условия схемы, хоста и пути должны быть чётко ограничены. Централизованное управление правилами снижает риск петель, сохраняя все условия в одном видимом месте.

Редирект обслуживания

Во время планового обслуживания конкретные пути или весь хост могут перенаправляться на временную страницу обслуживания. Временные коды статуса, такие как 302 или 307, более подходят в этом сценарии, чтобы клиенты не кэшировали редирект постоянно. После обслуживания правило отключается и трафик возвращается к нормальному потоку.

Когда применять

Централизованная миграция HTTP-трафика на HTTPS

Устаревшее приложение может быть опубликовано по HTTP. TR7 перенаправляет HTTP-запросы на HTTPS-цель без каких-либо изменений кода приложения, устанавливая стандарт защищённого соединения для всего сервиса.

Перенаправление устаревшего домена на новый корпоративный домен

При ребрендинге или смене доменов трафик устаревшего домена может быть перенесён на новый адрес. Постоянное перемещение явно сигнализируется с использованием 301 или 308.

Миграция устаревшей структуры путей на новый макет приложения

Старые URL-деревья могут перенаправляться на новые пути приложения. Закладки пользователей и устаревшие ссылки интеграций остаются нетронутыми в процессе миграции.

Перенаправление на страницу обслуживания при ошибке 503

Когда backend временно не может отвечать, пользователи могут быть отправлены на страницу обслуживания вместо сырой ошибки. Операционный сбой становится контролируемым пользовательским опытом.

Использование редиректов с сохранением метода для миграции API-эндпоинтов

Когда вызовы POST или PUT перемещаются на новый API-эндпоинт, можно использовать 307 или 308, чтобы гарантировать сохранение метода клиента и поведения запроса.

Часто задаваемые вопросы

В чём разница между 301, 302, 307 и 308, и как выбрать?

301 и 308 сигнализируют о постоянных перемещениях — поисковые системы индексируют URL назначения. 302 и 307 сигнализируют о временных редиректах и не передают вес индексирования. 307 и 308 сохраняют исходный метод запроса, предотвращая молчаливое понижение POST или PUT клиентом API до GET. Для SEO-критических миграций доменов обычно предпочтительны 301 или 308; для обслуживания или редиректов кампаний безопасным умолчанием является 307.

Как работает действие redirect_scheme?

redirect_scheme проверяет схему входящего запроса. Запросы, поступающие по HTTP, перенаправляются на HTTPS-цель; запросы, уже использующие HTTPS, не запускают правило и лишний редирект не создаётся. Это позволяет централизованно применять стандарт защищённого соединения для всего vService без изменения кода приложения или конфигурации веб-сервера.

Как настраивается редирект на основе кода ошибки?

error_redirect_at_tm срабатывает при тайм-аутах или ошибках менеджера трафика; error_redirect_at_res срабатывает при конкретных HTTP-кодах ошибок, возвращаемых backend (таких как 500, 502, 503 или 504). Оба действия настраиваются с целевым URL и кодом статуса. Эти правила должны эксплуатироваться совместно с логированием и мониторингом, чтобы фактический источник ошибки отслеживался и не маскировался.

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

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

Какие шаги следует предпринять, чтобы избежать петель редиректов?

При написании правила редиректа убедитесь, что целевой URL не может повторно запустить то же условие. Распространённые ловушки включают перенаправление уже HTTPS-запроса обратно на HTTPS или переход с нового домена обратно на старый. Поскольку TR7 хранит все правила в одном центральном месте, условия схемы, хоста и пути легче проверить, а риски петель легче выявить до достижения продакшна.

Как обрабатывается стандартизация www vs. apex-домена?

Используя req_redirect_location вместе с условием хоста, трафик, поступающий на www.example.com, может быть перенаправлен на example.com, или наоборот. Это правило должно применяться согласованно с областью действия TLS-сертификата, доменом cookie и конфигурацией SEO-канонизации. Редирект в неправильном направлении может как навредить SEO-индексации, так и создать несоответствия области действия сертификата.

Централизуйте HTTP-редиректы на уровне ADC

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