Настройка виртуальных хостов nginx

Как решить проблему с Apache?

Самое первое что вам нужно сделать в любом случае, если что-то не работает — это смотреть логи и информацию об ошибках. Только там вы сможете точно узнать что произошло. Самый простой способ это сделать, воспользоваться подсказкой systemd, которую она выдает при ошибке запуска:

То есть нам нужно выполнить systemctl status apache2.service или journalctl -xe чтобы получить больше сведений. Выполните сначала первую команду:

Мы сразу же видим причину проблемы — ошибка в конфигурационном файле, в директиве Listen, а теперь пробуем другую команду:

Только ее нужно выполнять сразу же, как была выполнена попытка перезапуска apache, потому что скоро буфер лога будет затерт и вы там ничего не увидите. Но здесь сообщается то же сообщение об ошибке в конфигурационном файле, даже видно строку — 54. Еще можно посмотреть error.log, но туда сообщения пишутся не всегда:

Дальше вы можете проверить конфигурационный файл на корректность с помощью такой команды:

Тут будут показаны даже предупреждения, которые не влияют на работу сервиса. Все серьезные ошибки нужно исправить если таковые имеются, возможно именно они препятствуют запуску.

Следующая важная проблема — это права доступа. Если Apache запускается от имени пользователя www-data, то у этого пользователя должен быть доступ на чтение к папке где лежат документы веб-сайта, а также ко всем папкам выше нее, также должен быть доступ на чтение и запись для логов и конфигурационных файлов. Проверить права можно с помощью команды namei, это аналог ls, который отображает полное дерево прав:

Таким же образом проверяем папку с логами:

Как видите, у меня папка /var/www/public_html принадлежит пользователю root, но на папку public_html установлены права чтения и записи для всех пользователей. Поэтому проблем нет, а на папку с логами в качестве группы установлена adm, в эту группу входит пользователь www-data, так что тут тоже проблем нет. Если у вас что-то отличается и вы видите что прав недостаточно, то либо измените владельца папки с файлами веб-сайтов на www-data, либо дайте больше разрешений:

Также, если в вашей системе включен SELinux, то вы можете его отключить на время, чтобы понять не в нем ли проблема:

Другой момент, который может вызвать ошибку, это если на порту, который вы хотите использовать для веб-сервера уже запущен какой-то процесс, например, nginx или lighttpd, в таком случае, его нужно остановить:

Или вы можете попытаться изменить порт на другой, для этого откройте конфигурационный файл веб-сервера и найдите там строку Listen:

Если такой строки еще нет, то вы можете ее создать. Далее просто измените номер порта с 80 на любой удобный, например, 8080

Дальше про ошибку старта при загрузке. Такая ошибка случалась в версиях ниже 2.2.4, если вы используете эту или более новую версию, то эта проблема вам не страшна. Она была вызвана тем, что Apache с SSL не хотел запускаться без папки /var/run/apache2, которой не было на момент загрузки. Самый простой способ решить проблему — отключить модуль ssl:

Второй способ более сложный — добавьте в конфигурационный файл /etc/init.d/apache2 такую строку:

Последняя проблема, о которой мы говорили — это когда неверно указанно имя сервера, на котором запускается Apache. Этой ошибке тоже были подвержены только ранние версии программы. Тогда при попытке запуска программа выдавала сообщение:

И дальше не запускалась. Чтобы решить эту проблему нужно было либо создавать виртуальные хосты, либо прописать в основном конфигурационном файле директиву ServerName, в которой будет указанно имя этого компьютера:

А также ассоциировать это имя с localhost в файле hosts:

Дальше было достаточно перезапустить Apache и все начинало работать.

Включение модуля pagespeed

После установки сервера Nginx нужно включить ngx_pagespeed.

Но сначала нужно создать папку, в которой модуль сможет хранить кэш файлов сайта:

Передайте права на эту папку пользователю Nginx, чтобы веб-сервер имел необходимый уровень доступа.

Откройте главный конфигурационный файл Nginx, nginx.conf, для редактирования:

Добавьте в блок server следующие строки и сохраните изменения:

