Редирект с www на без-www в Nginx: настройка канонического домена

Короткий ответ: как настроить редирект www на без-www

Выберите один канонический host и направьте на него все остальные варианты адреса постоянным редиректом 301. Для типового публичного сайта удобно использовать HTTPS без префикса www: основной адрес будет https://example.com, а запросы к http://example.com, http://www.example.com и https://www.example.com сразу перейдут на него.

В Nginx для этого достаточно разделить redirect-блоки и рабочий HTTPS-блок. Переменная $request_uri сохраняет путь и query-параметры исходного запроса.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

Домен example.com в примере замените на собственный. До reload проверьте записи DNS для обоих host и выпустите TLS-сертификат, который покрывает example.com и www.example.com. HTTPS-вариант с www сначала проходит TLS-проверку, поэтому одного сертификата только для без-www недостаточно.

Смена host затрагивает SEO-сигналы, cookies, авторизацию и аналитику. До переключения проверьте абсолютные ссылки, rel=canonical, sitemap.xml, область действия cookies, Google Analytics и Яндекс Метрику.

Как выбрать канонический домен: www или без www

www.example.com и example.com являются разными host-именами. Они могут указывать на один IP-адрес и обслуживаться одним Nginx, но браузер, поисковый робот и cookie-механизм воспринимают их как разные адреса.

Технически обе схемы корректны. Для SEO важна согласованность: один целевой host в редиректах, внутренних ссылках, canonical, sitemap, Open Graph, RSS и аналитике. Сам префикс www не делает домен лучше или хуже.

Когда удобнее использовать домен без www

Без-www обычно выбирают для публичного сайта, документации, блога или базы знаний. Адрес короче, его проще читать в терминале, диктовать по телефону и размещать в рекламных материалах.

Путь и host занимают меньше места в ссылках и логах.
Короткий адрес проще запомнить при ручном вводе.
Для небольшого проекта не требуется отделять веб-узел от других сервисов на корневом домене.
Миграция проходит предсказуемо, если все внутренние ссылки уже используют без-www.

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

Когда схема с www оправдана

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

Префикс www может отделять веб-сервис от корневого домена. На корневом домене при этом могут находиться почтовые, DNS- или другие служебные настройки, а веб-трафик будет явно направлен на www.

Схема с www удобна при развитой инфраструктуре с CDN и несколькими поддоменами, но она не изолирует cookies автоматически. Cookie с атрибутом Domain=.example.com все равно может передаваться поддоменам, если приложение так ее установило.

Что проверить перед сменой канонической версии

Соберите текущие URL в индексе Google и Яндекса. Проверьте главную страницу, статьи, пагинацию, страницы поиска и адреса с параметрами.
Проверьте DNS-записи A и AAAA для example.com и www.example.com. Запись AAAA не должна вести на старый сервер.
Подготовьте сертификат с обоими именами в SAN. При использовании отдельных сертификатов проверьте пути к каждому файлу в Nginx.
Найдите абсолютные ссылки в шаблонах, sitemap, RSS/Atom, Open Graph и конфигурации генератора сайта.
Снимите список cookies. Для каждой записи зафиксируйте Domain, Path, Secure, HttpOnly и SameSite.
Проверьте, как счетчики Google Analytics и Яндекс Метрики определяют host, источник перехода и сессию.
Подготовьте обновленные canonical и sitemap только для выбранного домена.
Проверьте настройки Google Search Console и Яндекс Вебмастера для обеих версий host.
Составьте план отката конфигурации и сохраните текущий файл сайта перед reload.

Для теста можно поднять отдельную копию сайта на VDS или VPS, например в Timeweb Cloud, и проверить TLS, cookies и редиректы до изменения production-конфигурации.

Если сайт уже последовательно использует www в canonical, sitemap и внутренних ссылках, оставьте www. Если трафик равномерно приходит на обе версии, выберите одну по архитектуре проекта и переведите вторую на 301.

301 редирект www на без-www в Nginx

