nginx 301 редирект https
Nginx редирект с www на без www
server <
listen 80;
server_name www.example.com;
return 301 http://example.com$request_uri;
>
Nginx редирект на https
server <
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
>
server <
listen 80;
server_name www.example.com example.com;
return 301 https://example.com$request_uri;
>
В последнем случае редирект будет отрабатывать для www.example.com и example.com, все запросы будут направляться на имя без www, доступную по https.
Если переадресация нужна только для example.com без www, то www.example.com можно указать в качестве server_name в отдельной специально созданной секции конфигурационного файла
server <
listen 80;
server_name www.example.com;
…
>
Также часто возникает необходимость переадресовывать запросы ко всем доменам в конфигах на один, сделать это можно задав две секции server и директиву default_server, под которую будут попадать все имена сайтов кроме заданных непосредственно (example.com и www.example.com в примере).
server <
listen 80;
server_name example.com www.example.com;
…
>
server <
listen 80 default_server;
server_name _;
return 301 http://example.com$request_uri;
>
Если на сервере используется конфигурация Nginx + Apache, Nginx + Unicorn или подобная редирект всегда настраивается для того пакета, который первым обрабатывает запрос принимая его непосредственно от пользователя
Для большинства конфигураций в выводе будет именно рассматриваемый веб-сервер — если это так, переадресацию нужно настраивать для него.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
🔥 Популярное
Руководство по команде grep в Linux
15 примеров команды PING для диагностики сети
Рекурсивно найти слово в файлах и папках Linux
15 примеров CURL в Linux
👌 Похожее
Исправляем 403 Forbidden в Apache на CentOS
Что такое chroot jail и как этим пользоваться?
Как восстановить пароль от root в CentOS 7
Монтирование и демонтирование файловых систем в Linux
Как настроить редирект с 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 на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.
Саму настройку на перенаправление в NGINX можно прописать несколькими способами.
* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:
* где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.
После внесения изменений, необходимо проверить их корректность:
И для их применения перезапустить веб-сервер:
systemctl restart nginx
service nginx restart
* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
С HTTP на HTTPS (другой порт)
Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):
server <
listen 80;
server_name domain.ru www.domain.ru;
return 301 https://$host$request_uri;
>
* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).
Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:
/page.html) <
return 301 https://$host$request_uri;
>
>
* в данном примере запрос на страницу /page.html будет открыт по http.
С одного домена на другой
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
Все домены, которые обслуживает nginx:
C index.php на / (корень)
Данная настройка позволит перевести все запросы с /index.php на корневой адрес /:
server <
.
if ($request_uri
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:
server <
listen 80 default_server;
return 302 https://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, необходимо указывать в настройках пути к сертификатам.
С IP-адреса на домен
В данном случае мы переводим все запросы по IP-адресу на конкретный домен:
server <
listen 80;
server_name 192.168.1.15;
return 301 http://site.ru$request_uri;
>
* при отправке http-запроса на сервер 192.168.1.15 по IP-адресу, он будет переведен на домен site.ru.
Редирект домена и всех его поддоменов
server <
.
server_name domain domain.*;
return 301 https://$host$request_uri;
>
На другой файл
Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:
server <
.
location = /robots.txt <
rewrite ^/robots.txt$ /robots2.txt;
>
>
* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.
Часть url на другой сервер
Перенаправить запрос на другой сервер при обращении по url page1:
server <
.
server_name domain1.ru;
location
* в данном примере для всех запросов, начинающихся на /page1/. будет работать перенаправление на другой домен domain2.ru.
Редирект со слешем
1. Убрать слеш в конце url
2. Добавить слеш в конце url
Удаляем расширение
Для перенаправления запроса, где в URL есть полное название файла скрипта (с расширением) используем конфигурацию:
server <
.
if ($request_uri
* в данном случае все запросы, которые заканчиваются на .php или .html, будут перенаправляться на страницы без данных расширений.
Для примера, запрос http://site-example.ru/page.php будет переведен на http://site-example.ru/page.
На другую страницу
Нам может понадобиться перенаправлять запросы с одной страницы сайта на другую. Приведем примеры, как это сделать с помощью return и rewrite.
а) с помощью rewrite:
server <
.
rewrite ^/page1$ /page2 permanent;
>
б) с помощью return:
server <
.
location = /page1 <
return 301 /page2;
>
>
Удалить часть URL
Иногда нужно удалять часть url. Это можно сделать следующими способами:
server <
.
rewrite /deleted-url/(.*) /$1 permanent;
>
server <
.
if ($request_uri
* в данном примере из url мы удалим deleted-url/.
Перенаправить запрос в случае обращения к несуществующим файлам
Перевод запросов, если файла не существует
Данное действие не является редиректом, но близко по смыслу — NGINX проверяет наличие файла скрипта, к которому идет обращение, и если его нет, переводит запрос на другой файл. Как правило, это используется для того, чтобы перевести все обращения на файл index.php.
* в данном примере мы скажем веб-серверу все запросы обрабатывать с помощью файла index.php в корневой директории.
Проксирование
Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.
Хоть это и не совсем редирект, рассмотрим примеры его настройки, так как очень часто нужно не перенаправление, а, как раз, обратное проксирование.
1. На другой сервер
Пример внутреннего перенаправления http-запроса на другой веб-сервер:
* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.
Использование NGINX в качестве http-прокси:
* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.
HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):
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.
2. Часть url на другой сервер
Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:
3. На другой сайт
Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:
* в данном случае мы при обращении к нашему серверу (до доменному имени dmosk.local) будем попадать на сайт https://www.dmosk.ru. Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси.
4. На другой сайт по части URL
Если нам нужно настроить проксирование на другой сайт при обращении к определенной странице сайта, настраиваем NGINX так:
* в данном примере, если мы перейдем на страницу www.dmosk.ru/page, то мы попадем на сайт www.site.ru.
5. Редиректы при проксировании
Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:
proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
>
>
* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.
Немного о 301 и 302
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
Перенаправить 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 перенаправления.
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
Nginx, 301 на все случаи жизни
В статье описано несколько примеров 301-го редиректа для Nginx
Nginx, 301 редирект с http на https протокол
Если у вас на сайте есть SSL сертификат для домена, то вы можете настроить https протокол. После чего для 301-го редиректа вам необходимо добавить следующий код в файл конфигурации nginx для домена:
Nginx, 301 редирект с https на http протокол
Обратный пример конфигурации для редиректа с http на https:
Nginx, 301 редирект с www на без www
Пример 301-го редиректа на основное зеркало без www:
Nginx, 301 редирект с без www на с www
Обратный пример 301-го редиректа на основное зеркало сайта с www:
Nginx, 301 редирект для одной страницы
Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL:
Nginx, 301 редирект для папки
Аналогичный пример 301-го редиректа для папки:
Nginx, 301 редирект с одного домена на другой
Если вы сменили домен сайт и хотите перенести вес старого домена на новый, то можно сделать 301-й редирект со старого домена на новый:
Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена
Если вы планируете изменить свой домен или изменить название предприятия, то перенаправление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен.
Nginx, 301 редирект со страниц со слешем на страницы без слеша в конце URL
Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него:
Nginx, 301 редирект со страниц без слеша на страницы со слешем в конце URL
Причина делать такой редирект та же, что и в ситуации описанным выше, за исключением того, что редирект необходимо делать со страницы без слеша в конце URL на страницу со слешем в конце URL:
Дополнительно
Не забудьте перед использованием примеров сменить devreadwrite.com на свой домен. После внесения изменений в файл конфигурации nginx для домена необходимо перезапустить nginx:
Если у вас есть вопросы или предложения по улучшению кода описанного в статье пишите в комментариях.
Я всегда открыт к конструктивному диалогу