Примечание: Этот код можно добавить в любую точку данного раздела; но в данном примере этот код будет добавлен в конец блока.

Теперь файл /etc/nginx/nginx.conf выглядит так:
Примечание: Конфигурацию pagespeed нужно добавить во все существующие блоки server.

Перезапустите Nginx:

Настройка Apache

Теперь нужно настроить Apacheкак бэкэнд сервера Nginx, запущенный на порту 8080. Чтобы Apache использовал правильный порт, откройте файл ports:

Найдите и отредактируйте следующие строки, чтобы запустить Apache на порту 8080, который доступен только с локального хоста.

Сохраните изменения и закройте файл.

Затем откройте новый файл виртуального хоста, скопировав макет из файла Apache по умолчанию:

Главный параметр, который необходимо исправить в данном случае, – это номер порта, на котором будет работать виртуальный хост; измените порт 80 по умолчанию на порт 8080.

Строка должна выглядеть так:

Убедитесь в том, что Document Root установлен правильно. Сохраните и закройте файл, а затем активируйте виртуальный хост:

Для корректной работы Apache нужно установить php. Для этого используйте:

Теперь перезапустите оба сервера, чтобы активировать изменения настроек:

Метод балансировки

Соединения к серверам для балансировки нагрузки могут распределяться по различным правилам. Существуют несколько методов распределения запросов. Я перечислю основные:

round-robin — используется по умолчанию. Веб сервер равномерно распределяет нагрузку на сервера с учетом их весов. Специально указывать этот метод в конфигурации не надо.
least-connected — запрос отправляется к серверу с наименьшим количеством активных подключений. В конфигурации данный параметр распределения запросов устанавливается параметром least_conn.
ip-hash — используется хэш функция, основанная на клиентском ip адресе, для определения, куда направить следующий запрос. Используется для привязки клиента к одному и тому же серверу. В предыдущих методах один и тот же клиент может попадать на разные серверы.
hash — задаёт метод балансировки, при котором соответствие клиента серверу определяется при помощи хэшированного значения ключа. В качестве ключа может использоваться текст, переменные и их комбинации.
random — балансировка нагрузки, при которой запрос передаётся случайно выбранному серверу, с учётом весов.

В платной версии существуют дополнительный более продвинутый метод распределения нагрузки — least_time, при котором запрос передаётся серверу с наименьшими средним временем ответа и числом активных соединений с учётом весов серверов.

Пример настройки:

upstream cache-api {
    ip_hash;
    server 10.32.18.6:8080;
    server 10.32.18.7:8080;
    server 10.32.18.8:8080;
}

Общая конфигурация и поддержка сети сайтов #Общая конфигурация и поддержка сети сайтов

Для работы WordPress на nginx вам потребуется настроить обработчик PHP (backend), это может быть php-fpm, php-cgi или fastcgi. Оптимальным и простым в установке вариантом является использование php-fpm, который поддерживается начиная с PHP 5.3

Основной файл конфигурации

Обычно это /etc/nginx/nginx.conf , но может и располагаться и в другом месте в зависимости от вашего дистрибутива операционной системы и источника пакетов nginx.

Ниже будут перечислены только те директивы, значение которых может непосредственно влиять на работу WordPress. Ваш дистрибутив должен предоставлять файл конфигурации обеспечивающий базовую работу nginx, вам следует только перепроверить его на директивы, перечисленные ниже. Строки в конфигурации начинающиеся с # являются комментариями.