Для постоянной смены host используйте директиву return. Она явно задает код ответа и целевой адрес, поэтому конфигурацию проще читать и проверять, чем длинное условие rewrite. Практические варианты с сохранением URI разобраны в статье о редиректах Nginx через return без rewrite.

Минимальная конфигурация для одного домена

Ниже приведены три роли server block: HTTP принимает оба host и отправляет их на конечный HTTPS-адрес, HTTPS для www делает редирект на без-www, HTTPS для канонического домена обслуживает сайт.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Пути к сертификатам, каталог /var/www/example и правило try_files замените настройками своего сайта. Для приложения за reverse proxy сохраните существующий рабочий location и замените только обработку канонического host. Готовые схемы проксирования и передачи заголовков описаны в руководстве по обратному прокси на Nginx.

Один SAN-сертификат можно использовать в обоих HTTPS-блоках. Сервер все равно определяет нужный блок по SNI и заголовку Host, а сертификат должен быть действителен для имени, указанного пользователем в адресе.

Почему нужно сохранять путь и query-параметры

Редирект должен менять host, а путь и параметры запроса должны оставаться прежними. Иначе глубокая ссылка на документацию, UTM-разметка или маршрут авторизации потеряются.

/docs/nginx?utm_source=mail должен перейти в https://example.com/docs/nginx?utm_source=mail.
/login?next=/admin должен сохранить параметр next, чтобы приложение вернуло пользователя в нужный раздел после входа.
/api/v1/items?limit=20 должен получить тот же путь и query string, если API действительно перенаправляется на новый host.

$request_uri содержит исходный URI вместе с query-параметрами. Вручную заданный адрес без этой переменной может привести к потере хвоста запроса. Проверяйте результат через curl, а не только по главной странице в браузере.

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

Как не создать цикл редиректов

Канонический HTTPS-блок не должен перенаправлять сам себя. В нем остается приложение, статика или reverse proxy. Редирект размещают только в блоках для HTTP и неканонического host.

Если в блоке server_name example.com стоит return 301 https://example.com$request_uri;, запрос будет ходить по кругу.
Если CDN передает на origin HTTP, а Nginx без проверки считает пользовательское соединение HTTP, origin может снова отправлять клиента на HTTPS.
Если приложение сравнивает Host с www, а Nginx передает ему другой Host, приложение может вернуть обратный редирект.
Если балансировщик и Nginx одновременно канонизируют host, два слоя могут выбрать разные конечные адреса.

При прямом TLS на Nginx для приложения за прокси обычно передают такие заголовки:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;

Этот пример подходит, когда Nginx сам видит реальную схему клиентского соединения. За CDN или внешним балансировщиком $scheme может быть HTTP, даже если клиент подключился по HTTPS. В такой схеме настройте доверие к проверенному X-Forwarded-Proto на одном выбранном уровне и не принимайте этот заголовок от произвольного клиента.

Редирект без www на www nginx

Обратная схема работает по тем же правилам. Каноническим становится https://www.example.com, а без-www служит источником 301-редиректа.

Готовая схема для канонического www

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

В этой схеме http://example.com/page, http://www.example.com/page и https://example.com/page должны сразу ответить адресом https://www.example.com/page. Запрос к каноническому HTTPS-блоку должен обслуживаться сайтом.

Сертификат обязан покрывать оба имени. Ошибка сертификата появляется до HTTP-ответа, поэтому браузер может остановить запрос и не показать 301.

Как выбрать направление при существующем сайте

Оставьте текущий host, если он уже используется во всех внутренних ссылках, canonical, sitemap, рекламных URL и настройках аналитики. Изменение направления приносит техническую работу и риск разлогинивания пользователей, но не дает отдельного SEO-преимущества.

При миграции выполните действия в таком порядке:

Подготовьте DNS и сертификат для обеих версий.
Добавьте redirect-блоки и проверьте их на тестовом host или отдельном сервере.
Включите постоянный 301 на конечный HTTPS-адрес.
Замените абсолютные ссылки, canonical, sitemap, Open Graph и ссылки в документации.
Проверьте cookies и вход пользователей.
Обновите настройки Google Search Console, Яндекс Вебмастера и аналитических систем.
Наблюдайте логи Nginx, ошибки авторизации и поисковую диагностику после переключения.

Одновременно направлять www на без-www и без-www на www нельзя. Такие правила образуют цикл, если запрос последовательно попадает в оба redirect-блока.

HTTP, HTTPS и TLS-сертификат: правильная связка server blocks

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

Схема без цепочек: любой вход сразу в конечный URL

Исходный адрес	Ожидаемый результат
`http://example.com/docs`	301 на `https://example.com/docs`
`http://www.example.com/docs`	301 на `https://example.com/docs`
`https://www.example.com/docs`	301 на `https://example.com/docs`
`https://example.com/docs`	200 или ответ приложения для канонического адреса

Комбинация http://www не должна сначала переходить на https://www, а потом на без-www. Два ответа 301 увеличивают время загрузки, усложняют диагностику и оставляют лишнее звено в цепочке. В redirect-блоке сразу указывайте конечную схему и host.

Тот же принцип действует для www: если канонический адрес равен https://www.example.com, все три остальные комбинации направляются туда одним ответом.

После проверки можно включить HSTS в каноническом HTTPS-блоке:

add_header Strict-Transport-Security 'max-age=31536000' always;

Значение 31536000 задает один год. HSTS заставляет браузер использовать HTTPS для этого host, но не выбирает между www и без-www. Не добавляйте includeSubDomains, пока каждый нужный поддомен не работает по HTTPS: настройка распространится на API, админ-панель и другие имена.

Сертификат для www и без-www

Для HTTPS-вариантов нужны SAN-сертификат с именами example.com и www.example.com или два отдельных сертификата. Сертификат только для канонического host не позволит безопасно обработать неканонический HTTPS-запрос.

Wildcard-сертификат *.example.com покрывает www.example.com, но не покрывает корневой example.com. Корневое имя добавляйте в SAN отдельно. Такой сертификат не покрывает вложенный host вроде api.www.example.com.

Проверьте A и AAAA для обоих имен. Если IPv4 ведет на новый Nginx, а IPv6 остается на старой машине, часть пользователей получит другой код ответа, старый сертификат или прежнюю версию сайта.

Сертификаты, цепочку доверия и ручную установку файлов на Nginx можно сверить по практическому руководству по SSL-сертификату для Nginx и Apache.

Особенности Nginx за CDN или балансировщиком

При TLS-терминации на CDN клиент устанавливает HTTPS-соединение с CDN, а CDN может подключаться к origin по HTTP. В результате Nginx видит внутренний HTTP и не должен слепо повторять редирект на HTTPS по этому признаку.

Зафиксируйте, где выполняются три операции:

выбор канонического host;
перевод HTTP в HTTPS;
передача исходной схемы и host приложению.

Если CDN уже отправляет www на без-www и HTTP на HTTPS, удалите дублирующие правила на origin либо оставьте их как резервную проверку с учетом доверенного заголовка. Если редирект выполняет origin, CDN должен передавать исходный Host и проверенный признак пользовательской схемы.

Для диагностики сравните запрос через CDN с запросом напрямую к origin, если инфраструктура позволяет это сделать. В логах Nginx запишите host, схему, статус и значение $request_uri. Несовпадение этих полей быстро показывает источник цикла.

Пример конфигурации Nginx для нескольких доменов

Несколько имен можно объединить в одном server_name, когда они служат альтернативами одного сайта и должны вести на один канонический URL. Для независимых проектов нужны отдельные блоки, каталоги или upstream и собственные цели редиректа.

Несколько имен для одного сайта

В примере old-example.net и его www-версия считаются старыми именами одного ресурса. Все они направляются на https://example.com.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com old-example.net www.old-example.net;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com old-example.net www.old-example.net;

    ssl_certificate /etc/nginx/tls/site-aliases/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-aliases/privkey.pem;

    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/tls/site-aliases/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-aliases/privkey.pem;

    root /var/www/example;
    index index.html;
}

