Nginx редирект на другой порт. Полезные редиректы в nginx

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

Это необходимо из соображений SEO оптимизации, а также безопасности пользователей, чтобы никто не мог разорвать защищенное соединение. В этой статье мы рассмотрим как настроить редирект с http на https Nginx.

Редирект с http на https Nginx

Я предполагаю, что вы будете использовать постоянное перенаправление с кодом статуса 301. Это означает перемещение на постоянной основе. Такой метод используется чтобы сообщить поисковым системам или браузеру, что текущая ссылка была обновлена, и ее стоит обновить в своей базе, например, закладок браузера.

В конфигурационном файле Nginx должно быть две секции server, для сайта на https и сайта http. В секции http вы просто перенаправляете все запросы на https c помощью инструкции return, а во второй секции уже все обрабатываете. Например, первая секция:

server {
server_name сайт www.сайт;
charset off;
index index.php;
ssi on;
return 301 https://$host:443$request_uri;

root $root_path;
listen:80 default_server;
...
}

Вторая секция уже с обработкой SSL слушает запросы на 443 порту:

server {
server_name сайт www.сайт;
ssl on;
ssl_certificate "/var/www/losst/сайт_le2.crtca";
ssl_certificate_key "/var/www/losst/сайт_le2.key";
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
add_header Strict-Transport-Security "max-age=31536000;";
charset off;
index index.php;
set $root_path /var/www/losst/data/www/сайт;
root $root_path;
listen:443 default_server;
...
}

Собственно, синтаксис тут очень прост, инструкция return позволяет возвращать необходимые коды ответа сервера. Здесь же мы возвращаем код 301, постоянный редирект, а также URL, на который собираемся перенаправить пользователя. Кроме директивы return, можно использовать инструкцию rewrite, с помощью нее выполняются точно те же действия:

rewrite ^/(.*)$ https://losst.com/$1 permanent;

Это обычный синтаксис регулярных выражений. В первом аргументе мы выделяем группу строки запроса, а во второй указываем правильный домен. Ее можно добавить вместо return 301. Также можно использовать такую конструкцию без отдельного блока server:

if ($host ~* ^(losst\.ru|www\.losst\.ru)$){
rewrite ^/(.*)$ https://сайт/$1 permanent;
}

Теперь осталось протестировать то, что получилось. Сохраните файл и проверьте конфигурацию nginx:

Затем, если все хорошо, перезапустите Nginx:

curl -I сайт

Или позволим утилите проследовать полный путь по перенаправлению:

curl ILa сайт

Выводы

Настроить редирект на https nginx достаточно просто, фактически, все выполняется добавлением одной строки в конфигурационный файл, все остальное - дополнительные параметры. Редирект с https на http nginx будет выполняться так же. Только нужно будет изменить несколько букв в параметрах retrun. Не забывайте проверять правильно ли настроены редиректы с www и на https, это играет очень важную роль для SEO. Надеюсь, эта информация была полезной для вас.

Начнем с вопроса, что вообще это такое 301 редирект ? Редирект (Redirect) – это перенаправление пользователей с одного (сайта) на другой, либо с одной определенной страницы на другу. Используется он довольно таки часто и сейчас мы разберемся, как его настроить и для чего он нужен.

Для чего нужен 301 редирект?

Когда необходимо определить зеркало главной страницы или еще називают переадресация домена с www на без и на оборот.

Возможно Вы сменили домен и вам необходимо все показатели () и ссылочную массу со старого домена перенести на новый.

Если имеются дубли на сайте или необходимо перенаправить посетителей с одной определенной страницы на другую.

Если вы имеете или купили домен с отличными показателями и он схожей тематики с вашим сайтом, вы можете склеить (сделать 301 редирект ) домен и ваш сайт. Частично показатели купленного домена перейдут к вашему сайту. Почему частично? Да потому что никто вам не гарантирует 100% склейку всех показателей.

