Источник https://www.dmosk.ru/miniinstruktions.php?mini=nginx-redirects#index
Настройка перенаправлений
С HTTP на HTTPS
На другой домен
Без www на www
С www на без www
C index.php на /
Перенаправление по умолчанию
Другой сервер
Для домена и всех его поддоменов
Файл
Часть url на другой сервер
Удалить часть URL
Немного о 301 и 302
Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В 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 можно прописать несколькими способами.
1. Первый:
rewrite ^ https://$host$request_uri? <флаг>;
* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:
2. Второй:
return <код> https://$host$request_uri;
* где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используется второй вариант.
После внесения изменений, необходимо проверить их корректность:
nginx -t
И для их применения перезапустить веб-сервер:
systemctl restart nginx
service nginx restart
* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
server {
listen 80;
server_name domain.ru www.domain,ru;
return 301 https://$host$request_uri;
}
* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).
server {
...
server_name domain1.ru;
return 302 http://domain2.ru$request_uri;
}
server {
...
server_name domain.ru;
return 301 http://www.$host$request_uri;
}
server {
...
server_name "~^www\.(.*)$" ;
return 301 $scheme://$1$request_uri;
}
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;
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, необходимо указывать в настройках пути к сертификатам.
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
...
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.
Использование 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.
HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):
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 {
...
server_name domain domain.*;
return 301 https://$host$request_uri;
}
Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:
server {
...
location = /robots.txt {
rewrite ^/robots.txt$ /robots2.txt;
}
}
* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.
Перенаправить запрос на жругой сервер при обращении по url page1:
server {
...
location ~ ^/page1/(.*)$ {
return 301 $scheme://10.10.10.10/$1;
}
}
Это позволит передать на обработку запроса по определенному url на другой сервер:
server {
...
location ~ ^/page1/(.*)$ {
proxy_pass $scheme://10.10.10.10/$1;
}
}
Иногда нужно удалять часть url. Это можно сделать следующими способоми:
server {
...
rewrite /deleted-url/(.*) /$1 permanent;
}
или:
server {
...
if ($request_uri ~ "/deleted-url/(.*)") {
return 301 $1;
}
}
* в данном примере из url мы удалим deleted-url/.
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.