Сертификат в этом варианте должен включать все имена: корневой домен, www и старый домен. DNS-записи каждого имени должны указывать на сервер или CDN, который действительно отвечает этим конфигом.

Объединяйте домены только после проверки содержания. Если на old-example.net раньше находился отдельный проект, отправка всех его страниц на главную другого сайта не заменяет постраничную миграцию. Для разных материалов настройте отдельные 301 на соответствующие новые URL.

Несколько независимых сайтов на одном Nginx

У двух независимых сайтов должны быть разные канонические host. Ниже показана сокращенная, но рабочая структура для сайтов site-a.example и site-b.example. Каждый проект получает свои redirect-блоки и собственный каталог.

server {
    listen 80;
    listen [::]:80;
    server_name site-a.example www.site-a.example;
    return 301 https://site-a.example$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.site-a.example;

    ssl_certificate /etc/nginx/tls/site-a/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-a/privkey.pem;
    return 301 https://site-a.example$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name site-a.example;

    ssl_certificate /etc/nginx/tls/site-a/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-a/privkey.pem;
    root /srv/site-a;
}

server {
    listen 80;
    listen [::]:80;
    server_name site-b.example www.site-b.example;
    return 301 https://www.site-b.example$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name site-b.example;

    ssl_certificate /etc/nginx/tls/site-b/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-b/privkey.pem;
    return 301 https://www.site-b.example$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.site-b.example;

    ssl_certificate /etc/nginx/tls/site-b/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/site-b/privkey.pem;
    root /srv/site-b;
}

В реальном приложении директиву root можно заменить на отдельный proxy_pass для каждого проекта. Главное правило сохраняется: site-a.example не должен редиректить на host сайта B, а одинаковые имена можно объединять только при одинаковом поведении.

Wildcard, поддомены и корневой домен

Не помещайте все имена в wildcard-правило без проверки. Запись *.example.com охватывает www.example.com, api.example.com, admin.example.com и другие поддомены, но не корневой example.com.

Для host с собственной логикой задайте отдельный server_name:

www.example.com может перенаправляться на канонический сайт;
api.example.com должен передавать запросы API в свой upstream;
admin.example.com может использовать отдельные ограничения доступа и cookies;
cdn.example.com может обслуживать статику без редиректа на основной сайт.

Проверьте TLS и cookies для каждого поддомена. Cookie с областью Domain=.example.com может попасть в запрос к API или админ-панели, поэтому wildcard-каноникализация способна изменить поведение сервисов и расширить область действия учетных данных.

Влияние canonical host на SEO

Доступность одной страницы по www и без-www создает два URL с одинаковым содержанием. Поисковому роботу приходится отдельно обходить эти адреса, а ссылочные и поведенческие сигналы могут распределяться между ними. Постоянный 301 сообщает о переезде и помогает собрать сигналы на выбранном host.

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

Какие SEO-сигналы нужно синхронизировать

Абсолютные внутренние ссылки в меню, статьях, хлебных крошках и навигации.
rel=canonical на каждой индексируемой странице. Значение должно содержать канонический host.
sitemap.xml с URL выбранной версии домена.
Open Graph, прежде всего значение og:url, чтобы социальные сети получали тот же адрес.
RSS и Atom, если в них публикуются ссылки на материалы.
URL в рекламных кампаниях, email-рассылках, документации и внутренних регламентах.
Hreflang для мультиязычных страниц, если проект использует несколько локалей.

Hreflang связывает языковые и региональные версии страниц поверх уже выбранной URL-архитектуры. Он не выбирает между www и без-www. Для каждой локали используйте канонический host, добавляйте ссылку страницы на саму себя и связывайте ее со всеми версиями кластера. Если русская, английская и казахская страницы ссылаются на разные варианты host, поисковая система получает противоречивые сигналы.

301, canonical и прямые ссылки: что делает каждый сигнал

