Linux nginx что такое

Руководство для начинающих

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется nginx.conf и расположен в каталоге /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx .

Запуск, остановка, перезагрузка конфигурации

Чтобы запустить nginx, нужно выполнить исполняемый файл. Когда nginx запущен, им можно управлять, вызывая исполняемый файл с параметром -s . Используйте следующий синтаксис:

Где сигнал может быть одним из нижеследующих:

• stop — быстрое завершение
• quit — плавное завершение
• reload — перезагрузка конфигурационного файла
• reopen — переоткрытие лог-файлов

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

Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

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

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

Посылать сигналы процессам nginx можно также средствами Unix, такими как утилита kill . В этом случае сигнал отправляется напрямую процессу с данным ID. ID главного процесса nginx записывается по умолчанию в файл nginx.pid в каталоге /usr/local/nginx/logs или /var/run . Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, который приведёт к плавному завершению nginx, нужно выполнить:

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

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).

Директивы, помещённые в конфигурационном файле вне любого контекста, считаются находящимися в контексте main. Директивы events и http располагаются в контексте main , server — в http , а location — в server .

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Одна из важных задач конфигурации nginx — раздача файлов, таких как изображения или статические HTML-страницы. Рассмотрим пример, в котором в зависимости от запроса файлы будут раздаваться из разных локальных каталогов: /data/www , который содержит HTML-файлы, и /data/images , содержащий файлы с изображениями. Для этого потребуется отредактировать конфигурационный файл и настроить блок server внутри блока http с двумя блоками location.

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

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

В общем случае конфигурационный файл может содержать несколько блоков server , различаемых по портам, на которых они слушают, и по имени сервера. Определив, какой server будет обрабатывать запрос, nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив location , определённых внутри блока server .

В блок server добавьте блок location следующего вида:

Этот блок location задаёт “ / ” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root, то есть, в данном случае, к /data/www , получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location , nginx выбирает блок с самым длинным префиксом. В блоке location выше указан самый короткий префикс, длины один, и поэтому этот блок будет использован, только если не будет совпадения ни с одним из остальных блоков location .

Далее, добавьте второй блок location :

Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).

Итоговая конфигурация блока server должна выглядеть следующим образом:

Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу http://localhost/ . В ответ на запросы, URI которых начинаются с /images/ , сервер будет отправлять файлы из каталога /data/images . Например, на запрос http://localhost/images/example.png nginx отправит в ответ файл /data/images/example.png . Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на /images/ , будут отображены на каталог /data/www . Например, в результате запроса http://localhost/some/example.html в ответ будет отправлен файл /data/www/some/example.html .

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов access.log и error.log из каталога /usr/local/nginx/logs или /var/log/nginx .

Настройка простого прокси-сервера

Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.

Мы настроим базовый прокси-сервер, который будет обслуживать запросы изображений из локального каталога и отправлять все остальные запросы на проксируемый сервер. В этом примере оба сервера будут работать в рамках одного экземпляра nginx.

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

Это будет простой сервер, слушающий на порту 8080 (ранее директива listen не указывалась, потому что использовался стандартный порт 80) и отображающий все запросы на каталог /data/up1 в локальной файловой системе. Создайте этот каталог и положите в него файл index.html . Обратите внимание, что директива root помещена в контекст server . Такая директива root будет использована, когда директива location , выбранная для выполнения запроса, не содержит собственной директивы root .

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):

Мы изменим второй блок location , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:

Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на .gif , .jpg или .png . Регулярному выражению должен предшествовать символ

. Соответствующие запросы будут отображены на каталог /data/images .

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

Итоговая конфигурация прокси-сервера выглядит следующим образом:

Этот сервер будет фильтровать запросы, оканчивающиеся на .gif , .jpg или .png , и отображать их на каталог /data/images (добавлением URI к параметру директивы root ) и перенаправлять все остальные запросы на проксируемый сервер, сконфигурированный выше.

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.

Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы proxy_pass , и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу localhost:9000 . Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000 . В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а в параметре QUERY_STRING передаются параметры запроса. Получится следующая конфигурация:

Таким образом будет настроен сервер, который будет перенаправлять все запросы, кроме запросов статических изображений, на проксируемый сервер, работающий по адресу localhost:9000 , по протоколу FastCGI.

Источник

nginx

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 22.38% самых нагруженных сайтов в августе 2021 года. Вот некоторые примеры успешного внедрения nginx (тексты на английском языке): Dropbox, Netflix, WordPress.com, FastMail.FM.

Исходные тексты и документация распространяются под BSD-подобной лицензией из 2 пунктов.

Коммерческая поддержка осуществляется компанией Nginx, Inc.

Основная функциональность HTTP-сервера

Другие возможности HTTP-сервера

Функциональность почтового прокси-сервера

• Перенаправление пользователя на IMAP- или POP3-сервер с использованием внешнего HTTP-сервера аутентификации;
• Проверка пользователя с помощью внешнего HTTP-сервера аутентификации и перенаправление соединения на внутренний SMTP-сервер;
• Методы аутентификации:
  • POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
• Поддержка SSL;
• Поддержка STARTTLS и STLS.

Функциональность TCP/UDP прокси-сервера

Архитектура и масштабируемость

• Один главный и несколько рабочих процессов, рабочие процессы работают под непривилегированным пользователем;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Поддержка kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), /dev/poll event ports select и poll;
• Использование возможностей, предоставляемых kqueue, таких как EV_CLEAR, EV_DISABLE (для временного выключения события), NOTE_LOWAT, EV_EOF, число доступных данных, коды ошибок;
• Использование возможностей, предоставляемых epoll, таких как EPOLLRDHUP (Linux 2.6.17+, glibc 2.8+) и EPOLLEXCLUSIVE (Linux 4.5+, glibc 2.24+);
• Поддержка sendfile (FreeBSD 3.1+, Linux 2.2+, macOS 10.5+), sendfile64 (Linux 2.4.21+) и sendfilev
• Поддержка файлового AIO (FreeBSD 4.3+, Linux 2.6.22+);
• Поддержка DIRECTIO (FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, macOS);
• Поддержка accept-фильтров (FreeBSD 4.1+, NetBSD 5.0+) и TCP_DEFER_ACCEPT (Linux 2.4+);
• На неактивных HTTP keep-alive соединений расходуется около 2.5M памяти;
• Минимум операций копирования данных.

Протестированные ОС и платформы

• FreeBSD 3 — 12 / i386; FreeBSD 5 — 12 / amd64; FreeBSD 11 / ppc; FreeBSD 12 / ppc64;
• Linux 2.2 — 4 / i386; Linux 2.6 — 5 / amd64; Linux 3 — 4 / armv6l, armv7l, aarch64, ppc64le;
• Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; Solaris 11 / x86;
• AIX 7.1 / powerpc;
• HP-UX 11.31 / ia64;
• macOS / ppc, i386, x86_64;
• Windows XP, Windows Server 2003, Windows 7, Windows 10.

Источник

nginx (Русский)

nginx (произносится «э́нжин-э́кс» или «э́нжин-и́кс») — это свободный высокопроизводительный HTTP-сервер с открытым исходным кодом, а также обратный прокси и IMAP/POP3 прокси-сервер, написанный Игорем Сысоевым в 2005 году. Согласно April 2015 Web Server Survey, nginx используется на 14,48% доменов всего мира, в то время как Apache используется примерно на 38,39% доменов. nginx получил широкое распространение благодаря своей стабильности, богатой функциональности, простой настройке и низкому потреблению ресурсов.

Contents

Установка

Для установки Ruby on Rails с nginx смотрите раздел Ruby on Rails#The Perfect Rails Setup.

Если для обеспечения дополнительной безопасности вы хотите установить nginx в chroot-окружении, смотрите раздел #Установка в chroot.

Запуск

Страница по умолчанию, доступная по адресу http://127.0.0.1 располагается в /usr/share/nginx/html/index.html .

Настройка

Первые шаги по настройке и использованию nginx описаны в руководстве Beginner’s Guide. Вы можете настроить сервер, редактируя файлы в /etc/nginx/ ; главный файл настроек расположен в /etc/nginx/nginx.conf .