Настройка PHP обработчика может быть произведена так (как в глобальном контексте http {} так и для каждого сайта в контекстах server {} , настройки должны соответствовать тем, что указаны в настройках директивы listen пула (pool) для php-fpm

Во многих дистрибутивах конфигурации для отдельных сайтов (контекст ) вынесены в папку sites-available, на которые создаются символические ссылки в папке sites-enabled. Конфигурации включенных сайтов загружаются в конце nginx.conf директивой

Некоторые полезные директивы для конфигурации сайта

server {
# Это адрес сайта
    server_name example.com;
# Путь к папке с файлами сайта (корню)
    root /var/www/example.com;
# Файл индекса сайта.
    index index.php;
# А вот показ индекса файлов в папках без файла-индекса отключим
    autoindex off;
# Журнал доступа может быть записан в отдельный файл с отложенной записью
access_log  /var/log/jinx/www-example.com.log main buffer=2k flush=30s;
# А для некоторых файлов журнал доступа можно и вовсе отключить
location = /favicon.ico {
    log_not_found off;
    access_log off;
}
location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

# Закроем доступ к скрытым файлам (начинаются с точки)
location ~ /\. {
    deny all;
}

# Вот так можно закрыть доступ к папке кеша (плагинов)
location ~ ^/wp-content/cache { deny all; }

# Запрет выполнения PHP в папках для загруженных файлов
location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}
# А директивы ниже показывают как можно установить заголовки кеширования для статических ресурсов (а также изменить сжатие gzip для некоторых из них)
location ~* ^.+\.(jpg|jpeg|png|ico|gif|swf|webp|srv)$ { expires 3w; gzip off; }
location ~* ^.+\.(css|js)$ { expires 7d; add_header Vary Accept-Encoding; }
location ~* ^.+\.(eot|ttf|woff|woff2)$ { expires 92d; add_header Vary Accept-Encoding; }

# Не забываем добавить обработчик для PHP
location ~ \.php$ {
 include fastcgi.conf;
 fastcgi_intercept_errors on;
 fastcgi_param  SCRIPT_FILENAME  $root$fastcgi_script_name;
# Должен соответствовать имени, определенному в примере директивы upsteam выше.
 fastcgi_pass php;
        }
# Ну и наконец, правила для "красивых постоянных ссылок"
location / { try_files $uri $uri/ /index.php?$args; }
# поближе к закрытию контекста server
}

Обязательно убедитесь в том, что в php.ini установлено значение константы

это предотвратит исполнение иных (без расширения .php) файлов, возможно содержащих PHP код, возможным злоумышленником.

Много других рецептов и хитростей по конфигурированию nginx можно посмотреть например здесь: https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/

Конфигурация для сети сайтов

С тех пор, как установка сети сайтов стала частью WordPress (а не отдельным пакетом WPMU), дополнительные правила для nginx не требуются, вам следует лишь иметь идентичные блоки server{} для всех сайтов вашей сети, вы можете создать отдельный файл и включать его в конфигурации сайтов директивой e. Переопределяя лишь и если вам нужно — .

Если же ваша сеть сайтов имеет общий домен, то вы можете разместить её на одном виртуальном сервере, с одним блоком конфигурации .

Директива будет работать с любым доменом третьего уровня в домене example.com.

Внимание: вы можете оставить комментарий обратной связи к этой статье. Если данная статья показалась вам неполной или вы нашли неточности, оставьте нам сообщение используя форму ниже

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

Также вы можете поучаствовать в составлении и дополнении документации на русском языке.Подробнее тут.

2 ответа

Лучший ответ

Цитируя комментарий Элитара,

Обратное проксирование

Использование Apache на порту 80 таким образом называется обратным прокси . Он принимает все входящие соединения на порт 80 (и / или порт 443 для https) и передает их, обычно в незашифрованном виде, только через внутренние соединения localhost вашей программе Go, работающей на любом выбранном вами порту. Часто используются 8000 и 8080. Трафик между Apache и вашим сервером сам по себе является HTTP-трафиком .

Поскольку ваша программа Go не запускается от имени пользователя root, она не может изменять важные функции на сервере. Следовательно, это дает дополнительную степень безопасности, если ваша программа когда-либо будет содержать недостатки безопасности, потому что любой злоумышленник получит только ограниченный доступ.

Fastcgi

Вы можете улучшить общую производительность обратного проксирования, не используя HTTP для подключения Apache к серверу Go. Это делается с помощью протокола FastCGI, изначально разработанного для сценариев оболочки, Perl и PHP, но работающего хорошо и с Go. Чтобы использовать это, вы должны изменить свой сервер Go для прослушивания с помощью fcgi strong> API. Также требуется Apache FastCGI. Трафик от Apache к вашему серверу использует более компактный формат (не HTTP), что снижает нагрузку на каждую сторону.

