Тонкая настройка Nginx. Защита, оптимизация. Как в nginx создавать виртуальные хосты

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

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html . Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. :)

Начнём с общих настроек. Сначала укажем пользователя, от имени которого будет работать nginx (от рута работать плохо, все знают:))

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

Worker_processes 2;

Уточним, куда писать логи ошибок. Потом, для отдельных виртуальных серверов, этот параметр можно переопределить, так что в этот лог будут сыпаться только «глобальные» ошибки, например, связанные со стартом сервера.

Error_log /spool/logs/nginx/nginx.error_log notice; # уровень уведомлений "notice", конечно, можно менять

Теперь идёт очень интересная секция «events». В ней можно задать максимальное количество соединений, которые одновременно будет обрабатывать один процесс-воркер, и метод, который будет использоваться для получения асинхронных уведомлений о событиях в ОС. Конечно же, можно выбрать только те методы, которые доступны на вашей ОС и были включены при компиляции.

Эти параметры могут оказать значительное влияние на производительность вашего сервера. Их надо подбирать индивидуально, в зависимости от ОС и железа. Я могу привести только несколько общих правил.

Модули работы с событиями:
- select и poll обычно медленнее и довольно сильно нагружают процессор, зато доступны практически везде, и работают практически всегда;
- kqueue и epoll - более эффективны, но доступны только во FreeBSD и Linux 2.6, соответственно;
- rtsig - довольно эффективный метод, и поддерживается даже очень старыми линуксами, но может вызывать проблемы при большом числе подключений;
- /dev/poll - насколько мне известно, работает в несколько более экзотических системах, типа соляриса, и в нём довольно эффективен;

Параметр worker_connections:
- Общее максимальное количество обслуживаемых клиентов будет равно worker_processes * worker_connections;
- Иногда могут сработать в положительную сторону даже самые экстремальные значения, вроде 128 процессов, по 128 коннектов на процесс, или 1 процесса, но с параметром worker_connections=16384. В последнем случае, впрочем, скорее всего понадобится тюнить ОС.

Events {
worker_connections 2048;
use kqueue; # У нас BSD:)
}

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

Http {
# Весь код ниже будет внутри этой секции %)
# ...
}

Внутри этой секции могут находиться несколько довольно интересных параметров.

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

Параметр keepalive_timeout отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Обдумайте, как именно на вашем сайте посылаются запросы, и исправьте этот параметр. Для сайтов, активно использующих AJAX, соединение лучше держать подольше, для статических страничек, которые пользователи будут долго читать, соединение лучше разрывать пораньше. Учтите, что поддерживая неактивное keepalive-соединение, вы занимаете коннекшн, который мог бы использоваться по-другому. :)

Keepalive_timeout 15;

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

Proxy_buffers 8 64k;
proxy_intercept_errors on;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Небольшой трюк. В случае, если nginx обслуживает более чем один виртуальный хост, имеет смысл создать «виртуальный хост по-умолчанию», который будет обрабатывать запросы в тех случаях, когда сервер не сможет найти другой альтернативы по заголовку Host в запросе клиента.

# default virtual host
server {
listen 80 default;
server_name localhost;
deny all;
}

Далее может следовать одна (или несколько) секций «server». В каждой из них описывается виртуальный хост (чаще всего, name-based). Для владельцев множества сайтов на одном хостинге, или для хостеров здесь может быть что-то, типа директивы

