редирект с 80 на 443 nginx
Перенаправить 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 перенаправления.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Как настроить редирект с HTTP на HTTPS в Nginx
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Это руководство покажет вам, как перенаправить HTTP на HTTPS с помощью Nginx.
Что нам потребуется
Редирект с HTTP на HTTPS
Для принудительного перенаправления HTTP на HTTPS вам необходимо отредактировать файл конфигурации Nginx.
Найдя файл конфигурации Nginx, откройте его в текстовом редакторе с помощью команды:
Замените местоположение фактическим местоположением и именем вашего файла конфигурации.
Когда файл конфигурации будет открыт для редактирования, вставьте один из блоков кода ниже. Как только вы закончите редактирование, сохраните файл и выйдите. Затем перезапустите службу Nginx с помощью следующей команды:
Перенаправить весь HTTP-трафик на HTTPS
Откройте файл конфигурации Nginx для редактирования, затем вставьте следующий код:
Вот разбивка команд:
После редактирования весь трафик сервера HTTP по умолчанию перенаправляется на HTTPS.
Перенаправить определенный сайт
У вас может быть несколько серверов, но только некоторые из них могут требовать HTTPS. Укажите имя сервера в блоке сервера для перенаправления выбранного трафика:
Замените имя my_app.com на имя сервера, который вы собираетесь перенаправить. Вы также можете добавить дополнительные сайты, добавив еще один блок сервера. Просто скопируйте код и измените имя сервера.
Принимать только SSL-соединения
Добавьте этот код, чтобы убедиться, что сервер будет принимать только SSL-соединения через порт 443:
Редирект страниц
Вы можете использовать rewrite для быстрого управления 301 (постоянным) или 302 (временным) перенаправлением:
Обратите внимание, что команда rewrite должна использоваться только с перенаправлениями 301 или 302.
Как перенаправить домен с помощью Nginx
Редирект с сайта www на сайт без www
Этот процесс аналогичен стандартному перенаправлению страницы:
Причины для перенаправления трафика
Есть несколько причин для перенаправления HTTP-трафика на HTTPS:
Заключение
Теперь вы знаете, как перенаправить HTTP на HTTPS в Nginx. Редактируя файл конфигурации, вы можете отправлять трафик из определенного места назначения на другой сайт и принудительно использовать сертификаты SSL. Это поможет вам безопасно управлять изменениями на вашем сайте, не нарушая пользовательский опыт.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Примеры настройки перенаправлений на 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 дней бесплатно!
Как перевести сайт целиком на постоянный HTTPS для всех
Шифруем всё подряд
Эра незашифрованного веба проходит, и это хорошо. В этой инструкции мы предполагаем, что на вашем сервере работает веб-сервер Nginx. И теперь мы сделаем так, чтобы все посетители сайта пользовались исключительно протоколом HTTPS. Кроме этого мы включим HSTS – это «HTTP Strict Transport Security», когда сайт не только поддерживает HTTPS, но и настаивает на его использовании.
Для этого есть множество способов, но я опишу метод под названием «HTTPS termination». Иначе говоря, мы поставим перед веб-сервером обратный прокси, который и будет обеспечивать HTTPS. Это получается проще и гибче, чем настраивать HTTPS только при помощи возможностей веб-сервера. Возможно, вам покажется контринтуитивным, что добавление ещё одного приложения в стек упростит вашу жизнь – но это действительно так.
Уточним, что данный рецепт подходит для серверов на базе Linux, на которых установлен Nginx.
То, что будет работать прежде всех остальных приложений в стопке – это HAProxy. Это в первую очередь приложение для балансировки – он умеет распределять приходящие запросы между разными физическими серверами. Много высоконагруженных сайтов используют его в этом качестве (тот же reddit), но в последней версии у него появилась возможность выполнять SSL termination. Он умеет устанавливать HTTPS-соединения от имени сервера.
Поэтому мы поставим HAProxy, скормим ему наши сертификаты SSL/TLS, поручим перенапрявлять все HTTP запросы на HTTPS, и покажем ему уже сам веб-сервер в качестве бэкенда.
Установка HAProxy
Порты 80 и 443 будут смотреть в интернет и получать HTTP и HTTPS трафик. Все HTTP запросы получат редирект 301 на тот же URL, но по HTTPS, и затем перенаправятся на бэкендовый веб-сервер (nginx) по чистому HTTP.
HAProxy package, включённый в поставку Ubuntu 14.04 LTS довольно старый, поэтому добавим репозиторий:
Затем обновим исходники и установим приложение:
Основные настройки лежат в /etc/haproxy/haproxy.cfg. Вот мои настройки:
Кстати, если вам понадобится подсветка синтаксиса конфига HAProxy для vim, её можно взять здесь. Разберём настройки подробнее.
Global
Оставляем первый кусок нетронутым. Это настройки логов, директория и права доступа.
Следующие части нужно поправить – там указано, где находится CA root и лежат сертификаты SSL/TLS. Возможно, нужно будет поменять ca-base и crt-base.
Строка ssl-default-bind-ciphers определяет, какие коды SSL/TLS будут применяться HAProxy при соединении с клиентом. Я использую рекомендованный список от Qualys/SSL Labs. Я также отредактировал строчку ssl-default-bind-options и запретил SSLv3 и TLS1.0, т.к. они дырявые. Последняя строка, tune.ssl.default-dh-param, сообщает программе о необходимости использовать не более 4096 бит в параметре Diffie-Hellman при обмене ключами DHE.
Defaults
Добавляем пару вещей — forwardfor и http-server-close. Поскольку мы используем приложение в качестве прокси, оно должно сообщать серверу IP-адреса, с которых идут запросы. Иначе это будет выглядеть, будто весь трафик идёт с HAProxy. Поэтому forwardfor сообщает, что программа работает как обратный прокси, и необходимо добавлять заголовок X-Forwarded For для сервера.
Настройка http-server-close нужна для быстродействия — HAProxy будет решать, закрывать ли соединение или использовать его повторно, при этом поддерживая более продвинутые вещи вроде WebSockets.
Certificates
Первая часть секции сообщает, какой трафик HAproxy должна обрабатывать и куда его отправлять.
Мы привязываем HAproxy к портам 80 и 443, она слушает HTTP на порту 80 и HTTPS на порту 443. Для HTTP мы скармливаем ей два разных сертификата. HAproxy использует Server Name Identification (SNI) чтобы привести хост входящего запроса в соответствие с нужным SSL/TLS сертификатом. У меня на сервере есть три сайта, они используют разные групповые сертификаты (*.bigdinosaur.org, *.chroniclesofgeorge.com и *.bigsaur.us) и HAProxy правильно выбирает нужный из них.
Убедитесь, что владельцем файла будет root:root, и права у него должны быть только на чтение:
От HTTP к HTTPS, и HSTS в качестве бонуса
Теперь определим ACL, список контроля доступа. В HAProxy это список вещей, удовлетворяющих определённому критерию:
Мы создали ACL по имени secure, который совпадает со всем, что идёт на TCP порт 443. Он нам скоро понадобится.
Следующая строка – та самая, где происходит перенаправление трафика с HTTP на HTTPS.
Это значит, что если входящий запрос не HTTPS, то надо отправить перенаправление 301 к тому же ресурсу, но по схеме HTTPS.
Это именно то HTTP Strict Transport Security – всем браузерам предписывается использование HTTPS:
Настройка добавляет нужную строку в заголовки. Браузер, распознающий этот заголовок, понимает, что сайт предпочитает работать по HTTPS, и это указание действительно в течение года (31,536,000 seconds). Директива preload сообщает Google-боту, что ваш сайт можно добавить в их список сайтов, поддерживающих HSTS.
HSTS – штука правильная. Шифрование должно быть всегда, и администраторам надо стремиться распространять его везде.
Кстати – необходимо учесть, чтобы все куки также включали атрибут secure, поскольку с точки зрения вашего веб-сервера всё происходит по обычному протоколу HTTP. Для этого используем директиву rsprep:
1
Обратите внимание на «if secure». Это значит, что меняются только куки, идущие по HTTPS (secure – это переменная, которую мы несколько линий назад определили). Вообще, всё должно работать через HTTPS, поэтому это в принципе необязательно – но можно и подстраховаться.
Последняя строка определяет, куда отправлять трафик. Это default_backend. Тут можно определять несколько серверов для распределения нагрузки и т.п. Но, поскольку у нас есть один бэкенд-сервер, то всё довольно просто.
back end
Поскольку у нас один бэкенд-сервер, эта секция коротка. HAProxy необходимо лишь добавить пару заголовков, чтобы сервер понял, что реальное общение происходит через HTTPS, даже если он видит только лишь HTTP:
Первая директива устанавливает заголовок, объясняющий, что клиент изначально пришёл на порт 443. Вторая усиливает первую, устанавливая X-Forwarded-Proto в HTTPS, если запрос шёл через HTTPS, чтобы веб-сервер понимал, что происходит и не создавал неправильных ответов.
Затем мы объясняем HAProxy, куда слать запросы – имя, IP и порт веб-сервера. У меня веб-сервер работал на отдельной машине, поэтому я пишу сюда другой IP и 80-й порт. Если у вас всё работает на одном компьютере, то пишите localhost и порт.
Статистика, если нужно
Последняя секция диктует HAProxy выдавать статусную страницу по заданному порту. Тут можно добавить basic auth, добавив stats auth username:password, или определить отличающийся URL.
Если вы используете директиву HSTS «includesubdomains», у вас может не получиться запросить статусную страницу по имени, поскольку веб-браузер попытается загрузить её HTTPS-версию, а HAProxy отдаёт только HTTP-версию. Это можно обойти, запрашивая страницу по IP вместе с портом (http://192.168.x.x:9999).
Подчищаем
Сохраните настройки, но пока не перезапускайте сервис HAProxy. Если у вас всё работает на одной машине, и nginx также слушает события на портах 80 и 443, нужно кое-что подправить.
Поскольку nginx больше не будет отдавать HTTPS-запросы, нужно убрать все упоминания HTTPS из всех файлов виртуальных хостов.
Вот и всё. Нужно только добавить в главный файл nginx.conf две строчки, чтобы убедиться, что nginx будет заменять ip-адреса согласно заголовку X-Forwarded-For, если запросы приходят от 127.0.0.1:
Это будет работать, если вы скомпилили nginx с опцией ngx_http_realip_module.
Перезапустите HAProxy (service haproxy restart) и она начнёт слушать запросы.
Проверка работы
Сделайте запрос к сайту через http. Если URL меняется на https и вы видите сайт – всё работает. Можно убедиться, что заголовок HSTS отправляется корректно:
Как настроить nginx на https и перенаправление с-www на без-www
Как правильно настроить nginx для 301 редиректов основных зеркал сайта для корректного SEO продвижения? Давайте разберемся. Для начала правильно сформулируем задачу. Любой сайт, как правило, может быть доступен по 4-ым основным зеркалам. Откуда 4ре и как их быстро запомнить для тестирования в любое для и ночи при настройке перенаправлений? Делюсь своими правилами.
4 варианта зеркал сайта
Итого получаем 2 * 2 = 4 варианта обращения к главной странице сайта в адресной строке браузера. Рассмотрим на примере домена tale.by:
Настройка выделенного сервера для редиректов
В этой статье рассмотрена самая популярная конфигурация VPS на момент написания:
Для чего нужен SSL-сертификат
SSL-сертификат нужен для корректной работы сайта по протоколу HTTPS. Зачем вообще сайту работать по протоколу HTTPS? И чем он отличается от старого-доброго HTTP?
Что такое протокол HTTPS
Зачем сайту передаваться между комьютерами в зашифронованном виде?
Объективно это надо только тогда, когда передается важная информация, к примеру, данные о платженой карте.
Связь HTPS и SSL-сертификата
Не вникая в глубины теории, чтобы шифрование по протоколу HTTPS работало нужны два файла: секретный ключ и публичный ключ. Очень грубо говоря SSL-сертификат из них и состоит. Кашэрный сертификат должен быть удостоверен авторитетным центром. Если попытаться открыть сайт по протоколу HTTPS, а на сервере сайта не будет находиться привязанного к сайту, действительного сертификата, то вместо содержимого сайта ваш браузер выдаст враждебно раскрашенное предупреждение о попытке установления небезопасного соединения:
Бесплатный SSL-сертификат
Рассмотрми на примере сайта madewithfire.com. Я хочу, чтобы certbot сам добавил в конфиг вирутального хоста nginx пути к сгенерированным ключам сертификата и настроил 301-редиректы. Что для этого надо?
Запуск certbot для nginx
Далее открываем сайт с конфигом и проверяем редиректы.
Перенаправление https://www на просто https:// без www
Для этого должна быть прописана конфиграция сервера, которая:
Код для такой конфигурации приведен ниже:
Настройка server для основного зеркала
Эта настройка должа включать следующее:
Отрывки этой конфигурации приведены ниже:
Перенаправление не-www версии сайта с http на https
Конфигурация приведена ниже. Она делает редирект с http://madewithfire.com на https://madewithfire.com
Перенаправление с http://www на https://www
Пример конфига от certbot для этого случая приведен ниже: