Настройка редиректа с http на https nginx
Переадресация HTTP to HTTPS in Nginx
В этом руководстве мы объясним, как перенаправить HTTP-трафик на HTTPS в Nginx.
В этом руководстве мы объясним, как перенаправить HTTP-трафик на HTTPS в Nginx.
В отличие от HTTP, где запросы и ответы отправляются и возвращаются в виде открытого текста, HTTPS использует TLS / SSL для шифрования связи между клиентом и сервером.
Есть много преимуществ использования HTTPS по HTTP, таких как:
Перенаправить HTTP на HTTPS для каждого сайта
Чтобы перенаправить один сайт на HTTPS, откройте файл конфигурации домена и внесите следующие изменения:
Давайте разберем код построчно:
Например, чтобы перенаправить запросы HTTPS www не на www, вы должны использовать следующую конфигурацию:
Перенаправить все сайты на HTTPS
Если все веб-сайты, размещенные на сервере, настроены на использование HTTPS, и вы не хотите создавать отдельный блок HTTP-сервера для каждого сайта, вы можете создать один универсальный блок HTTP-сервера. Этот блок перенаправит все HTTP-запросы в соответствующие блоки HTTPS.
Чтобы создать один универсальный HTTP-блок, который будет перенаправлять посетителей на HTTPS-версию сайта, откройте файл конфигурации Nginx и внесите следующие изменения:
Давайте проанализируем код построчно:
Если возможно, предпочтите создание перенаправления для каждого домена вместо глобального перенаправления HTTP на HTTPS.
Вывод
После того, как на вашем сайте установлен SSL-сертификат, вы должны перенаправить HTTP-трафик на HTTPS.
Правильный redirect 301 для SEO в Nginx
Хочу сегодня рассмотреть тему редиректов в Nginx. Я обычно настраиваю их в лоб. То есть нужен какой-то редирект, я его добавляю. На днях меня попросили СЕО специалисты переработать редиректы одного проекта и сделать так, чтобы для клиента был ровно один 301 редирект, который включает в себя сразу все необходимые преобразования url.
Пример двойного редиректа
Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен редирект с http на https и добавление к урлу в конце слеш. То есть вы хотите такое преобразование:
Допустим, у вас сначала был настроен редирект на https подобным образом:
А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.
В целом все нормально, редиректы работают. Но если перейти по ссылке http://site.ru/catalog, мы получим 2 301-х редиректа.
На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:
Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png/, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.
Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный location /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.
Пример с nginx rewrite
Обращаю внимание на то, что сделано. Я использую rewrite без какого-либо флага на конце, чтобы не прекращать обработку директив. В данном случае просто меняется uri и передается дальше. Если запрос приходит со слешом на конце, мы его обрезаем и отправляем в правило редиректа на https. Если слеша нет, то он сразу на редирект уходит. Теперь все в порядке.
Встроенные редиректы WordPress
Очевидно, что выше описана простая ситуация. На нее достаточно обратить внимание и исправить. Но не всегда бывает так просто. Например, вы сами не настраивали редирект урлов без слеша на урлы со слешом, он вам не нужен. Но, к примеру, WordPress реализует подобный редирект своими средствами. В итоге, при запросе http://site.ru/catalog вы получите такую картину с редиректами.
Сначала nginx сделал редирект на https, так как вы это настроили у него в конфигурации, а потом wordpress на страницу со слешом на конце. В итоге у вас два редиректа, а надо один. Причем, два редиректа получились не по вашей воле. Если не обратите на это внимание, так и будете с ними жить. По факту, все типовые редиректы лучше сразу реализовывать в одном месте в веб сервере.
Все стандартные редиректы в nginx
Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:
Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.
Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.
Корректный редирект с одного url на другой
Допустим вы корректно настроили стандартные редиректы в nginx. А потом в какой-то момент у вас поменялась структура сайта, или просто нужно было сделать редиректы для отдельных страниц. К примеру, запрос https://site.ru/main/hello/ перенаправить в https://site.ru/main/. По идее ничего сложного. Добавляем редирект:
Опять два 301-х редиректа. Переделываем на один, не забывая все возможные варианты написания.
Ну и так далее. Думаю, идея ясна. Следует следить за всеми редиректами и стараться всегда оставлять только один.
Заключение
Я прилично заморочился с темой редиректов в nginx. Раньше никогда не обращал на них пристального внимания. Да и у других не видел акцента на этом. В интернете полно готовых вариантов перенаправлений на все случаи жизни, но рассмотрены они в отдельности. А вот так комплексно взглянуть на полный конфиг со всеми нюансами не приходилось.
Материал полностью написан и протестирован мной от начала до конца, поэтому призываю не копировать слепо к себе, а проверить. Я могу где-то ошибаться, что в такой важной теме может быть чревато проблемами с индексацией и работой сайта. Так что внимательно все проверяйте, прежде чем внедрять у себя. Ну а замечания все, как обычно, жду в комментариях.
В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему. А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx.
Онлайн курс по Kubernetes
Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.
Примеры настройки перенаправлений на NGINX
Где настраивать редирект в Nginx
Эти файлы с параметрами, которые идентичны, вне зависимости от используемого дистрибутива Linux. Тем не менее, их расположение может отличаться:
Как применить настройки редиректа
Чтобы применить редиректы на веб-сервере Nginx, необходимо выполнить последовательно два действия:
Настройка редиректа
Ниже разберем два основных способа настройки редиректов для выбранных веб-страниц. Так как общепринятого мнения, какой из них является оптимальным, в практике не сложилось, в последующих примерах будут использоваться оба.
Способ №1
Первый представляет собой строку:
При настройке можно выбрать следующие флаги ( ):
Способ №2
По завершении редактирования файлов остается проверить, правильны ли они:
Чтобы их применить, необходима перезагрузка Nginx:
Первая команда используется в новых версиях Linux. Вторая — для устаревших версий и FreeBSD.
Практическое использование редиректов
Редирект с www на без www
Это наиболее распространенное перенаправление, которое позволяет направить весь трафик непосредственно на домен, минуя поддомены. Код редиректа:
Если необходимо получить противоположный эффект (перенаправление на «www» c «без www»):
Редирект на другой домен
Чтобы организовать перенаправление на другой сайт — например, после изменения адреса сайта — можно воспользоваться командой:
Второй вариант проще:
Редирект с http на https
Установить перенаправление с http на https (защищенный протокол SSL ) можно следующим образом:
Здесь при всех обращениях domain.ru по протоколу http сработает перенаправление на 443-порт с использованием 301 редиректа для склейки доменов.
Редирект на другой сервер
При необходимости использовать перенаправление на другой сервер всех запросов:
Здесь за прием запросов браузера и ответ на них отвечает веб-сервер Nginx. Их обработка выполняется сервером с IP-адресом 192.168.0.12 (порт 8080 ). Таким же образом осуществляется и перенаправление на другой Nginx.
Редирект с IP адреса на домен
Перенаправление домена без www на домен с www
В противном случае (редирект с www на без www) нужно использовать такое сочитание:
Перенаправление одного URL
Перенаправление на index.php
Сделать так, чтобы запросы из браузера обрабатывались через index.php можно таким образом:
Если же файл расположен в корневом каталоге, перенаправление на index.php указывается командой:
Перенаправление «после слэша» (/)
Следующий блок позволяет установить перенаправление «после слэша» для домена:
Это приведет к тому, что после ввода адреса http://domain.com/mail пользователь будет перенаправлен на https://mail-server.com/mail-panel.
Стоит добавить в приведенный пример знак « = », чтобы перенаправление относилось только к этому элементу (почта), а не ко всему, что начинается с «mail»:
Перенаправление с изменением типа файла
Еще один вариант будет полезным, когда ссылку на файл HTML нужно автоматически заменить ссылкой на файл PHP:
Несколько доменов, один каталог и один основной домен
Этот прием пригодится при наличии нескольких доменов. Для примера возьмем следующие домены:
Все эти домены указывают на один и тот же каталог на сервере. Соответственно, они отображают одну и ту же страницу/контент, хотя и при вводе разных адресов.
Не стоит забывать об исключении ошибки 404 («страница не найдена»), которая может возникнуть, если кто-то воспользуется ссылкой на товар/страницу с одного из альтернативных доменов. Решить эту задачу можно следующим способом:
Таким образом, все альтернативные адреса, отличные от «.ru», будут направлены на «new-address.ru», который является основным адресом.
Техническое обслуживание сайта
Следующий сценарий подойдет для сайта, который находится на техническом обслуживании. То есть в случае необходимости внесения изменений на сайте. При этом перенаправление будет работать в случае обращения к определенному IP-адресу.
Задача заключается в перенаправлении оставшихся посетителей на страницу, которая будет содержать информацию, подобную «На сайте ведутся технические работы…». Это можно осуществить следующим способом:
Вместо подстановочных значений «123.123.123.123» в примере следует вписать IP-адрес своего сервера.
Дополнительные настройки
Свой IP-адрес нужно исключить с редиректа, чтобы сохранить полный доступ к сайту:
Вместо 123.123.123.123 следует указать IP адрес своего сервера.
Благодаря примеру ниже можно обнаружить, существует ли такой файл (technical-break.html) на сервере:
Если да, перенаправление сработает, в противном случае сайт открывается в обычном режиме.
Работа над новой версией сайта с перенаправлением на старую
Перенаправить пользователей на старую версию:
Вместо «123.123.123.123» необходимо подставить IP адрес своего сервера (или адреса).
В случае, если возникает циклическое перенаправление на странице, следует добавить:
Перенаправление в зависимости от IP-адреса посетителя
Приведённый ниже способ предпочтителен с точки зрения SEO-оптимизации, так как при выполнении сценария в ссылках ничего не меняется:
При посещении сайта, сервер предоставляет владельца или администратору ресурса ( MY_IP ) файлы из каталога new-version («новая-версия»). Когда страница посещается «сторонним лицом», сервер открывает старую версию сайта.
Перенаправление в зависимости от IP-адреса посетителя и браузера
Ситуация становится немного сложнее, когда нужно нужно организовать подключение с использованием сразу двух условий:
К сожалению, Nginx не поддерживает правила объединения, поэтому здесь следует применить небольшой трюк:
Редирект в зависимости от файлов cookie
В то время как на рабочем месте часто используется статический IP-адрес, бывает, что работу над сайтом нужно проводить удалённо, с другого IP-адреса.
Хотя в таких ситуациях может помочь подключение через VPN, это не всегда возможно. Здесь применяется еще одно условие — проверка cookie:
Если в браузере будет сохранен cookie с контентом «text», то файлы нового сайта будут открываться без редиректа.
Очевидно, понадобится механизм для сохранения соответствующего куки в браузере. Здесь достаточно применить директиву PHP:
Она сохраняется на сервере (например, в файле cookie.php). Он добавляется в каталог со старой (для создания cookie) и новой страницей (обновления cookie до его истечения). Данный код выполняет следующую инструкцию:
В приведенном выше примере cookie действителен в течение 5 минут (300 секунд), после чего — если он не будет создан снова — вместо новой страницы снова будет отображаться старая страница. Когда новая страница готова, достаточно удалить эти несколько строк.
Nginx и CloudFlare
В случае использования CloudFlare существует высокая вероятность того, что редирект не будет работать правильно для выбранного IP-адреса, то есть сервис не будет его распознавать.
В этом случае в файле конфигурации виртуального хоста следует добавить:
Адреса в примере взяты из текущего списка адресов, используемых CloudFlare, размещенного на официальной странице https://www.cloudflare.com/ips/. Это список актуален на момент публикации, но может со временем меняться
Начни экономить на хостинге сейчас — 14 дней бесплатно!
Настройка SSL в Nginx 🔒 Правильный редирект на https
Published by Roman Matovsky on June 9, 2017 June 9, 2017
Корпорация Google уже неоднократно заявляла о том, что будет выше ранжировать сайты, которые работают через защищённое соединение. Firefox очень быстро подключился к этой теме и всячески пытается предупредить своих пользователей о том, что их данные могут оказаться в опасности если попытаться ввести логин и пароль на сайте без SSL шифрования.
Таким образом, если у вас есть форум или система комментирования, но сайт работает через не защищенное соединение, то пользователи у которых Firefox будут видеть то, что я показал на скриншоте выше. А это отпугивает посетителей. Поэтому сегодня будем решать эту проблему.
Ранее я уже писал статью о том как заставить работать в связке Apache2 и Nginx, где первый выступает в роли бэкэнда, а второй в роли фронтэнда. И если ваш сайт работает именно в такой связке, то я расскажу в сжатой и доступной форме как защитить передаваемый трафик между сервером и клиентом, используя механизм SSL шифрования.
Для начала вам потребуется сам сертификат безопасности. Без него никак не получится перевести сайт на защищенное соединение. Если он у вас уже есть, то далее всё очень просто.
На этом всё. Редирект с http на http s мы настроили. Теперь переходим ниже, в саму секцию server нашего сайта. Там нам необходимо заменить строчку
listen 11.22.33.44:443 ssl;
а ниже добавляем строки:
Таким образом, настройка редиректа с http на http s и защищённого соединения у нас должен выглядеть примерно так:
А теперь нам необходимо внести небольшую запись в настройки Apache в секцию VirtualHost нашего сайта:
SetEnvIf X-Forwarded-Proto https HTTPS=on
Редирект с http на https Nginx
Как и большая часть сайтов интернета, которые следуют современным тенденциям losst.ru использует безопасный протокол связи https. Многим сайтам при переходе на https необходимо, чтобы весь трафик, который приходит на порт http автоматически перенаправлялся на https.
Это необходимо из соображений SEO оптимизации, а также безопасности пользователей, чтобы никто не мог разорвать защищенное соединение. В этой статье мы рассмотрим как настроить редирект с http на https Nginx.
Редирект с http на https Nginx
Я предполагаю, что вы будете использовать постоянное перенаправление с кодом статуса 301. Это означает перемещение на постоянной основе. Такой метод используется чтобы сообщить поисковым системам или браузеру, что текущая ссылка была обновлена, и ее стоит обновить в своей базе, например, закладок браузера.
В конфигурационном файле Nginx должно быть две секции server, для сайта на https и сайта http. В секции http вы просто перенаправляете все запросы на https c помощью инструкции return, а во второй секции уже все обрабатываете. Например, первая секция:
Вторая секция уже с обработкой SSL слушает запросы на 443 порту:
Собственно, синтаксис тут очень прост, инструкция return позволяет возвращать необходимые коды ответа сервера. Здесь же мы возвращаем код 301, постоянный редирект, а также URL, на который собираемся перенаправить пользователя. Кроме директивы return, можно использовать инструкцию rewrite, с помощью нее выполняются точно те же действия:
rewrite ^/(.*)$ https://losst.com/$1 permanent;
Это обычный синтаксис регулярных выражений. В первом аргументе мы выделяем группу строки запроса, а во второй указываем правильный домен. Ее можно добавить вместо return 301. Также можно использовать такую конструкцию без отдельного блока server:
* ^(losst\.ru|www\.losst\.ru)$ ) <
rewrite ^/(.*)$ https://losst.ru/$1 permanent;
>
Теперь осталось протестировать то, что получилось. Сохраните файл и проверьте конфигурацию nginx:
Затем, если все хорошо, перезапустите Nginx:
sudo systemctl restart nginx
Далее можно проверить какой ответ сервера вы получите с помощью curl:
Или позволим утилите проследовать полный путь по перенаправлению:
