Мы продолжаем цикл статей о настройке VDS с операционной системой Ubuntu 14.04.
На текущий момент на нашем VDS уже установлены Apache и/или Nginx - об их установке и настройке мы писали в предыдущих статьях. Еще немного ранее мы касались вопроса выбора того или иного сервера и схемы его использования.
Сегодня мы продолжим разговор о настройке веб-серверов и ее особенностях в зависимости от выбранной схемы. В статье мы рассмотрим примеры конфигурации Apache и Nginx для наиболее популярных CMS (Bitrix, Wordpress, Joomla), а также способы решения типичных задач - таких, как настройка перенаправлений и управление доступом - с помощью конфигурации серверов.
Итак, речь пойдет о следующих схемах работы:
- Apache + mod_php
- Nginx + php_fpm
- Nginx + Apache + mod_php
Apache + mod_php
При подобной схеме все настройки могут быть прописаны в файле .htaccess - на него не накладывается никаких архитектурных ограничений. Также в этом режиме доступны все команды Apache.
Если при этом в настройках Apache не было указано значение None для параметра AllowOverride, то для настройки сайтов Вы можете использовать стандартные файлы .htaccess Вашей CMS.
Примеры данных файлов можно скачать здесь:
Nginx + php_fpm
При использовании данной схемы возникает противоположная ситуация - файл .htaccess не может быть использован при настройке сайта.
Все настройки из данного файла необходимо перенести в конфигурационный файл сайта для Nginx.
Примеры конфигурационных файлов Вы можете скачать здесь:
Nginx + Apache + mod_php
При подобной связке Nginx, выступающий в роли frontend-сервера, будет получать все входящие запросы и далее либо обрабатывать их и отдавать клиенту, если это статические данные, либо передавать запрос backend-серверу Apache, если это динамические данные.
Соответственно, Вам необходимо внести определенные настройки в конфигурационный файл сайта для проксирования запросов. Например:
location / { proxy_pass http://localhost:8080/; } location ~* \.(jpg|jpeg|gif|png|ico|css|js|txt|doc|docx|xls|xlsx|ppt|pptx)$ { root /var/www/site1/public-html/; }
Таким образом, статические файлы с расширениями, указанными в списке (рекомендуем Вам отредактировать его под свои нужды), не будут обрабатываться через Apache, и любые директивы в файле .htaccess не будут на них действовать. Для ограничения доступа к ним необходимо дополнительно дописывать соответствующие правила в Nginx.
Кроме настроек самой CMS Вам может потребоваться донастройка каких-либо задач.
Мы рассмотрим настройку ограничений и перенаправлений.
Правила перенаправлений
Замените old.ru и new.ru, а также выделенные цветом параметры, на необходимые Вам значения.
Apache | Nginx |
Общий блок | |
<IfModule mod_rewrite.c> |
server { |
Перенаправление на другой домен | |
RewriteCond %{HTTP_HOST} |
server_name old.ru www.old.ru; |
Перенаправление домена с www на домен без www | |
RewriteCond %{HTTP_HOST} ^www\.new\.ru$ [NC] |
server_name www.new.ru; |
Перенаправление домена без www на домен с www | |
RewriteCond %{HTTP_HOST} ^new\.ru$ [NC] |
server_name new.ru; |
Перенаправление в подкаталог (в примере - в подкаталог forum) | |
RewriteCond %{HTTP_HOST} ^forum\.new\.ru$ |
server_name forum.new.ru; |
Перенаправление c http на https | |
RewriteBase / |
if ($ssl_protocol = "") { |
Ограничение доступа
Замените выделенные цветом параметры на актуальные для Вас значения.
Apache | Nginx |
Ограничение доступа по паролю (Basic Auth) | |
AuthType Basic |
location / { |
Restricted - имя области, куда пользователь пытается получить доступ; зона применения аутентификации. В параметре AuthUserFile (auth_basic_user_file для Nginx) необходимо указать абсолютный путь к файлу, содержащему пароли. В параметре Require указывается требование, которое должны быть выполнено для получения доступа. Например, |
|
Блокировка User-agent | |
RewriteCond %{HTTP_USER_AGENT} googlebot [NC,OR] или SetEnvIfNoCase User-Agent "Mozilla/4.0 (compatible; ICS)" bad_user |
location / { |
С помощью данных правил Вы можете заблокировать доступ к сайту для нежелательных посетителей и ботов. | |
Блокировка IP-адресов | |
order allow,deny |
location / { |
В данном случае в первую очередь будут обработаны все директивы Allow, после - Deny. Будет разрешен доступ для всех IP, кроме 192.168.132.24. Обратите внимание, что если изменить порядок директив в Order на Deny,Allow, то доступ будет разрешен всем, т.к. директива Allow all будет применена последней и “перезапишет” правила, указанные в deny. |
В данном случае правила применяются в порядке их записи. В примере выше будет запрещен доступ для всех IP, кроме подсети 192.168.1.0/24. |
Надеемся, приведенная в статье информация окажется полезной для Вас и поможет в дальнейшей работе с Вашим сайтом на VDS.
Если у Вас возникнут вопросы, спрашивайте в комментариях - будем рады совместно разобраться в сложных моментах.
Комментарии