Nginx редирект на другой домен. Редирект с каждой страницы одного домена на такой же URL адрес другого домена. Использование вложенных if
Если у вас на сайте есть SSL сертификат для домена, то вы можете настроить https протокол. После чего для 301-го редиректа вам необходимо добавить следующий код в файл конфигурации nginx для домена:
Server { #... if ($scheme = http) { return 301 https://$server_name$request_uri; } }
Server { #... listen server_ip:80; server_name www.devreadwrite.com; rewrite ^ https://www.devreadwrite.com$request_uri? permanent; }
Nginx, 301 редирект с https на http протокол
Обратный пример конфигурации для редиректа с http на https:
Server { listen 443; server_name www.devreadwrite.com; rewrite ^ http://www.devreadwrite.com$request_uri? permanent; } server { listen 80; server_name www.devreadwrite.com; #... }
Nginx, 301 редирект с www на без www
Пример 301-го редиректа на основное зеркало без www:
Server { #... if ($host ~* www\.(.*)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; } }
Server { #... server_name www.devreadwrite.com; rewrite ^/(.*)$ http://devreadwrite.com/$1 permanent; }
Nginx, 301 редирект с без www на с www
Обратный пример 301-го редиректа на основное зеркало сайта с www:
Server { #... server_name devreadwrite.com; rewrite ^/(.*)$ http://www.devreadvrite.com/$1 permanent; } server { listen 80; server_name www.devreadvrite.com; #... }
Nginx, 301 редирект для одной страницы
Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL:
Server { #... if ($request_filename ~ oldpage/) { rewrite ^ http://www.devreadvrite.com/newpage/? permanent; } #... }
Nginx, 301 редирект для папки
Аналогичный пример 301-го редиректа для папки:
Server { #... if ($request_filename ~ oldfolder/.+) { rewrite ^(.*) http://www.devreadvrite.com/newfolder/$1 permanent; } #... }
Nginx, 301 редирект с одного домена на другой
Если вы сменили домен сайт и хотите перенести вес старого домена на новый, то можно сделать 301-й редирект со старого домена на новый:
Server { server_name domain.com www.devreadvrite.com; rewrite ^ $scheme://www.new-devreadvrite.com; }
Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена
Если вы планируете изменить свой домен или изменить название предприятия, то перенаправление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен.
Server { server_name devreadvrite.com www.devreadvrite.com; rewrite ^ $scheme://www.new-devreadvrite.com$request_uri permanent; }
Nginx, 301 редирект со страниц со слешем на страницы без слеша в конце URL
Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него:
Server { #... rewrite ^/(.*)/$ /$1 permanent; #... }
Nginx, 301 редирект со страниц без слеша на страницы со слешем в конце URL
Причина делать такой редирект та же, что и в ситуации описанным выше, за исключением того, что редирект необходимо делать со страницы без слеша в конце URL на страницу со слешем в конце URL:
Server { #... rewrite ^(.*[^/])$ $1/ permanent; #... }
Дополнительно
Не забудьте перед использованием примеров сменить devreadwrite.com на свой домен. После внесения изменений в файл конфигурации nginx для домена необходимо перезапустить nginx:
Service nginx reload
Nginx is an extremely efficient and quite flexible web server. When you want to do a redirect in Nginx, you have a few options to select from, so you can choose the one that suits you best to do an Nginx redirect.
Simplest and fastest: return
The by far simplest and fastest – because there is no regexp that has to be evaluated – is to use the return statement. Place this in your server block:
Return 301 https://example.com$request_uri;
This is a permanent redirect. Use 302 if you want a temporary redirect. A full sample server block could be:
Server { listen 80; listen [::]:80; hostname example.com www.example.com; return 301 https://example.com$request_uri; }
Using regular expressions
If you need something more complex, don’t be afraid to use a regexp – they’re still extremely fast in Nginx:
Rewrite ^/foo/(bar)/(.*)$ https://$server_name/$1/$2 permanent;
Replace permanent with redirect if you want a temporary (HTTP 302) redirect. Our full sample server block could then be:
Server { listen 80; listen [::]:80; hostname example.com www.example.com; root /var/www/example.com/public; rewrite ^/foo/(bar)/(.*)$ $scheme://$server_name/$1/$2 permanent; }
Using maps
If you have a list of URLs or regular expressions that you want to redirect differently, you ought to look into using a map, which you very well may define in a separate file for your convenience. Just note that the map definition must be outside the server block:
Include redirect-map.conf; server { […] if ($redirect_uri) { return 301 $redirect_uri; } }
The file redirect-map.conf may then look something like this:
Map $request_uri $redirect_uri { /about.html /about-us; /customers.html /our-customers; /products.html /our-products; }
Note the following excerpt from the docs:
A regular expression should either start from the “~” symbol for a case-sensitive matching, or from the “~*” symbols (1.0.4) for case-insensitive matching. A regular expression can contain named and positional captures that can later be used in other directives along with the resulting variable.
Here’s an example that might help you understand what that was about:
Map $request_uri $redirect_uri {
/about.html /about-us;
/customers.html /our-customers;
/products.html /our-products;
# Match any url that ends in products.html or producs.htm
~products\.html?$ /our-products;
# case-insensitive version of the above
~*products\.html?$ /our-products;
# A named capture that maps
# e.g. product-1234.html into /products/item-1234/overview
~product-(?
Cute, huh? :-) Also please note that the variable name $redirect_uri have no special meaning: It is one I made up. You can name it whatever you like, but make sure the variable name in the map and the server block matches.
Some useful variables
I’ve used a few of these in the examples above, so you might have noticed them before. These are variables that comes predefined by Nginx, ready for you to use in your configs:
$scheme – The scheme used for the current request. E.g. “http” or “https”
$host – The hostname provided by the client for the current request.
$server_name – The first hostname from the hostname declaration in your config for the server block that responds to the request.
$request_uri – The full original request URI – with arguments.
$request_filename – The file path for the current request.
Some useful recipes for an Nginx redirect
HTTP to HTTPS
return 301 https://$host$request_uri;Canonical hostname
If the hostname doesn’t match the first name in the server_name list. Makes sure your content is only available at the canonical hostname, e.g. to avoid duplicate content issues. Excellent for redirecting non-www to www or redirecting www to non-www in Nginx as long as your server block is only for a single website.
Server_name example.com www.example.com example.net www.example.net _; if ($host != $server_name) { return 301 $scheme://$server_name$request_uri; }
Nginx is very efficient, but please note that it would be more efficient to have two separate server blocks – one for the hostnames you want to redirect and one for the website. Then Nginx won’t have to do the comparison for every request.
Generic non-www/www redirects
If your server block covers multiple websites – e.g. a WordPress multisite network and you don’t want all of them to redirect to the same hostname, you can still do a universal check:
Redirect non-www to www:
if ($host !~ ^www\.) { return 301 $scheme://www.$host$request_uri; }Redirect www to non-www
if ($host ~ ^www\.(?For the www/non-www redirects, it is worth mentioning again that using separate server blocks, where one use the return statement described at the top, is by far the most efficient.
1. Nginx, 301 редирект с http на https протокол
Если у вас на сайте есть SSL сертификат для домена, то вы можете настроить https протокол. После чего для 301-го редиректа вам необходимо добавить следующий код в файл конфигурации nginx для домена:
Server { #... if ($scheme = http) { return 301 https://$server_name$request_uri; } }
Server { #... listen server_ip:80; server_name www.devreadwrite.com; rewrite ^ https://www.devreadwrite.com$request_uri? permanent; }
2. Nginx, 301 редирект с https на http протокол
Обратный пример конфигурации для редиректа с http на https:
Server { listen 443; server_name www.devreadwrite.com; rewrite ^ http://www.devreadwrite.com$request_uri? permanent; } server { listen 80; server_name www.devreadwrite.com; #... }
3. Nginx, 301 редирект с www на без www
Пример 301-го редиректа на основное зеркало без www:
Server { #... if ($host ~* www\.(.*)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; } }
Server { #... server_name www.devreadwrite.com; rewrite ^/(.*)$ http://devreadwrite.com/$1 permanent; }
4. Nginx, 301 редирект с без www на с www
Обратный пример 301-го редиректа на основное зеркало сайта с www:
Server { #... server_name devreadwrite.com; rewrite ^/(.*)$ http://www.devreadvrite.com/$1 permanent; } server { listen 80; server_name www.devreadvrite.com; #... }
5. Nginx, 301 редирект для одной страницы
Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL:
Server { #... if ($request_filename ~ oldpage/) { rewrite ^ http://www.devreadvrite.com/newpage/? permanent; } #... }
6. Nginx, 301 редирект для папки
Аналогичный пример 301-го редиректа для папки:
Server { #... if ($request_filename ~ oldfolder/.+) { rewrite ^(.*) http://www.devreadvrite.com/newfolder/$1 permanent; } #... }
7. Nginx, 301 редирект с одного домена на другой
Если вы сменили домен сайт и хотите перенести вес старого домена на новый, то можно сделать 301-й редирект со старого домена на новый:
Server { server_name domain.com www.devreadvrite.com; rewrite ^ $scheme://www.new-devreadvrite.com; }
8. Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена Если вы планируете изменить свой домен или изменить название предприятия, то перенаправление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен.
Server { server_name devreadvrite.com www.devreadvrite.com; rewrite ^ $scheme://www.new-devreadvrite.com$request_uri permanent; }
9. Nginx, 301 редирект со страниц со слешем на страницы без слеша в конце URL
Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него:
Server { #... rewrite ^/(.*)/$ /$1 permanent; #... }
10. Nginx, 301 редирект со страниц без слеша на страницы со слешем в конце URL
Причина делать такой редирект та же, что и в ситуации описанным выше, за исключением того, что редирект необходимо делать со страницы без слеша в конце URL на страницу со слешем в конце URL:
Server { #... rewrite ^(.*[^/])$ $1/ permanent; #... }
Дополнительно:
Не забудьте перед использованием примеров сменить devreadwrite.com на свой домен. После внесения изменений в файл конфигурации nginx для домена необходимо перезапустить nginx:
Service nginx reload
На основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.
Саму настройку на перенаправление в NGINX можно прописать несколькими способами.
1. Первый:
rewrite ^ https://$host$request_uri? <флаг>;
* $host
— имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri
— первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:
- permanent — перенаправление с кодом 301.
- redirect — перенаправить с кодом 302.
- last — закончить обработку с переходом в новый location.
- break — закончить обработку и остаться в текущем location.
2. Второй:
return <код> https://$host$request_uri;
* где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используется второй вариант.
После внесения изменений, необходимо проверить их корректность:
И для их применения перезапустить веб-сервер :
systemctl restart nginx
service nginx restart
* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.
С одного домена на другой
server {
...
server_name domain1.ru;
return 302 http://domain2.ru$request_uri;
}
C домена без www на домен с www
server {
...
server_name domain.ru;
return 301 http://www.$host$request_uri;
}
С www на без www
server {
...
server_name "~^www\.(.*)$" ;
return 301 $scheme://$1$request_uri;
}
C index.php на /
server {
...
if ($request_uri ~ "^(.*)index\.(?:php|html)") {
return 301 $1;
}
}
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:
server {
listen 80 default_server;
return 302 https://welcome.domain.ru$request_uri;
}
или независимо от протокола:
server {
listen 80 default_server;
}
Server {
listen 443 default_server;
return 302 $scheme://welcome.domain.ru$request_uri;
Ssl on;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
}
* $scheme
позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабаывать запросы по https, необходимо указывать в настройках пути к сертификатам.
На другой сервер
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
...
location / {
proxy_pass $scheme://192.168.0.15:8080/;
proxy_redirect off;
}
* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.
Использование NGINX в качестве http-прокси:
server {
...
server_name site1.ru www.site1.ru;
location / {
proxy_pass http://192.168.1.21/;
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;
}
}
Server {
...
server_name site2.ru www.site2.ru;
location / {
proxy_pass http://192.168.1.22/;
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;
}
}
* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21 , а запросы на site2.ru — 192.168.1.22 .
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.
Редирект домена и всех его поддоменов
server {
...
if ($request_uri ~ "/deleted-url/(.*)") {
return 301 $1;
}
}
* в данном примере из url мы удалим deleted-url/ .
Немного о 301 и 302
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
06.09.2018
10.09.2018
В данной статье буду собирать все редиректы в nginx которыми пользуюсь
Рассматриваю на примере конфигурации веб-окружения BitrixVM, т.к. занимаюсь разработкой именно в данной среде, но правила одинаковые для любых систем, поэтому, это не принципиально.
Правила нужно прописывать в файле с описаниемм конфигурации конкретного хоста (для BitrixVM это
/etc/nginx/bx/site_avaliable/bx_ext_domain.conf - для сайта, работающего без ssl;
/etc/nginx/bx/site_avaliable/bx_ext_ssl_domain.conf - при работе по ssl);
Саму настройку на перенаправление в NGINX можно прописать двумя способами.
Rewrite ^ https://$host$request_uri? ;
* $host - имя хоста из запроса, если отсутствует - имя в поле «Host» заголовка, если тоже отсутствует - имя сервера; $request_uri - первоначальный запрос с аргументами (все, что идет после доменного имени). ** где флаги могут быть следующие:
- permanent - перенаправление с кодом 301.
- redirect - перенаправить с кодом 302.
- last - закончить обработку с переходом в новый location.
- break - закончить обработку и остаться в текущем location.
Return https://$host$request_uri;
Где коды могут использоваться любые, но чаще всего - 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться - решать по ситуации. В сети в примерах используется чаще всего второй вариант.
Редирект с http: на https
if ($scheme = http) { return 301 https://$server_name$request_uri; }Или, если вам повезло также как и мне и конфигурационные файлы для ssl и без ssl - разные, то в файле для без ssl можно прописать прямой редирект:
Server { #... listen server_ip:80; server_name www.sitename.com; rewrite ^ https://www.sitename.com$request_uri? permanent; }
редирект с www на без www
if ($host ~* www\.(.*)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; }Добавляем слеши в конце
if (!-f $request_filename) { rewrite [^/]$ $uri/ permanent; }Убираем слеш в конце
if (!-f $request_filename) { rewrite ^/(.*)/$ /$1 permanent; }Убираем index.php в конце адреса
if ($request_uri ~ "^(.*)index\.(?:php|html)") { return 301 $1; }Если для определенных разделов данный редирект нужно отключить, то в маску добавляем разделы исключения:
If ($request_uri ~ "^(/(?!personal|catalog).*)index\.(?:php|html)") { return 301 $1; }
If ($request_uri ~ "^(.*)index\.(?:php|html)") { return 301 $1$is_args$args; break; # break нужен в том случае, #если происходит склейка нескольких редиректов одновременно }
Редирект для конкретной страницы
Обычный редирект в htaccess имеет вид:
Redirect 301 /catalog/section_1/section_1_1/ /catalog/section_1_1/
В nginx примет вид:
Rewrite /catalog/section_1/section_1_1/ /catalog/section_1_1/ permanent;
Также, редирект конкретного файла можно сделать так:
Location = /robots.txt { rewrite ^/robots.txt$ /robots2.txt; }
Чтобы удалить из адреса часть строки, можно сделать так:
Rewrite /deleted-url/(.*) /$1 permanent;
If ($request_uri ~ "/deleted-url/(.*)") { return 301 $1; }
Редирект с одного домена на другой
server { server_name domain.com www.domain.com; rewrite ^ $scheme://www.new-domain.com; }Редирект с каждой страницы одного домена на такой же URL адрес другого домена
server { server_name domain.com www.domain.com; rewrite ^ $scheme://www.new-domain.com$request_uri permanent; }Редирект домена и всех его поддоменов:
server { ... server_name domain domain.*; return 301 https://$host$request_uri; }Сложный анализ ЧПУ
Пример из сети по обработке api-запросов:
Location ~* api/ { rewrite ^/api/(.*)$ /api.php?_d=$1&ajax_custom=1&$args last; }
Пока не приходилось сталкиваться, но, может быть, кому-то будет полезным!
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Для этого, в основном конфигурационном файле (для bitrixVM это /etc/nginx/bx/site_available/s1.conf) пишем:
Server { listen 80 default_server; return 302 https://welcome.domain.ru$request_uri; }
или независимо от протокола:
Server { listen 80 default_server; return 302 $scheme://welcome.domain.ru$request_uri; } server { listen 443 default_server; return 302 $scheme://welcome.domain.ru$request_uri; ssl on; ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/cert.key; }
* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабаывать запросы по https, необходимо указывать в настройках пути к сертификатам.
Редирект на особенную страницу по 404-му статусу
Если страница не найдена - будет выдан 404-й статус и показана соответствующая страница. Но иногда, для случая, когда при отсутствии того или иного файла должен быть выполнен редирект куда-то, можно воспользоваться конструкцией:
Location ~ \.php$ { .... try_files = $uri @missing; } location @missing { rewrite ^ $scheme://$host/some_file.php permanent; }
По этой логике можно определять любые конструкции, которые вам нужны. Сначала сервер попробует выполнить файл, и, если он не будет найден, он переместится в часть @missing. А второй блок, с @missing, перенаправит на нужную страницу.
Использование вложенных if
Вложенные if в конфигурации nginx запрещены, поскольку это вовсе не языковая конструкция nginx, а обычная директива из модуля rewrite, использование которой в ее же собственном контексте if не предусмотрено. Использование списка условий, разделенных логическими операторами "и" и "или" тоже не предусмотрено. Обычно для эмуляции вложенных условий с использованием директивы if предлагают использовать регулярные выражения. Например, проверить, что имя, указаное в HTTP хедере HOST, соответствует значению localhost, а в URI присутствует аргумент "a" (в этом случае переменная $arg_a будет не пустой), можно так:
Location /test_if.html { set $cond $host::$arg_a; if ($cond ~* "^localhost::.+") { echo "Matched: host = "$host", a = "$arg_a""; break; } echo "Not matched: host = "$host", a = "$arg_a""; }
К сожалению, условие в директиве if имеет ограничения. По крайней мере, это не выражение, и оно не может быть составлено в виде цепочки выражений, разделенных логическими операторами. Кроме того, в случае сравнения чего-то с регулярным выражением, это что-то может быть только именем переменной, именно поэтому пришлось ввести новую переменную $cond:
Location /test_if.html { set $goodhost "localhost"; set $cond $host::$goodhost::$arg_a; if ($cond ~* "^(.*)::\1::.+") { echo "Matched: host = "$host", a = "$arg_a""; break; } echo "Not matched: host = "$host", a = "$arg_a""; }
В данном примере мы соединили через произвольно выбранный нами разделитель:: три переменных $host, $goodhost и $arg_a и присвоили это значение переменной $cond. А регулярное выражение, с которым мы сопоставляем это значение, проверяет, что его первая часть (до разделителя::) и вторая часть (до второго разделителя::) равны, а последняя часть (после второго разделителя) не пуста.
В полном виде конструкция проверки примет вид:
Location /test_if.html { set $goodhost "localhost"; set $cond $host::$goodhost::$arg_a; if ($cond ~* "^(.*)::\1::ok$") { echo "Matched: host = "$host", a is Ok"; break; } if ($cond ~* "^(.*)::\1::.+$") { echo "Matched: host = "$host", a = "$arg_a""; break; } echo "Not matched: host = "$host", a = "$arg_a""; }
Описание структуры работы с вложенными if взято отсюда .
Сложное условие и проксирование запросов
Если нужно выполнить проксирование запросов с помозью директивы proxy_pass только при соблюдении нескольких условий, то можно воспользоваться следующей конструкцией:
If ($request_uri = /) { set $test A; } if ($host ~* domain.com) { set $test "${test}B"; } if ($http_cookie !~* "auth_token") { set $test "${test}C"; } if ($test = ABC) { proxy_pass http://domain-new.com; break; }
Пояснения:
Условие RewriteCond обозначает совпадение с которым будет выполнено правило RewriteRule. При этом, используются символы:
.
– Точка - это любой символ (но только один!).
^
- Эта метка означает начала строки.
$
- Эта метка означает конец строки.
\
- Эта экранирующий слэш, позволяет считать следующий за ним символ, обычным символом.
()
– Этот символ обозначает группировку.
!
– Метка отрицания.
+
- Этот символ повторяется от 1 до 65536 раз.
?
- Этот символ повторяется 0 или 1 раз.
*
- А этот символ повторяется от 0 до 65536 раз.
Флаги определяют дополнительные опции.
R - (redirect)
- По умолчанию останавливает процесс преобразования, возвращает результат в браузер клиента, как редирект на данную страницу 302, MOVED TEMPORARY
. Например флагу можно указать другой код результата, R=301
и он возвратит редирект клиенту с кодом 301 MOVED PERMANENTLY
.
NC - (nocase)
- Этот флаг отключает проверку регистра символов.
L - (last)
- Флаг останавливает процесс преобразования, текущая ссылка считается окончательной.
Чтобы изменения вступили в силу - не забудьде произвести рестарт nginx. Но для начала - проверьте, что ваша конфигурация в порядке. Для этого выполните команду:
Nginx -t
Если выдаст "OK" - делаем смело перезагрузку:
Service nginx restart
Systemctl restart nginx
Первый вариант - для устаревших систем Linux или FreeBSD. Второй - для новых систем Linux
Если же показывает ошибку - разбираемся с ней.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
Отличия между 301 и 302 редиректами:
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы - это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
P.S. Не забывайте, что внесение любых изменений в конфигурации сервера могут привести к тому, что самостоятельно вы можете и не восстановить. Поэтому не забывайте делать бекапы!