Где находится файл конфигурации nginx

Обновлено: 21.11.2024

Работа на клиентском сервере, на котором установлены две разные версии nginx. Я думаю, что один из них был установлен с помощью диспетчера пакетов brew (это коробка osx), а другой, похоже, был скомпилирован и установлен с упакованным Makefile nginx. Я искал все файлы nginx.conf на сервере, но ни один из этих файлов не определяет параметры, которые фактически использует nginx, когда я запускаю его на сервере. Где находится неизвестный мне файл nginx.conf?

6 ответов 6

Запуск nginx -t через вашу командную строку выдаст тест и добавит выходные данные с путем к файлу в файл конфигурации (либо с сообщением об ошибке, либо с сообщением об успешном завершении).

И nginx -t, и nginx -V распечатают путь к файлу конфигурации nginx по умолчанию.

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

Даже если вы загрузили какой-либо другой файл конфигурации, они все равно распечатают значение по умолчанию.

ps aux покажет вам текущий загруженный файл конфигурации nginx.

Чтобы вы могли получить файл конфигурации, например:

сообщит вам путь к используемому nginx

РЕДАКТИРОВАНИЕ (18 января 2017 г.)

Благодаря комментарию Уилла Палмера к этому ответу я добавил следующее.

Если вы установили nginx через менеджер пакетов, например HomeBrew.

может не дать вам ТОЧНЫЙ путь к используемому nginx. Однако вы можете найти его с помощью

и, как упомянул @Daniel Li

вы можете получить конфигурацию nginx с помощью его метода

в качестве альтернативы вы можете использовать это:

"который" работает в большинстве систем на базе Unix. Я просто набрал его в Ubuntu, чтобы убедиться, что не сошёл с ума.

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

Все остальные ответы полезны, но они могут не помочь вам, если nginx не находится в PATH, поэтому при попытке запустить nginx вы получаете команду, не найденную:

У меня есть nginx 1.2.1 на Debian 7 Wheezy, исполняемый файл nginx отсутствует в PATH , поэтому мне нужно было сначала найти его. Он уже был запущен, поэтому с помощью ps aux | grep nginx Я обнаружил, что он находится в /usr/sbin/nginx , поэтому мне нужно было запустить /usr/sbin/nginx -t .

Если вы хотите использовать файл конфигурации не по умолчанию (то есть не /etc/nginx/nginx.conf ), запустите его с параметром -c: /usr/sbin/nginx -c -t .

Возможно, вам также потребуется запустить его от имени пользователя root , иначе у 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. Используйте следующий синтаксис:

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

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

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

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

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

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

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

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

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

Обслуживание статического контента

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

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

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

Добавьте следующий блок местоположения в блок сервера:

В этом блоке местоположения указан префикс «/» по сравнению с URI из запроса. Для совпадающих запросов к пути, указанному в корневой директиве, то есть к /data/www, будет добавлен URI для формирования пути к запрашиваемому файлу в локальной файловой системе. Если есть несколько совпадающих блоков местоположения, nginx выбирает блок с самым длинным префиксом. Вышеприведенный блок местоположений предоставляет самый короткий префикс длины один, поэтому этот блок будет использоваться только в том случае, если все остальные блоки местоположений не обеспечивают совпадения.

Далее добавьте второй блок местоположения:

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

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

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

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

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

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

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

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

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

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

Параметр представляет собой регулярное выражение, соответствующее всем URI, оканчивающимся на .jpg , .jpg или .jpg . Перед регулярным выражением должен стоять ~. Соответствующие запросы будут сопоставлены с каталогом /data/images.

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

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

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

Чтобы применить новую конфигурацию, отправьте сигнал перезагрузки в 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 используется для передачи параметров запроса. В результате конфигурация будет следующей:

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

NGINX – это веб-сервер, предназначенный для случаев использования с большими объемами трафика. Это популярное, легкое и высокопроизводительное решение.

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

Этот веб-сервер передает динамический контент на FastCGI, CGI или альтернативные серверы (включая Apache), прежде чем он будет отправлен обратно в NGINX для доставки клиентам.

В этом руководстве по настройке NGINX мы рассмотрим основы NGINX, чтобы помочь вам понять, как он работает и какие преимущества он предлагает.

Конфигурация NGINX: понимание директив

Каждый файл конфигурации NGINX находится в каталоге /etc/nginx/, а основной файл конфигурации находится в /etc/nginx/nginx.conf.

Параметры конфигурации NGINX известны как «директивы»: они организованы в группы, которые взаимозаменяемо называются блоками или контекстами .

Ниже мы включили сокращенную копию файла /etc/nginx/nginx.conf, входящего в состав установок из репозиториев NGINX. Этот файл начинается с четырех директив:

пользователь

рабочие_процессы

