настройка htaccess для nginx

Примеры настройки перенаправлений на NGINX

Где настраивать редирект в Nginx

Если в случае с серверами Apache2 для переадресации следует отредактировать файл .htaccess, в Nginx таковой отсутствует. Тем не менее, редирект можно настроить, отредактировав файлы конфигурации виртуальных доменов.

Эти файлы с параметрами, которые идентичны, вне зависимости от используемого дистрибутива Linux. Тем не менее, их расположение может отличаться:

• в дистрибутивах, основанных на RPM (CentOS, Red Hat) — /etc/nginx/conf.d/.
• в дистрибутивах, основанных на Debian (Ubuntu, Debian) — /etc/nginx/sites-enabled/.

Как применить настройки редиректа

Чтобы применить редиректы на веб-сервере Nginx, необходимо выполнить последовательно два действия:

1. Добавить соответствующую команду в виртуальный хост выбранного домена.
2. Перезагрузить сервер.

Настройка редиректа

Ниже разберем два основных способа настройки редиректов для выбранных веб-страниц. Так как общепринятого мнения, какой из них является оптимальным, в практике не сложилось, в последующих примерах будут использоваться оба.

Способ №1

Первый представляет собой строку:

Здесь переменная $host является хостом из запросов. Если он отсутствует, следует воспользоваться именем заголовка в поле «Host», если и его нет — подойдет имя сервера.

Переменная $request_uri — это первоначальный запрос с аргументами.

При настройке можно выбрать следующие флаги ( ):

• permanent — 301 редирект (или постоянный редирект) на страницу с кодом ответа сервера 301.
• redirect — 302 редирект (или временный редирект) на страницу с кодом 302.
• last — завершение обработки и последующий переходом в новый location.
• break — завершение обработки и работа в текущем location.

Способ №2

Здесь можно использовать любой код редиректа, однако самые распространенные случаи — 301 , 302 , 404 .

По завершении редактирования файлов остается проверить, правильны ли они:

Чтобы их применить, необходима перезагрузка Nginx:

Первая команда используется в новых версиях Linux. Вторая — для устаревших версий и FreeBSD.

Практическое использование редиректов

Редирект с www на без www

Это наиболее распространенное перенаправление, которое позволяет направить весь трафик непосредственно на домен, минуя поддомены. Код редиректа:

Если необходимо получить противоположный эффект (перенаправление на «www» c «без www»):

Редирект на другой домен

Чтобы организовать перенаправление на другой сайт — например, после изменения адреса сайта — можно воспользоваться командой:

Редирект с http на https

Установить перенаправление с http на https (защищенный протокол SSL ) можно следующим образом:

Здесь при всех обращениях domain.ru по протоколу http сработает перенаправление на 443-порт с использованием 301 редиректа для склейки доменов.

Чтобы установить редирект на http с https , достаточно изменить код ответа сервера:

Редирект на другой сервер

При необходимости использовать перенаправление на другой сервер всех запросов:

Здесь за прием запросов браузера и ответ на них отвечает веб-сервер 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) на сервере:

Если да, перенаправление сработает, в противном случае сайт открывается в обычном режиме.

Работа над новой версией сайта с перенаправлением на старую

• Задача: начать работу над модернизацией действующего веб-сайта, оставить при этом посетителям доступ к его старой версии.
• Решение: старую версию сайта можно поместить в каталог «old», а в главной директории работать над созданием новой версии.

Перенаправить пользователей на старую версию:

Вместо «123.123.123.123» необходимо подставить IP адрес своего сервера (или адреса).

В случае, если возникает циклическое перенаправление на странице, следует добавить:

Перенаправление в зависимости от IP-адреса посетителя

Приведённый ниже способ предпочтителен с точки зрения SEO-оптимизации, так как при выполнении сценария в ссылках ничего не меняется:

При посещении сайта, сервер предоставляет владельца или администратору ресурса ( MY_IP ) файлы из каталога new-version («новая-версия»). Когда страница посещается «сторонним лицом», сервер открывает старую версию сайта.

Перенаправление в зависимости от IP-адреса посетителя и браузера