Более подробную информацию можно прочитать на странице Nginx Configuration Examples и в официальной документации.

Приведенные далее примеры покрывают большинство типичных потребностей. Предполагается, что вы используете стандартное место расположения веб-документов ( /usr/share/nginx/html ). Если это не так, замените путь на свой.

Основные настройки

Процессы и соединения

Вы должны выбрать подходящее значение для worker_processes . Этот параметр определяет сколько одновременных соединений сможет принимать nginx и сколько процессоров он сможет при этом использовать. Как правило, это значение устанавливают равным количеству аппаратных потоков в системе. Однако, начиная с версий 1.3.8 и 1.2.5, в качестве значения worker_processes вы также можете задать auto , при этом nginx попытается автоматически подобрать оптимальное значение (источник).

Максимальное количество одновременных соединений, которое nginx сможет принимать, вычисляется как max_clients = worker_processes * worker_connections .

Запуск под другим пользователем

По умолчанию nginx выполняется от имени пользователя nobody. Чтобы запустить его от имени другого пользователя, измените строку user в nginx.conf :

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

Блоки server

Посредством добавления блоков server в файл настроек возможно обслуживать сразу несколько доменов одновременно. Эти блоки работают аналогично «VirtualHosts» в Apache.

В этом примере сервер принимает запросы для двух доменов: domainname1.dom и domainname2.dom :

Перезапустите службу nginx , чтобы изменения вступили в силу.

Следует настроить DNS-сервер, например BIND или dnsmasq, чтобы у подключающихся клиентов эти доменные имена разрешались в IP-адрес сервера.

А пока вы можете просто добавить их в ваш файл /etc/hosts , заменив 192.168.0.101 на фактический IP-адрес сервера:

TLS/SSL

openssl предоставляет поддержку TLS/SSL и установлен по умолчанию на установленных Arch.

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

Если же вам нужно создать CSR, то следуйте данным инструкциям по созданию ключа, вместо приведённых выше:

Пример nginx.conf , использующего SSL:

Перезапустите службу nginx , чтобы изменения вступили в силу.

FastCGI

FastCGI или просто FCGI — это протокол, являющийся интерфейсом между веб-сервером и интерактивными программами. Это модифицированный CGI (Common Gateway Interface), главная цель которого — снизить накладные расходы, связанные со взаимодействием веб сервера и CGI программ, тем самым позволяя серверу обрабатывать большее количество запросов одновременно.

Технология FastCGI встроена в nginx для работы со многими внешними инструментами, например, Perl, PHP и Python.

Реализация PHP

В качестве FastCGI-сервера для PHP рекомендуется использовать PHP-FPM.

Настройка PHP

Опция open_basedir в /etc/php/php.ini должна содержать список всех каталогов, с файлами PHP, которые должны быть доступны серверу. Например, для /usr/share/nginx/html/ и /usr/share/webapps/ :

После этого настройте нужные вам модули. Например, для использования sqlite3 нужно установить php-sqlite . Затем включите этот модуль в файле /etc/php/php.ini , раскомментировав следующую строку:

Основным конфигурационным файлом PHP-FPM является /etc/php/php-fpm.conf . Включите и запустите systemd службу php-fpm .

MariaDB

Настройте MySQL/MariaDB как описано в MariaDB.

Раскомментируйте хотя бы одну из следующих строк в /etc/php/php.ini :

Вы можете добавить менее привилегированных MySQL пользователей для ваших веб скриптов. Вы можете также захотеть отредактировать /etc/mysql/my.cnf и раскомментировать строку skip-networking , чтобы MySQL сервер был доступен только из localhost. Вы должны перезапустить MySQL, чтобы изменения вступили в силу.

Настройка nginx

Добавление к основной конфигурации

Внутри каждого блока server , который обслуживает веб-приложение PHP должен находиться блок location :

Если требуется обрабатывать другие расширения наряду с PHP (например .html и .htm):

Все расширения, обрабатываемые в php-fpm должны быть также явно добавлены в /etc/php/php-fpm.conf :

Вы можете использовать также общий TCP-сокет:

Однако, доменные сокеты Unix должны работать быстрее.

