Все стандартные редиректы в nginx
Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:
- С http на https.
- С www на без www для обоих протоколов.
- Без слеша на конце на урл со слешем.
Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.
server {
listen 443 ssl http2;
server_name site.ru;
root /web/sites/site.ru/www/;
index index.php index.html index.htm;
access_log /web/sites/site.ru/log/access.log main;
error_log /web/sites/site.ru/log/error.log;
ssl_certificate /etc/letsencrypt/live/site.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/site.ru/privkey.pem;
location / {
rewrite ^(*)$ $1/ permanent;
try_files $uri/ /index.php?$args;
}
location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
access_log off;
expires max;
}
location ~* ^/(\.ht|xmlrpc\.php)$ {
return 404;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php-fpm/php7-fpm.sock;
fastcgi_index index.php;
fastcgi_param DOCUMENT_ROOT /web/sites/site.ru/www/;
fastcgi_param SCRIPT_FILENAME /web/sites/site.ru/www$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /web/sites/site.ru/www$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param HTTPS on;
fastcgi_intercept_errors on;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
}
server {
listen 443 ssl http2;
server_name www.site.ru;
location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
return 301 https://site.ru$request_uri;
}
location / {
rewrite ^/(.*)/$ /$1;
return 301 https://site.ru$uri/;
}
}
server {
listen 80;
server_name site.ru www.site.ru;
location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
return 301 https://site.ru$request_uri;
}
location / {
rewrite ^/(.*)/$ /$1;
return 301 https://site.ru$uri/;
}
}
Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.
Перенаправить HTTP на HTTPS для каждого сайта
Обычно, когда сертификат SSL установлен в домене, у вас будет два серверных блока для этого домена. Первый для HTTP-версии сайта на порту 80, а второй для версии HTTPS на порту 443.
Чтобы перенаправить отдельный веб-сайт на HTTPS, откройте файл конфигурации домена и внесите следующие изменения:
Давайте разберем код построчно:
- — серверный блок будет прослушивать входящие соединения на порту 80 для указанного домена.
- — указывает доменные имена серверного блока. Убедитесь, что вы заменили его на свое доменное имя.
- — Перенаправить трафик на HTTPS-версию сайта. Переменная — это полный исходный URI запроса, включая аргументы.
Обычно вы также можете перенаправить HTTPS-версию сайта с www на не-www или наоборот. Рекомендуемый способ выполнить перенаправление — создать отдельный серверный блок для версий с www и без www.
Например, чтобы перенаправить HTTPS-запросы www на не-www, вы должны использовать следующую конфигурацию:
Каждый раз, когда вы вносите изменения в файлы конфигурации, вам необходимо перезапустить или перезагрузить службу Nginx, чтобы изменения вступили в силу:
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Если обращение к веб-серверу идет по 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, необходимо указывать в настройках пути к сертификатам.
Основные причины возникновения
- Технические работы на сервере на некоторое время могут привести к возникновению ошибки. После их завершения, как правило, сайт быстро восстанавливает свою корректную работу. Если этого не произошло, в большинстве случаев, со стороны сервера были изменены настройки, отвечающие за переадресацию.
- Повышенная нагрузка на сервер при большом количестве посетителей, пытающихся одновременно получить доступ к странице. В результате сервер не выдерживает нагрузки и «падает» выдавая сообщение об ошибке.
- Некорректно выставленное время на устройстве, с которого выполняется вход на страницу. В большинстве случаев, браузер проводит автоматическую проверки времени на компьютере и сервере. При их несовпадении может возникнуть ошибка циклической переадресации.
- Большой объем данных сохранённых в кэше и cookie браузера.
- Запрет на сохранение cookie сайтов в браузере.
- Циклическое перенаправление и установка CMS
- В панели управления хостингом и в файле .htaccess одновременно указана переадресация на HTTPS.
- Ошибка циклического перенаправления может возникнуть при некорректной установке или настройке CMS. Это относится как к популярным «движкам» – WordPress, Joomla, Opencart, или 1С-Битрикс так и к менее известным.
Как в NGINX сделать редирект на мобильную версию сайта
Данный код вставляется на уровне в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).
### Устанавливаем переменную в 0. В неё пишем 1, если обнаружили мобильную версию браузера
set $mobile_rewrite 0;
if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
set $mobile_rewrite 1;
}
if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez(0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-)|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10|n20|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-(|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)") {
set $mobile_rewrite 1;
}
### Мобильный барузер обнаружен, редиректим на мобильный поддомен, в моём случае, m.example.com
if ($mobile_rewrite = 1) {
rewrite ^ http://m.example.com/$request_uri redirect;
break;
}
Настройка proxy_pass в nginx
Рассмотрим самый простой пример. Буду использовать свой технический домен zeroxzed.ru в этом и последующих примерах. Допустим, у нас есть сайт blog.zeroxzed.ru. В DNS создана A запись, указывающая на ip адрес сервера, где установлен nginx — nginx_srv. Мы будем проксировать все запросы с этого сервера на другой сервер в локальной сети blog_srv, где реально размещается сайт. Рисуем конфиг для секции server.
Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.
Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:
Проверяем blog_srv:
Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:
Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит 
Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.
Оптимизация работы соединений
Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.
— Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto. По умолчанию 1
— Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать * , остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. По умолчанию 512.
— Позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение. По умолчанию off.
— Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45. По умолчанию 75.
— Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним. По умолчанию off.
— Ждет выставленное количество секунд тело запроса от клиента, после чего сбрасывает соединение. По умолчанию 60.
— Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение. По умолчанию 60.
Использование вложенных if
Вложенные if в конфигурации nginx запрещены, поскольку это вовсе не языковая конструкция nginx, а обычная директива из модуля rewrite, использование которой в ее же собственном контексте if не предусмотрено. Использование списка условий, разделенных логическими операторами «и» и «или» тоже не предусмотрено. Обычно для эмуляции вложенных условий с использованием директивы if предлагают использовать регулярные выражения. Например, проверить, что имя, указаное в HTTP хедере HOST, соответствует значению localhost, а в URI присутствует аргумент «a» (в этом случае переменная $arg_a будет не пустой), можно так:
К сожалению, условие в директиве if имеет ограничения. По крайней мере, это не выражение, и оно не может быть составлено в виде цепочки выражений, разделенных логическими операторами. Кроме того, в случае сравнения чего-то с регулярным выражением, это что-то может быть только именем переменной, именно поэтому пришлось ввести новую переменную $cond:
В данном примере мы соединили через произвольно выбранный нами разделитель :: три переменных $host, $goodhost и $arg_a и присвоили это значение переменной $cond. А регулярное выражение, с которым мы сопоставляем это значение, проверяет, что его первая часть (до разделителя ::) и вторая часть (до второго разделителя ::) равны, а последняя часть (после второго разделителя) не пуста.
В полном виде конструкция проверки примет вид:
Часто задаваемые вопросы по теме статьи (FAQ)
При использовании https нужно ли в режиме proxy_pass настраивать https и на бэкенде?
В общем случае не обязательно. Но есть некоторый софт, который не может корректно работать в таком режиме. Он не понимает, как корректно обрабатывать такую ситуацию. Может создавать ссылки вида http://site.ru:443, которые будут являться ошибочными. В таком случае необходимо настроить обмен между nginx и бэк сервером тоже https соединение.
Как наиболее простым спосбом передавать сертификат let’s encrypt с nginx на backend? Ведь обновдление и генерация сертификата происходят только на nginx.
Я в таких случаях использую 2 способа, в зависимости от ситуации. Самый простой — на сервере с nginx настроить nfs сервер, а на бэкенде подмонтировать по nfs к себе директорию /etc/letsencrypt и спокойно использовать сертификаты, как-будто они лежат локально. Второй вариант — использовать простой bash скрипт для копирования сертификатов к себе на сервер по scp. В обоих случаях надо не забыть на бэкенде перезапускать службы, которые использую сертификат, после его обновления.
При обращении с бэкенда по адресу сайта, запрос уходит на nginx proxy, так как в dns прописан его ip адрес. Из-за этого иногда не работают встроенные скрипты или проверки некоторых движков, так как они ожидают, что запрос вернется с того же сервера, с которого он был сделан. Но на практике он уходит на proxy и приходит оттуда.
В такой ситуации может помочь правка файла /etc/hosts на самом бэкенде. Сделайте там статическую запись с именем сайта и локальным ip адресом. Тогда запросы с самого сервера будут приходить на него же локально, а не на nginx proxy.
Что лучше использовать для проксирования http запросов nginx или haproxy?
Однозначного ответа на этот вопрос не может быть. В чем-то это схожий софт, но есть и существенные отличия. В общем случае, описанном в статье, принципиальной разницы нет. У haproxy в бесплатной версии есть функционал, который присутсвует только в nginx plus. Так что нужно смотреть по конкретным задачам и решать, какой продукт подойдет лучше.
Добавляет ли nginx в режиме proxy_pass дополнительные сетевые задержки?
Конечно да. Но на практике они очень малы, если nginx и целевой сервер находятся в общей локальной сети. С учетом задержек при передачи пакетов по сети интернет, этими локальными задержками можно пренебречь. Они будут ничтожно малы. Если же вы проксируете запросы через интернет, то нужно внимательно смотреть величину задержек между nginx и бэкендом. Желательно их делать минимальными, располагая сервера поближе друг к другу.
Как настроить 301 редирект
Джон Мюллер предупреждает, что Google может не проиндексировать конечную страницу, если не соблюсти все правила. Нужно использовать канонический тег, внутренние ссылки и при необходимости тег hreflang для конечной страницы, а не той, с которой вы перенаправляете пользователя. Иначе Google получит неправильные сигналы и может не проиндексировать конечную страницу.
Настроить переадресацию можно через панель управления вашим хостингом или вручную средствами HTML, PHP, JavaScript.
В настройках конкретного хостинга обычно подробно описано, как сделать редирект через панель управления. Для разных CMS есть специальные плагины для редиректов. Разберем способы для настройки вручную на примере редиректа на сайт с www или без него.
Редирект для Nginx
Для серверов под Nginx нужно использовать файл nginx.config, добавьте код в секцию server. Если вы настроили виртуальные хосты, для каждого хоста нужно редактировать файлы отдельно.
С домена с www на домен без www
server {#...
if($host~ * www\.(.*)) {
set $host_without_www $1;
rewrite ^ (.*) $ http: //$host_without_www$1 permanent;
}#...
}
С домена без www на домен с www
server {#...
if($host~ * ^ + \. + $) {
rewrite ^ (.*) $ $scheme: //www.$host$1 permanent;
}#...
}
После изменения nginx.config перезапустите nginx с помощью команды «service nginx restart». Проверить, все ли корректно заполнено, можно через команду «nginx -t».
Редирект для Apache
Если вы используете Apache, вам нужен файл .htaccess. Для доступа есть несколько вариантов:
- Используйте FTP и включите отображение скрытых файлов. Найдите .htaccess в каталоге public_html в папке с названием домена.
- Откройте панель управления хостингом, включите отображение скрытых файлов и найдите его через Диспетчер файлов.
Скачайте .htaccess, добавьте код редиректа и загрузите файл заново. Если файла .htaccess нет, его нужно создать.
На домен без www
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.site\.ru$
RewriteRule ^(.*)$ <a href="https://site.ru/https://site.ru/$1" class="redactor-autoparser-object">https://site.ru/https://site.ru/$1</a>
На домен с www
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^site.ru
RewriteRule (.*) <a href="http://www.site.ru/http://www.site.ru/$1" class="redactor-autoparser-object">http://www.site.ru/http://www.site.ru/$1</a>
Редирект через PHP
Действует на уровне сервера. Лучше использовать другой способ, потому что этот работает медленно. Через PHP перенаправление настраивают для сайтов, где редирект нужен на многих, но не на всех страницах.
Файл index.php расположен в корневой папке. Скачайте его и добавьте код или отредактируйте прямо в диспетчере файлов в панели управления хостингом.
На домен без www
<!--?php
header("Location: http://site.ru/", true, 301);
exit();
?-->
На домен с www
<!--?php
header("Location: http://www.site.ru/", true, 301);
exit();
?-->
Редирект через HTML
Редирект через HTML-код медленнее, он работает на стороне браузера. Код нужно добавить между тегами и страницы, с которой нужно перенаправить. В параметре content=»» указывают задержку по времени.
На домен без www
<meta http-equiv="refresh" content="0; url=http://site.ru/">
На домен с www
<meta http-equiv="refresh" content="0; url=http://www.site.ru/">
Редирект через JavaScript
Редирект настраивают и с помощью JavaScript, он работает на стороне браузера, как и HTML. Это медленный способ и не сработает, если у пользователя в браузере отключен JavaScript. Его обычно настраивают для редиректов с задержкой, если такое требуется.
Код для редиректа нужно добавить между и в код первой исходной страницы.
На домен без www
<script type="text/javascript">
window.location.replace("http://site.ru/");
</script>
Для задержки:
На домен с www
<pre><script>
window.location.replace("http://www.site.ru/");
</script></pre>
Через cPanel
cPanel — это платная панель управления веб-хостингом. В ней тоже можно настроить редиректы, причем не используя вводы кодов. Во вкладке «Домены» есть раздел «Перенаправления», там нужно настроить редирект.
На домен без www
- В списке выберите нужный домен.
- В поле «Перенаправляет на» пропишите его с префиксом http://.
- Поставьте отметку у «Перенаправлять только с www»
На домен с www
- В списке выберите нужный домен.
- В поле «Перенаправляет на» пропишите его с префиксом http://www.
-
Поставьте отметку у «Не перенаправлять www»
Основные ошибки nginx и их устранение
502 Bad Gateway
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в прописаны правильные права
listen = /tmp/php5-fpm.sock listen.group = www-data listen.owner = www-data
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:
server {
...
send_timeout 800;
proxy_send_timeout 800;
proxy_connect_timeout 800;
proxy_read_timeout 800;
...
}
Тут мы выставили ожидание таймаута в 800 секунд.
Upstream timed out (110: Connection timed out) while reading response header from upstream
Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
location ~ \.php$ {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/tmp/php5-fpm.sock;
fastcgi_read_timeout 800;
}
800 секунд на ожидание ответа от бекенда.
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
client_max_body_size 1m;
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до
client_max_body_size 100m;
Также, можно отключить проверку размера тела ответа полностью значением ноль:
client_max_body_size 0;
304 Not Modified не устанавливается
Если возникает проблема с правильным отображением ответного заголовка сервера , то проблема, скорее всего, в пунктах:
- В секции конкретного сайта включен (). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
- установить в , то есть на уровне или конкретного прописать:
Постоянный и Временный Nginx Redirect
Временные перенаправления полезны в том случае, если нам нужно временно изменить местоположение страницы с одного места на другое. Чтобы обозначить временное перенаправление страницы, используется код ответа 302.
Временные перенаправления сообщают пользователям, что сайт временно не доступен, например, когда он закрыт на обслуживание. Ещё один пример временного редиректа, когда вы связываете страницу с неполной информацией с другим пунктом или главной страницей:
Посетитель–> Страница сайта–> Сайт находится на обслуживании
В свою очередь, постоянное перенаправление Nginx сообщает веб-браузеру, что он должен постоянно связывать старую страницу или домен с новым местоположением или доменом. Для обозначения постоянного перемещения страницы используется код ответа 301. Такие перенаправления полезны, когда пользователь хочет изменить имя домена и больше не хочет, чтобы браузер обращался к нему.
Например, если вы хотите изменить домен вашего сайта или создать новую страницу, чтобы заменить старую:
Посетитель –> Нажимает на www.devisers.in/home –> Перенаправлен на www.devisers.in/home1
Перенаправления Страниц в Nginx
Обратите внимание, что сначала вы должны получить доступ к вашему VPS через SSH. Если у вас возникли проблемы, ознакомьтесь с нашим руководством по PuTTY
В Nginx большинство перенаправлений могут быть реализованы с помощью встроенной функции перезаписи. Перезапись является функцией по умолчанию, доступной в чистой установке Nginx. С её помощью можно создать оба вида перенаправлений Nginx – как постоянные, так и временные. Для самого простого редиректа вам понадобится минимум два параметра – старый URL и новый URL.
Перенаправить страницы на временное или постоянное местоположение на веб-сервере Nginx довольно просто. Вставьте следующий код в /etc/nginx/sites-enabled/default, заменив переменные необходимыми данными:
Location path_pattern {
rewrite ^/oldURL$ https://www.domainone.com/newURL redirect;
}
Если вы хотите перенаправить страницу на другую ссылку навсегда, просто используйте “permanent” (“постоянно”) вместо “redirect” (“перенаправить”) в приведённой выше команде. Между тем, path_patern обычно является /index.html.
Перенаправление домена в Nginx
Для перенаправления одного домена на другой введите в терминале указанную ниже команду:
server {
listen 80;
hostname devisers.in www.devisers.in;
rewrite ^ http://www.devisers.com$request_uri? permanent;
}
Здесь мы используем два домена. Тот, который мы хотим перенаправить – www.devisers.in, а новый – www.devisers.com.
Nginx Redirect с HTTP на HTTPS (SSL)
HTTP и HTTPS используют разные порты – HTTP-порт 80 и HTTPS-порт 443. HTTPS означает безопасное соединение, защищённое от MITM-атак, которые могут перехватить ваш сеанс
Обратите внимание, что для того, чтобы этот метод работал, вам нужно настроить SSL. Таким образом, чтобы защитить информацию, которая циркулирует между вами и вашими посетителями, следует перенаправлять все запросы, поступающие с HTTP на HTTPS
Для этого мы можем добавить следующую модификацию в тот же файл:
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
Теперь весь трафик на дефолтный HTTP-сервер перенаправляется на HTTPS.
Nginx Redirect Определённых Сайтов
Если вы используете различные сайты или приложения и хотите перенаправить только один из них, следуйте инструкциям:
server {
listen 80;
server_name devisers.in;
return 301 https://devisers.in$request_uri;
}
В этом примере мы перенаправляем сайт http://www.devisers.in на https://www.devisers.in.
Переадресация с www на без www
Вы наверняка обращали внимание, что есть сайты, на которые можно попасть, прописав www в начале адреса, так и без этого. Если вы хотите, чтобы посетители могли прийти на ваш сайт просто по домену вашей веб-страницы, тогда вы можете настроить соответствующий редирект
В Nginx есть много способов переадресации с www на без www. Вот один из самых простых:
server {
server_name www.devisers.in;
return 301 $scheme://devisers.in$request_uri;
}
Важно: это постоянный, или “301 редирект”. Чтобы увидеть изменения, перезапустите веб-сервер Nginx, используя команду:
Чтобы увидеть изменения, перезапустите веб-сервер Nginx, используя команду:
sudo systemctl restart Nginx
Для редиректа с без www на www, просто замените URL сайта в примере выше. Вместо www.devisers.in укажите devisers.in.