журнал_ошибок

идентификатор

Они существуют вне какого-либо конкретного контекста или блока, и говорят, что они находятся в основном контексте.

error_log /var/log/nginx/error.log предупреждение;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

журнал доступа /var/log/nginx/access.log основной;

Что такое серверные блоки?

При установке NGINX из репозиториев Ubuntu или Debian строка будет выглядеть так: include /etc/nginx/sites-enabled/*;. Папка ../sites-enabled/ будет содержать символические ссылки на файлы конфигурации сайта, расположенные в /etc/nginx/sites-available/. Вы можете отключить сайты в пределах site-available, если уберете символическую ссылку на site-enabled.

В зависимости от источника установки иллюстративный файл конфигурации можно найти в /etc/nginx/conf.d/default.conf или etc/nginx/sites-enabled/default.

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

прослушать 80 default_server;

прослушать [::]:80 default_server;

try_files $uri /index.html;

Что такое прослушивающие порты?

Аргумент default_server означает, что этот виртуальный хост будет отвечать на запросы через порт 80, которые не соответствуют оператору прослушивания отдельного виртуального хоста. Что касается второго оператора, то он будет прослушивать IPv6 и демонстрировать аналогичное поведение.

Что такое виртуальный хостинг на основе имени?

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

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

Обрабатывать запросы для всех доменных имен, начинающихся с example.:

Недоменные имена хостов могут оказаться полезными, если ваш сервер находится в локальной сети или вы знаете всех клиентов, которые могут отправлять запросы на сервер. Сюда входят внешние прокси-серверы с записями /etc/hosts, настроенными для IP-адреса, который прослушивает NGINX.

Что такое блоки местоположения?

Давайте рассмотрим несколько примеров:

В NGINX запросы всегда выполняются с наиболее точным совпадением:

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

Если за директивами местоположения следует символ ~ (тильда), NGINX будет выполнять сопоставление с регулярным выражением, которое всегда чувствительно к регистру.

Например, IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php — нет.

Во втором примере регулярное выражение ^/BlogPlanet(/|/index\.php)$ < >соответствует запросам для /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/ или /blogplanet/index.php. NGINX использует Perl-совместимые регулярные выражения (PCRE).

Что делать, если вы предпочитаете, чтобы совпадения не учитывали регистр? Ну, вы должны использовать тильду, за которой следует звездочка: ~*. Вы можете видеть, что приведенные выше примеры определяют, что NGINX должен обрабатывать запросы, оканчивающиеся на определенное расширение файла: первый пример определяет, что файлы, оканчивающиеся на .pl, PL, .cgi, .perl, .Perl, .prl и .PrL (а также как и другие) будут соответствовать запросу.

Добавляя знак вставки и тильду (^~) к директивам местоположения, вы сообщаете NGINX, что в случае совпадения с определенной строкой он должен прекратить поиск более конкретных совпадений и вместо этого использовать эти директивы здесь.

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

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

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

Обработка директив будет осуществляться в следующем порядке:

  1. Сначала будут обрабатываться точные совпадения строк: NGINX прекращает поиск, если найдено совпадение, и выполняет запрос.
  2. Все остальные литеральные строковые директивы будут обработаны далее. NGINX остановится и выполнит запрос, если найдет совпадение с использованием аргумента ^~. В противном случае NGINX продолжит обработку директив местоположения.
  3. Каждая директива местоположения с регулярным выражением (~ и ~*) будет обработана следующей. Если регулярное выражение соответствует запросу, NGINX завершит поиск и выполнит запрос.
  4. Наконец, если совпадающих регулярных выражений нет, будет использоваться наиболее точное совпадение буквальной строки.

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

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

Как использовать корневой каталог и индекс местоположения

Настройка местоположения — это еще одна переменная с собственным блоком аргументов.

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

индекс index.html index.htm;

В этом примере мы видим, что корень документа находится в каталоге html/. Под префиксом установки NGINX по умолчанию полный путь к местоположению — /etc/nginx/html/.

Возвращает: NGINX попытается обслужить файл, найденный в /etc/nginx/html/blog/includes/style.css

Обратите внимание:

По желанию можно использовать абсолютные пути для корневой директивы. Переменная index сообщает NGINX, какой файл он должен обслуживать, если не указано ни одного.

Так, например:

Возврат: NGINX попытается обслужить файл, найденный в /etc/nginx/html/index.html.

Если для директивы index указано количество файлов, список будет обработан по порядку, и NGINX выполнит запрос с первым обнаруженным существующим файлом. Если index.html не может быть расположен в соответствующем каталоге, вместо него будет использоваться index.htm. Сообщение 404 будет доставлено в том случае, если их вообще не существует.

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

индекс index.html index.htm;

Здесь мы видим, что второй блок location обрабатывает все запросы ресурсов, оканчивающихся на расширение .pl, и указывает для них обработчик fastcgi. В противном случае NGINX будет использовать первую директиву location.

Давайте рассмотрим, что происходит во время нескольких примеров запросов:

На этом наше руководство по настройке NGINX заканчивается. Мы надеемся, что это поможет вам быстро приступить к работе и настроить его!

Понимать основные элементы файла конфигурации NGINX или NGINX Plus, включая директивы и контексты.

NGINX и NGINX Plus похожи на другие сервисы тем, что используют текстовый файл конфигурации, записанный в определенном формате. По умолчанию файл называется nginx.conf и для NGINX Plus размещается в каталоге /etc/nginx. (Для NGINX с открытым исходным кодом расположение зависит от системы пакетов, используемой для установки NGINX и операционной системы. Обычно это /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx. .)

Директивы

Файл конфигурации состоит из директив и их параметров. Каждая простая (однострочная) директива заканчивается точкой с запятой. Другие директивы действуют как «контейнеры», которые группируют связанные директивы, заключая их в фигурные скобки ( <> ); их часто называют блоками. Вот несколько примеров простых директив.

Файлы конфигурации для конкретных функций

Чтобы упростить обслуживание конфигурации, мы рекомендуем разделить ее на набор файлов для конкретных функций, хранящихся в каталоге /etc/nginx/conf.d, и использовать директиву include в основном файле nginx.conf для ссылаться на содержимое файлов, относящихся к конкретным функциям.

Контексты

Несколько директив верхнего уровня, называемых контекстами, объединяют директивы, применимые к разным типам трафика:

Директивы, размещенные вне этих контекстов, называются основными контекстами.

Виртуальные серверы

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

Для почты и трафика TCP/UDP (контексты почты и потока) директивы сервера управляют обработкой трафика, поступающего на определенный порт TCP или сокет UNIX.

Пример файла конфигурации с несколькими контекстами

Следующая конфигурация иллюстрирует использование контекстов.

Наследование

Как правило, дочерний контекст, содержащийся в другом контексте (своем родительском), наследует настройки директив, включенных на родительском уровне. Некоторые директивы могут появляться в нескольких контекстах, и в этом случае вы можете переопределить настройку, унаследованную от родителя, включив директиву в дочерний контекст. Пример см. в директиве proxy_set_header.

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

Чтобы изменения в файле конфигурации вступили в силу, его необходимо перезагрузить. Вы можете либо перезапустить процесс nginx, либо отправить сигнал перезагрузки для обновления конфигурации, не прерывая обработку текущих запросов. Подробнее см. в разделе Управление процессами NGINX во время выполнения.

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

Энтони Хеддингс

Энтони Хеддингс
Писатель

Энтони Хеддингс (Anthony Heddings) – штатный облачный инженер LifeSavvy Media, технический писатель, программист и эксперт по платформе Amazon AWS. Он написал сотни статей для How-To Geek и CloudSavvy IT, которые были прочитаны миллионы раз. Подробнее.

NGINX

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

Обычные места

Расположение папки конфигурации nginx по умолчанию:

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

В этом каталоге у вас есть несколько файлов, независимо от того, где находится основная папка на вашем диске:

Если у вас нет папки в /etc/nginx/ , ваша установка могла создать ее где-то еще, что вполне вероятно, если вы скомпилировали ее самостоятельно. В этом случае он, вероятно, установлен в папку /usr/local/ в одном из следующих корневых каталогов:

  • /usr/local/nginx/ , наиболее вероятный сценарий, если вы скомпилировали из исходного кода
  • /usr/local/nginx/conf/
  • /usr/local/etc/nginx/

Если его здесь нет, возможно, он работает в контейнерной среде или что-то пошло не так во время установки. Если это так, вам нужно найти его вручную.

Как найти папку конфигурации вручную

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

Команда проста:

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

Если эта функция не работает, у вас вообще не установлен nginx (или его нет в системном PATH).

Местоположения корня документа

Вы можете изменить корень документа на что угодно, так что это не так важно, как расположение конфигурации. Расположение по умолчанию должно быть:

  • /var/www/html/ в системах на основе Debian, таких как Ubuntu
  • /usr/share/nginx/html/ в системах на основе RHEL, таких как CentOS

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

  • › Следует ли вам заботиться о подключении IPv6 к вашему веб-серверу?
  • › Как развернуть сервер GitLab с помощью Docker
  • › Что будет в React 18?
  • › CloudFoundry или Kubernetes: какую облачную платформу выбрать?
  • › Как использовать Docker для упаковки приложений CLI
  • › Как развернуть веб-сервер Caddy с помощью Docker
  • › Что нового в TypeScript 4.6?

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

Читайте также: