Готовые конфигурации nginx для всех типов редиректов: со страницы на страницу, с HTTP на HTTPS, с www на без www, массовые редиректы по маске. Примеры server блоков и location правил для российских VPS.
Введение
Nginx — самый популярный веб-сервер в России, и настройка редиректов в нём отличается от привычного Apache с .htaccess. Здесь нет файла, который можно поправить через FTP и сразу увидеть результат. Nginx требует правки конфигурационных файлов, перезагрузки сервера и понимания синтаксиса. Но взамен он даёт скорость: редиректы в nginx обрабатываются на порядок быстрее, чем в Apache. В этой статье — готовые конфигурации для всех типов редиректов, которые могут понадобиться при SEO-оптимизации: от простого перенаправления одной страницы до массовых редиректов по маске.
Базовая структура конфигурации nginx
Чтобы понимать, куда вставлять редиректы, нужно знать структуру конфигурационных файлов. Nginx работает с блоками. Главный блок — server, который описывает виртуальный хост. Внутри server находятся location — блоки для обработки конкретных URL. Конфиги обычно лежат в /etc/nginx/sites-available/ (активные подключаются симлинками в sites-enabled) или в /etc/nginx/conf.d/. После любых правок обязательна проверка синтаксиса командой nginx -t. Если синтаксис нарушен, nginx откажется перезагружаться, и сайт ляжет. Поэтому взяли за правило: сначала nginx -t, потом systemctl reload nginx. Флаг reload перезагружает конфигурацию без разрыва текущих соединений — пользователи не заметят перезагрузки.
Простой редирект одной страницы
Самый частый кейс: перенесли страницу на новый URL, нужно настроить 301 редирект. В nginx это делается через location с директивой return. Создаём location для старого URL и указываем return 301 с новым адресом. Важно: location в nginx чувствителен к слешу в конце и к точному совпадению. Если нужно редиректить и со слешем, и без, используем несколько location или регулярное выражение. Если редиректов много (десятки и сотни), не создавайте по location на каждый — читайте раздел про map ниже. После добавления location проверяем nginx -t и перезагружаем. Редирект работает мгновенно.
Редирект с HTTP на HTTPS
Обязательный редирект для любого современного сайта. Реализуется через отдельный server-блок для порта 80 (HTTP). Внутри этого блока все запросы перенаправляются на HTTPS-версию с кодом 301. Переменная server_name задаёт домен, переменная request_uri сохраняет путь запроса. Так пользователь, открывший http://site.ru/statya, попадёт на https://site.ru/statya, а не на главную. О том, как полностью перевести сайт на HTTPS без потери позиций, читайте в статье Переезд сайта на HTTPS: как не угробить позиции.
Редирект с www на без www и наоборот
Склейка зеркал — обязательное SEO-действие. Выберите основной вариант (с www или без) и настройте редирект с неосновного. В nginx это делается через отдельный server-блок для неосновного домена. Внутри — return 301 на основной домен с сохранением URI. Если у вас один server-блок и нужно внутри него проверять www, используйте if с переменной host. Но if в nginx имеет нюансы, поэтому предпочтительнее отдельный server-блок. Не делайте цепочек: сначала на HTTPS, потом на без www. Всё должно быть в один шаг. Пользователь с http://www.site.ru должен сразу попасть на https://site.ru, без промежуточных редиректов. Каждый лишний редирект — это минус 100-300 миллисекунд к загрузке и потеря микро-доли ссылочного веса.
Массовые редиректы через map
Если нужно настроить сотни редиректов (например, при смене структуры каталога), создавать по location на каждый URL — безумие. В nginx есть директива map, которая создаёт словарь соответствий старых и новых URL. Выносим map в отдельный файл, подключаем его в конфиг. Внутри map — строки вида «старый URL — новый URL». Затем в server-блоке проверяем, есть ли текущий URI в этом словаре, и если есть — отдаём 301 на новый URL. Преимущества map: все редиректы в одном файле, легко редактировать и дополнять, не нужно перезагружать nginx для каждого нового редиректа (только перечитать конфиг). Map также поддерживает регулярные выражения для массовых редиректов по маске. Подробнее о склейке зеркал и настройке доменов читайте в статье Файл .htaccess для SEO: какие директивы помогают.
Rewrite: когда return недостаточно
Директива return хороша для простых редиректов. Для сложной логики (условия, регулярные выражения, захват частей URL) используют rewrite. Синтаксис: rewrite regex замена флаг. Флаг permanent означает 301, флаг redirect — 302. Пример: перенос всех страниц из раздела /blog/ в /articles/ с сохранением остальной части URL. Одна строка rewrite с регулярным выражением делает это для всех URL разом. Важные моменты при работе с rewrite. Первое: rewrite выполняется в порядке расположения в конфиге. Первое совпадение срабатывает, остальные игнорируются. Второе: флаг last прекращает обработку rewrite-правил в текущем location и передаёт новый URI в обработку. Третье: избегайте циклов. Если regex захватывает и новый URL, редирект зациклится. Тестируйте на ограниченном наборе URL перед массовым применением.
Часто задаваемые вопросы
Чем отличается return от rewrite в nginx? return проще и быстрее. Используйте return для редиректов без условий и без захвата частей URL. rewrite используйте, когда нужны регулярные выражения или условия. Для SEO-редиректов return предпочтительнее в 90 процентах случаев.
Можно ли использовать .htaccess на nginx? Нет. Nginx принципиально не поддерживает .htaccess. Создатели nginx сознательно отказались от этого механизма ради производительности. Все правки вносятся в основные конфигурационные файлы сервера.
Как откатить изменения, если после правки nginx не запускается? Команда nginx -t перед перезагрузкой — ваша страховка. Если тест пройден, nginx перезагрузится. Если после перезагрузки что-то работает не так, откатите конфиг из бэкапа и перезагрузите снова. Всегда делайте копию конфига перед правками: cp /etc/nginx/sites-available/site.conf /etc/nginx/sites-available/site.conf.backup.
Нужно ли перезагружать nginx после каждого изменения конфига? Для новых location и return — да, нужен reload. Для map-файла — достаточно reload. Для изменений в подключённых файлах — тоже reload. Команда systemctl reload nginx выполняется мгновенно и не обрывает активные соединения.
Как проверить, что редирект работает корректно? Используйте curl с флагом -I для проверки заголовков ответа. Команда curl -I http://site.ru/staryj-url покажет код ответа (301) и заголовок Location с новым URL. Также проверьте в Яндекс.Вебмастере через инструмент «Проверить URL».