Перейдем непосредственно к настройке редиректа 301 для разных серверов.

Как настроить 301 редирект.htaccess?

Если вы используете сервер Apache, то вы без проблем сможете сделать 301 редирект с помощью файлов.htaccess или httpd.conf. Необходимо так же включить модули, для поддержки директив.:

Директивы:

mod_alias (Redirect, RedirectPermanent и RedirectMatch);
mod_rewrite (RewriteRule).

Используем директивы Redirect или RedirectPermanent, для настройки 301 редиректа co старой страницы на новую страницу, нового сайта.

Redirect 301 /old-page.html http://new-domain.ru/new-page.html
или
Redirect permanent /old-page.html http://new-domain.ru/new-page.html
или
RedirectPermanent /old-page.html http://new-site.ru/new-pagehtml

Недостатком этого метода является то, что все страницы которые необходимо перенаправлять, нужно прописывать одну за другой (последовательно). Используем директиву RedirectMatch, для тех же целей.

RedirectMatch /(.*)\.php$ /$1.aspx

Данный метод можно использовать при переносе сайта с PHP движка на ASP.

Переадресация домена с www префиксом на без www в.htaccess.

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

Используем директивы RewriteRule для редиректа 301 , домена с www префиксом на без него. Как пример будем использовать наш сайта:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.loleknbolek\.com$

Теперь без www префикса на домен с www:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^loleknbolek\.com$
RewriteRule ^(.*)$ https://сайт/$1

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

Как настроить 301 редирект nginx?

Давайте рассмотрим пример переадресации для сайта с www на без www. Пример для нашего сайта:

if ($host = ‘www.www.сайт’) {
rewrite ^(.*)$ https://сайт$1 permanent;
}

Можно еще попробовать вот так:

server {
server_name сайт;
rewrite ^ https://сайт$request_uri? permanent;
}
server {
server_name www.сайт;
…. основная конфига. …
}

Как настроить 301 редирект с помощью скриптов (отправки заголовков)?

Настраиваем с помощью использования скриптов, редирект делаем на новый адрес сайта, со старого.

PHP редирект:

ASP редирект:

ASP.NET редирект:

private void Page_Load(object sender, System.EventArgs e)
{
Response.Status = “301 Moved Permanently”;
Response.AddHeader(“Location”,“http://www.new-url.com”);
}

ColdFusion редирект:

JSP (Java) редирект

CGI PERL:

$q = new CGI;
print $q->redirect(“http://www.new-url.com/”);
Ruby on Rails
def old_action

end

Ruby on Rails:

def old_action
headers[“Status”] = “301 Moved Permanently”
redirect_to “http://www.new-url.com/”
end

Редирект 301 часто используют как ответ сервера, заменяя этим действием традиционную ошибку 404 – Not Found. Если говорить проще, то посетитель при переходе по неправильной ссылке, либо на удаленную страницу, столкнется не с сообщением типа: «Извините, но такая страница удалена», а будет перенаправлен на другую действующую страницу. Хотя такой момент является спорным среди специалистов и поэтому тут присутствует несколько вариантов решений.

Во-первых, существует две категории ошибок 404: первая – традиционная (классическая), когда страница действительно отсутствует, а вторая – когда такая ошибка возникает из-за «кривых» внешних ссылок. Поэтому в первом случает лучше оставить все как есть, т. е. «ошибку 404». Но во втором случае лучше позаботиться о редиректе на правильный URL-адрес, если присутствует возможность восстановить его из битой ссылки либо перенаправить пользователя на главную страницу.

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

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

При составлении в.htaccess правил редиректов нужно исключать реальные адреса файлов и директорий на сервере и следить за выборкой.

На основе 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; }

Редирект на особенную страницу по 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-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы - это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.

P.S. Не забывайте, что внесение любых изменений в конфигурации сервера могут привести к тому, что самостоятельно вы можете и не восстановить. Поэтому не забывайте делать бекапы!