Редиректы в nginx: настройка без циклов и лишних цепочек

Nginx — популярный веб-сервер, на котором работают многие сайты на VPS и в облаке. В отличие от Apache, он не читает файлы .htaccess в папках сайта: все правила задаются в конфигурационных файлах сервера, а после изменений конфигурацию нужно перезагрузить. Это требует доступа к серверу, но даёт быструю и предсказуемую обработку редиректов.

Return или rewrite

В nginx два основных инструмента. Директива return сразу возвращает код и новый адрес — это быстрый и понятный вариант для большинства случаев. Директива rewrite использует регулярные выражения и подходит, когда нужно преобразовать путь по шаблону. Общее правило: если можно обойтись return, используйте его.

Главное зеркало и https

Удобнее всего вынести все неосновные варианты адреса в отдельный блок server:

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

Переменная request_uri сохраняет путь и параметры, поэтому человек попадает на ту же страницу. Каждый вариант ведёт на финальный адрес одним шагом. В блоке с listen 443 для www нужны настройки сертификата, который покрывает и www.

Перенос отдельной страницы

Внутри основного блока server используйте точное совпадение location:

location = /old-page/ {
    return 301 /new-page/;
}

Знак равенства означает точное совпадение адреса, такие правила обрабатываются быстрее всего.

Перенос раздела

Если папка переименована, используйте rewrite с сохранением окончания адреса:

rewrite ^/stati/(.*)$ /blog/$1 permanent;

Флаг permanent означает 301, флаг redirect — 302. Без флага rewrite выполнит внутреннюю перезапись без смены адреса в браузере, и это частая путаница у новичков.

Много редиректов — карта map

Если после редизайна нужно перенаправить сотни адресов, не пишите сотни location. Используйте директиву map: она сопоставляет старые адреса с новыми по таблице, которую можно держать в отдельном файле. Затем в блоке server одна проверка: если для текущего адреса нашёлся новый, вернуть 301 на него. Такой подход проще поддерживать и быстро работает даже с большим списком.

Как не получить цикл

Циклы возникают, когда правило срабатывает и на адресе назначения. Например, правило добавления слеша конфликтует с приложением, которое его убирает. Или прокси перед сервером передаёт запросы по http, а nginx снова отправляет их на https. Если браузер пишет о слишком большом числе перенаправлений, проверьте, по какому протоколу запрос приходит в nginx и какие правила срабатывают для финального адреса.

Проверка перед применением

• Проверьте синтаксис конфигурации командой проверки nginx
• Перезагружайте конфигурацию мягко, без остановки сервера
• Проверьте старые и новые адреса в режиме инкогнито или через curl
• Убедитесь, что не задели адреса, которые не должны перенаправляться

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

Слеш на конце адреса

Решите, какой вариант основной — со слешем на конце или без, — и приведите к нему все адреса одним правилом. Важно, чтобы правило не задевало файлы вроде sitemap.xml и robots.txt, иначе они перестанут открываться. Проверьте также, как приложение само обрабатывает слеш, чтобы не получить конфликт.

Если сайт в контейнере

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