Сигнал	Что он сообщает	Как использовать
301	Запрошенный адрес постоянно переехал	Перенаправлять каждый неканонический host на соответствующий URL канонического домена
`rel=canonical`	Какой URL предпочтителен для индексирования среди доступных вариантов	Указывать канонический адрес в HTML страницы
Внутренняя ссылка	Какую архитектуру URL формирует сам сайт	Ссылаться сразу на выбранный host
Sitemap	Какие URL сайт предлагает роботу для обхода	Публиковать только канонические адреса

Canonical не заменяет редирект, когда альтернативный host не нужен пользователю. Рабочие дубли продолжают принимать запросы и могут оставаться в обходе. Для www/без-www оставьте один доступный HTTPS-адрес, а остальные перенаправьте на него.

301 полезен для старых внешних ссылок и закладок. Внутренние ссылки все равно обновите: постоянные переходы через редирект добавляют задержку и усложняют анализ логов.

Что проверить в Google и Яндекс после миграции

Откройте несколько старых URL в Google Search Console через проверку URL. Сервис должен видеть конечный канонический адрес.
Проверьте в Яндекс Вебмастере обход, диагностику и представление сайта для выбранного host.
Проверьте главную страницу, обычную статью, страницу пагинации, URL с query-параметром и несуществующий адрес.
Убедитесь, что sitemap содержит канонические URL, а старые варианты не возвращаются как полноценные страницы.
Проверьте, что canonical страницы совпадает с конечным адресом после 301.

Переход старого URL на новый не гарантирует мгновенную замену всех адресов в отчетах. Следите за динамикой обхода, ошибками покрытия и появлением новых URL на неканоническом host.

Cookies, сессии и аналитика после смены host

Браузер применяет правила cookies к host независимо от того, что оба имени указывают на один сервер. После 301 пользовательский запрос продолжается уже на другом host, поэтому прежняя cookie может не отправиться.

Как смена www влияет на cookies

Cookie без атрибута Domain считается host-only. Если приложение установило ее на www.example.com, браузер передаст запись только этому host. При переходе на example.com cookie не попадет в запрос, и приложение может создать новую сессию.

Set-Cookie: session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Cookie с атрибутом Domain=.example.com может передаваться корневому домену и его поддоменам, включая www. В современных браузерах начальная точка обычно записывается как Domain=example.com, но в документации и конфигурациях часто встречается форма с точкой.

Общая Domain-cookie расширяет область, в которой сервисы получают значение. Если на api.example.com или admin.example.com есть уязвимость, широкая cookie увеличивает последствия компрометации. Не добавляйте Domain ко всем cookies без анализа модели доступа.

Параметр Secure разрешает отправку только по HTTPS, HttpOnly закрывает cookie от JavaScript, а SameSite ограничивает отправку в межсайтовых сценариях. Эти атрибуты не заменяют правильный выбор Domain.

Проверка Google Analytics и Яндекс Метрики

После редиректа счетчик должен загружаться на конечном host, а сессии не должны дробиться между двумя версиями сайта.

Откройте DevTools и убедитесь, что скрипты Google Analytics и Яндекс Метрики загружаются после перехода на канонический адрес.
Проверьте cookies аналитики и их Domain в разделе Application или Storage.
Перейдите по ссылке с utm_source, utm_medium и utm_campaign. Параметры должны сохраниться после 301.
Проверьте отчеты в реальном времени, источник перехода и отсутствие лишнего self-referral между www и без-www.
Не включайте cross-domain tracking для www и без-www без причины. Это поддомены одного домена, а не два независимых сайта.

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

Переход без потери активных сессий

Снимите список cookies, которые отвечают за вход, корзину, CSRF-защиту и пользовательские настройки.
Проверьте, какие из них host-only, а какие используют Domain.
Настройте приложение так, чтобы на новом host оно выдавало корректные cookies с нужными атрибутами.
Проверьте авторизацию на тестовой копии в чистом профиле браузера.
Включите редирект в период низкой нагрузки и наблюдайте ошибки входа, 401, 403 и обращения к старому host.

Существующую host-only cookie нельзя автоматически сделать доступной другому host одним Nginx-редиректом. Если нужна бесшовная миграция, используйте короткоживущий подписанный механизм передачи состояния на уровне приложения. Не передавайте идентификатор сессии в query-параметре.