Include /spool/users/nginx/*.conf;

Остальные, скорее всего опишут свой виртуальный хост прямо в основном конфиге.

Server {
listen 80;

# Обратите внимание, в директиве server_name можно указать несколько имён одновременно.
server_name myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log timed;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Установим кодировку для отдачи по-умолчанию.

Charset utf-8;

И скажем, что мы не хотим принимать от клиентов запросы, длиной более чем 1 мегабайт.

Client_max_body_size 1m;

Включим для сервера SSI и попросим для SSI-переменных резервировать не более 1 килобайта.

Ssi on;
ssi_value_length 1024;

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

Сегодня рассмотрим настройку виртуального хоста, обслуживающего сайт со статическим контентом. То бишь, никаких CGI, Perl, PHP и еже с ними. Все примеры, упоминающиеся в статье, относятся и проверялись на Debian Linux 5.0 Lenny . Владельцев других систем это никак не должно смущать, поскольку меняться могут только пути к файлам конфигурации, в то время как их содержимое применимо к любой системе, на которой работает Nginx.

Способ хранения файлов конфигурации

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

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

Include /etc/nginx/sites-enabled/*;

То есть, из каталога /etc/nginx/sites-enabled считывается содержимое всех файлов и применяется к текущей конфигурации сервера. Заглянув в упомянутый каталог, вы увидите там один файл default , являющийся символической ссылкой на файл /etc/nginx/sites-available/default . Тоже очень удобный подход: вам вдруг понадобилось отключить какой-то виртуальный хост, вы просто удаляете символическую ссылку, а на заморачиваетесь с перемещением файла туда-сюда.

Создание виртуального сервера

Для «чистоты эксперимента» предлагаю удалить поставляемую с дистрибутивом символическую ссылку /etc/nginx/sites-enabled/default и начать, так сказать, с чистого листа.

Создайте файл /etc/nginx/sites-available/myvhost со следующим содержимым:

Server { listen 80; server_name myvhost; access_log /var/log/nginx/myvhost.log; location / { root /var/www/myvhost/; index index.htm index.html; autoindex on; } }

Это и есть сама простая конфигурация виртуального сервера в Nginx. Теперь об используемых параметрах по порядку.

Первая опция server , за которой следует фигурная скобка, начинает новую секцию. Именно в секциях server и описываются конфигурации всех виртуальных серверов в Nginx.

Опцией listen мы сообщаем Nginx номер порта, на котором наш виртуальный сервер должен ожидать соединений. По умолчанию значение этой опции равно 80 , и в приведённом примере значение определено лишь для наглядности. Также при помощи этой опции можно указать не только номер порта, но и адрес сетевого интерфейса, к которому нужно «прицепить» данный сервер. Например следующие два примера «вешают» сервер на все доступные в системе TCP/IP-интерфейсы, на порт 8080:

Listen 8080 listen *:8080

Следующий пример связывает виртуальный сервер с определённым сетевым интерфейсом с IP-адресом 192.168.0.1, ожидая входящих соединений на порту 8080:

Listen 192.168.0.1:8080

Опция server_name определяет имя виртуального сервера, которое используется при анализе веб-сервером HTTP-заголовка Host , приходящего от клиента. Именно эта опция и реализует настройку виртуальных хостов, базирующихся на имени. Например, вот так будет выглядеть фрагмент конфигурации двух виртуальных хостов на одном сервере:

Server { ... listen 80; server_name example-1.com ... } server { ... listen 80; server_name example-2.com ... }

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

Server_name example-1.com www.example-1.com www1.example-1.com

Также, можно использовать символ звёздочки, заменяющий любую последовательность символов в имени сервера:

Server_name example-1.com *.example-1.com

С параметром access_log мы знакомились в . Значение этого параметра определяет месторасположение и формат лог-файла доступа к контенту сервера.

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

Например, если вам необходимо, чтобы при обнаружении в URI подстроки /images/ , Nginx не обращался в корневой каталог сервера, а искал файлы в каталоге /mnt/server2/var/www/images/ , можно определить следующие два location:

Location / { root /var/www/myvhost/; } location /images/ { root /mnt/server2/var/www/; }

В приведённых выше примерах использования location используется поиск подстроки в строке URI. То есть, подстрока /images/ будет найдена как в http://server/images /, так и http://server/my/images /. Если вам необходимо, чтобы Nginx выполнял поиск точного соответствия, для этого можно воспользоваться символом "=" , который и заставляет сервер вести поиск таким образом:

Location = /images/ { root /mnt/server2/var/www/; }

Также вы можете определить подстроку, с которой должен начинаться URI. Для этого используется конструкция из двух символов "^~" :

Location ^~ /images/ { ... }

Ну и регулярные выражения, само-собой, поддерживаются и дают большую гибкость при описании location. Следующий location будет соответствовать всем URI, содержащим в конце имена графических файлов (без учёта регистра):

Location ~* \.(gif|jpg|jpeg)$ { ... }

То же самое, но с учётом регистра:

Location ~ \.(gif|jpg|jpeg)$ { ... }

И немного о порядке очереди обработки опций location в Nginx. Вопреки тому, что многим кажется на первый взгляд, совершенно не имеет значения (кроме регулярных выражений, само-собой) в каком порядке определены location в конфигурационном файле. Как ни меняйте их местами, результат будет один и тот же. При поиске нужного локейшена, Nginx следует следующему алгоритму:

Выполняется поиск правила, начинающегося с "=" . Как только такое правило будет найдено, дальнейший поиск будет прекращён.
Выполняется поиск «обычных» правил, т. е. не регулярных выражений. Если среди них будет найдено правило, начинающееся с "^~" , дальнейший поиск будет прекращён.
Обрабатываются регулярные выражения в том порядке, в котором они встречаются в файле конфигурации.
Если будет найдено соответствие по п. 3, то будет использоваться именно этот location, в противном случае будет использоваться location, найденный в п. 2.

Опция root своим значением определяет путь к корню документов виртуального сервера на файловой системе.

При помощи опции index вы можете определить имена файлов индексных документов, которые будет «отдавать» клиентам Nginx, если был запрошен доступ к каталогу. Если в каталоге такого файла не окажется и для данного location отключена опция autoindex , то клиент в ответ получит HTTP-код 403 , говорящий о том, что доступ запрещён.

Опция autoindex настраивает поведение Nginx в случае, если в каталоге не найден запрашиваемый индексный файл. Если значением опции autoindex, как примере выше, является "on" , то сервер вернёт клиенту содержимое каталога в виде HTML-списка файлов. По умолчанию autoindex отключён, и будьте осторожны с ней, чтобы ненароком не вывесить на всеобщее обозрение критически-важную информацию.

Перезапуск сервера

Теперь, когда конфигурационный файл готов, необходимо сделать на него символическую ссылку из каталога /etc/nginx/sites-enabled/ , чтобы при перезапуске Nginx подключил его содержимое в свою конфигурацию:

# ln -s /etc/nginx/sites-available/myvhost /etc/nginx/sites-enabled/myvhost

# mkdir /var/www/myvhost

Осталось перезапустить сервер:

# /etc/init.d/nginx restart

И, если все настройки были выполнены без ошибок, вы сможете подключиться к вашему первому виртуальному серверу Nginx при помощи веб-браузера и увидеть пустой индекс файлов корневого каталога сервера. Попробуйте разместить пару статических html-файлов в каталоге /var/www/myshost и затем получить доступ к ним из вашего браузера.

В следующей статье мы рассмотрим конфигурацию SSL-сервера в Nginx.

Более 50% трафика во всем мире обслуживает технология связки Apache и Nginx – веб сервера, которые имеют открытый исходный код. Nginx исполняет функцию фронтэнда, Apache – бэкэнда . Nginx первым принимает запросы пользователей и выдает по ним необходимый контент – изображения, файлы, скрипты. Тяжелый Apache в свою очередь не имеет с этим дело, а обрабатывает динамику. Nginx проксирует запросы и возвращает ответы . Данная связка отлично подходит для больших сайтов, которые посещают много пользователей. Для маленьких сайтов данная связка не даст роста производительности. Apache и Nginx снижает нагрузку на сервер в общем, благодаря тому, что Nginx обрабатывает статический контент, а Apache динамический.

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

Функциональный и быстрый Nginx был выпущен в 2004 году и после этого релиза начал набирать свою популярность. Благодаря своей легкости и масштабируемости хорошо работает на любом оборудовании. Nginx используют в двух направлениях: как веб сервер или как прокси.

Что делает Nginx в качестве веб сервера?

автоматически создает кэш дескрипторы и списки файлов, обслуживает индексные файлы и статические запросы;
ускоряет отказоустойчивость, проксирование и рапределение нагрузки;
кэширует при FastCGI и ускоряет проксирование;
поддерживает SSL;
поддерживает Perl;
имеет филтры и модульность;
аунтифецирует HTTP и фильтрирует SSL.

В качестве прокси Nginx:

полное обеспечение StartTLS и SSL;
легкость аутентификации (USER/PASS, LOGIN);
использует внешний HTTP-сервер для перенаправления на POP3/IMAP-бэкенд.

Как видим, Nginx выполняет множество функций, при этом не перегружая систему. По официальным данным, технологию используют более 56 млн. сайтов во всем мире (к примеру, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), но по популярности Nginx уступает Apache. Почему же так популярен Apache?

Веб сервер Apache – кросплатформенное программное обеспечение, которое было создано в 1995 году. Благодаря большой документации и хорошей интеграции с сторонним ПО, Apache получил огромное распространение. Поддерживает следущие ОС – Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Преимущества веб сервера Apache:

поддержка языков программирования PHP, Python, Ruby, Perl, ASP, Tcl ;
легкость в подключении внешних модулей;
поддержка технологий CGI и FastCGI ;
наличие механизмов, которые обеспечивают безопасноть и разграничение к доступу данных;
возможность использовать СУБД для аутентификации пользователей;
гибкая и надежная конфигурация системы;
подходит для приложений, которым нужна мощная криптографическая защита данных ;
возможность создания пользовательских директорий для веб-сайта;
возможность настройки виртуальных хостов , с помощью которых на одном физическом сервере можно создать несколько виртуальных;
ведет протоколы того, что происходит на вашем сервере;
активная обратная связь с разработчиками и своевременное решения возникших ошибок в ПО.

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

Хотите обезопасить работу PHP на сервере? Об этом более подробно .

После ознакомления с плюсами и минусами Apache и Nginx, Вы можете выбрать полезное решения для своего сайта в зависимости от целей, которые преследуете. Но возможно Вам понадобится именно связка Apache+Nginx для достижения наилучшего результата. Например, часто используют Nginx перед Apache в качестве реверс прокси. Такая комбинация позволяет обрабатывать много конкурентных запросов и сортирует их. Те запросы, которые не под силу Nginx отправляются к Apache, тем самым снижается нагрузка на последний. Отказоустойчивость в таком случае увеличивается. Перед выбором веб сервера нужно провести обязательные тесты на производительность и возможности каждого решения.

Обо всех технологиях, которые поддерживает хостинг HyperHost, более подробно по .

Данная статья была предоставлена для общего ознакомления с возможностями связки веб серверов Apache и Nginx. Еще больше информации в .

Если понадобится наша помощь, обращайтесь!

Мы будем рады ответить на все интересующие вас вопросы по настройке веб серверов. Также у нас Вы всегда можете с бесплатным администрированием. Вся ли техническая поддержка хостеров одинакова? Об особенностях бесплатного и платного администрирования в специальной .

17248 раз(а) 9 Сегодня просмотрено раз(а)

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

В одной из предыдущих статей мы уже рассматривали и настройку его основных параметров, в этой же статье я хочу больше остановиться на производительности и подготовке веб-сервера к использованию в боевых условиях. Что касается дистрибутива Linux, то сегодня мы будем рассматривать CentOS, эта система часто используется на серверах и с настройкой Nginx тут могут возникнуть некоторые сложности. Дальше будет рассмотрена настройка Nginx CentOS, поговорим как включить полную поддержку http2, google pagespeed, и настроить основной конфигурационный файл.

В официальных репозиториях CentOS есть Nginx и он, скорее всего, уже установлен в вашей системе. Но мы хотим чтобы сайт работал по протоколу http2, который позволяет передавать все данные одним подключением, а это увеличивает производительность. Для работы по http2 вам понадобиться настроить SSL сертификат, но об этом уже написано в статье получение сертификата Lets Encrypt Nginx. Но это еще не все. для переключения с обычного SSL на HTTP2.0 в большинстве браузеров сейчас используется протокол ALPN, а он поддерживается начиная с OpenSSL 1.02. В то время, как в репозиториях есть только OpenSSL 1.01. Поэтому нам нужно установить версию Nginx, собранную с OpenSSL 1.02. Для этого можно использовать Broken Repo:

sudo yum -y install yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Если вы используете репозиторий EPEL, то нужно указать что не надо из него брать Nginx:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Теперь для установки правильной версии Nginx достаточно набрать:

sudo yum install nginx

Будет установлена самая последняя версия Nginx 1.13.2, с полной поддержкой ALPN. Дальше перейдем к настройке.

2. Настройка Nginx

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

глобальные опции
events {}
http{
server {
location{}
}
server {}
}

Сначала идут глобальные опции, которые задают основные параметры программы, например, от какого пользователя она будет запущена и количество процессов. Дальше есть секция events , в которой описано как Nginx будет реагировать на входящие подключения, затем идет секция http , которая объединяет все настройки касаемо работы протокола http. В ней находится секция server , каждая такая секция отвечает за отдельный домен, в секции server размещаются секции location , каждая из которых отвечает за определенный URL запроса, обратите внимание, что не файл на сервере, как в Apache, а именно URL запроса.

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

user - пользователь, от имени которого будет запущен сервер, должен быть владельцем каталога с файлами сайта, и от имени его же нужно запускать php-fpm;
worker_processes - количество процессов Nginx, которые будут запущены, нужно установить ровно столько, сколько у вас есть ядер, например, у меня - 4;
worker_cpu_affinity - этот параметр позволяет закрепить каждый процесс за отдельным ядром процессора, установите значение auto, чтобы программа сама выбрала что и к чему крепить;
worker_rlimit_nofile - максимальное количество файлов, которые может открыть программа, на каждое соединение нужно как минимум два файла и каждый процесс будет иметь указанное вами количество соединений, поэтому формула такая: worker_processes * worker_connections* 2, параметр worker_connections разберем чуть ниже;
pcre_jit - включите этот параметр для ускорения обработки регулярных выражений с помощью JIT компиляции;

В секции events стоит настроить два параметра:

worker_connections - количество соединений для одного процесса, должно быть достаточным для обработки входящих соединений. Сначала нам нужно знать сколько этих входящих соединений есть, для этого смотрим статистику по адресу ip_сервера/nginx_status. Как включить рассмотрим ниже. В строке Active Connections видим количество активных соединений с сервером, также нужно учесть что соединения с php-fpm тоже считаются. Дальше обратите внимание на поля accepted и handled, первое отображает обработанных подключений, второе - количество принятых. Из значения должны быть одинаковыми. Если отличаются значит соединений не хватает. Смотрите примеры, первый снимок проблема, второй - порядок. Для моей конфигурации оптимальной может быть цифра в 200 соединений (всего 800, учитывая 4 процесса):

multi_accept - позволяет программе принимать несколько соединений одновременно, тоже ускоряет работу, при большом количестве соединений;
accept_mutex - установите значение этого параметра в off, чтобы сразу все процессы получали уведомление про новые соединения;

Также в секции events рекомендуется использовать директиву use epoll, так как этот самый эффективный метод обработки входящих соединений для Linux, но этот метод применяется по умолчанию, поэтому не вижу смысла добавлять его вручную. Рассмотрим еще несколько параметров из секции http:

sendfile - использовать метод отправки данных sendfile. Самый эффективный метод для Linux.
tcp_nodelay, tcp_nopush - отправляет заголовки и тело запроса одним пакетом, работает немного быстрее;
keepalive_timeout - таймаут поддержания соединения с клиентом, если у вас нет очень медленных скриптов, то будет достаточно будет 10 секунд, устанавливаем значение сколько нужно чтобы пользователь мог быть подключен к серверу;
reset_timedout_connection - разрывать соединения после таймаута.
open_file_cache - кэшировать информацию об открытых файлах. Например, open_file_cache max=200000 inactive=120s; max - максимальное количество файлов в кэше, время кэширования.
open_file_cache_valid - когда нужно проверить актуальность файлов. Например: open_file_cache_valid 120s;
open_file_cache_min_uses - кэшировать только файлы, которые были открыты указанное количество раз;
open_file_cache_errors - запоминать ошибки открытия файлов.
if_modified_since - устанавливает каким образом будут обрабатываться заголовки if-modified-since. С помощью этого заголовка браузер может получить ответ 304 если страница не изменилась с момента последнего просмотра. Возможны варианты - не отправлять - off, отправлять при точном совпадении времени - exact, отправлять если время совпадает точно или больше - before;

Вот как-то так будет выглядеть настройка nginx conf:

user nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;

error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";

events {
multi_accept on;
accept_mutex off;
worker_connections 1024;
}

sendfile on;
tcp_nopush on;
tcp_nodelay on;

open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;

reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;

include /etc/nginx/sites-enabled.*.conf

3. Настройка http2

Я не буду подробно описывать настройку секции server, потому что делал это уже в статье установка Nginx в Ubuntu и здесь мне нечего добавить, настройка SSL это достаточно обширная тема и тоже будет рассмотрена в отдельной статье. Но чтобы настроить http2 вам нужно иметь уже SSL. Далее, просто подправьте директиву listen в вашей секции server:

listen 194.67.215.125:443 default_server;

listen 194.67.215.125:443 http2 default_server;

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

4. Настройка PageSpeed

Google Pagespeed - это модуль Nginx, который выполняет различные оптимизации для того, чтобы страницы грузились быстрее, веб-сервер работал эффективнее, а пользователи не чувствовали дискомфорта. Сюда входит кэширование, оптимизация html кода, оптимизация картинок, объединение javascript и css кода и многое другое. Все это выполняется на уровне Nginx, поэтому эффективнее, чем если бы вы это делали в php. Но тут есть один недостаток, модуль удаляет заголовок Last Modified.

Дело в том, что PageSpeed устанавливает очень долгий строк кэширования для всех файлов, а в имя файла добавляет его хэш. Так скорость загрузки ресурсов выходит намного выше, поскольку браузер будет запрашивать файлы только с новым хэшем, а LastModified удаляется чтобы пользователи смогли увидеть изменения в случае если какой-либо файл будет изменен. А теперь рассмотрим как установить модуль. Нам придется собрать его из исходных кодов.

Сначала установите инструменты для сборки, очень важно, если не установите, потом получите ошибку и не будете знать что делать:

yum install wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel

Скачайте и распакуйте исходники Nginx для вашей версии, например, 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

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

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# unzip v1.12.34.2-stable.zip

Скачайте и распакуйте библиотеку оптимизации PageSpeed в папку с исходниками модуля:

cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

Скачайте и распакуйте исходники OpenSSL 1.02:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Теперь нам нужно собрать модуль. Сначала смотрим опции, с которыми собран текущий Nginx:

А теперь переходим в папку с Nginx, подставляем все полученные опции, опцию --add-dynamic-module для PageSpeed, OpenSSL и пробуем собрать:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with-ld-opt= --with-openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable ${PS_NGX_EXTRA_FLAGS}
# make

Если все было сделано правильно, то на выходе вы получите модуль ngx_pagespeed.so в папке obj, его нужно скопировать в папку /etc/nginx/modules:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Создаем папку для кэша:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Теперь добавьте такую строчку для включения модуля в /etc/nginx/nginx.conf:

load_module "modules/ngx_pagespeed.so";