Nginx conf как его найти

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

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

nginx -s сигнал

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

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

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

nginx -s quit

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

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

nginx -s reload

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

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

kill -s QUIT 1628

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

ps -ax | grep nginx

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

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

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

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

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

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

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

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

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

http {
    server {
    }
}

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

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

location / {
    root /data/www;
}

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

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

location /images/ {
    root /data;
}

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

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

server {
    location / {
        root /data/www;
    }

    location /images/ {
        root /data;
    }
}

Это уже работающая конфигурация сервера, слушающего на стандартном порту 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,
выполнив:

nginx -s reload

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

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

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

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

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

server {
    listen 8080;
    root /data/up1;

    location / {
    }
}

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

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

server {
    location / {
        proxy_pass http://localhost:8080;
    }

    location /images/ {
        root /data;
    }
}

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

location ~ .(gif|jpg|png)$ {
    root /data/images;
}

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

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

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

server {
    location / {
        proxy_pass http://localhost:8080/;
    }

    location ~ .(gif|jpg|png)$ {
        root /data/images;
    }
}

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

server {
    location / {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param QUERY_STRING    $query_string;
    }

    location ~ .(gif|jpg|png)$ {
        root /data/images;
    }
}

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

Understand the basic elements in an NGINX or NGINX Plus configuration file, including directives and contexts.

NGINX and NGINX Plus are similar to other services in that they use a text‑based configuration file written in a particular format. By default the file is named nginx.conf and for NGINX Plus is placed in the /etc/nginx directory. (For NGINX Open Source , the location depends on the package system used to install NGINX and the operating system. It is typically one of /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.)

Directives

The configuration file consists of directives and their parameters. Simple (single‑line) directives each end with a semicolon. Other directives act as “containers” that group together related directives, enclosing them in curly braces ( {} ); these are often referred to as blocks. Here are some examples of simple directives.

user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

Feature-Specific Configuration Files

To make the configuration easier to maintain, we recommend that you split it into a set of feature‑specific files stored in the /etc/nginx/conf.d directory and use the include directive in the main nginx.conf file to reference the contents of the feature‑specific files.

include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;

Contexts

A few top‑level directives, referred to as contexts, group together the directives that apply to different traffic types:

• events – General connection processing
• http – HTTP traffic
• mail – Mail traffic
• stream – TCP and UDP traffic

Directives placed outside of these contexts are said to be in the main context.

Virtual Servers

In each of the traffic‑handling contexts, you include one or more server blocks to define virtual servers that control the processing of requests. The directives you can include within a server context vary depending on the traffic type.

For HTTP traffic (the http context), each server directive controls the processing of requests for resources at particular domains or IP addresses. One or more location contexts in a server context define how to process specific sets of URIs.

For mail and TCP/UDP traffic (the mail and stream contexts) the server directives each control the processing of traffic arriving at a particular TCP port or UNIX socket.

Sample Configuration File with Multiple Contexts

The following configuration illustrates the use of contexts.

user nobody; # a directive in the 'main' context

events {
    # configuration of connection processing
}

http {
    # Configuration specific to HTTP and affecting all virtual servers  

    server {
        # configuration of HTTP virtual server 1       
        location /one {
            # configuration for processing URIs starting with '/one'
        }
        location /two {
            # configuration for processing URIs starting with '/two'
        }
    } 
    
    server {
        # configuration of HTTP virtual server 2
    }
}

stream {
    # Configuration specific to TCP/UDP and affecting all virtual servers
    server {
        # configuration of TCP virtual server 1 
    }
}

Inheritance

In general, a child context – one contained within another context (its parent) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the proxy_set_header directive.

Reloading Configuration

For changes to the configuration file to take effect, it must be reloaded. You can either restart the nginx process or send the reload signal to upgrade the configuration without interrupting the processing of current requests. For details, see Controlling NGINX Processes at Runtime.

With NGINX Plus, you can dynamically reconfigure load balancing across the servers in an upstream group without reloading the configuration. You can also use the NGINX Plus API and key‑value store to dynamically control access, for example based on client IP address.