Также открыт выбор типа сокета: вместо обычных сокетов TCP можно использовать сокеты Unix , что еще больше снижает нагрузку на обработку. Я сам не делал этого в Go, но API поддерживает необходимые биты (см. связанный вопрос ).

Nginx

Хотя все вышеперечисленное описывает использование Apache, существуют и другие серверные продукты, которые также могут предоставлять обратный прокси. Наиболее примечательным является Nginx (Пример обратного прокси Nginx), что даст вам небольшие, но полезные преимущества в производительности и масштабируемости. Если у вас есть эта опция на ваших серверах, ее стоит изучить и развернуть.

Community
23 Май 2017 в 12:02

Основываясь на этом предыдущем ответе о переменных среды, я легко смог решить проблему sudo.

Добавил эти строки:

Кстати, используя ubuntu 12.04. Я думаю, что предыдущий ответ о прокси для использования порта 80 является правильным выбором, потому что после исправления проблемы с sudo мне вместо этого была выдана эта ошибка о порте 80:

Это означает, что команда sudo была исправлена, но привязка прокси не будет работать с другой службой, уже использующей порт 80 (apache).

-3

Community
23 Май 2017 в 12:26

Виртуальные хосты в Windows 7

В качестве примера поместим один или несколько проектов на диск D: локального компьютера. Сначала организуем структуру каталогов. На диске D: создаем каталог «mysites», а в нём каталог для первого сайта «site1». В каталоге «site1» сделаем два подкаталога: «www» и «logs». В первом подкаталоге будет располагаться сам сайт, а во втором, журналы виртуального хоста: access.log (журнал доступа) и error.log (журнал ошибок).

Файлы журналов создавать не надо, они будут созданы автоматически. А в каталоге «www», пока нет сайта, поместим простейший файл-заглушку «index.html» следующего содержания:

Теперь немного поправим настройки для виртуальных хостов веб-сервера Apache. Открываем C:\xampp\apache\conf\extra\ httpd-vhosts.confКак видим, этот файл уже содержит два примера виртуальных хостов. Не будем их трогать, а ниже разместим следующие строки:

NameVirtualHost *:80
<VirtualHost *:80>
    DocumentRoot "C:/xampp/htdocs"
    ServerName localhost
</VirtualHost>
<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot "D:/mysites/site1/www"
    ServerName site1
    ServerAlias www.site1
    ErrorLog "D:/mysites/site1/logs/error.log"
    CustomLog "D:/mysites/site1/logs/access.log" common
   <Directory "D:/mysites/site1/www">
	AllowOverride All
	Require all granted
    </Directory>
</VirtualHost>

Первая директива NameVirtualHost *:80 включает поименное использование виртуальных хостов на 80-ом порту (обычный http, если нужен https, используем 443 порт).Следующие четыре строки это общая секция для всех виртуальных хостов. Если клиент обращается к серверу по IP-адресу или по несуществующему имени он попадет на этот виртуальный хост. В нашем случае в корневую директорию веб-сервера. Остальные строки это описание нашего первого виртуального хоста. Если нужно добавить ещё один виртуальный хост, то просто копируем эту секцию, вставляем ниже и по аналогии изменяем данные. Сохраняем файл.Значение данных в секции виртуального хоста:

<VirtualHost *:80> Какой порт используется
ServerAdmin [email protected] Эл. почта администратора сайта
DocumentRoot «D:/mysites/site1/www» Корневой каталог сайта
ServerName site1 Имя хоста
ServerAlias www.site1 Псевдоним хоста. Можно обращаться, используя псевдоним
ErrorLog «D:/mysites/site1/logs/error.log» Расположение журнала ошибок
CustomLog «D:/mysites/site1/logs/access.log» common Расположение журнала доступа. Оператор common определяет общую степень детализации журнала. Если нужна более подробная детализация, то вместо common пишем combined
<Directory «D:/mysites/site1/www»> Подсекция, в которой определяются права и настройки для конкретного каталога.
AllowOverride All Эта директива нужна для правильной работы системы SEF

