Редиректы в NGINX: 301, 302, HTTPS и примеры конфигов

NGINX часто стоит как веб-сервер и reverse proxy. Редиректы – одна из базовых задач: смена URL, HTTPS, слияние зеркал, переезд на новый домен. Ниже рабочие схемы с return и regex, плюс типичные ошибки.

301 и 302: что выбрать

301 – постоянный перенос. Браузеры и поисковики «запоминают» новый адрес. Подходит для смены структуры сайта, канонизации www/HTTPS, переезда домена.

302 (и 307) – временно. Контент «сейчас» здесь, но исходный URL ещё в игре. Для A/B, обслуживания, коротких акций. Для SEO-канона почти всегда нужен 301, не 302.

В NGINX удобнее писать return CODE URL; в server или location – меньше сюрпризов, чем у rewrite ... redirect/permanent в сложных цепочках.

Примеры конфигурации

1. Один URL на другой

server {
    ...
    location = /oldpage {
        return 301 https://example.com/newpage;
    }
    ...
}

location = – точное совпадение. Для префикса без regex достаточно location /oldpage, но следите, чтобы не зацепить лишние пути.

2. www на без www

server {
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
}

$request_uri сохраняет путь и query string. Отдельный server для www проще и надёжнее, чем путаница if внутри общего блока.

3. Весь домен на новый

server {
    server_name oldexample.com;
    return 301 $scheme://newexample.com$request_uri;
}

При полном переезде на HTTPS целевой URL лучше сразу с https://, чтобы не ловить второй hop.

4. HTTP на HTTPS

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

Отдельный server на 80 только для редиректа – чистая схема. Сертификат и контент – в server с listen 443 ssl.

Редирект с regex

Когда путь нужно «переложить» по шаблону:

server {
    ...
    location ~ ^/oldprefix/(.*)$ {
        return 301 https://example.com/newprefix/$1;
    }
    ...
}

~ – case-sensitive regex, ~* – без учёта регистра. Группы (...) попадают в $1, $2… Не злоупотребляйте regex на горячих location: префиксные location быстрее.

Практика без боли

• Всегда nginx -t перед reload. Синтаксическая ошибка на проде без теста = даунтайм.
• Проверяйте циклы. A на B и обратно ломает браузер и краулеры. Смотрите цепочку через curl -I / curl -IL.
• Один hop лучше двух. HTTP+www сразу на HTTPS+apex (финальный URL).
• Не смешивайте лишний if с редиректами, если хватает отдельного server/location.
• После смены схемы обновите sitemap, каноникалы, внутренние ссылки – редирект не отменяет мусорные self-links.

Краткий вывод

Редиректы в NGINX – простой и мощный инструмент для SEO и UX. Базовый набор: 301 для постоянного переноса, отдельный server для HTTPS/www, return + при необходимости regex. Планируйте целевые URL, тестируйте конфиг и цепочки, не оставляйте петли. Тогда переезд и канонизация проходят без сюрпризов для пользователей и поисковиков.

Источники и ссылки