---

NGINX — программное обеспечение, написанное для UNIX-систем. Основное назначение — самостоятельный HTTP-сервер, или, как его используют чаще, фронтенд для высоконагруженных проектов. Возможно использование NGINX как почтового SMTP/IMAP/POP3-сервера, а также обратного TCP прокси-сервера.

Как используется и работает nginx

NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.

Как проверить, установлен ли NGINX

Пишете в консоль SSH следующую команду, она покажет версию NGINX

nginx -v

Если видите что-то навроде
nginx version: nginx/1.10.3
Значит, всё в порядке, установлен NGINX версии 1.10.3. Если нет, установим его.

Как установить NGINX

Если вы сидите не под root, предваряйте команды apt-get префиксом sudo, например sudo apt-get install nginx

1. Обновляем порты (не обязательно)

   apt-get update && apt-get upgrade

2. Установка NGINX

   apt-get install nginx

3. Проверим, установлен ли NGINX

   nginx -v

   Команда должна показать версию сервера, что-то подобное:
   nginx version: nginx/1.10.3

Где расположен nginx

Во FreeBSD NGINX располагается в /usr/local/etc/nginx.
В Ubuntu, Debian NGINX располагается тут: /etc/nginx. В ней располагается конфигурационный файл nginx.conf — основной конфигурационный файл nginx.
Чтобы добраться до него, выполняем команду в консоли

nano /etc/nginx/nginx.conf

По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/

cd /etc/nginx/sites-enabled/

или в /etc/nginx/vhosts/

cd /etc/nginx/vhosts/

Как правильно составить правила nginx.conf

Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде

 # Определяем пользователя, под которым работает nginx
user www-data;

 # Определяем количество рабочих процессов автоматически
 # Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5.
worker_processes auto;


 # Определяем, куда писать лог ошибок и уровень логирования
error_log  /var/log/nginx/error.log warn;

 # Задаём файл, в котором будет храниться номер (PID) основного процесса
pid /var/run/nginx.pid;


events {
    # Устанавливает максимальное количество соединений одного рабочего процесса. Следует выбирать значения от 1024 до 4096.
    # Как правило, число устанавливают в зависимости от числа ядер процессора по принципу n * 1024. Например, 2 ядра дадут worker_connections 2048.
    worker_connections  1024;

    # Метод обработки соединений. Наличие того или иного метода определяется платформой.
    # Как правило, NGINX сам умеет определять оптимальный метод, однако, его можно указать явно.
    # use epoll - используется в Linux 2.6+
    # use kqueue - FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и Mac OS X
    use epoll;


    # Будет принимать максимально возможное количество соединений 
    multi_accept on;
}


