Nginx windows nginx config

nginx под Windows

Версия nginx под Windows использует “родной” Win32 API (не эмуляцию Cygwin). В настоящий момент в качестве методов обработки соединений используются select() и poll() (1.15.9), поэтому не стоит ожидать высокой производительности и масштабируемости. В силу этого и ряда других известных проблем версия nginx под Windows рассматривается пока как бета-версия. На данный момент в ней доступна практически вся функциональность, что и в версии nginx под UNIX, за исключением XSLT-фильтра, фильтра изображений, модуля GeoIP и встроенного языка Perl.

Чтобы установить nginx/Windows, скачайте дистрибутив последней основной версии (1.19.10), поскольку основная ветвь nginx содержит все известные исправления. Затем распакуйте дистрибутив, перейдите в каталог nginx-1.19.10 и запустите nginx . Вот пример для корневого каталога на диске C:

Чтобы увидеть процессы nginx, запустите утилиту командной строки tasklist :

Один из процессов главный, другой — рабочий. Если nginx не запускается, нужно искать причину в в файле лога ошибок logs\error.log . Если же лог-файл не создался, то причину этого следует искать в Windows Event Log. Если вместо ожидаемой страницы выводится страница с ошибкой, нужно также искать причины ошибки в файле logs\error.log .

nginx/Windows использует каталог, в котором он был запущен, в качестве префикса для относительных путей в конфигурации. В вышеприведённом примере префиксом является C:\nginx-1.19.10\ . Пути в конфигурационном файле должны задаваться в UNIX-стиле с использованием прямых слэшей:

nginx/Windows работает как стандартное консольное приложение (не сервис) и управляется при помощи следующих команд:

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

В этом руководстве даётся начальное введение в 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 .

Читайте также:  Рабочий viber для windows

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

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

Одна из важных задач конфигурации 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 передаются параметры запроса. Получится следующая конфигурация:

Читайте также:  Program file editor windows

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

Установка и настройка nginx + php под Windows

Из данного HOWTO Вы узнаете как установить и настроить связку nginx + php (в режиме FastCGI) + СУБД MySQL для работы под операционной Microsoft Windows.

Мы подробно рассмотрим вопросы установки, базовой и расширенной настройки, а также безопасности.

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

Подробности смотрите под катом.

Шаг 1. Подготовка к установке

Для начала рекомендуем в корне системного диска создать каталог nginx (например, c:\nginx\), а в нём подкаталоги public_html, php и mysql. Лучше всего связка работает, когда все основные компоненты находятся в одном каталоге. В каталог php мы будем устанавливать интерпретатор PHP5, в mysql соответственно данную СУБД, а в public_html — файлы главного сайта.

Разместив все компоненты таким образом, Вы сделаете пакет перемещаемым (Portable) и готовым к работе с любого компьютера.

Шаг 2. Загрузка необходимых компонентов

Нам потребуются следующие компоненты:

  1. PHP — http://windows.php.net/download/. Вам необходимо скачать версию с инсталлятором (*.msi) в варианте Thread Safe;
  2. MySQL — http://dev.mysql.com/downloads/mysql/. Также скачайте версию с msi-инсталлятором;
  3. nginx — http://nginx.org/ru/download.html. Скачайте последнюю версию;
  4. RunHiddenConsole — http://redmine.lighttpd.net/attachments/660/RunHiddenConsole.zip.

Шаг 3. Установка компонентов

