Как сделать редирект с www на без www nginx

Обновлено: 23.01.2025

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

Для перенаправления трафика Nginx использует несколько инструментов.

Nginx

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена с www, вторая для домена без www:
Секция server для редиректа:

Секция server, где находятся основные настройки домена:

После внесения изменений в конфигурационный файл Nginx, нужно перезапустить веб сервер.

Секция server для редиректа:

Секция server, где находятся основные настройки домена.

После внесения изменений в конфигурационный файл Nginx, нужно перезапустить веб сервер.

Для существующего домена в конф. файле nginx

Если вы вносите изменения в существующую секцию конф. файла nginx делайте это так: Из основной секции домена удалите строку вида

И создайте новую секцию server такого вида:

После внесения изменений в конфигурационный файл Nginx, его нужно перезапустить:

Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL:

301 редирект для папки

301 редирект с одного домена на другой

301 редирект со страниц со слешем на страницы без слеша в конце URL

Убрать / на конце страницы

Редиректы со страниц с index.php

Редиректы со страниц //

После внесения изменений в конфигурационный файл Nginx, нужно перезапустить веб сервер.

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.

Саму настройку на перенаправление в NGINX можно прописать несколькими способами.

permanent — перенаправление с кодом 301.
redirect — перенаправить с кодом 302.
last — закончить обработку с переходом в новый location.
break — закончить обработку и остаться в текущем location.

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

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

После внесения изменений, необходимо проверить их корректность:

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5 . Если и это не помогает, закрывайте вкладку и открывайте новую.

С одного домена на другой

C домена без www на домен с www

С www на без www

server …
server_name "~^www\.(.*)$" ;
return 301 $scheme://$1$request_uri;
>

C index.php на / (корень)

Данная настройка позволит перевести все запросы с /index.php на корневой адрес /:

server …
if ($request_uri ~ "^(.*)index\.(?:php|html)") return 301 $1;
>
>

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

или независимо от протокола:

ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
>

С IP-адреса на домен

В данном случае мы переводим все запросы по IP-адресу на конкретный домен:

Редирект домена и всех его поддоменов

На другой файл

Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:

server …
location = /robots.txt rewrite ^/robots.txt$ /robots2.txt;
>
>

* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.

Часть url на другой сервер

Перенаправить запрос на другой сервер при обращении по url page1:

Редирект со слешем

1. Убрать слеш в конце url

а) с помощью rewrite:

б) с помощью return:

2. Добавить слеш в конце url

а) с помощью rewrite:

б) с помощью return:

На другую страницу

Нам может понадобиться перенаправлять запросы с одной страницы сайта на другую. Приведем примеры, как это сделать с помощью return и rewrite.

а) с помощью rewrite:

server …
rewrite ^/page1$ /page2 permanent;
>

б) с помощью return:

server …
location = /page1 return 301 /page2;
>
>

Удалить часть URL

Иногда нужно удалять часть url. Это можно сделать следующими способами:

server …
rewrite /deleted-url/(.*) /$1 permanent;
>

server …
if ($request_uri ~ "/deleted-url/(.*)") return 301 $1;
>
>

* в данном примере из url мы удалим deleted-url/.

* в данном примере мы проверяем наличие файла, к которому идет обращение. И если его нет, то происходит замена адреса на такое же имя файла с .php на конце.

Проксирование

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

1. На другой сервер

…
location / proxy_pass $scheme://192.168.0.15:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX , а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

server …
location / proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization "Basic dGVzdDp0ZXN0";
…
>
>

* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.

2. Часть url на другой сервер

Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:

server …
location ~ ^/page1/(.*)$ proxy_pass $scheme://10.10.10.10/$1;
>
>

3. На другой сайт

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

Немного о 301 и 302

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.

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

Я использую nginx на облаке Rackspace после урока и обыскав сеть и до сих пор не может получить эту сортировку.

мой в/etc/nginx/сайты доступны/ВСП.пример.ком.файл vhost конфигурация:

Я тоже пробовал

Я тоже пробовал. Обе вторые попытки дают цикл перенаправления ошибки.

мой DNS настроен как стандартный:

(пример IPs и папки были использованы для примеров и помочь людям в будущем). Я использую Ubuntu 11.

С документация, "правильный способ-определить отдельный сервер для example.org":

некоторые из моего кода, показанного ниже для лучшего представления:

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

следующий фрагмент удаляет www перед любым доменом:

вот как это сделать для нескольких www-имен серверов no-www (я использовал это для поддоменов):

вам нужно два серверных блока.

поместите их в свой конфигурационный файл, например /etc/nginx/sites-available/sitename

допустим, вы решили иметь http://example.com в качестве основного адреса для использования.

ваш конфигурационный файл должен выглядеть так:

первый серверный блок будет содержать инструкции по перенаправлению любых запросов с префиксом 'www'. Он слушает запросы на URL-адрес с префиксом " www " и перенаправляет.

он ничего не делает еще.

второй блок сервера будет содержать ваш основной адрес-URL, который вы хотите использовать. Все остальные настройки идут сюда, как root , index , location и т. д. Проверьте файл по умолчанию для этих параметров можно включить в блок Server.

серверу нужны две записи DNS A.

для ipv6 создайте пару записей AAAA, используя ваш-ipv6-адрес.

попробуй такое

другим способом: Nginx no-www to www

и www к no-www

Хочу сегодня рассмотреть тему редиректов в Nginx. Я обычно настраиваю их в лоб. То есть нужен какой-то редирект, я его добавляю. На днях меня попросили СЕО специалисты переработать редиректы одного проекта и сделать так, чтобы для клиента был ровно один 301 редирект, который включает в себя сразу все необходимые преобразования url.

Пример двойного редиректа

А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный location /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.

Пример с nginx rewrite

Встроенные редиректы WordPress

Все стандартные редиректы в nginx

Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:

Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.

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

Корректный редирект с одного url на другой

Опять два 301-х редиректа. Переделываем на один, не забывая все возможные варианты написания.

Ну и так далее. Думаю, идея ясна. Следует следить за всеми редиректами и стараться всегда оставлять только один.

Заключение

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

Материал полностью написан и протестирован мной от начала до конца, поэтому призываю не копировать слепо к себе, а проверить. Я могу где-то ошибаться, что в такой важной теме может быть чревато проблемами с индексацией и работой сайта. Так что внимательно все проверяйте, прежде чем внедрять у себя. Ну а замечания все, как обычно, жду в комментариях.

В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему. А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx.

Читайте также: