Как настроить 301-редирект в Nginx без цепочек и зацикливания

301-редирект нужен, когда адрес страницы изменился, а посетители и поисковики должны попасть на её актуальную версию. Например, /old-guide/ переехал на /guides/new-guide/, либо основной адрес сайта теперь работает по HTTPS без www.

Надёжная настройка решает три задачи: ведёт на правильную страницу, сохраняет нужные параметры запроса и не создаёт цепочку переходов. Ниже разберём правила Nginx, проверку через curl и возврат при ошибке. Базовая установка Nginx на Ubuntu описана отдельно.

Выбрать код перенаправления

Код	Основное назначение	Что учитывать
301	Постоянный переезд	Для обычной страницы, открываемой GET, подходит в большинстве сценариев
302	Временное перенаправление	Удобен на этапе проверки временного маршрута
307	Временный переход с сохранением метода	Нужен там, где важно сохранить POST и тело запроса
308	Постоянный переход с сохранением метода	Подходит для постоянного маршрута API, если его поддерживает схема приложения

При 301 и 302 клиент может изменить POST на GET. Поэтому перенос API, оплаты или формы нельзя проверять только открытием ссылки в браузере. Сначала определите, какие методы реально использует маршрут.

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

Подготовить карту адресов

Составьте небольшую таблицу «старый адрес → новый адрес». Для каждой пары откройте целевую страницу напрямую: она должна существовать и отдавать ожидаемое содержимое. Перенаправление на страницу с 404 не исправляет ошибку.

Старайтесь сопоставлять смысловые аналоги. Массовая отправка всех удалённых статей на главную ухудшает путь посетителя и не гарантирует сохранения поисковой видимости. Если у удалённого материала нет замены, настоящий 404 или 410 может быть точнее искусственного перехода.

До изменения сохраните конфигурацию сайта. Если переезд затрагивает файлы, базу или домен, нужна и резервная копия проекта. Копия одного Nginx-файла не восстанавливает содержимое приложения.

Перенаправить одну страницу в Nginx

Добавьте точный location внутрь действующего server нужного сайта:

location = /old-guide/ {
    return 301 /guides/new-guide/$is_args$args;
}

Знак = означает точное совпадение пути. Этот блок не охватывает автоматически /old-guide/chapter/ и /old-guide без завершающего слеша. Сначала проверьте, какие варианты адреса действительно встречаются, и добавляйте только нужные правила.

$is_args$args переносит строку запроса: например, ?utm_source=mail. Если параметры старой страницы несовместимы с новой логикой, сохранять их все не нужно. Тогда задайте чистый целевой адрес без этой части. Решение должно зависеть от назначения параметров, а не от привычки копировать любой пример.

Для перехода на другой домен укажите фиксированное имя:

location = /old-guide/ {
    return 301 https://new.example.org/guides/new-guide/$is_args$args;
}

Не подставляйте произвольный адрес из пользовательского параметра next или url: так можно случайно создать открытое перенаправление на посторонние сайты.

Перевести HTTP на основной HTTPS-адрес

Для отдельного HTTP-хоста типовая схема выглядит так:

server {
    listen 80;
    server_name example.org www.example.org;
    return 301 https://example.org$request_uri;
}

Целевое имя здесь фиксировано. $request_uri сохраняет исходный путь и строку запроса. Перед применением должны работать DNS и HTTPS на example.org. Если сертификат ещё не выпущен, сначала выполните инструкцию по SSL, включая доступность выбранного способа ACME-проверки.

Этот пример не заменяет рабочий HTTPS-хост. Перенаправление https://www.example.org также требует сертификат, действительный для www: TLS-соединение устанавливается раньше, чем браузер сможет получить HTTP-редирект. Правило только на порту 80 этого не решает.

При reverse proxy отдельно выясните, где завершается TLS. Если приложение видит внутренний HTTP и повторно отправляет браузер на уже открытый HTTPS, возникает цикл. Заголовки доверенного прокси и настройки приложения должны описывать одну схему.

Проверить конфигурацию и первый ответ

sudo nginx -t
sudo systemctl reload nginx
curl -I --max-time 15 https://example.org/old-guide/

Перезагрузку выполняйте только после успешного nginx -t. В первом ответе ожидаются код 301 и Location с правильным адресом. Сам по себе код 301 ничего не говорит о том, куда направляется посетитель.

Проверьте запрос с параметрами, заключив URL в кавычки:

curl -I --max-time 15 "https://example.org/old-guide/?utm_source=lesson&mode=full"

Без кавычек оболочка может интерпретировать & как управление процессами. В PowerShell используйте curl.exe, чтобы явно вызвать curl, а не одноимённую команду старой среды Windows PowerShell.

Посчитать переходы до конечной страницы

curl -sS -L --max-redirs 5 --max-time 20 \
  -o /dev/null \
  -w 'HTTP: %{http_code}; redirects: %{num_redirects}; URL: %{url_effective}\n' \
  "https://example.org/old-guide/?utm_source=lesson"

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

На нашем отдельном стенде Nginx запрос к /old/ сохранил utm_source=lesson, выполнил один переход и завершился 200. Контролируемый цикл из двух других адресов остановился по ограничению curl. В опыте использованы локальные HTTP-порты; выпуск сертификата не является частью этого теста.

Устранить цепочку или зацикливание

При цепочке HTTP → HTTPS с www → HTTPS без www → новый путь каждый шаг добавляет ожидание и точку отказа. Где возможно, ведите сразу на конечный основной адрес.

Проверьте три распространённые причины цикла:

1. Nginx направляет на адрес с www, а CMS возвращает на адрес без него.
2. Приложение неправильно определяет HTTPS за прокси.
3. Новая страница попадает под общее правило, возвращающее её на старую.

Уточняйте причину по последовательности Location, а не увеличивайте число разрешённых переходов. При ошибке верните сохранённый конфигурационный файл, снова выполните nginx -t и только затем reload. Учтите, что браузер может продолжать использовать закешированный постоянный переход: сравните результат с curl или чистым профилем.

Обновить внутренние ссылки и SEO-сигналы

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

В sitemap указывают конечные канонические страницы, а не перечень перенаправлений. Проверьте это по руководству о robots.txt и sitemap.xml. Постоянное перенаправление помогает поисковику понять переезд, но не обещает неизменные позиции и мгновенное обновление выдачи.

Если после перехода браузер блокирует старые HTTP-ресурсы, отдельно исправьте смешанный контент. Редирект HTML-страницы не переписывает автоматически сохранённые ссылки на картинки, скрипты и стили.