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

Добавил пользователь Дмитрий К.
Обновлено: 10.09.2024

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

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

Nginx

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

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

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

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

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

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

После внесения изменений в конфигурационный файл 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.

Настройка редиректов в Nginx

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

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

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

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

Пример с nginx rewrite

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

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

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

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

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

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

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

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

Заключение

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

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

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

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