nginx как сделать редирект с http на https
Перенаправить HTTP на HTTPS в Nginx
В этом руководстве мы объясним, как перенаправить HTTP-трафик на HTTPS в Nginx.
Nginx произносится как «движок x» — это бесплатный высокопроизводительный HTTP-сервер и обратный прокси-сервер с открытым исходным кодом, отвечающий за обработку нагрузки некоторых из крупнейших сайтов в Интернете.
Если вы разработчик или системный администратор, скорее всего, вы имеете дело с Nginx на регулярной основе. Одна из наиболее распространенных задач, которую вы, вероятно, будете выполнять, — это перенаправление HTTP-трафика на защищенную (HTTPS) версию вашего веб-сайта.
В отличие от HTTP, где запросы и ответы отправляются и возвращаются в виде открытого текста, HTTPS использует TLS / SSL для шифрования связи между клиентом и сервером.
Использование HTTPS поверх HTTP дает множество преимуществ, например:
Перенаправить HTTP на HTTPS для каждого сайта
Обычно, когда сертификат SSL установлен в домене, у вас будет два серверных блока для этого домена. Первый для HTTP-версии сайта на порту 80, а второй для версии HTTPS на порту 443.
Чтобы перенаправить отдельный веб-сайт на HTTPS, откройте файл конфигурации домена и внесите следующие изменения:
Давайте разберем код построчно:
Обычно вы также можете перенаправить HTTPS-версию сайта с www на не-www или наоборот. Рекомендуемый способ выполнить перенаправление — создать отдельный серверный блок для версий с www и без www.
Например, чтобы перенаправить HTTPS-запросы www на не-www, вы должны использовать следующую конфигурацию:
Каждый раз, когда вы вносите изменения в файлы конфигурации, вам необходимо перезапустить или перезагрузить службу Nginx, чтобы изменения вступили в силу:
Перенаправить все сайты на HTTPS
Если все веб-сайты, размещенные на сервере, настроены на использование HTTPS, и вы не хотите создавать отдельный блок HTTP-сервера для каждого сайта, вы можете создать один всеобъемлющий блок HTTP-сервера. Этот блок будет перенаправлять все HTTP-запросы на соответствующие блоки HTTPS.
Чтобы создать единый всеобъемлющий HTTP-блок, который будет перенаправлять посетителей на HTTPS-версию сайта, откройте файл конфигурации Nginx и внесите следующие изменения:
Давайте проанализируем код построчно:
Если возможно, предпочтительнее создавать перенаправление для каждого домена вместо глобального перенаправления HTTP на HTTPS.
Выводы
В Nginx предпочтительным способом перенаправления HTTP на HTTPS является создание отдельных серверных блоков и выполнение 301 перенаправления.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
Настройка 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
Примеры настройки перенаправлений на 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 дней бесплатно!
Правильный 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.
Переадресация 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.