Пример, показанный ниже, является копией рабочей конфигурации. Заметьте, что в этом примере путь к root определен непосредственно в server , а не внутри location (как это сделано в конфигурации по умолчанию).

Управление несколькими блоками (опционально)

Если вы добавляете однотипную конфигурацию для PHP сразу во множество блоков server , может оказаться удобнее использовать для этого внешний файл:

Теперь включите файл php.conf в каждый из блоков server :

Проверка конфигурации

Перезапустите службы php-fpm и nginx после изменения настроек, чтобы изменения вступили в силу.

Чтобы проверить работу FastCGI, создайте новый файл .php внутри каталога веб-документов, содержащий:

При открытии файла в браузере должна отобразиться информационная страница с текущими настройками PHP.

Смотрите #Решение проблем, если новая конфигурация не работает.

Реализация CGI

Эта реализация нужна для CGI-приложений.

fcgiwrap

Установите fcgiwrap . Файл настроек находится в /usr/lib/systemd/system/fcgiwrap.socket . Включите и запустите fcgiwrap.socket .

Несколько рабочих потоков

Если вы хотите породить несколько рабочих потоков, вам рекомендуется использовать multiwatch AUR , который умеет отслеживать упавшие подпроцессы и перезапускать их. Вам нужно использовать spawn-fcgi , чтобы создать доменный сокет Unix, так как multiwatch не может обрабатывать сокеты, созданные systemd, однако, fcgiwrap сама по себе не вызывает никаких проблем, если вызывается непосредственно из юнит-файла.

Скопируйте юнит-файл из /usr/lib/systemd/system/fcgiwrap.service в /etc/systemd/system/fcgiwrap.service (и юнит fcgiwrap.socket , если он есть), и отредактируйте строку ExecStart в соответствии с вашими нуждами. В примере показан юнит файл, который использует multiwatch AUR . Убедитесь, что fcgiwrap.socket не включен и не запущен, потому что он будет конфликтовать с этим юнитом:

Выберите подходящий -f 10 , чтобы изменить количество порождаемых подпроцессов.

Настройка nginx

Внутри каждого блока server CGI-приложения должен находиться вложенный блок location :

Стандартным сокетом для fcgiwrap является /run/fcgiwrap.sock .

Установка в 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 .

Создание необходимых каталогов

Для работы nginx требует определенный набор файлов. Перед тем, как их копировать, создайте для них соответствующие каталоги. Предполагается, что ваш корневой каталог веб-документов nginx находится в /srv/http/www .

Затем смонтируйте $JAIL/tmp и $JAIL/run как tmpfs-ы. Размер должен быть ограничен, чтобы быть уверенным, что атакующий не сможет занять всю доступную RAM.

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

Заполнение chroot

Сначала скопируйте простые файлы.

Теперь скопируйте нужные библиотеки. Используйте ldd, чтобы отобразить их и скопируйте все файлы в правильное место. Копирование предпочтительнее, чем создание жестких ссылок, потому, что даже если атакующий получит права записи в файлы, они не смогут уничтожить или изменить системные файлы вне chroot-окружения.

Для файлов, находящихся в /usr/lib , вы можете воспользоваться следующей командой:

Копируйте другие необходимые библиотеки и системные файлы.

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

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

Если ваш сервер будет принимать входящие соединения на 80 порту (или любому другому порту в диапазоне 891), дайте исполнителю chroot права на соединение с этими портами без необходимости прав суперпользователя.

Отредактируйте nginx.service для запуска chroot

Перед редактированием юнит-файла nginx.service неплохо будет скопировать его в /etc/systemd/system/ , так как там юнит файлы имеют приоритет над теми, что в /usr/lib/systemd/system/ . Это значит, что обновление nginx не перезапишет ваш собственный файл .service.

Юнит systemd должен быть настроен так, чтобы запускать nginx в chroot от имени пользователя http и хранить pid-файл в chroot.

Теперь вы можете спокойно удалить установленный вне chroot nginx.

Если вы не удалили установленный вне chroot nginx, проверьте, что работающий процесс nginx — это действительно именно тот, что в находится chroot. Для этого посмотрите, куда указывает символическая ссылка /proc//root : она должен указывать на /srv/http , а не на / .