Ситуация становится немного сложнее, когда нужно нужно организовать подключение с использованием сразу двух условий:

1. указанного IP;
2. строго определённого браузера.

К сожалению, Nginx не поддерживает правила объединения, поэтому здесь следует применить небольшой трюк:

Здесь используется дополнительная переменная $TEST . С первым условием (действительным IP-адресом) она получает значение « okA », а со вторым (браузер Firefox) — дополнительное значение « okB ».

В результате, значением должно быть « okAokB ». И только когда оба условия выполняются одновременно ( $ TEST соответствует « okAokB »), открывается доступ в соответствующий (рабочий) каталог (public_html).

Редирект в зависимости от файлов cookie

В то время как на рабочем месте часто используется статический IP-адрес, бывает, что работу над сайтом нужно проводить удалённо, с другого IP-адреса.

Хотя в таких ситуациях может помочь подключение через VPN, это не всегда возможно. Здесь применяется еще одно условие – проверка cookie:

Если в браузере будет сохранен cookie с контентом «text», то файлы нового сайта будут открываться без редиректа.

Очевидно, понадобится механизм для сохранения соответствующего куки в браузере. Здесь достаточно применить директиву PHP:

Она сохраняется на сервере (например, в файле cookie.php). Он добавляется в каталог со старой (для создания cookie) и новой страницей (обновления cookie до его истечения). Данный код выполняет следующую инструкцию:

1. Осуществляется переход по адресу [domain] /cookie.php.
2. Выполняется стандартный переход на сайт.
3. Вместо старого сайта открывается новый.

В приведенном выше примере cookie действителен в течение 5 минут (300 секунд), после чего — если он не будет создан снова — вместо новой страницы снова будет отображаться старая страница. Когда новая страница готова, достаточно удалить эти несколько строк.

Nginx и CloudFlare

В случае использования CloudFlare существует высокая вероятность того, что редирект не будет работать правильно для выбранного IP-адреса, то есть сервис не будет его распознавать.

В этом случае в файле конфигурации виртуального хоста следует добавить:

Адреса в примере взяты из текущего списка адресов, используемых CloudFlare, размещенного на официальной странице https://www.cloudflare.com/ips/. Это список актуален на момент публикации, но может со временем меняться

Начни экономить на хостинге сейчас — 14 дней бесплатно!

источник

Nginx — htaccess, как конвертировать

Apache — это не единственный тип сервера, который существует. Второй по популярности сервер — это Nginx. Те, кто уже побывал на Apache, наверняка привыкли к тому, что там есть файл конфигураций htaccess. Потому после перехода на Nginx таким пользователям будет сложно осознать, что данный сервер не поддерживает файл htaccess и его директивы.

Если хотите использовать функции конфигурационного файла htaccess на сервере Nginx, то вам придется научиться конвертировать директивы этого документа в опции Nginx.

Стоит ли использовать аналог htaccess на сервере Nginx

Прежде чем начать искать аналоги файла htaccess для этого сервера, стоит задуматься о целесообразности такого решения. Использовать файл дополнительных конфигураций необязательно, даже для серверов Apache. Многие его функции можно реализовать через php-код. Большинство вебмастеров лишь изредка обращаются к htaccess, так как этот файл со временем сильно нагружает сервер. Ведь он загружается каждый раз, когда появляется запрос к серверу.

Тем не менее, некоторые опции конфигурационного файла позволяют ускорить работу сервера. К примеру, при помощи него вы сможете активировать кэширование браузеров пользователей, включить сжатие данных и т. д. Также файл htaccess подходит для защиты файлов и папок, а также для общей оптимизации ресурса. Потому все-таки есть смысл искать аналоги этого файла для Nginx.

Как конвертировать опции htaccess для серверов Nginx

Существует специальный Nginx converter — это онлайн-сервис, который необходим для перевода синтаксиса файла htaccess в синтаксис конфигурационного документа сервера Nginx. То есть все, что вам понадобится сделать, — это ввести директивы файла htaccess в конвертер, затем скопировать результат, и вставить в конфигурации Nginx. При этом важно, чтобы файл Apache, с которого вы копируете данные, был рабочим. Протестируйте его на локальном сервере. Если возникает ошибка 500, значит его нельзя использовать для перевода — в нем содержится ошибка.