Из панели управления XAMPP перестартовываем Apache. Изменяем файл C:\Windows\System32\drivers\etc\hosts. Дописываем в него две строки:

127.0.0.1     site1
127.0.0.1     www.site1

Вместо 127.0.0.1 можно написать 127.0.0.2, а для следующего виртуального хоста 127.0.0.3, но в этом нет особой нужды. Об этом напишу в другой раз. А сейчас сохраняем файл. Открываем браузер и адресной строке вводим http://site1 или просто site1. Если всё сделано правильно, видим информацию из файла-заглушки.

Установка компонентов

Первым делом нужно установить сам веб-сервер в систему. Программа есть в официальных репозиториях, но ее версия уже немного устарела, поэтому если хотите самую новую версию, нужно добавить PPA:

Сейчас в официальных репозиториях доступна версия 1.10.0, а в стабильной PPA уже доступна 1.10.1. Если для вас версия не нужна можно обойтись и без PPA. Дальше обновите списки пакетов из репозиториев:

И устанавливаем ngnix:

После того как установка сервера Nginx будет завершена добавим программу в автозагрузку, чтобы она запускалась автоматически:

Если вы уже сейчас откроете браузер, то увидите работающий nginx, но нам предстоит его еще настроить.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

<VirtualHost *:80>
ServerName site.ru
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать

Установка модуля rewrite

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

vi /etc/httpd/conf.modules.d/00-base.conf

LoadModule rewrite_module modules/mod_rewrite.so

* если ее нет, добавляем; если она закомментирована, снимаем комментарий.

systemctl restart httpd

б) в Ubuntu:

a2enmod rewrite

systemctl restart apache2

Настройка ssl сертификата Lets Encrypt в apache

Теперь настроим работу web сервера apache с ssl сертификатом. Хотя если быть точным, то tls сертификатом. Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. Для этого нам сначала надо подключить репозиторий epel.

# dnf install epel-release
# dnf install certbot

После установки пакетов certbot, если его запустить, напишет ошибку, что не может сам настроить apache.

Настроим все сами. Для начала создадим самоподписанный дефолтный сертификат, чтобы apache не ругался на отсутствие файла и смог запуститься.

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt

Все параметры оставляйте дефолтные, не принципиально. Мы этот сертификат использовать не будет. Перезапустите apache.

# apachectl restart

Теперь выпустим сертификат для нашего домена. Имейте ввиду, чтобы получить сертификат у вас должно быть действующее доменное имя, ссылающееся на web сервер, который настраиваете. Let’s Encrypt будет по доменному имени обращаться к серверу, на котором настраиваете сертификат, чтобы проверить домен. В тестовой лаборатории с вымышленным доменным именем получить настоящий ssl сертификат не получится.

# certbot certonly

В качестве способа аутентификации выбирайте

1: Apache Web Server plugin (apache)

Дальше заполняйте в соответствии с вашими названиями. После получения сертификата, укажем его в конфигурации виртуального хоста. В моем случае в файле z.serveradmin.ru.conf. Добавляем туда параметры ssl.

<VirtualHost *:80 *:443>

    ServerName z.serveradmin.ru
    ServerAlias www.z.serveradmin.ru
    DocumentRoot /web/sites/z.serveradmin.ru/www

    ErrorLog /web/sites/z.serveradmin.ru/log/error.log
    CustomLog /web/sites/z.serveradmin.ru/log/access.log common

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem

    <Directory /web/sites/z.serveradmin.ru/www>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    php_admin_value date.timezone 'Europe/Moscow'
    php_admin_value max_execution_time 60
    php_admin_value upload_max_filesize 30M

</VirtualHost>

Перезапускайте apache и проверяйте работу сайта по https, зайдя по соответствующему протоколу.

По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:

# Cert Renewal
30 4 * * * root /usr/bin/certbot renew --post-hook "/usr/sbin/apachectl restart" >> /var/log/le-renew.log

Переадресация с http на https в apache