Решение проблем

Валидация конфигурации

При доступе с локального IP перенаправляется на localhost

В файле /etc/nginx/nginx.conf найдите незакомментированную строку server_name localhost (без # вначале) и добавьте под ней:

По умолчанию, nginx перенаправляет любые запросы на указанное в опции server_name имя.

Ошибка: Страница, которую вы ищите, временно недоступна. Пожалуйста, попробуйте позже. (502 Bad Gateway)

Это из-за того, что сервер FastCGI не запущен или используемый сокет имеет неправильные права доступа.

Попробуйте этот ответ, чтобы исправить 502 ошибку.

В Archlinux, файлом настройки, упомянутом по ссылке выше, является /etc/php/php-fpm.conf .

При определённых обстоятельствах, fcgiwrap.socket может не запуститься правильно и создать бесполезный сокет юникс домена /run/fcgiwrap.sock .

Попробуйте остановить службу fcgiwrap.socket и удалить файл доменного юникс сокета по умолчанию.

Затем запустите fcgiwrap.service вместо него. Проверьте статус fcgiwrap.service и нового доменного юникс сокета /run/fcgiwrap.sock :

Если это сработало, отключите fcgiwrap.socket и включите fcgiwrap.service .

Ошибка: No input file specified

1. Скорее всего у вас не установлена переменная SCRIPT_FILENAME , содержащая полный путь до ваших скриптов. Если конфигурация nginx ( fastcgi_param SCRIPT_FILENAME ) правильная, то эта ошибка означает, что php не смог загрузить запрашиваемый скрипт. Часто это просто оказывается ошибкой прав доступа, и вы можете запустить php-cgi с правами root:

или вам следует создать группу и пользователя для запуска php-cgi:

2. Другой причиной может быть то, что задан неправильный аргумент root в секции location

\.php$ в nginx.conf . Убедитесь, что root указывает на ту же директорию, что и в location / на том же сервере. Либо вы можете просто задать абсолютный путь до корневого каталога, не определяя его в каких-либо location секциях.

3. Убедитесь, что переменная open_basedir в /etc/php/php.ini также содержит путь, который соответствует аргументу root в nginx.conf .

4. Также обратите внимание, что не только php-скрипты должны иметь права на чтение, но также и вся структура каталогов должна иметь право на исполнение, чтобы пользователь PHP мог добраться до этого каталога.

Ошибка: «File not found» в браузере или «Primary script unknown» в лог-файле

Убедитесь, что вы определили root и index в ваших директивах server или location :

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

Ошибка: chroot: ‘/usr/sbin/nginx’ No such file or directory

Если у вас возникает эта ошибка при запуске демона nginx в chroot, скорее всего, это происходит из-за отсутствующих 64-битных библиотек в изолированном окружении.

Если ваш chroot запущен в /srv/http , вам нужно добавить требуемые 64-битные библиотеки.

Сначала создайте каталоги:

Затем скопируйте требуемые 64-битные библиотеки, перечисленные командой ldd /usr/sbin/nginx в /srv/http/usr/lib64 .

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

Альтернативный скрипт для systemd

На чистой systemd вы можете получить преимущества при использовании связки chroot и systemd [1]. На основе заданных пользователя и группы и pid:

абсолютным путем к файлу является /srv/http/etc/nginx/nginx.conf .3

Нет необходимости задавать расположение по умолчанию, nginx по умолчанию загружает -c /etc/nginx/nginx.conf , хотя вообще это хорошая идея.

Также можно запускать только ExecStart как chroot с параметром RootDirectoryStartOnly заданным как yes man systemd service или запустить его до точки монтирования в качестве эффективного или пути systemd.

Включите nginx.path и замените WantedBy=default.target на WantedBy=nginx.path in /etc/systemd/system/nginx.service .

Ссылка PIDFile в файле юнита позволяет systemd следить за процессом (необходим абсолютный путь). Если это нежелательно, вы можете изменить тип one-shoot по умолчанию и удалить ссылку из файла юнита.

Источник