Проверка 301-редиректа и типичные ошибки

Проверяйте конфигурацию последовательно: синтаксис Nginx, DNS, TLS, заголовки ответа, конечный код и поведение приложения. Браузер может скрыть часть проблемы из-за кеша HSTS, сохраненных cookies или автоматического следования редиректам.

Команды curl для проверки всех вариантов

Для канонического без-www выполните четыре запроса:

curl -I 'http://example.com/path?x=1'
curl -I 'http://www.example.com/path?x=1'
curl -I 'https://www.example.com/path?x=1'
curl -I 'https://example.com/path?x=1'

Ожидаемый результат для первых трех запросов:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/path?x=1

Канонический HTTPS-адрес должен вернуть ответ приложения, обычно 200. Если сайт специально перенаправляет каталог на завершающий слеш, проверьте это как отдельное правило.

Чтобы увидеть всю цепочку:

curl -IL --max-redirs 5 'http://www.example.com/path?x=1'

При одном host-редиректе вы должны увидеть один ответ 301 и конечный ответ приложения. Несколько блоков с Location подряд показывают цепочку. Одинаковый URL в повторяющихся ответах указывает на redirect loop.

Для более подробного вывода без автоматического перехода используйте:

curl -sS -D - -o /dev/null 'https://www.example.com/path?x=1'

В заголовках проверьте код ответа, один Location, сохранение пути и параметров, а при необходимости заголовок Strict-Transport-Security.

Ошибки 301, 302, 404 и redirect loop

301. Используйте этот код для постоянной смены канонического host. Он сообщает браузерам и поисковым роботам, что старый адрес переехал. Перед публикацией допустимо временно использовать 302, чтобы проверить направление без фиксации постоянного переезда в кешах и поисковых системах.

302. Если после проверки в production остался 302, поисковый робот может воспринимать смену как временную. Для окончательной каноникализации замените его на 301.

404. Частая причина, потерянный путь. Например, правило отправляет любой запрос на главную страницу или вручную заданный target без исходного URI. Сравните входной путь и значение Location.

Redirect loop. Проверьте направление обоих правил, Host в proxy-заголовках, доверие к X-Forwarded-Proto, настройки CDN и редиректы приложения. Команда curl -IL --max-redirs 5 показывает повторяющийся адрес.

Trailing slash и регистр. Нормализацию /docs в /docs/ и изменение регистра вынесите в отдельные правила. Сначала добейтесь корректной смены host и протокола, потом проверяйте дополнительные преобразования URL.

Финальный чек-лист перед публикацией

Записи A и AAAA для www и без-www указывают на правильную инфраструктуру.
TLS-сертификат покрывает оба host, а цепочка сертификатов читается Nginx без ошибок.
В каждом server block указан правильный server_name.
Канонический host выбран один, обратного правила в рабочем HTTPS-блоке нет.
Все неканонические варианты отвечают кодом 301.
В Location сразу указан конечный HTTPS-адрес.
$request_uri сохраняет путь и query-параметры.
Между исходным и конечным адресом нет лишнего 301 и цикла.
Авторизация, корзина, пользовательские настройки и CSRF-защита работают после перехода.
Google Analytics и Яндекс Метрика получают события на конечном host, а UTM-параметры не теряются.
Canonical, sitemap, Open Graph, RSS/Atom, hreflang и внутренние ссылки используют выбранную версию домена.
Проверены Google Search Console и Яндекс Вебмастер для основных типов страниц.
Команда nginx -t завершается успешно.
Полный результат nginx -T не содержит конфликтующих server blocks и неожиданных wildcard-правил.
После reload в логах Nginx нет всплеска 4xx, 5xx, повторных Location и обращений к неверному upstream.

После проверки примените конфигурацию командой systemctl reload nginx и повторите запросы через IPv4, IPv6 и CDN. В итоговой схеме должен оставаться один канонический HTTPS-адрес, а любой старый вариант должен приводить пользователя и поискового робота к нему одним постоянным редиректом.