В настроенном ранее примере https отлично работает, но неудобно, что нет автоматической переадресации с http на https. Чтобы использовать безопасную версию сайта, необходимо вручную в браузере набирать https. Хотя все современные браузеры уже сами умеют проверять версии сайта и если есть защищенная, то они автоматически сами ее выбирают.

Тем не менее, лучше все же добавить редирект с http на https. Его можно сделать двумя различными способами:

Через файл .htaccess
С помощью настройки виртуального хоста.

Мне нравится больше второй вариант, поэтому приводим конфиг виртуального хоста к следующему виду.

<VirtualHost *:80>

    ServerName z.serveradmin.ru
    ServerAlias www.z.serveradmin.ru
    Redirect permanent / https://z.serveradmin.ru

</VirtualHost>

<VirtualHost *:443>

    ServerName z.serveradmin.ru
    ServerAlias www.z.serveradmin.ru
    DocumentRoot /web/sites/z.serveradmin.ru/www

    ErrorLog /web/sites/z.serveradmin.ru/log/error.log
    CustomLog /web/sites/z.serveradmin.ru/log/access.log common

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/z.serveradmin.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/z.serveradmin.ru/privkey.pem

    <Directory /web/sites/z.serveradmin.ru/www>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    php_admin_value date.timezone 'Europe/Moscow'
    php_admin_value max_execution_time 60
    php_admin_value upload_max_filesize 30M

</VirtualHost>

Перечитывайте конфиг httpd и проверяйте. Должно работать автоматическое перенаправление на https версию.

Рабочий пример:

Как правило, когда мне нужно сервер нескольких сайтов на одном сервере, я использую следующую конфигурацию (конечно, это упрощено, в настоящее время мы обычно используем HTTPS с перенаправлением на ):

Файл конфигурации сайта 1

Файл конфигурации сайта 2

Файл конфигурации сервера по умолчанию

Из-за флага в директиве третий блок сервера используется, когда заголовок запроса не содержит ни одного из имен моих сайтов (или у запроса нет заголовок вообще). Я не ожидаю, что посетители, которые не знают, какой сайт они посещают (обычно это сканеры портов, поисковики уязвимостей и т. Д.), Поэтому я использую для них специальный код nginx 444 (закрытое соединение без какого-либо ответа).

Установка Nginx на Ubuntu 20.04

Установить Nginx можно двумя способами. Первый способ заключается в установки пакета из официального репозитория Ubuntu. На момент написания статьи (1 августа 2021 года) актуальной версией Nginx присутствующей в репозитории Ubuntu была версия 1.18.0. Данная версия считается устаревшей. Актуальной же версией считается 1.20.1 (по состоянию на 1 августа 2021 года).

1. Официальные репозитории Ubuntu

Если вы хотите установить версию Nginx из репозиториев Ubuntu необходимо выполнить следующие действия. Для начала обновляем списки пакетов при помощи команды:

Для того, чтобы установить Nginx, достаточно выполнить команду:

После этого программу можно использовать. Проверка и настройка программы будет описана в разделах ниже.

2. Официальные репозитории Nginx

Второй способ заключается в установке последней версии Nginx из официальных репозиториев, которые предоставляют разработчики Nginx. Если вы хотите использовать данный метод установки, для начала необходимо обновить списки пакетов при помощи команды:

Установите необходимые пакеты:

Далее у вас на выбор есть два пути – подключить репозиторий со стабильной версией nginx или подключить репозиторий с основной версией. Стабильная версия является более проверенной и работоспособной. Эту версию можно использовать, как и в тестовых средах так и на производственных. Основная версия не такая стабильная и может содержать ошибки. Данную версию не рекомендуется использовать в производственных средах.

Для подключения репозитория со стабильной версией nginx, выполните следующую команду:

Для подключения репозитория с основной версией nginx, выполните следующую команду:

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

Проверьте, верный ли ключ был загружен:

Вывод команды должен содержать полный отпечаток ключа 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62:

Переместите ключ в каталог доверенных ключей apt:

Чтобы установить nginx, выполните следующие команды:

Версия Nginx от разработчиков немного отличается от версии из официальных репозиториев. Все дополнительные конфигурационные файлы здесь находятся в папке /etc/nginx/conf.d. Если вы хотите использовать папки sites-available и sites-enabled, то необходимо их создать:

Затем добавьте следующую строчку в конец секции http файла /etc/nginx.conf для того чтобы из папки /etc/nginx/sites-enabled загружалась конфигурация сайтов:

Затем перезапустите Nginx:

3. Запуск Nginx

После установки пакета, проверяем что Nginx успешно запустился при помощи команды:

Если в статусе вместо active будет inactive (dead), то сервис необходимо запустить вручную при помощи команды:

Так же обратите внимание, что вы не можете запускать Apache и Nginx на одном порту. В таком случае вы получите ошибку nginx address already in use 80. Для корректной работы Nginx, необходимо будет отключить веб-сервер Apache (если он у вас используется) или изменить его порт с 80 (который используется по умолчанию) на другой свободный порт

4. Настройка брандмауэра

По умолчанию брандмауэр закрывает все неразрешённые входящие подключения. Поэтому, чтобы к вашему веб-серверу можно было получить доступ извне, необходимо добавить его порт в исключения:

5. Проверка работы Nginx

После того, как Nginx будет запущен, он будет доступен по адресу сервера, на который он устанавливался. Вы можете проверить, всё ли работает, просто перейдя по адресу сервера, введя его в браузере. Для примера Nginx был установлен на localhost:

Если вы увидите приветственное сообщение как на скриншоте выше это означает что Nginx успешно установлен и запущен.

Переход с Apache на Nginx

На данный момент Apache обслуживает запросы на порте 80. Это значит, что Nginx не сможет подключиться к этому порту. Нужно остановить веб-сервер Apache, прежде чем включить Nginx.

В некоторых случаях есть необходимость оставить сервер Apache включенным, если он обслуживает другой контент (к примеру, если у вас несколько сайтов, и вы перемещаете на Nginx только один из них). Для этого нужно убрать все ссылки на порт 80 в конфигурации Apache.

Файлы, которые нужно проверить:

Примечание: Также вы можете настроить Nginx как прокси-сервер Apache. Подробнее о такой настройке можно прочитать здесь.

Изменив порт Apache, перезапустите веб-сервер, чтобы обновить настройки, а затем включите Nginx. После этого порт 80 будет занят сервером Nginx, а Apache будет использовать новый порт.

Если же в дальнейшем сервер Apache не нужен, так как обслуживание файлов полностью перейдёт к Nginx, выключите Apache:

На данном этапе важно либо передать порт 80 серверу Nginx, настроив Apache на другой порт, либо же полностью остановить Apache. В противном случае Nginx не запустится, потому что порт занят другим веб-сервером

Если переход был выполнен успешно и теперь контент обслуживается сервером Nginx, можно удалить Apache и его зависимости, если он больше не нужен. Для этого введите:

А затем удалите эти пакеты:

Также можно удалить ранее установленные зависимости, которые больше не используются.

Настройка Nginx в качестве фронт-энда

Откройте конфигурационный файл:

Ниже приведенный блок кода содержит все необходимые конфигурации. В целом, он очень похож на настройки Nginx по умолчанию; подробную информацию о данном коде можно найти ниже.

Итак, данный блок кода выполняет следующие действия:

указывает правильный root-каталог сайта;
вносит index.php в строку index;
try_files пытается обслужить любую запрашиваемую страницу. В случае если Nginx не может этого сделать, файл передается на прокси;
proxy_pass содержит адрес проксированного сервера;
блок location ~ /\.ht { закрывает доступ к файлам .htaccess в случае если root документа Apache и Nginx совпадают.

Данные настройки создают систему, перенаправляющую все расширения с окончанием php на бэкэнд Apache, запущенный на порту 8080.

Теперь активируйте виртуальный хост:

Кроме того, необходимо удалить блок server (виртуальный хост Nginx) по умолчанию.

Готово! Теперь, когда Nginx установлен и полностью готов к работе, можно переходить к установке и настройке Apache.