http {

    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    # Куда писать лог доступа и уровень логирования
    access_log  /var/log/nginx/access.log  main;

    # Для нормального ответа 304 Not Modified;
    if_modified_since before;

    # Включаем поддержку WebP
    map $http_accept $webp_ext {
        default "";
        "~*webp" ".webp";
    }

    ##
    # Basic Settings
    ##
  
    # Используется, если количество имен серверов большое
    #server_names_hash_max_size 1200;
    #server_names_hash_bucket_size 64;


    ### Обработка запросов ###

    # Метод отправки данных sendfile более эффективен, чем стандартный метод read+write 
    sendfile on;
    # Будет отправлять заголовки и и начало файла в одном пакете 
    tcp_nopush on;
    tcp_nodelay on;


    ### Информация о файлах ###

    # Максимальное количество файлов, информация о которых будет содержаться в кеше
    open_file_cache max=200000 inactive=20s;
    # Через какое время информация будет удалена из кеша
    open_file_cache_valid 30s;
    # Кеширование информации о тех файлах, которые были использованы хотя бы 2 раза
    open_file_cache_min_uses 2;
    # Кеширование информации об отсутствующих файлах
    open_file_cache_errors on;


    # Удаляем информацию об nginx в headers
    server_tokens off;

    # Будет ждать 30 секунд перед закрытием keepalive соединения 
    keepalive_timeout 30s;    
    ## Максимальное количество keepalive запросов от одного клиента 
    keepalive_requests 100;

    # Разрешает или запрещает сброс соединений по таймауту 
    reset_timedout_connection on;
    # Будет ждать 30 секунд тело запроса от клиента, после чего сбросит соединение 
    client_body_timeout 30s;
    # В этом случае сервер не будет принимать запросы размером более 200Мб 
    client_max_body_size 200m;
    # Если клиент прекратит чтение ответа, Nginx подождет 30 секунд и сбросит соединение 
    send_timeout 30s;

    # Proxy #
    # Задаёт таймаут для установления соединения с проксированным сервером. 
    # Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд. 
    proxy_connect_timeout 30s;
    # Задаёт таймаут при передаче запроса проксированному серверу. 
    # Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи. 
    # Если по истечении этого времени проксируемый сервер не примет новых данных, соединение закрывается. 
    proxy_send_timeout 30s;
    # Задаёт таймаут при чтении ответа проксированного сервера. 
    # Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения. 
    # Если по истечении этого времени проксируемый сервер ничего не передаст, соединение закрывается. 
    proxy_read_timeout 30s;

    
  
    ##
    # Gzip Settings
    ##

    # Включаем сжатие gzip
    gzip on;
    # Для IE6 отключить
    gzip_disable "msie6";
     # Добавляет Vary: Accept-Encoding в Headers
     gzip_vary on;
     # Cжатие для всех проксированных запросов (для работы NGINX+Apache)
     gzip_proxied any;
     # Устанавливает степень сжатия ответа методом gzip. Допустимые значения находятся в диапазоне от 1 до 9
     gzip_comp_level 6;
     # Задаёт число и размер буферов, в которые будет сжиматься ответ
     gzip_buffers 16 8k;
     # Устанавливает минимальную HTTP-версию запроса, необходимую для сжатия ответа. Значение по умолчанию
     gzip_http_version 1.1;
     # MIME-типы файлов в дополнение к text/html, которые нужно сжимать
     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
     # Минимальная длина файла, которую нужно сжимать
     gzip_min_length 10;

  # Подключаем конфиги конкретных сайтов 
  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/vhosts/*/*;

  ### Далее определяем localhost
  ### Сюда отправляются запросы, для которых не был найден свой конкретный блок server в /vhosts/
  server {
     server_name localhost; # Тут можно ввести IP сервера
     disable_symlinks if_not_owner;
     listen 80 default_server; # Указываем, что это сервер по умолчанию на порту 80

     ### Возможно, понадобится чётко указать IP сервера
     # listen      192.168.1.1:80 default_server;

     ### Можно сбрасывать соединения с сервером по умолчанию, а не отправлять запросы в бекенд
     #return      444;

    include /etc/nginx/vhosts-includes/*.conf;
    location @fallback {
       error_log /dev/null crit;
       proxy_pass http://127.0.0.1:8080;
       proxy_redirect http://127.0.0.1:8080 /;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       access_log off ;
    }
  }
}

Строка include /etc/nginx/vhosts/*; указывает на поддиректорию vhosts, в которой содержатся файлы конфигураций конкретно под каждый домен.
Пример того, что может содержаться там — example.com.conf
Ниже пример для Apache в бекенде:

server {
  # Домен сайта и его алиасы через пробел
  server_name example.com www.example.com;
  # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою.
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  #IP:Port сервера NGINX
  listen 192.168.1.1:80;
  include /etc/nginx/vhosts-includes/*.conf;
  location / {
    location ~ [^/].ph(pd*|tml)$ {
      try_files /does_not_exists @fallback;
    }
    # WebP
    location ~* ^.+.(png|jpe?g)$ {
      expires 365d;
      add_header Vary Accept;
      try_files $uri$webp_ext $uri =404;
    }
    location ~* ^.+.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
      expires 365d;
      try_files $uri =404;
    }
    location / {
      try_files /does_not_exists @fallback;
    }
  }
  location @fallback {
    proxy_pass http://127.0.0.1:8080;
    proxy_redirect http://127.0.0.1:8080 /;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    access_log off ;
  }
}

А вот вариант для PHP-FPM:

server {
  # Домен сайта и его алиасы через пробел
  server_name example.com www.example.com;
  # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою.
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  #IP:Port сервера NGINX
  listen 192.168.1.1:80;
  include /etc/nginx/vhosts-includes/*.conf;
  location / {
    location ~ [^/].ph(pd*|tml)$ {
      try_files /does_not_exists @php;
    }
    # WebP
    location ~* ^.+.(png|jpe?g)$ {
      expires 365d;
      add_header Vary Accept;
      try_files $uri$webp_ext $uri =404;
    }
    location ~* ^.+.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
      expires 365d;
      try_files $uri =404;
    }
    location / {
      try_files $uri $uri/ @php;
    }
  }
  location @php {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]";
    # Путь к сокету php-fpm сайта
    fastcgi_pass unix:/var/www/php-fpm/example.sock;
    fastcgi_split_path_info ^((?U).+.ph(?:pd*|tml))(/?.+)$;
  }
}

NGINX WordPress Multisite

Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:

#user 'example' virtual host 'example.com' configuration file
server {
  server_name example.com www.example.com;
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html index.php;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  listen 1.2.3.4:80;
  include /etc/nginx/vhosts-includes/*.conf;

  # А вот тут блок специально для MU subdirectories
  if (!-e $request_filename) {
      rewrite /wp-admin$ $scheme://$host$uri/ permanent;
      rewrite ^(/[^/]+)?(/wp-.*) $2 last;
      rewrite ^(/[^/]+)?(/.*.php) $2 last;
  }

  location / {
      try_files $uri $uri/ /index.php?$args ;
  }

  location ~ .php {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]";
    fastcgi_pass unix:/var/www/php-fpm/example.sock;
    fastcgi_split_path_info ^((?U).+.ph(?:pd*|tml))(/?.+)$;
  }
}

Как заблокировать по IP в NGINX

Блокировать можно с помощью директив allow и deny.

Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:

  deny 1.2.3.4 ; # Здесь мы вводим IP нарушителя
  deny 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть в бан
  deny 2001:0db8::/32 ; # Пример заблокированного IPv6
  allow all ; # Всем остальным разрешаем доступ

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

### https://sheensay.ru/?p=408
################################

location = /wp-admin/admin-ajax.php { # Открываем доступ к admin-ajax.php. Это нужно, чтобы проходили ajax запросы в WordPress
  try_files $uri/ @php ;
}
 
location = /adminer.php { # Закрываем Adminer, если он есть
  try_files /does_not_exists @deny ;
}
 
location = /wp-login.php { # Закрываем /wp-login.php
  try_files /does_not_exists @deny ;
}
  
location ~* /wp-admin/.+.php$ { # Закрываем каталог /wp-admin/
  try_files /does_not_exists @deny ;
}
 
 
location @deny { # В этом location мы определяем правила, какие IP пропускать, а какие забанить

  allow 1.2.3.4 ; # Здесь мы вводим свой IP из белого списка
  allow 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть IP
  allow 2001:0db8::/32 ; # Пример IPv6

  deny all ; # Закрываем доступ всем, кто не попал в белый список
 
  try_files /does_not_exists @php; # Отправляем на обработку php в бекенд
}
 
location ~ .php$ { ### Файлы PHP обрабатываем в location @php
    try_files /does_not_exist @php;  
}

location @php{ 
    ### Обработчик php, PHP-FPM или Apache
}

Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:

	
### Задаём таблицу соответсткий
map $remote_addr $allowed_ip {

   ### Перечисляете разрешённые IP
   1.2.3.4 1; ### 1.2.3.4 - это разрешённый IP
   4.3.2.1 1; ### 4.3.2.1 - это ещё один разрешённый IP

   default 0; ### По умолчанию, запрещаем доступ
}
 
server {

   ### Объявляем переменную, по которой будем проводить проверку доступа
   set $check '';
 
   ### Если IP не входит в список разрешённых, отмечаем это
   if ( $allowed_ip = 0  ) {
      set $check "A";
   }
 
   ### Если доступ идёт к wp-login.php, отмечаем это
   if ( $request_uri ~ ^/wp-login.php ) {
      set $check "${check}B";
   }

   ### Если совпали правила запрета доступа - отправляем соответствующий заголовок ответа 
   if ( $check = "AB" ) {
      return 444; ### Вместо 444 можно использовать стандартный 403 Forbidden, чтобы отслеживать попытки доступа в логах

   ### Остальные правила server ####
}
 

Как в NGINX указать размер и время

Размеры:

• Байты указываются без суффикса. Пример:

  directio_alignment 512;

• Килобайты указываются с суффиксом k или K. Пример:

  client_header_buffer_size 1k;

• Мегабайты указываются с суффиксом m или M. Пример:

  client_max_body_size 100M;

• Гигабайты указываются с суффиксом g или G. Пример:

  client_max_body_size 1G;

Время задаётся в следующих суффиксах:

• ms — миллисекунды
• s — секунды
• m — минуты
• h — часы
• d — дни
• w — недели
• M — месяцы, 30 дней
• Y — годы, 365 дней

В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s. Значение без суффикса задаёт секунды.

Рекомендуется всегда указывать суффикс

Некоторые интервалы времени можно задать лишь с точностью до секунд.

Настройка отладки в NGINX

В целях отладки настройки NGINX вы можете писать данные в логи, но я советую воспользоваться директивой add_header. С её помощью вы можете выводить различные данные в http headers.
Пример, как можно определить, в каком location обрабатывается правило:

  location ~ [^/].ph(pd*|tml)$ {
    try_files /does_not_exists @fallback;
    add_header X-debug-message "This is php" always;
  }

  location ~* ^.+.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
    expires 365d; log_not_found off; access_log off;
    try_files $uri $uri/ @fallback;
    add_header X-debug-message "This is static file" always;
  }

Теперь, если проверить, какие заголовки отдаёт статичный файл, например https://sheensay.ru/wp-content/uploads/2015/06/nginx.png, то вы увидите среди них и наш X-debug-message

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

Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)

Функционал NGINX возможно расширить с помощью модулей. С их списком и возможным функционалом можно ознакомиться на официальном сайте http://nginx.org/ru/docs/. Также, существуют интересные сторонние модули, например, модуль NGINX для защиты от DDoS
Приведу пример установки модуля ngx_headers_more.

Все команды выполняются в консоли, используйте Putty или Far Manager с NetBox/WinSCP. Установка будет происходить под Debian

1. nginx -V

   В результате увидите что-то навроде

   nginx version: nginx/1.8.0
   built by gcc 4.9.1 (Debian 4.9.1-19)
   built with OpenSSL 1.0.1k 8 Jan 2015
   TLS SNI support enabled
   configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/ngin
   x/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/p
   roxy_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=ng
   inx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-htt
   p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-htt
   p_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-securi
   ty' --with-ld-opt=-Wl,-z,relro --with-ipv6 

   Результат запишем в блокнот, пригодится при компиляции

2. wget http://nginx.org/download/nginx-1.8.0.tar.gz

   tar xvf nginx-1.8.0.tar.gz

   rm -rf nginx-1.8.0.tar.gz

   cd nginx-1.8.0

   Тут мы скачиваем нужную версию NGINX.

3. wget https://github.com/openresty/headers-more-nginx-module/archive/v0.29.tar.gz

   tar xvf v0.29.tar.gz

   Скачиваем и распаковываем последнюю версию модуля из источника, в моём случае, с GitHub

4. aptitude install build-essential

   Установим дополнительные пакеты.
   Если выходит ошибка aptitude: команда не найдена, нужно предварительно установить aptitude:

   apt-get install aptitude

5. Теперь приступаем к конфигурированию NGINX с модулем headers-more-nginx-module
   Ещё раз запускаем nginx -V и копируем, начиная с —prefix= и до первого —add-module= (все присутствующие в результате —add_module= нам не нужны). После чего пишем в консоли ./configure и вставляем скопированное из редактора:

   ./configure --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29

   —add-module={Тут надо добавить путь до распакованного модуля, абсолютный или относительный}

6. Во время конфигурирования могут возникнуть ошибки
   • Ошибка

     ./configure: error: the HTTP rewrite module requires the PCRE library.
     You can either disable the module by using --without-http_rewrite_module
     option, or install the PCRE library into the system, or build the PCRE library
     statically from the source with nginx by using --with-pcre=<path> option.

     Эта проблема решается установкой libpcre++-dev:

     aptitude install libpcre++-dev

   • Ошибка

     ./configure: error: SSL modules require the OpenSSL library.
     You can either do not enable the modules, or install the OpenSSL library
     into the system, or build the OpenSSL library statically from the source
     with nginx by using --with-openssl=<path> option.
     

     Эта проблема решается так:

     aptitude install libssl-dev

7. В случае успеха, вы увидите что-то навроде

   Configuration summary
     + using system PCRE library
     + using system OpenSSL library
     + md5: using OpenSSL library
     + sha1: using OpenSSL library
     + using system zlib library
   
     nginx path prefix: "/etc/nginx"
     nginx binary file: "/etc/nginx/sbin/nginx"
     nginx configuration prefix: "/etc/nginx"
     nginx configuration file: "/etc/nginx/nginx.conf"
     nginx pid file: "/var/run/nginx.pid"
     nginx error log file: "/var/log/nginx/error.log"
     nginx http access log file: "/var/log/nginx/access.log"
     nginx http client request body temporary files: "/var/cache/nginx/client_temp"
     nginx http proxy temporary files: "/var/cache/nginx/proxy_temp"
     nginx http fastcgi temporary files: "/var/cache/nginx/fastcgi_temp"
     nginx http uwsgi temporary files: "/var/cache/nginx/uwsgi_temp"
     nginx http scgi temporary files: "/var/cache/nginx/scgi_temp"
   

8. Пришло время собрать бинарный файл nginx

   make install clean

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

   /usr/sbin/nginx -V

   В результате должны увидеть модуль на месте

   nginx version: nginx/1.8.0
   built by gcc 4.9.2 (Debian 4.9.2-10)
   built with OpenSSL 1.0.1k 8 Jan 2015
   TLS SNI support enabled
   configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --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-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29
   

10. Останавливаем nginx

    service nginx stop

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

    mv /usr/sbin/nginx /usr/sbin/nginx_back

12. Свежесобранный бинарник nginx ставим на место старого

    mv /etc/nginx/sbin/nginx /usr/sbin/nginx

13. Проверяем, что вышло в итоге, что ничего не перепутано, и нужные модули на месте

    nginx -V

14. Запускаем NGINX

    service nginx start

15. Подчищаем за собой

    cd ../

    rm -rf nginx-1.8.0

    rm -rf /etc/nginx/sbin

Основные ошибки nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 Gateway Time-out

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

server { 
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Тут мы выставили ожидание таймаута в 800 секунд.

Upstream timed out (110: Connection timed out) while reading response header from upstream

Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута

location ~ .php$ { 
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

800 секунд на ожидание ответа от бекенда.

Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;

и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100Mb

client_max_body_size 100m;

Также, можно отключить проверку размера тела ответа полностью значением ноль:

client_max_body_size 0;

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

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

304 Not Modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера 304 Not Modified, то проблема, скорее всего, в пунктах:

• В секции server конкретного сайта включен ssi on (Подробнее в документации). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
• if_modified_since установить в before, то есть на уровне http или конкретного server прописать: if_modified_since before;

Правильность ответа 304 Not Modified можно проверить с помощью:

• Консоли разработчика браузера (F12) в разделе Network (Cеть) (не забываем перезагружать страницу);
  
• Или сторонних сервисов, например last-modified.com.

Client intended to send too large body

Решается с помощью увеличения параметра client_max_body_size

client_max_body_size 200m;

Как перезагрузить nginx

Для перезагрузки NGINX используйте restart или reload.
Команда в консоли:

service nginx reload

либо

/etc/init.d/nginx reload

либо

nginx -s reload

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

nginx -s reload

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

nginx -t 

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

1. Команда посылается серверу
2. Сервер анализирует конфигурационный файл
3. Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
4. Если конфигурация содержит ошибки, то при использовании
   1. restart процесс перезагрузки сервера прерывается, сервер не запускается
   2. reload сервер откатывается назад к старой конфигурации, работа продолжается

Короче говоря, restart обрывает работу резко, reload делает это плавно.
Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.

Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой nginx -t, например:

nginx -t && service nginx reload

или

nginx -t && nginx -s reload

Как вместо 404 ошибки делать 301 редирект на главную

error_page 404 = @gotomain;

location @gotomain {
  return 301 /;
}

Как в NGINX сделать редирект на мобильную версию сайта

Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).

### Устанавливаем переменную в 0. В неё пишем 1, если обнаружили мобильную версию браузера
set $mobile_rewrite 0;

if ($http_user_agent ~* "(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
  set $mobile_rewrite 1;
}

if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-(n|u)|c55/|capi|ccwa|cdm-|cell|chtm|cldc|cmd-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-s|devi|dica|dmob|do(c|p)o|ds(12|-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(-|_)|g1 u|g560|gene|gf-5|g-mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-(m|p|t)|hei-|hi(pt|ta)|hp( i|ip)|hs-c|ht(c(-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i-(20|go|ma)|i230|iac( |-|/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |/)|klon|kpt |kwc-|kyo(c|k)|le(no|xi)|lg( g|/(k|l|u)|50|54|-[a-w])|libw|lynx|m1-w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|-([1-8]|c))|phil|pire|pl(ay|uc)|pn-2|po(ck|rt|se)|prox|psio|pt-g|qa-a|qc(07|12|21|32|60|-[2-7]|i-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny|va)|sc(01|h-|oo|p-)|sdk/|se(c(-|0|1)|47|mc|nd|ri)|sgh-|shar|sie(-|m)|sk-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h-|v-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-|tdg-|tel(i|m)|tim-|t-mo|to(pl|sh)|ts(70|m-|m3|m5)|tx-9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas-|your|zeto|zte-)") {
  set $mobile_rewrite 1;
}
### Мобильный барузер обнаружен, редиректим на мобильный поддомен, в моём случае, m.example.com
if ($mobile_rewrite = 1) {
    rewrite ^ http://m.example.com/$request_uri redirect;
    break;
} 

Как в NGINX включить поддержку WebP

Чтобы включить поддержку WebP, нужно прописать в секции http:

    # Прописываем маппинг для WebP, если он поддерживается браузером
    map $http_accept $webp_ext {
        default "";
        "~*webp" ".webp";
    }

Теперь, в секции server можно использовать:

location ~* ^.+.(png|jpe?g)$ {
    expires 365d; # Включаем браузерный кеш на год для изображений
    add_header Vary Accept; # Даём заголовок, что акцептируем запрос
    try_files $uri$webp_ext $uri =404; # Пробуем сначала искать версию изображения .webp
}

Полезные материалы и ссылки

Настройка NGINX под WP Super Cache

Конвертер правил .htaccess (Apache) в NGINX

Весьма полезный сервис, который поможет cконвертировать правила из .htaccess в NGINX. Результат, возможно, придётся донастроить вручную, но, в целом, он весьма удобен в применении.
Вот как описывают сервис сами авторы:

Сервис предназначен для перевода конфигурационного файла Apache .htaccess в инструкции конфигурационного файла nginx.

В первую очередь, сервис задумывался как переводчик инструкций mod_rewrite с htaccess на nginx. Однако, он позволяет переводить другие инструкции, которые можно и резонно перевести из Apache в nginx.

Инструкции, не относящиеся к настройке сервера (например, php_value), игнорируются.

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

Результат перевода следует обязательно проверить вручную, а затем разместить в секции server {} конфигурационного файла nginx.

Замечания и предложения по улучшению ждем, как обычно, на [email protected] 😉

Перейти в конвертер из .htaccess Apache в NGINX