В основном, конвертер предназначается для перевода директив модуля mod_rewrite. Как известно, директивы этого модуля используются в htaccess чаще других. Вы сможете перевести опции переадресаций с редиректами, директивы склеивания зеркал, удаления слешей из ссылок и т. д. А теперь коротко рассмотрим некоторые директивы htaccess и их аналоги в Nginx.

Если вы захотите добавить в Nginx свои страницы с ошибками, что весьма правильно, то вместо ErrorDocument, вам нужно будет писать, к примеру, вот так: error_page 404 http://domen.ru/error/404.htm. И так вы сможете написать для каждой страницы. Только не забудьте предварительно создать страницы с ошибками. Только потом вы сможете прописать для них путь.

В качестве защиты папок в htaccess часто указывали директиву для запрета листинга каталогов. Для этого писали следующую опцию: Options -Indexes. В Nginx она будет выглядеть совсем по-другому: autoindex off. А для активации листинга укажите вместо off слово on. К сожалению, директиву IndexIgnore через конвертер у вас перевести не получится. Потому вы не сможете при открытом листинге скрывать какие-либо файлы на сервере Nginx. Зато вы сумеете указать свой вариант индексного файла. Для этого нужно прописать вместо DirectoryIndex одно слово: index, и к нему добавить перечень файлов, которые нужно считать индексными.

Некоторые директивы так же легко переводить в Nginx, как и опцию DirectoryIndex. К примеру, директива определения основной кодировки для сайта AddDefaultCharset. Она нужна для того, чтобы все браузеры видели сайт в одной кодировке. Настройка этой опции исключит появление несвязных закорючек на страницах вашего ресурса. Кроме того, вы сможете создать версии портала на другом языке. Чтобы сделать это в Nginx, нужно указать директиву Charset и название кодировки.

Если вы хотите заблокировать доступ к сайту только для некоторых пользователей, то необязательно прописывать сначала Allow from all, а потом указывать исключения. В Nginx достаточно прописать каждый IP-адрес в отдельной строчке после директивы Deny. Например:

deny 81.222.144.12;
deny 81.222.144.20;

А если нужно разрешить доступ только некоторым IP-адресам, то нужно сначала его запретить для всех при помощи директивы Deny all. А потом так же, как и с deny в предыдущем примере: указать в каждой строке по одному IP-адресу, только уже с директивой Allow. Для блокировки какого либо-файла или папки вместо тегов вам следует писать сначала опцию location, а затем в скобках <> указывать директивы deny и allow. Например, вот как будет выглядеть блокировка файла passwd.html для всех, кроме IP-адреса 81.222.144.12:

location /passwd.html <
deny all;
allow 81.222.144.12;
>

А что касается установки пароля на определенные файлы, то в Nginx это делать еще проще, чем если бы прописывали эту опцию в документе htaccess. Вместо того, чтобы указывать четыре директивы, вам необходимо будет указать всего две. В первой строчке необходимо написать опцию auth_basic и в кавычках указать обращение к пользователю, который хочет авторизоваться. А во второй auth_basic_user_file вам следует написать путь к файлу с паролями, которые необходимы для аутентификации.

Единственное, с чем вам придется изрядно помучиться — это перевод директив модуля mod_rewrite в формат настроек Nginx. С этим действительно все сложно, поскольку вам придется изучить синтаксис Nginx, чтобы понять, как активировать на сервере перенаправление URl. В любом случае, вам понадобится директива location, которая нужна для указания адреса переадресации. В скобках вместо директивы RewriteCond, обозначающей условия перенаправления ссылки, нужно писать if. А вместо правила переадресации RewriteRule пишите просто Rewrite.

Многие функции вы не сможете перевести из стандартного файла htaccess в модифицированный для серверов Nginx. Потому от некоторых возможностей Apache вам придется либо полностью отказаться, либо искать другие пути решения. Используйте специальные плагины и модули для сайта, и сможете реализовать возможности htaccess не через сервер, а через движок.

источник