Состояние перевода: На этой странице представлен перевод статьи nginx. Дата последней синхронизации: 18 июля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
nginx (произносится «э́нжин-э́кс» или «э́нжин-и́кс») — это свободный высокопроизводительный HTTP-сервер с открытым исходным кодом, а также обратный прокси и IMAP/POP3 прокси-сервер, написанный Игорем Сысоевым в 2005 году. nginx получил широкое распространение благодаря своей стабильности, богатой функциональности, простой настройке и низкому потреблению ресурсов.
Данная статья описывает установку nginx и интеграцию с PHP через #FastCGI.
Команды root и alias в Nginx сбивают с толку многих людей, потому что основная причина в том, что они не поняли замысел проекта и применимые сценарии этих двух команд. Теперь есть потребность: при разработке небольшой программы запрашиваемое доменное имя Tencent необходимо проверить, поэтому при разработке часто требуется поместить файл проверки txt в корневой каталог доменного имени, а затем Tencent выполняет проверку имени домена через доступ к этому файлу. По историческим причинам корневой каталог кода не открыт для внешнего мира, что требует отдельного расположения, которое будет использоваться файлом проверки txt. Как вы пишете это местоположение? Прежде всего, посмотрите на способ написания. Как вы думаете, запросhttp://test.com/1234.txt Сможет ли Nginx послушно вернуть 200?
location /1234.txt {
alias /data/w3/txt/;
}
Вы готовы? Поразмыслив, я объявлю ответ: в журнале доступа Nginx будет две записи, одна — 301, а другая — 403. Вы удивлены или удивлены? Конкретные причины пока не указаны, давайте сначала взглянем на официальные документы alias и root.
[23/Aug/2018:11:47:28 +0800] "GET /1234.txt HTTP/1.1" 301 284
[23/Aug/2018:11:47:28 +0800] "GET /1234.txt/ HTTP/1.1" 403 596
Nginx — это быстрый и легкий веб-сервер. Файлы конфигурации Nginx действительно просты и удобны в работе. Это отличная альтернатива веб-серверу Apache. В этой статье я покажу вам, как установить и настроить веб-сервер Nginx на CentOS 8. Итак, приступим.
- Установка Nginx:
- Управление службой nginx:
- Настройка брандмауэра:
- Тестирование веб-сервера:
- Файлы конфигурации nginx:
- Настройка базового веб-сервера:
- Директивы, блоки и контексты
- Блок http
- Серверные блоки
- Блоки Location
- Заключение
- Hello world
- Установка в chroot
- Создание необходимых устройств
- Создание необходимых каталогов
- Отредактируйте nginx.service для запуска chroot
- Процессы и соединения
- Запуск под другим пользователем
- Ошибка: Страница, которую вы ищете, временно недоступна. Пожалуйста, попробуйте позже. (502 Bad Gateway)
- Ошибка: No input file specified
- Warning: Could not build optimal types_hash
- Cannot assign requested address
- Официальное определение root и alias
- Путь, определяемый местоположением, является каталогом
- Путь, определяемый местоположением, является файлом
- Советы и рекомендации
- Запуск без привилегий через systemd
- Права каталогов и файлов журналов
- Альтернативный скрипт для systemd
- Более удобное управление заголовками
Установка Nginx:
Nginx доступен в официальный репозиторий пакетов CentOS 8. Таким образом, его очень легко установить.
Сначала обновите кеш репозитория пакетов DNF следующим образом:
Теперь установите Nginx с помощью следующей команды:
Чтобы подтвердить установку, нажмите Y , а затем нажмите .
Должен быть установлен Nginx.
Управление службой nginx:
По умолчанию nginx должен быть неактивен (не запущен) и отключен (выиграл ‘ t автоматически запускается при загрузке).
$ sudo systemctl status nginx
Вы можете запустить службу nginx следующим образом:
$ sudo systemctl start nginx
nginx должен быть запущен .
$ sudo systemctl status nginx
Теперь добавьте службу nginx в запуск системы следующим образом:
$ sudo systemctl enable nginx
Настройка брандмауэра:
Вы должны настроить брандмауэр, чтобы разрешить доступ к HTTP-порту 80 и HTTPS-порту 443 по порядку для доступа к веб-серверу Nginx с других компьютеров в сети.
Вы можете разрешить доступ к портам HTTP и HTTPS с помощью следующей команды:
Теперь, чтобы изменения вступили в силу, выполните следующую команду:
$ sudo firewall-cmd —reload
Тестирование веб-сервера:
Теперь посетите http://192.168.20.175 из ваш веб-браузер. Вы должны увидеть следующую страницу. Это означает, что веб-сервер Nginx работает.
Файлы конфигурации nginx:
Файлы конфигурации веб-сервера Nginx находятся в каталоге /etc/nginx/.
/etc/nginx/nginx.conf — это главный файл конфигурации Nginx.
Настройка базового веб-сервера:
В этом разделе я покажу вам, как установить вверх базовый веб-сервер Nginx.
Сначала сделайте резервную копию исходного файла конфигурации Nginx с помощью следующей команды:
$ sudo mv -v /etc/nginx/nginx.conf/etc/nginx/nginx.conf.original
Теперь создайте новый файл конфигурации Nginx следующим образом:
$ sudo nano/etc/nginx/nginx.conf
Теперь введите следующие строки в /etc/nginx/nginx.conf и сохраните файл.
Здесь параметр пользователь — используется для установки пользователя и группы запуска Nginx на nginx соответственно.
Параметр error_log используется для установки журнала ошибок путь к файлу /var/log/nginx/error.log . Здесь будут храниться ошибки, связанные с сервером Nginx.
Основная конфигурация сервера Nginx определяется в разделе server внутри http. раздел. При необходимости вы можете определить более одного раздела server внутри раздела http .
На сервере , параметр
listen используется для настройки Nginx для прослушивания порта 80 (HTTP-порт) для веб-запросов.
используется для установки одного или нескольких доменных имен для веб-сервера Nginx. Если ваши настройки DNS верны, вы можете получить доступ к веб-серверу Nginx, используя эти доменные имена..
Местоположение используется для установки корневого каталога веб-сервера Nginx.
Здесь должны храниться все файлы веб-сайта. Параметр index устанавливает index.html в качестве файла по умолчанию, который будет использоваться, если не запрашивается конкретный файл. Например, если вы посетите http://192.168.20.175/myfile.html, то Nginx вернет файл myfile.html . Но если вы посетите http://192.168.20.175/, то Nginx отправит вам файл index.html, поскольку конкретный файл не запрашивался.
Теперь введите следующие строки в index. html и сохраните файл.
Nginx – компактный и производительный веб-сервер, созданный для систем с высоким трафиком. Одной из его сильных сторон является эффективное представление статического контента, например, HTML или медиафайлов. В Nginx используется асинхронная модель с управлением событиями, что обеспечивает предсказуемую производительность при высокой нагрузке.
Динамический контент Nginx передает CGI, FastCGI или другим веб-серверам, например, Apache. Затем этот контент возвращается Nginx для отправки клиенту. В данном руководстве мы рассмотрим базовые принципы и параметры конфигурации Nginx.
Директивы, блоки и контексты
user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { . . . } http { . . . }
Блок http
Блок http содержит директивы управления веб-трафиком. Они часто называются универсальными, потому что используются для конфигурации всех веб-сайтов, содержащихся на сервере. Полный список всех доступных директив и их параметров для этого блока можно посмотреть в документации Nginx. В /etc/nginx/nginx.conf
можно увидить примерно следующий блок http
http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; }
В рассмотренном примере заданы следующие директивы:
include – указывает расположение дополнительных файлов конфигурации
default_type – задает MIME-тип ответов по умолчанию
log_format – задает поля, которые будут сохраняться в логе сервера
access_log – путь к файлу лога доступа к серверу
sendfile – прямая передача данных без буферизации, используется для ускорения работы сервера
tcp_nopush – настройка формирования TCP-пакетов, ускоряющая работу сервера (в данном случае закомментировано)
keepalive_timeout – максимальное время поддержания соединения, если пользователь ничего не запрашивает
gzip – включение компрессии (в данном случае закомментировано)
- Как уже было сказано, блок http содержит директиву include, которая указывает расположение файлов конфигурации Nginx.
Если установка выполнялась из официального репозитория Nginx, эта строка, как и в рассмотренном примере, будет иметь видinclude /etc/nginx/conf.d/*.conf;
. У каждого веб-сайта на вашем сервере в этой директории должен быть свой файл конфигурации с именем формата example.com.conf. Для отключенных сайтов (не отображаемых Nginx) он может быть переименован в формате example.com.conf.disabled. - При установке из репозиториев Debian или Ubuntu данная строка будет иметь вид
include /etc/nginx/sites-enabled/*;
. Директория/sites-enabled/
содержит символические ссылки на файлы конфигурации, которые хранятся в/etc/nginx/sites-available/
. Отключение сайта осуществляется удалением символической ссылки на sites-enabled. - В зависимости от источника установки в
/etc/nginx/conf.d/default.conf
или/etc/nginx/sites-enabled/default
есть пример файла конфигурации.
Серверные блоки
Независимо от источника установки файлы конфигурации будут содержать серверный блок (или блоки) для веб-сайта, обозначенный словом server. Например:
server { listen 80 default_server; listen [::]:80 default_server; server_name example.com www.example.com; root /var/www/example.com; index index.html; try_files $uri /index.html; }
Обычно для каждого домена или сайта на сервере требуется создать свой файл. Вот некоторые примеры:
1.Обработка запросов к example.com и www.example.com:
server_name example.com www.example.com;
2.В директиве server_name можно использовать маски. Например, *.example.com и .example.com указывают серверу обрабатывать запросы на все поддомены example.com:
server_name *.example.com; server_name .example.com;
3.Обработка запросов ко всем доменным именам, начинающимся с example.:
server_name example.*;
Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.
Блоки Location
Блоки location позволяют настроить, как Nginx будет отвечать на запросы к ресурсам на сервере. Подобно тому, как директива server_name определяет обработку запросов к доменам, директивы location охватывают запросы к конкретным файлам и папкам, таким как http://example.com/blog/. Вот несколько примеров:
location / { } location /images/ { } location /blog/ { } location /planet/ { } location /planet/blog/ { }
Указанные выше расположения – это точно определенные строки, которые соответствуют части HTTP-запроса после имени узла.
Запрос: http://example.com/
Ответ: Если для example.com есть запись server_name, обработка данного запроса будет определяться директивой location /
.
Nginx всегда выполняет запрос, находя наиболее точное соответствие:
Запрос: http://example.com/planet/blog/ или http://example.com/planet/blog/about/
Ответ: Обработку запроса будет определять директива location /planet/blog/
, потому что она соответствует точнее, хотя location /planet/
также удовлетворяет условиям запроса.
location ~ IndexPage\.php$ { } location ~ ^/BlogPlanet(/|/index\.php)$ { }
Когда после директивы location указана тильда (~), Nginx определяет соответствие по регулярному выражению. Этот поиск всегда чувствителен к регистру. Таким образом, страница IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php – нет. Во втором примере регулярному выражению будут соответствовать запросы к /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/, или /blogplanet/index.php. В Nginx используются Perl-совместимые регулярные выражения.
Если вы хотите, чтобы поиск не был чувствителен к регистру, после тильды нужно указать звездочку (~*).
location ^~ /images/IndexPage/ { } location ^~ /blog/BlogPlanet/ { }
Если указать перед тильдой символ «крышки» (^~), при соответствии запроса указанной строке сервер прекратит поиск более точных соответствий (даже если они есть) и будет использовать эти директивы. Во всем остальном они аналогичны рассмотренным выше директивам.
location = / { }
Знак равенства (=) после директивы location означает необходимость точного соответствия указанному пути. В случае его наличия поиск прекращается. Например, запрос http://example.com/ будет соответствовать указанному выше примеру, а http://example.com/index.html — нет. Использование точных соответствий может ускорить время обработки запроса, если какие-то запросы распространены больше других.
Директивы обрабатываются в следующем порядке:
- Сначала обрабатываются точные соответствия строк. Если соответствие найдено, Nginx прекращает поиск и отвечает на запрос.
- Обрабатываются оставшиеся директивы с точно заданными строками. Если Nginx находит соответствие директиве с аргументом ^~, он прекращает поиск и отвечает на запрос. В противном случае обработка директив location продолжается.
- Обрабатываются директивы location с регулярными выражениями (~ и ~*). Если запрос соответствует регулярному выражению, Nginx прекращает поиск и отвечает на запрос.
- Если соответствия регулярным выражениям не найдено, используется наиболее точное соответствие из жестко заданных строк.
Убедитесь, что каждый файл или папка в домене соответствуют условиям хотя бы одной директивы location.
Внутри блока location указываются собственные директивы, например:
location / { root html; index index.html index.htm; }
В данном примере корень документов находится в директории html/. При установке Nginx в месторасположение по умолчанию она находится в /etc/nginx/html/
. В директиве root также можно использовать абсолютный путь.
Запрос: http://example.com/blog/includes/style.css
Ответ: Nginx попытается передать клиенту файл /etc/nginx/html/blog/includes/style.css
Переменная index сообщает Nginx, какой файл передавать, если клиент не указал конкретное имя, например:
Запрос: http://example.com
Ответ: Nginx попытается передать файл /etc/nginx/html/index.html
.
Если в директиве index указано несколько файлов, Nginx пройдет по списку и передаст первый существующий файл. Если файла index.html в соответствующей директории нет, будет передан index.htm. В случае если ни один из файлов не существует, будет отправлено сообщение об ошибке 404.
Вот более сложный пример набора директив location для сервера example.com:
location / { root /srv/www/example.com/public_html; index index.html index.htm; } location ~ \.pl$ { gzip off; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/run/fcgiwrap.socket; fastcgi_index index.pl; fastcgi_param SCRIPT_FILENAME /srv/www/example.com/public_html$fastcgi_script_name; }
В данном примере все запросы ресурсов, которые заканчиваются на расширение .pl, будут обработаны вторым блоком location, в котором для ответа на эти запросы задан обработчик fastcgi. Ресурсы расположены в файловой системе /srv/www/example.com/public_html/
. Если имя файла в запросе не указано, Nginx найдет и передаст файл index.html или index.htm. Если их нет, он выдаст ошибку 404.
Разберем ответы на некоторые запросы
Запрос: http://example.com/
Ответ: /srv/www/example.com/public_html/index.html
если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/index.htm
. Если и этот файл не существует, Nginx выдаст ошибку 404.
Запрос: http://example.com/blog/
Ответ: /srv/www/example.com/public_html/blog/index.html
если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/blog/index.htm
. Если и этот файл не существует, Nginx выдаст ошибку 404.
Запрос: http://example.com/tasks.pl
Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/tasks.pl
и выдаст результат.
Заключение
Мы разобрали базовые принципы и параметры конфигурации веб-сервера Nginx. Этого достаточно, чтобы настроить простой сайт. Для более подробной информации о директивах файлов конфигурации стоит изучить официальную документацию Nginx.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Hello world
& copy; 2020 LinuxHint.com
Теперь перезапустите службу nginx следующим образом:
$ sudo systemctl restart nginx
Теперь перейдите по адресу http://192.168.20.175 из своего веб-браузера, и вы должны увидеть следующее страница. Поздравляю! Вы настроили свой первый веб-сервер Nginx.
Вы можете настроить страницы ошибок в Nginx. Например, если страница/файл/каталог недоступны, в браузер будет возвращен код состояния HTTP 404. Вы можете настроить пользовательскую страницу ошибок HTML для кода состояния HTTP 404, который будет возвращаться браузеру.
Для этого добавьте следующую строку в сервер раздел файла nginx.conf .
Теперь введите следующие строки в 404.html и сохраните файл.
Установка в chroot
Установка nginx в chroot добавляет дополнительный уровень безопасности. Для максимальной безопасности chroot должен включать только файлы, необходимые для запуска сервера nginx, при этом все файлы должны иметь по возможности максимально ограниченные права доступа. Например, как можно больше файлов должно принадлежать пользователю root, а таким каталогам, как /usr/bin
должен быть установлен запрет на чтение и запись.
Arch поставляется с пользователем http
и группой по умолчанию, от имени которых запускается сервер. Измененный корневой каталог будет находиться в /srv/http
.
Существует perl-скрипт для создания chroot-окружения, который доступен в jail.pl gist. Вы можете либо использовать его, либо следовать дальнейшим инструкциям из этой статьи. Скрипт требует прав суперпользователя для работы. Вам нужно будет раскомментировать строку, перед тем, как он сможет выполнять какие-либо изменения.
Создание необходимых устройств
Для nginx нужны /dev/null
, /dev/random
и /dev/urandom
. Чтобы установить их в chroot мы создадим каталог /dev
и добавим устройства с помощью mknod. Избегайте монтирования всех устройств в /dev
: тогда, даже если chroot будет скомпрометирован, атакующий должен будет выбраться из chroot-окружения чтобы добраться до важных устройств, например /dev/sda1
.
Совет: Убедитесь, что /src/http
примонтирован без опции no-dev
# export JAIL=/srv/http # mkdir $JAIL/dev # mknod -m 0666 $JAIL/dev/null c 1 3 # mknod -m 0666 $JAIL/dev/random c 1 8 # mknod -m 0444 $JAIL/dev/urandom c 1 9
Создание необходимых каталогов
Для работы nginx требует определенный набор файлов. Перед тем, как их копировать, создайте для них соответствующие каталоги. Предполагается, что ваш корневой каталог веб-документов nginx находится в /srv/http/www
.
# mkdir -p $JAIL/etc/nginx/logs # mkdir -p $JAIL/usr/{lib,bin} # mkdir -p $JAIL/usr/share/nginx # mkdir -p $JAIL/var/{log,lib}/nginx # mkdir -p $JAIL/www/cgi-bin # mkdir -p $JAIL/{run,tmp} # cd $JAIL; ln -s usr/lib lib # cd $JAIL; ln -s usr/lib lib64 # cd $JAIL/usr; ln -s lib lib64
Затем смонтируйте $JAIL/tmp
и $JAIL/run
как tmpfs-ы. Размер должен быть ограничен, чтобы быть уверенным, что атакующий не сможет занять всю доступную RAM.
# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M' # mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'
Для того, чтобы монтирование выполнялось автоматически при загрузке системы, добавьте следующие записи в /etc/fstab
:
/etc/fstab
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0 tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0
Сначала скопируйте простые файлы.
# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx # cp -r /usr/share/nginx/html/* $JAIL/www # cp /usr/bin/nginx $JAIL/usr/bin/ # cp -r /var/lib/nginx $JAIL/var/lib/nginx
Теперь скопируйте нужные библиотеки. Используйте ldd, чтобы отобразить их и скопируйте все файлы в правильное место. Копирование предпочтительнее, чем создание жестких ссылок, потому, что даже если атакующий получит права записи в файлы, они не смогут уничтожить или изменить системные файлы вне chroot-окружения.
$ ldd /usr/bin/nginx
linux-vdso.so.1 (0x00007fffc41fe000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000) libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000) libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000) /lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)
Для файлов, находящихся в /usr/lib
, вы можете воспользоваться следующей командой:
# cp $(ldd /usr/bin/nginx | grep /usr/lib | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib
А для ld-linux-x86-64.so
— следующей командой:
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib
Примечание: Не пытайтесь скопировать linux-vdso.so
— это не настоящая библиотека и ее не существует в /usr/lib
.
Копируйте другие необходимые библиотеки и системные файлы.
# cp /usr/lib/libnss_* $JAIL/usr/lib # cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc
Создайте файлы пользователей и групп в chroot-окружении. Таким образом, в chroot-окружении будут доступны только указанные пользователи, и никакая информация о пользователях из основной системы не будет доступна атакующему, получившему доступ в chroot-окружение.
$JAIL/etc/group
http:x:33: nobody:x:99:
$JAIL/etc/passwd
http:x:33:33:http:/:/bin/false nobody:x:99:99:nobody:/:/bin/false
$JAIL/etc/shadow
http:x:14871:::::: nobody:x:14871::::::
$JAIL/etc/gshadow
http::: nobody:::
# touch $JAIL/etc/shells # touch $JAIL/run/nginx.pid
Наконец, сделайте права доступа максимально ограниченными. Как можно больше должно принадлежать суперпользователю и быть закрытым для записи.
# chown -R root:root $JAIL/ # chown -R http:http $JAIL/www # chown -R http:http $JAIL/etc/nginx # chown -R http:http $JAIL/var/{log,lib}/nginx # chown http:http $JAIL/run/nginx.pid # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod -rw # find $JAIL/ -gid 0 -uid 0 -type d -print | xargs chmod +x # find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs chmod -x # find $JAIL/usr/bin -type f -print | xargs chmod ug+rx # find $JAIL/ -group http -user http -print | xargs chmod o-rwx # chmod +rw $JAIL/tmp # chmod +rw $JAIL/run
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx
Отредактируйте nginx.service для запуска chroot
Сделайте замещение файла юнита nginx.service
— тогда обновление nginx не изменит ваш файл .service.
Юнит systemd должен быть настроен так, чтобы запускать nginx в chroot от имени пользователя http и хранить pid-файл в chroot.
Примечание: Я не уверен, нужно ли хранить pid-файл в chroot.
/etc/systemd/system/nginx.service
[Unit] Description=A high performance web server and a reverse proxy server After=syslog.target network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit [Install] WantedBy=multi-user.target
Примечание: Обновление nginx с помощью pacman не обновит установленную в chroot копию. Вы должны вручную выполнять обновления, повторяя указанные выше шаги по переносу файлов. Не забудьте также обновить библиотеки, которые использует nginx.
Теперь вы можете спокойно удалить nginx, установленный вне chroot.
# pacman -Rsc nginx
Если вы не удалили nginx, установленный вне chroot, проверьте, что работающий процесс nginx — это действительно именно тот, что в находится chroot. Для этого посмотрите, куда указывает символическая ссылка /proc/PID/root
: она должна указывать на /srv/http
, а не на /
.
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done
Первые шаги по настройке и использованию nginx описаны в официальном руководстве для начинающих. Вы можете настроить сервер, редактируя файлы в /etc/nginx/
; главный файл настроек расположен в /etc/nginx/nginx.conf
.
/etc/nginx/nginx.conf
user http; worker_processes auto; worker_cpu_affinity auto; events { multi_accept on; worker_connections 1024; } http { charset utf-8; sendfile on; tcp_nopush on; tcp_nodelay on; server_tokens off; log_not_found off; types_hash_max_size 4096; client_max_body_size 16M; # MIME include mime.types; default_type application/octet-stream; # журналы access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log warn; # загрузка дополнительных файлов конфигурации include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }
Процессы и соединения
Вы должны выбрать подходящее значение для worker_processes
. Этот параметр определяет сколько одновременных соединений сможет принимать nginx и сколько процессоров он сможет при этом использовать. Как правило, это значение устанавливают равным количеству аппаратных потоков в системе. Однако, начиная с версий 1.3.8 и 1.2.5, в качестве значения worker_processes
вы также можете задать auto
, при этом nginx попытается автоматически подобрать оптимальное значение (источник).
Максимальное количество одновременных соединений, которое nginx сможет принимать, вычисляется как max_clients = worker_processes * worker_connections
.
Запуск под другим пользователем
/etc/nginx/nginx.conf
user пользователь [группа];
Если группа не указана, будет использоваться группа, совпадающая с указанным именем пользователя.
Совет: Можно запустить nginx без прав root
через systemd. Смотрите #Запуск без привилегий через systemd.
В этом примере сервер принимает запросы для двух доменов: domainname1.dom
и domainname2.dom
:
/etc/nginx/nginx.conf
... server { listen 80; listen [::]:80; server_name domainname1.dom; root /usr/share/nginx/domainname1.dom/html; location / { index index.php index.html index.htm; } } server { listen 80; listen [::]:80; server_name domainname2.dom; root /usr/share/nginx/domainname2.dom/html; ... }
Перезапустите службу nginx.service
, чтобы изменения вступили в силу.
Управление блоками server
Для удобства можно поместить разные блоки server
в разные файлы. Это также позволит включать и отключать отдельные сайты.
Создайте следующие каталоги:
# mkdir /etc/nginx/sites-available # mkdir /etc/nginx/sites-enabled
Внутри каталога sites-available
создайте файл, содержащий один или несколько блоков server:
/etc/nginx/sites-available/example.conf
server { listen 443 ssl http2; listen [::]:443 ssl http2; ... }
В файле nginx.conf
конце блока http
добавьте строку include sites-enabled/*;
:
/etc/nginx/nginx.conf
http { ... include sites-enabled/*; }
Чтобы включить сайт, в каталоге sites-enabled
создайте символическую ссылку на связанный с ним файл:
# ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/example.conf
А чтобы отключить сайт, удалите её:
# unlink /etc/nginx/sites-enabled/example.conf
Перезапустите службу nginx.service
или перезагрузите конфигурацию (reload), чтобы изменения вступили в силу.
предоставляет поддержку TLS/SSL и установлен по умолчанию на установленных Arch.
- Перед тем как настраивать SSL, вы можете почитать документацию ngx_http_ssl_module
- Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации. Есть плагин для получения доверенных SSL-сертификатов прямо из командной строки и автоматической настройки.
- На сайте Mozilla есть полезная статья про TLS, а также инструмент, помогающий составить безопасную конфигурацию.
Создайте секретный ключ и самоподписанный сертификат. Это подходит для большинства случаев, в которых не требуется CSR:
# cd /etc/nginx/ # openssl req -new -x509 -nodes -newkey rsa:4096 -keyout nginx.key -out nginx.crt -days 1095 # chmod 400 nginx.key # chmod 444 nginx.crt
Примечание: Опция -days является необязательной, а RSA keysize можно уменьшить до 2048 (по умолчанию).
Если же вам нужно создать CSR, то следуйте данным инструкциям по созданию ключа, вместо приведённых выше:
# openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out nginx.key # chmod 400 nginx.key # openssl req -new -sha256 -key nginx.key -out nginx.csr # openssl x509 -req -days 1095 -in nginx.csr -signkey nginx.key -out nginx.crt
В качестве отправкой точки для создания конфигурации TLS в /etc/nginx/nginx.conf
можно использовать генератор настроек SSL от Mozilla.
Перезапустите службу nginx
, чтобы изменения вступили в силу.
Чтобы сделать Apache-подобные адреса вида ~пользователь
, указывающие на пользовательские каталоги ~/public_html
, используйте подобную конфигурацию. (Примечание: если вы планируете использовать PHP, то связанный с ним location должен стоять первым.)
/etc/nginx/nginx.conf
... server { ... # Обработка файлов PHP в пользовательских каталогах, например http://example.com/~user/test.php location ~ ^/~(.+?)(/.+\.php)$ { alias /home/$1/public_html$2; fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi.conf; } # Пользовательские каталоги, например http://example.com/~user/ location ~ ^/~(.+?)(/.*)?$ { alias /home/$1/public_html$2; index index.html index.htm; autoindex on; } ... } ...
Подробнее о настройке PHP в nginx
смотрите в разделе #Реализация PHP.
Перезапустите службу nginx.service
, чтобы изменения вступили в силу.
FastCGI или просто FCGI — это протокол, являющийся интерфейсом между веб-сервером и интерактивными программами. Это модифицированный CGI (Common Gateway Interface), главная цель которого — снизить накладные расходы, связанные со взаимодействием веб сервера и CGI программ, тем самым позволяя серверу обрабатывать большее количество запросов одновременно.
Технология FastCGI встроена в nginx для работы со многими внешними инструментами, например, Perl, PHP и Python.
В качестве FastCGI-сервера для PHP рекомендуется использовать PHP-FPM.
Установите пакет и проверьте корректность настроек PHP.
Основным конфигурационным файлом PHP-FPM является /etc/php/php-fpm.conf
. Включите и запустите systemd службу php-fpm
.
- Если вы запускаете nginx под другим пользователем, убедитесь, что Unix-сокет PHP-FPM доступен этому пользователю, или используйте TCP-сокет.
- Если вы запускаете nginx в изолированном окружении (к примеру, chroot находится в
/srv/nginx-jail
, веб-документы расположены в/srv/nginx-jail/www
), то вы должны в/etc/php/php-fpm.conf
добавить опцииchroot /srv/nginx-jail
иlisten = /srv/nginx-jail/run/php-fpm/php-fpm.sock
внутри секции пула (по умолчанию это[www]
). Создайте каталог для файла сокета, если его нет. Более того, для модулей, которые динамически связаны с зависимостями, вам нужно будет скопировать эти зависимости в chroot (например, для php-imagick вам нужно будет скопировать в chroot библиотеки ImageMagick, но не сам imagick.so).
/etc/nginx/sites-available/example.conf
server { root /usr/share/nginx/html; location / { index index.html index.htm index.php; } location ~ \.php$ { # 404 try_files $fastcgi_script_name =404; # default fastcgi_params include fastcgi_params; # fastcgi settings fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; # fastcgi params fastcgi_param DOCUMENT_ROOT $realpath_root; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; #fastcgi_param PHP_ADMIN_VALUE "open_basedir=$base/:/usr/lib/php/:/tmp/"; } }
Если требуется обрабатывать другие расширения наряду с PHP (например .html и .htm):
location ~ [^/]\.(php|html|htm)(/|$) { ... }
Все расширения, обрабатываемые в php-fpm должны быть также явно добавлены в
/etc/php/php-fpm.d/www.conf
:
security.limit_extensions = .php .html .htm
Примечание: Аргумент fastcgi_pass
должен быть определен как TCP-сокет или сокет Unix выбранным FastCGI сервером в его конфигурационном файле. По умолчанию для php-fpm
используется сокет
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
Вы можете использовать также общий TCP-сокет:
fastcgi_pass 127.0.0.1:9000;
Однако, доменные сокеты Unix должны работать быстрее.
Совет: Если несколько блоков server
используют одну и ту же конфигурацию PHP-FPM, можно вынести общие настройки в отдельный файл для удобства, например php_fastcgi.conf
:
/etc/nginx/php_fastcgi.conf
location ~ \.php$ { # 404 try_files $fastcgi_script_name =404; # default fastcgi_params include fastcgi_params; # fastcgi settings ... }
И затем подключать этот файл в тех блоках server, в которых нужна обработка PHP:
/etc/nginx/sites-available/example.conf
server { server_name example.com; ... include /etc/nginx/php_fastcgi.conf; }
Перезапустите службы php-fpm
и nginx
после изменения настроек, чтобы изменения вступили в силу.
Чтобы проверить работу FastCGI, создайте новый файл .php внутри каталога веб-документов, содержащий:
<?php phpinfo(); ?>
При открытии файла в браузере должна отобразиться информационная страница с текущими настройками PHP.
Эта реализация нужна для CGI-приложений.
Установите . Настроить его можно путём редактирования юнита fcgiwrap.socket
. Включите и запустите fcgiwrap.socket
.
Несколько рабочих потоков
Если вы хотите породить несколько рабочих потоков, вам рекомендуется использовать AUR, который умеет отслеживать упавшие подпроцессы и перезапускать их. Вам нужно использовать spawn-fcgi
, чтобы создать доменный сокет Unix, так как multiwatch не может обрабатывать сокеты, созданные systemd, однако, fcgiwrap сама по себе не вызывает никаких проблем, если вызывается непосредственно из юнит-файла.
Сделайте замещение файла юнита fcgiwrap.service
(и юнита fcgiwrap.socket
, если он есть), и отредактируйте строку ExecStart
в соответствии с вашими нуждами. В примере показан юнит файл, который использует AUR. Убедитесь, что fcgiwrap.socket
не включен и не запущен, потому что он будет конфликтовать с этим юнитом:
/etc/systemd/system/fcgiwrap.service
[Unit] Description=Simple CGI Server After=nss-user-lookup.target [Service] ExecStartPre=/bin/rm -f /run/fcgiwrap.socket ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock PrivateTmp=true Restart=on-failure [Install] WantedBy=multi-user.target
Выберите подходящий -f 10
, чтобы изменить количество порождаемых подпроцессов.
Важно: Строка ExecStartPost
требуется из-за странного поведения, которое я наблюдаю при использовании опции -M 660
для spawn-fcgi
. Устанавливается неправильный режим. Может это баг?
В каталоге /etc/nginx
скопируйте файл fastcgi_params
в fcgiwrap_params
. В файле fcgiwrap_params
удалите строки, которые устанавливают SCRIPT_NAME
и DOCUMENT_ROOT
.
Внутри каждого блока server
CGI-приложения должен находиться вложенный блок location
:
location ~ \.cgi$ { include fcgiwrap_params; fastcgi_param DOCUMENT_ROOT /srv/www/cgi-bin/; fastcgi_param SCRIPT_NAME myscript.cgi; fastcgi_pass unix:/run/fcgiwrap.sock; }
Сокетом по умолчанию для fcgiwrap
является /run/fcgiwrap.sock
.
Вместо параметров DOCUMENT_ROOT
и SCRIPT_NAME
можно использовать более короткую альтернативу fastcgi_param SCRIPT_FILENAME /srv/www/cgi-bin/myscript.cgi
. При её использовании не понадобится копировать fastcgi_params
в fcgiwrap_params
и удалять строки DOCUMENT_ROOT
and SCRIPT_NAME
.
Важно: Если используются SCRIPT_NAME и DOCUMENT_ROOT, fcgiwrap будет отклонять любые другие fastcgi_param, установленные в nginx. Вы должны использовать SCRIPT_FILENAME для того, чтобы другие параметры (например, PATH_INFO) могли быть установлены через конфигурацию Nginx. Подробнее на GitHub.
Если вы продолжаете получать ошибку 502 - bad Gateway
, проверьте, передаёт ли ли ваше CGI-приложение mime-тип содержимого. Для html это должно быть Content-type: text/html
.
Если вы получаете ошибки 403, убедитесь, что CGI-файл доступен для чтения и выполнения пользователю http
и что каждая родительская папка доступна ему для чтения.
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Ошибка: Страница, которую вы ищете, временно недоступна. Пожалуйста, попробуйте позже. (502 Bad Gateway)
Это из-за того, что сервер FastCGI не запущен или используемый сокет имеет неправильные права доступа.
Попробуйте этот ответ, чтобы исправить 502 ошибку.
В Arch Linux, файлом настройки, упомянутом по ссылке выше, является /etc/php/php-fpm.conf
.
Ошибка: No input file specified
2. Другой причиной может быть то, что задан неправильный аргумент root
в секции location ~ \.php$
в nginx.conf
. Убедитесь, что root
указывает на ту же директорию, что и в location /
на том же сервере. Либо вы можете просто задать параметр root глобально, не переопределяя его в каких-либо location секциях.
3. Проверьте права доступа: например, пользователь/группа http
, биты разрешений 755
для каталогов и 644
для файлов. Имейте в виду, что все родительские каталоги тоже должны иметь корректные права доступа. Как массово изменить права всего дерева каталогов, описано в разделе Разрешения и атрибуты файлов#Массовое изменение разрешений.
4. Возможно, у вас не установлена переменная SCRIPT_FILENAME
, содержащая полный путь до ваших скриптов. Если конфигурация nginx (fastcgi_param SCRIPT_FILENAME
) правильная, то эта ошибка означает, что php не смог загрузить запрашиваемый скрипт. Часто это просто оказывается ошибкой прав доступа, и вы можете запустить php-cgi с правами root:
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi
или вам следует создать группу и пользователя для запуска php-cgi:
# groupadd www # useradd -g www www # chmod +w /srv/www/nginx/html # chown -R www:www /srv/www/nginx/html # spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi
5. Если вы используете chroot, убедитесь, что опция chroot
в файле /etc/php-fpm/php-fpm.d/www.conf
имеет корректное значение.
Warning: Could not build optimal types_hash
Если при запуске nginx.service
в журнале появляется такое сообщение:
[warn] 18872#18872: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
/etc/nginx/nginx.conf
http { types_hash_max_size 4096; server_names_hash_bucket_size 128; ... }
Cannot assign requested address
Полный текст ошибки в статусе юнита nginx.service
:
[emerg] 460#460: bind() to A.B.C.D:443 failed (99: Cannot assign requested address)
Установите пакет (основная ветка: новые возможности, обновления и исправления ошибок) или (стабильная ветка; только исправления серьёзных ошибок).
Рекомендуется использовать основную (mainline) ветку. Основная причина для использования стабильной ветки — возможная несовместимость со сторонними модулями или непреднамеренное появление ошибок при реализации новых функций.
Примечание: Все модули nginx, доступные в официальных репозиториях, в качестве зависимости требуют пакет nginx (а не nginx-mainline). Возможно, стоит просмотреть список модулей на наличие тех, которые вам могут понадобиться, прежде чем принимать решение о выборе между nginx и nginx-mainline. Модули для nginx-mainline можно найти в пользовательском репозитории Arch.
Если для обеспечения дополнительной безопасности вы хотите установить nginx в chroot-окружении, смотрите раздел #Установка в chroot.
Официальное определение root и alias
- root: устанавливает корневой каталог для запросов. Путь к файлу создается путем простого добавления URI к значению корневой директивы. В документе очень четко сказано, что root используется для определения корневого каталога запроса и фактического доступа Путь к файлу — это значение root + URI. Например, если вы обращаетесь к /i/top.gif, фактически возвращаемый файл будет /data/w3/i/top.gif. В документе также подчеркивается:Если вам нужно изменить URI, используйте псевдоним. На самом деле, root относительно легко понять.
location /i/ {
root /data/w3;
}
- alias: определяет замену для указанного местоположения.Если псевдоним используется внутри местоположения, определенного с помощью регулярного выражения, такое регулярное выражение должно содержать захваты, а псевдоним должен ссылаться на эти захваты. Как следует из названия, псевдоним — это псевдоним, который является псевдонимом местоположения, указанного командой alias.Если псевдоним используется в местоположении, определенном обычным пользователем, обычный должен содержать группы захвата, а псевдоним должен использовать эти группы захвата.。
Что сбивает с толку, так это конкретный контент, представленный этим псевдонимом. Возможны две ситуации:
Путь, определяемый местоположением, является каталогом
Определение следующее, посетите /i/top.gif, фактический файл возврата — /data/w3/images/top.gif, обратите внимание на это/i/ Частично заменено значением псевдонима
location /i/ {
alias /data/w3/images/;
}
Если путь расположения совпадает с частью после псевдонима, рекомендуется использовать root, а следующие два эквивалентны.
location /images/ {
alias /data/w3/images/;
}
location /images/ {
root /data/w3;
}
Путь, определяемый местоположением, является файлом
Как следует из названия, псевдоним файла по-прежнему должен быть файлом, поэтому псевдоним должен быть настроен как файл в это время. Как показано ниже
location /i/top.gif {
alias /data/w3/images/top.gif;
}
location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ {
alias /data/w3/images/$1;
}
Хорошо, вернемся к странному примеру в начале. Внимательно проанализируйте требования, этоНет необходимости изменять URI Подходит для рута, а способ написания очень простой. Если вам нужно использовать псевдоним, вы можете записать его, что более сложно.
location ~* ^/.+\.txt$ {
root /path/to/nginx/root/path/;
}
location ~* ^/(.+\.txt)$ {
alias /path/to/nginx/root/path/$1;
}
Теперь нетрудно понять формулировку заголовка. Первое посещение соответствует местоположению. После замены псевдонима соответствующим файлом возврата будет / data / w3 / txt /. Для Nginx, когда URL указывает на каталог и Если в конце не указан «/», Nginx автоматически выполнит внутреннее перенаправление 301 и автоматически добавит «/», и запрос станетhttp://test.com/1234.txt/, Доступ все еще может быть сопоставлен с местоположением, а /data/w3/txt/index.html не существует, поэтому возвращается 403. Следуйте этому ходу мыслей, посетитеhttp://test.com/1234.txt/1234.txt Вернет ли 200? Ответ очевиден — да.
Запустите/включите службу nginx.service
.
Советы и рекомендации
Запуск без привилегий через systemd
/etc/systemd/system/nginx.service.d/user.conf
[Service] User=пользователь Group=группа
Также можно запретить повышение привилегий:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... NoNewPrivileges=yes
Совет: Подробнее о повышающих безопасность опциях можно почитать в .
После этого нужно убедиться, что пользователь
имеет доступ ко всем необходимым ресурсам. Следуйте инструкциям, описанным в следующих разделах, и затем запустите nginx.
Совет: Аналогичные настройки можно применить и для сервера FastCGI.
По умолчанию Linux запрещает не-root процессам слушать порты ниже 1024. Можно использовать порт выше 1024:
/etc/nginx/nginx.conf
server { listen 8080; }
Совет: Если вы хотите, чтобы nginx всё равно был доступен на порту 80 или 443, можно настроить межсетевой экран для перенаправления запросов с порта 80 или 444 на порт, который использует nginx.
Или можно выдать процессу nginx привилегию CAP_NET_BIND_SERVICE, которая позволит ему использовать порты ниже 1024:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... CapabilityBoundingSet= CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities= AmbientCapabilities=CAP_NET_BIND_SERVICE
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... Environment=NGINX=3:4;
На каждый прослушиваемый порт будет приходиться один сокет, начиная с файлового дескриптора 3, поэтому в данном примере мы говорим nginx ожидать два сокета. Теперь создайте юнит nginx.socket
, указав, какие порты прослушивать:
/etc/systemd/system/nginx.socket
[Socket] ListenStream=0.0.0.0:80 ListenStream=0.0.0.0:443 After=network.target Requires=network.target [Install] WantedBy=sockets.target
По умолчанию использует /run/nginx.pid
. Нужно будет создать каталог, в котором пользователь будет иметь право записи, и перенастроить запись PID-файла туда. Например, можно использовать systemd-tmpfiles:
/etc/tmpfiles.d/nginx.conf
d /run/nginx 0775 root группа - -
# systemd-tmpfiles --create
Отредактируйте параметры службы, связанные с PID-файлом:
/etc/systemd/system/nginx.service.d/user.conf
[Service] ... PIDFile=/run/nginx/nginx.pid ExecStart= ExecStart=/usr/bin/nginx -g 'pid /run/nginx/nginx.pid; error_log stderr;' ExecReload= ExecReload=/usr/bin/nginx -s reload -g 'pid /run/nginx/nginx.pid;'
Некоторые каталоги в каталоге /var/lib/nginx
должны быть инициализированы путём запуска nginx от имени root
. Для этого не обязательно запускать весь сервер, nginx сделает это при проверке конфигурации. Так что просто запустите её — и готово.
Права каталогов и файлов журналов
После запуска проверки конфигурации будет создан журнал, принадлежащий root
. Удалите журналы в /var/log/nginx
.
Пользователю, от имени которого будет работать служба, nginx нужно выдать разрешение на запись в /var/log/nginx
. Для этого может понадобиться изменить права и/или владельца каталога.
Альтернативный скрипт для systemd
/etc/nginx/nginx.conf
user http; pid /run/nginx.pid;
Абсолютный путь к файлу настроек будет /srv/http/etc/nginx/nginx.conf
.
/etc/systemd/system/nginx.service
[Unit] Description=nginx (Chroot) After=syslog.target network.target [Service] Type=forking PIDFile=/srv/http/run/nginx.pid RootDirectory=/srv/http ExecStartPre=/usr/bin/nginx -t -c /etc/nginx/nginx.conf ExecStart=/usr/bin/nginx -c /etc/nginx/nginx.conf ExecReload=/usr/bin/nginx -c /etc/nginx/nginx.conf -s reload ExecStop=/usr/bin/nginx -c /etc/nginx/nginx.conf -s stop [Install] WantedBy=multi-user.target
Указывать стандартный путь к файлу настроек необязательно, nginx по умолчанию использует -c /etc/nginx/nginx.conf
, но, возможно, явное прописывание является хорошей идеей.
Также можно запускать только ExecStart
внутри chroot с параметром RootDirectoryStartOnly
заданным как yes
(смотрите ) или запустить его до того, как точка монтирования станет эффективной или будет доступен путь systemd (смотрите ).
/etc/systemd/system/nginx.path
[Unit] Description=nginx (Chroot) path [Path] PathExists=/srv/http/site/Public_html [Install] WantedBy=default.target
Включите созданный юнит nginx.path
и в юните nginx.service
измените строку WantedBy=default.target
на WantedBy=nginx.path
.
Параметр PIDFile
в файле юнита позволяет systemd следить за процессом (требуется абсолютный путь). Если это нежелательно, вы можете изменить тип на oneshot и удалить упоминание pid-файла из файла юнита.
AUR — это инструмент командной строки, используемый для улучшения и форматирования конфигурационных файлов nginx.
Более удобное управление заголовками
Nginx имеет довольно неинтуитивную систему управления HTTP-заголовками: они могут быть определены только в одном контексте, любые другие заголовки игнорируются. Чтобы исправить это, можно установить модуль headers-more-nginx.
Установите пакет . Модуль будет установлен в каталог /usr/lib/nginx/modules
.
Чтобы загрузить модуль, добавьте следующее в начало основного конфигурационного файла nginx.
/etc/nginx/nginx.conf
load_module "/usr/lib/nginx/modules/ngx_http_headers_more_filter_module.so"; ...