По окончании скачивания приступайте к установке компонентов согласно данному алгоритму:

  1. распакуйте архив с nginx в созданный на шаге 1 каталог в корне (например, c:\nginx\). Далее в данном HOWTO будет использоваться именно этот каталог, поэтому если Вы изменили путь, сделайте соответствующие правки;
  2. установите PHP в каталог c:\nginx\php\:
    1. на этапе выбора типа установки (Web Server Setup) обязательно выберите вариант «Other CGI«, иначе модули, необходимые для работы PHP в режиме FastCGI не будут установлены;

    PHP — Web Server Setup
    на этапе выбора необходимых модулей (Choose Items to Install) обязательно выберите MySQL, MySQLi и OpenSSL (если хотите далее настроить SSL). Также рекомендуется выбрать модули, необходимые для большинства CMS: bzip2, Curl, Exif, GD2, Gettext, XML. Если Вы забыли что-то нужное и оно Вам потребуется, Вы всегда сможете доустановить/удалить эти компоненты, снова запустив программу установки PHP и выбрав пункт Change.

    PHP — выбор компонентов

  • установите СУБД MySQL в каталог c:\nginx\mysql\. Здесь нет ничего сложного. В мастере конфигурации выберите стандартную конфигурацию и обязательно задайте пароль администратора (пароль встроенной учётной записи суперпользователя root);
  • распакуйте архив RunHiddenConsole.zip в каталог c:\nginx\.
  • Шаг 4. Создание скриптов запуска и остановки

    Для быстрого запуска набора Вам потребуется создать в каталоге c:\nginx\ 3 файла: start.cmd, shutdown.cmd и restart.cmd, предназначенные соответственно для запуска, остановки и перезапуска серверов.

    Листинг файла start.cmd (запуск сервера):

    Листинг файла shutdown.cmd (остановка сервера):

    Листинг файла restart.cmd (перезапуск сервера):

    Если Вы изменили путь со стандартного C:\nginx\, на что-то другое, внесите соответствующие правки в скрипты.

    Если требуется запускать сервер nginx+php+mysql при загрузке системы, то добавьте задание на автозапуск скрипта start.cmd с помощью оснастки Назначенные задания Windows.

    Шаг 5. Настройка nginx

    Откройте файл c:\nginx\conf\nginx.conf в любом текстовом редакторе (я рекомендую Notepad++).

    1. Измените строку:

    Здесь вместо 1 укажите количество рабочих процессов nginx. Рекомендуется указывать число, равное количеству ядер процессора.

    2. Уберите символ комментария (решётку) у строки:

    Это позволит включить запись логов ошибок в файл error.log, который Вы всегда найдёте в каталоге c:\nginx\logs\.

    3. Измените значение директивы server<> для nginx без использования SSL:

    Если Вы хотите использовать SSL, Вам потребуется совсем иной конфиг:

    Здесь C:/nginx/private/ssl_cert_domain.pem — файл сертификата SSL, а C:/nginx/private/ssl_cert_domain.key — закрытый ключ для него. Внимание! При старте сервера у Вас запросят пароль для расшифровки закрытого ключа, поэтому чтобы не вводить его постоянно, во время создания (получения) сертификата оставьте поле ввода пароля пустым (это конечно небезопасно, но экономит время во время запуска сервера). В новых версиях возможно появится функция указания пароля в конфиге (как у Apache).

    Вы можете включить ведение логов доступа (access.log), убрав символ комментария у строки #access_log logs/access.log main;.

    Вы также можете переопределить страницы ошибок 404, 500, 502, 503, 504 и 403 путём указания в директиве error_page кода ошибки и имени файла, который будет отображаться при её возникновении.

    Шаг 6. Настройка php и безопасность

    Откройте текстовый файл C:\nginx\php\php.ini в любом текстовом редакторе. Из соображений безопасности рекомендуем изменить строку

    Также найдите в файле строку

    и замените её на следующую:

    Эти действия включат безопасный режим для PHP (Safe Mode), при котором запрещены большинство небезопасных функций и исполнение файлов, а также отключит ряд потенциально уязвимых функций. Внимание! Если Ваша CMS не работает при включённом режиме PHP Safe Mode, отключите его, либо поставьте правильную CMS ;-).

    Если Вы являетесь разработчиком и хотите видеть ошибки и сообщения PHP, то найдите строку

    и замените её на

    Для исправления опасной уязвимости в PHP, позволяющей выполнять PHP-код из загружаемых файлов, найдите в php.ini строку

    уберите символ комментария (;) около неё и замените на следующую:

    Дальнейшие настройки файла изменять не требуется — всё уже настроено оптимально для большинства применений программой установки PHP.

    Шаг 7. Обработка нескольких PHP-файлов одновременно

    К сожалению, PHP в Windows не умеет создавать копии своих экземпляров, поэтому придётся заранее запускать несколько копий и описать их использование в конфиге nginx.

    В файле start.cmd пропишите запуск php-cgi.exe на разные номера портов:

    Запустите столько процессов, сколько вам потребуется (обычно достаточно 5-20). В нашем примере используется 5 экземпляров с номерами портов 9000 — 9004.

    Откройте файл nginx.conf в текстовом редакторе и перед директивой server <> пропишите следующие строки:

    Теперь откройте файл fastcgi_params и в самом начале пропишите следующее:

    Обязательно уберите fastcgi_pass 127.0.0.1:9000; во всех директивах location.

    Пример готового конфига nginx.conf:

    Пример конфига, использующего SSL:

    Пример файла fastcgi_params:

    Шаг 8. Тестирование и заключение

    Запустите серверы и создайте в каталоге C:\nginx\public_html\ файл test.php со следующим содержанием:

    Откройте этот файл в браузере по адресу http://localhost/test.php и если Вы увидели информацию об установленном сервере, значит всё работает корректно и Вы можете приступать к использованию сервера.

    Шаг 9. Готовые примеры файлов конфигурации

    По многочисленным просьбам мы решили выложить примеры всех файлов конфигурации nginx в Git-репозитории. В данный момент доступно три разных готовых конфига:

    • nginx_simple.conf — простейший конфиг для запуска одного сайта без поддержки SSL;
    • nginx_ssl.conf — конфиг для запуска одного сайта с поддержкой SSL;
    • nginx_vhosts.conf — специально настроенный конфиг с относительными путями, поддержкой SSL, виртуальных хостов (позволяет держать несколько сайтов на одном сервере) и отдельных логов.

    Там же вы найдете готовые скрипты запуска и остановки сервера, а также файл конфигурации PHP.

    68 комментариев к записи

    А как заставить Nginx быть доступным из интернета?

    1. Иметь белый (внешний) IP-адрес.
    2. Открыть и пробросить порт 80 (и 443 в случае использования SSL) на роутере по протоколу TCP (иногда провайдер запрещает абонентам открывать привилегированные порты, поэтому может потребоваться написать у них заявление).

    Ааааа.. ну я вообще то уже им написал, задал вопрос. жду ответа.
    Скажите а в конфиге может где то свой ip прописать нужно?

    Скажите а в конфиге может где то свой ip прописать нужно?

    Ничего прописывать не нужно. По умолчанию сервер слушает все сетевые интерфейсы.

    Привет! Уже прошло больше месяц с момента установки. Использую для собственных нужд, по минимуму, в принципе доволен. Однако, иногда бекенд падает. В логах все чисто.

    Решил потестить… запустил сервер, открыл оперу (там есть класная фишка «обновлять каждые…») открыл 5 вкладок с сайтом и оставил их обновляться…

    После +-20 000 запросов все 5 php-cgi.exe из процессов улетают.
    Первое что приходит на ум — мониторить работу бекенда и в случае падения повторно запускать, но что то мне подсказывает, что это не лучший вариант решения проблемы =)
    Что посоветуете?

    После +-20 000 запросов все 5 php-cgi.exe из процессов улетают.

    Оно не предназначено для таких нагрузок. Это же тестовый отладочный сервер.

    Привет! Уже прошло больше месяц с момента установки. Использую для собственных нужд, по минимуму, в принципе доволен. Однако, иногда бекенд падает. В логах все чисто.

    Первое что приходит на ум — мониторить работу бекенда и в случае падения повторно запускать, но что то мне подсказывает, что это не лучший вариант решения проблемы =)
    Что посоветуете?

    php-fpm, но, к сожалению, только для UNIX.

    @Олег
    Переменная PHP_FCGI_MAX_REQUESTS отвечает за количество запросов, которые обработает один процесс. В windows процессы автоматом не поднимаются, используйте spawn-php.py

    @Олег
    В windows процессы автоматом не поднимаются, используйте spawn-php.py

    Как уже я несколько раз писал в комментариях, описанную в статье связку не следует использовать в продакшене. Если уж хочется держать сервер под Windows, то для запуска PHP лучше использовать Apache 2 бэкэндом с фронтендом в виде nginx.

    Спасибо за описание директивы upstream backend

    Он создает виртуальный диск?

    Он создает виртуальный диск?

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

    Пример создания виртуального диска:

    Для удаления созданного диска, используйте следующую команду (здесь Z: — буква виртуального диска):

    На самом деле php-cgi для Windows можно заставить работать стабильно.
    Давно пользуюсь сам (в том числе в продакшн).
    Доступно на гитхабе: https://github.com/deemru/php-cgi-spawner

    Давно пользуюсь сам (в том числе в продакшн).

    Как у него с запуском от имени бесправных пользователей (как сделано в php-fpm под *никсами)?

    deemru :
    Давно пользуюсь сам (в том числе в продакшн).

    Как у него с запуском от имени бесправных пользователей (как сделано в php-fpm под *никсами)?

    Процессы php-cgi будут от имени запускающего php-cgi-spawner.
    Так как bind локальный на 127.0.0.1, каких-то особых прав не требуется.

    Процессы php-cgi будут от имени запускающего php-cgi-spawner.
    Так как bind локальный на 127.0.0.1, каких-то особых прав не требуется.

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

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

    Не вникал в тему, но, так как php-cgi исполняется от имени пользователя, скорее всего, единственный вариант, каждому пользователю иметь свой обработчик php на непересекающихся портах (9000, 9001, 9002 и т.д.).

    Здравствуйте помогите примерно 4 дня назад при входе на сайт zaycev стала появляться
    Welcome to nginx! If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
    Никакой программы nginx я не ставил, читал в интернете о том как удалить (почистить файл hosts, сканировать и почистить компьютер программой spyhunter) но ничего не получилось
    помогите удалить.

    @Nikolaych123
    Nginx — это веб-сервер. Похоже на сайте, на который вы пытаетесь зайти, он просто некорректно настроен. Сообщите администрации этого ресурса и они внесут правки в конфиг сервера и всё снова будет работать.

    Читайте также:  Pitivi linux ��� ������������
    Оцените статью