Конфигурационный файл nginx где находится
Обновлено: 06.07.2024
Настройка веб-сервера Nginx
Один из самых популярных веб-серверов
Nginx пользуется большой популярностью среди пользователей веб- и прокси-серверов благодаря своей производительности. Сервер имеет много преимуществ, но настроить его будет сложно для новичка. Мы хотим вам помочь разобраться с конфигурационными файлами, синтаксисом, а также настройкой основных параметров Nginx.
Иерархия каталогов
Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.
Если вы пользовались Apache, то должны быть знакомы с каталогами sites-enabled и sites-available. Они и определяют конфигурацию сайтов. Созданные файлы хранятся в последнем каталоге. Папка sites-enabled нужна для хранения конфигураций только активированных страниц. Чтобы их связать, нужна символическая ссылка между папками. Конфигурации можно также хранить в каталоге conf.d. При этом, во время запуска Nginx каждый файл с расширением .conf будет читаться по новой. При написании конфигурационных файлов, набирайте код без ошибок и соблюдайте синтаксис. Все остальные файлы располагаются в /etc/nginx. Конфигуратор содержит сведения о конкретных процессах, а также дополнительных компонентах.
Главный конфигурационный файл Nginx – это nginx.conf.
Он считывает все конфигурационные файлы, объединяя их в один, запрашиваемый при запуске сервера. Откройте файл с помощью:
На экране появятся вот такие строки:
Структура конфигурационного файла Nginx
Когда вы настраиваете сервер Nginx, помните, что чем ниже располагается блок конфигурации, тем меньше элементов будут наследовать свойства и наоборот. В файле присутствует большое количество опций, меняющих работу сервера. Вы можете установить сжатие файлов отправляющихся клиенту, например. Для этого пропишите параметры:
Имейте ввиду, что один и тот же параметр может принимать разные значения в различных блоках. Сначала задайте его вверху, в потом переопределите параметр на нужном уровне. Если последнее действие не выполнить, программа задаст значения в автоматическом режиме.
Последними строками файла nginx.conf выступают:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Они свидетельствуют о том, что блоки location и server хранятся вне данного файла. Они определяют настройки url-адресов и конкретных файлов. Такая структура необходима для поддерживания модульной структуры конфигураций. Внутри нее получится создавать новые директории, файлы для различный сайтов. Кроме того, похожие файлы вы сможете сгруппировать. После рассмотрения вы можете закрывать файл nginx.conf.
Виртуальные блоки
Они являются аналогами виртуальных хостов в Apache. Блоки раздела server включают в себя характеристики отдельных сайтов, которые располагаются на сервере. В папке sites-available вы найдете файл блока server, который применяется по умолчанию. Внутри него можно найти вне нужные данные, которые могут потребоваться при обслуживании сайтов.
cd sites-available
sudo nano default
server <
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / <
try_files $uri $uri/ /index.html;
>
location /doc/ <
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
>
>
В вышеуказанном примере было намеренно убрано комментирование. Это было сделано для удобства восприятия. Внутри блоки server располагаются настройки, заключенные в фигурные скобки:
Правило server_name
Location-блоки
Следующий на очереди у нас будет блок location. Он нужен для определения способа обработки определенных запросов. Если ресурсы не соответствуют никаким иным блокам location, то к ним будут применяться директивы, указанные в скобках. Эти блоки могут включать путь вроде /doc/. Для установления полного соответствия между uri и location, применяется знак =. Применяя тильду, получится задать соответствие регулярным выражениям. Вы также можете установить чувствительность к регистру, поставив
. Если добавить звездочку, регистр не будет играть никакой роли.
Имейте ввиду: когда запрос будет полностью соответствовать блоку location, он будет использован, а поиск остановится. Когда совпадение неполное, URI будет сравниваться с параметрами директив location. Используется блок с сочетанием ^
, совпадающий с URI для выбора блока. Если данную опцию не задействовать, сервер выбирает оптимальное совпадение, а также произведет поиск с использованием регулярных выражений. Это необходимо для подбора одного из подходящих шаблонов. Если подходящее выражение будет найдено, оно будет использовано. В противном случае, применится предыдущее совпадение с URI. Однако имейте ввиду, что Nginx больше любит полные соответствия. Если их нет, начнется поиск регулярных выражений, а потом по URI. Паритетность поиска задается комбинацией символов ^
Правило try_files
Это весьма полезный инструмент, способный проверять наличие файлов в установленном порядке. Он применяет первый соответствующий критериям для обработки запроса. Вы можете использовать дополнительные параметры, чтобы задать, каким образом сервер обслужит запросы. В конфигураторе есть вот такая строка по умолчанию:
Что же она означает? Если поступает запрос, который обслуживается блоком location, сервер сначала попытается обработать uri как файл. Это обеспечивает переменная $uri. Когда соответствий ей не будет, uri будет обработан как каталог. Можно проверить его существование, задав слеш в конце: $uri/. Бывают ситуации, когда ни файл, ни каталог не будет найден. В таком случае загрузится файл по умолчанию – index.html. Правило try_files применяет последний параметр как запасной вариант. Именно поэтому данный файл должен быть в системе. Однако, если совпадений вообще не найдено, Nginx вернет страничку ошибки. Чтобы ее задать, пропишите = и код ошибки:
Дополнительные опции
Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.
В качестве заключения стоит сказать, что 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.
Структура конфигурационного файла
Раздача статического содержимого
Во-первых, создайте каталог /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 должна выглядеть следующим образом:
Чтобы применить новую конфигурацию, запустите 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 , который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:
Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на .jpg , .jpg или .jpg . Регулярному выражению должен предшествовать символ
. Соответствующие запросы будут отображены на каталог /data/images .
Когда nginx выбирает блок location , который будет обслуживать запрос, то вначале он проверяет директивы location, задающие префиксы, запоминая location с самым длинным подходящим префиксом, а затем проверяет регулярные выражения. Если есть совпадение с регулярным выражением, nginx выбирает соответствующий location , в противном случае берётся запомненный ранее location .
Итоговая конфигурация прокси-сервера выглядит следующим образом:
Этот сервер будет фильтровать запросы, оканчивающиеся на .jpg , .jpg или .jpg , и отображать их на каталог /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 много преимуществ, однако его настройки достаточно сложные и не всегда понятны новичкам. Данное руководство поможет разобраться с основными параметрами, синтаксисом и конфигурационными файлами Nginx.
Примечание: Руководство выполнено на Ubuntu 12.04.
Иерархия каталогов Nginx
Nginx хранит конфигурационные файлы в каталоге /etc/nginx.
В этом каталоге находится ещё несколько каталогов и модульных конфигурационных файлов.
cd /etc/nginx
ls -F
Пользователи Apache уже знакомы с каталогами sites-available и sites-enabled. Эти каталоги определяют конфигурации сайтов. Файлы обычно создаются и хранятся в sites-available; в sites-enabled хранятся только конфигурации включенных сайтов. Для этого нужно создать символическую ссылку из sites-available в sites-enabled.
Каталог conf.d тоже можно использовать для хранения конфигураций. Каждый файл с расширением .conf будет читаться при запуске Nginx. Синтаксис таких файлов не должен содержать ошибок.
Почти все оставшиеся файлы хранятся в /etc/nginx, который содержит сведения о конфигурации конкретных процессов или дополнительных компонентов.
Главным конфигурационным файлом Nginx является nginx.conf.
Файл nginx.conf
Файл nginx.conf читает соответствующие конфигурационные файлы и объединяет их в единый файл конфигурации при запуске сервера.
sudo nano /etc/nginx/nginx.conf
Первые строки задают общие сведения о Nginx. Строка user www-data указывает пользователя, с помощью которого запускается сервер.
Директива pid указывает, где будут храниться PID процессов для внутреннего использования. Строка worker_processes определяет количество процессов, которое может одновременно поддерживать Nginx.
Также в этой части файла можно указать логи (например, лог ошибок определяется с помощью директивы error_log).
Структура конфигурационного файла Nginx
Конфигурационный файл Nginx делится на блоки.
Если вы внимательно рассмотрите файл, вы заметите, что он содержит много опций, которые определяют поведение программы как единого целого.
Например, чтобы настроить сжатие файлов, нужно установить такие параметры:
gzip on;
gzip_disable "msie6";
Это включит поддержку gzip для сжатия отправляемых клиенту данных и отключит gzip для Internet Explorer 6 (поскольку этот браузер не поддерживает сжатия данных).
Если какой-либо параметр должен иметь разное значение в нескольких блоках server, то такой параметр можно задать на высшем уровне, а затем переопределить его внутри самих блоков server. В результате Nginx выполнит параметр низшего уровня.
Такое разбиение конфигураций на уровни позволяет избежать необходимости управлять несколькими идентичными файлами. Кроме того, если вы забыли определить параметры на низшем уровне, Nginx просто выполнит параметры по умолчанию.
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Это говорит о том, что блоки server и location, которые определяют настройки конкретных сайтов и URL-адресов, будут храниться за пределами этого файла.
Это позволяет поддерживать модульную архитектуру конфигураций, в которой можно создавать новые файлы для обслуживания новых сайтов. Также это позволяет группировать похожие файлы.
Закройте файл nginx.conf. Теперь нужно изучить настройки отдельных сайтов.
Виртуальные блоки Nginx
Блоки server в Nginx являются аналогом виртуальных хостов Apache (но для удобства их тоже принято называть виртуальными хостами). По сути, блоки server – это технические характеристики отдельных веб-сайтов, размещённых на одном сервере.
В каталоге sites-available можно найти файл блока server по умолчанию, который поставляется вместе с сервером. Этот файл содержит все необходимые данные для обслуживания сайта.
cd sites-available
sudo nano default
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location /
try_files $uri $uri/ /index.html;
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
Файл по умолчанию очень хорошо закомментирован, но в примере выше комментарии опущены для простоты и удобства.
Блок server включает в себя все настройки, помещённые между фигурными скобками:
Обратите внимание: все строки заканчиваются точкой с запятой. Так Nginx отделяет одну директиву от другой. Если точки с запятой не будет, Nginx прочитает две директивы (или несколько директив) как одну директиву с дополнительными аргументами.
Директива index определяет файлы, которые будут использоваться в качестве индекса. Веб-сервер будет проверять файлы в порядке их перечисления. Если ни одна страница не была запрошена, блок server найдёт и вернёт файл index.html. Если он не сможет найти этот файл, он попытается обработать index.htm.
Директива server_name
Директива server_name содержит список доменных имен, которые будут обслуживаться этим блоком server. Количество доменов неограниченно; домены в списке следует разделять пробелами.
Если запрашиваемый url-адрес соответствует нескольким директивам server_name, он сначала ответит той, с которой совпадает полностью.
Если адрес не обнаружит совпадений, он будет искать самое длинное имя с маской, которое заканчивается звездочкой. Если он не найдёт такого имени, он вернёт первое соответствие с регулярными выражениями.
Имена сервера, которые используют регулярные выражения, начинаются с тильды (
). К сожалению, данная тема выходит за рамки данной статьи.
Блоки location
Далее в конфигурационном файле находится блок location. Такие блоки определяют, как обрабатываются определённые запросы.
Строка location / указывает, что директивы в скобках будут применяться ко всем запрашиваемым ресурсам, которые не соответствуют никаким другим блокам location.
Такие блоки могут содержать uri путь (например /doc/). Чтобы установить полное соответствие между location и uri, используется символ =. Символ
устанавливает соответствие с регулярными выражениями.
Тильда включает чувствительный к регистру режим, а тильда со звёздочкой – регистронезависимый режим.
Если запрос полностью соответствует блоку location, то сервер останавливает поиск и использует такой блок. Если сервер не находит полностью подходящего блока location, он сравнивает URI с параметрами директив location. Nginx выберет блок, в котором используется сочетание символов ^
и который совпадает с URI.
не используется, Nginx выберет наиболее близкое совпадение и выполнит поиск по регулярным выражениям, чтобы попробовать подобрать один из доступных шаблонов. Если он найдёт такое выражение, то он использует его. Если такого выражения нет, то сервер использует найденное ранее совпадение с URI.
В качестве заключения следует отметить, что Nginx предпочитает точные соответствия. Если таких соответствий нет, он ищет регулярное выражение, а затем выполняет поиск по URI. Чтобы изменить приоритетность поиска по URI, используйте комбинацию символов ^
Директива try_files
Директива try_files – очень полезный инструмент, который проверяет наличие файлов в заданном порядке и использует первый найденный файл для обработки запроса.
Это позволяет вам с помощью дополнительных параметров определить, как Nginx будет обслуживать запросы.
В конфигурационном файле по умолчанию есть строка:
try_files $uri $uri/ /index.html;
Это значит, что при поступлении запроса, обслуживаемого блоком location, Nginx сначала попробует обслужить uri как файл (такое поведение задаёт переменная $uri).
Если сервер не обнаруживает соответствия переменной $uri, он попробует использовать uri как каталог.
С помощью слэша в конце сервер проверяет существование каталога, например, $uri/.
Если ни один файл или каталог не найден, Nginx выполняет файл по умолчанию (в данном случае это index.html в root-каталоге блока server). Каждая директива try_files использует последний параметр в качестве запасного варианта, потому этот файл должен существовать в системе.
В случае, если веб-сервер не обнаружил совпадений в предыдущих параметрах, он может вернуть страницу ошибки. Для этого используется знак равно и код ошибки.
Например, если блок location / не может найти запрашиваемый ресурс, вместо файла index.html он может вернуть ошибку 404:
try_files $uri $uri/ =404;
Для этого нужно поставить знак равно и задать код ошибки в качестве последнего параметра (=404).
Дополнительные параметры
Директива alias позволяет Nginx обслуживать страницы блока location вне заданного каталога (например, вне root).
Например, файлы, запрашиваемые в /doc/, будут обслужены из /usr/share/doc/.
Директива autoindex on позволяет включает листинг директорий Nginx для заданной директивы location.
Строки allow и deny управляют доступом к каталогам.
Заключение
Веб-сервер Nginx является многофункциональным и очень производительным средством, однако его терминология и параметры могут показаться запутанными.
Разобравшись с конфигурациями Nginx и научившись работать с ними, вы получите все преимущества этого мощного и легковесного инструмента.
Сегодня я хочу поговорить о настройке веб сервера Nginx, установка которого была описана в предыдущей статье.
Функционирование nginx определяется конфигурационным файлом nginx.conf, находящимся в директории /etc/nginx. Nginx состоит из модулей, модули настраиваются директивами, директивы указываются в конфигурационном файле. Директивы могут быть простыми или блочными.
Простая директива состоит из имени и указанного рядом с ним параметра, имя и параметр разделяются между собой пробелом, в конце директивы ставится точка с запятой. Блочная директива устроена так же как и простая, но вместо точки с запятой, после имени и параметра идет набор дополнительных функций, помещенных внутри фигурных скобок <>.
Начинаем писать свою конфигурацию.
Контекст main
Укажем пользователя от имени которого будет работать сервер. При установке сервера был создан пользователь nginx, он и будет основным пользователем.
Определим число worker_processes или другими словами, рабочих процессов. Число процессов должно равняться числу процессорных ядер, хотя для последних версий nginx данный параметр рекомендуют устанавливать в значение auto. Поскольку на моем недорогом VPS/VDS сервере доступно одно ядро, то я устанавливаю значение равное единице.
Также зададим приоритет рабочих процессов, это нужно для того, чтобы при сильной нагрузке сервер сразу не упал мог продолжать обрабатывать запросы клиентов. Значения могут варьироваться от -20 до 20, причем чем больше будет отрицательное значение, тем больше будет приоритет процесса.
Указываем местонахождение pid-файла и лог-файла ошибок. Отмечаться будут только ошибки критического уровня, другими словами фиксация ошибок практически прекращается, в логах будут только события связанные со стартом или перезагрузкой сервера. Чем меньше производится записей в лог-файлы, тем меньше нагрузка на сервер.
Контекст events
Директива worker_connections устанавливает максимальное количество возможных соединений для одного рабочего процесса, сюда входят все соединения, а не только соединения с клиентами.
Верхний предел количества процессов для одного пользователя можно узнать при помощи команды ulimit, просмотрев ограничения ядра операционной системы.
Значение скорее всего будет равно 1024, это значение можно задать для worker_connections.
Директива use задает метод обработки соединений, в Linux следует использовать метод epoll. Включение multi_accept позволяет принимать максимально возможное количество соединений.
Отдельно разберем директиву include подключающую в конфигурацию дополнительные файл или файлы. Рассмотрим несколько примеров чтобы понять как она работает.
Для включения в конфигурацию отдельного файла, например test.conf, нужно указать имя файла и каталог в котором он находится.
Для включения всех файлов из каталога, должен быть указан каталог и символ "*", теперь все файлы из указанного каталога будут включены в конфигурацию.
Можно подключить только определенный вид файлов, например имеющих расширение ".conf", для этого нужно указать "*.conf".
Продолжаем писать конфигурацию и подключаем файл с MIME-типами данных. Данный файл содержит список MIME заголовков и расширений передающихся по сети в соответствии со стандартом MIME. По умолчанию файл mime.types находится в директории /etc/nginx, поэтому в include достаточно просто указать имя файла.
Добавим системный вызов sendfile. Системный вызов активирует передачу данных между файловыми дескрипторами посредством ядра, а не при помощи связки read + write. Sendfile позволяет отправлять данные сразу в сеть, минуя процесс их копирования и тем самым повышая производительность.
Сразу добавим sendfile_max_chunk, для ограничения объема данных могущих передаваться за один вызов sendfile. Если этого не сделать, то одно соединение может подмять под себя весь рабочий процесс.
Поскольку sendfile активирована, то в таком случае нужно добавить tcp_nopush, директива позволяет передавать заголовок ответа и начало файла одним пакетом.
Отключаем буферизацию соединений перешедших в состояние keep-alive.
Установим временной промежуток в течении которого keep-alive соединение с клиентом не будет закрыто, если пользователь перестал отвечать. Поддерживая неактивное keep-alive соединение, мы тем самым занимаем соединение, которое может использоваться по другому.
Зададим максимальное число запросов для одного keep-alive соединения. После достижения максимального числа запросов соединение будет закрыто.
reset_timedout_connection закрывает подключения для переставших отвечать клиентов.
Установим таймаут чтения тела запроса для клиента. Если по истечении установленного времени клиент ничего не ответит, то ему будет возвращена ошибка 408 - Request Time-out.
Установим таймаут чтения заголовка запроса для клиента. Если по истечении установленного времени клиент не передаст заголовок полностью, то ему будет возвращена ошибка 408 - Request Time-out.
Установим временной промежуток для передачи ответа клиента. Если по истечении времени клиент не ответит, то соединение будет закрыто.
Зададим размер буфера для заголовка запроса от клиента.
При поступлении от клиентов больших запросов, можно выделять дополнительные буферы с помощью директивы large_client_header_buffers. Строка запроса не должна быть больше размера одного буфера, иначе клиенту будет возвращена ошибка 414 - Request URI Too Large. Поле заголовка запроса также не должно превышать размер одного буфера, иначе клиенту будет возвращена ошибка Bad Request.
Буферы выделяются по мере необходимости. Если по окончанию обработки запроса соединение переходит в состояние keep-alive буферы освобождаются. Может использоваться для защиты от различных ботов или DoS-атак.
Директивой client_body_buffer_size установим размер буфера для чтения тела запроса клиента.
client_max_body_size задает размер тела запроса клиента и ограничивает максимальный размер файла, который можно загрузить на сервер посредством PHP.
Для снижения нагрузки отключаем запись событий в логах доступа на уровне сервера.
Укажем каталог в котором будут находиться конфигурационные файлы сайтов.
Подводя итог статьи, привожу готовый файл nginx.conf.
О конфигурационных файлах сайтов мы поговорим в следующей статье, в которой будет рассмотрена дальнейшая настройка Nginx для WordPress-сайта.
Виртуальная машина сэкономит вам время и силы на правильное развертывание и администрирование вашего сайта или внутреннего информационного ресурса на базе продуктов «1С-Битрикс».
Курс предназначен для администраторов и пользователей продуктов «1С-Битрикс», устанавливающих для ознакомления либо переносящих готовые проекты на виртуальную машину BitrixVM. Аналогичным способом можно переносить проекты с удаленного сайта на виртуальную машину, между виртуальными машинами и т.д. В курсе рассматриваются процедуры установки всех необходимых приложений для работы продукта на виртуальной машине BitrixVM.
Описание установки VMWare Player не входит в данное руководство. По всем вопросам установки этой программы обращайтесь к документации VMWare Player.
На текущий момент рекомендуется к использованию виртуальная машина в версии 7.х. Описания остальных машин оставлены для тех, кто пока не переходит на более совершенную версию.
Баллы опыта
В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:
уроке.
Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса.
Читайте также: