Nginx если файл не существует
Configure NGINX and NGINX Plus to serve static content, with type-specific root directories, checks for file existence, and performance optimizations.
This section describes how to configure NGINX and NGINX Plus to serve static content, how to define which paths are searched to find requested files, how to set up index files, and how to tune NGINX and NGINX Plus, as well as the kernel, for optimal performance.
Optimizing Performance for Serving Content
Loading speed is a crucial factor of serving any content. Making minor optimizations to your NGINX configuration may boost the productivity and help reach optimal performance.
Enabling tcp_nodelay
The tcp_nodelay directive allows override of Nagle’s algorithm, originally designed to solve problems with small packets in slow networks. The algorithm consolidates a number of small packets into a larger one and sends the packet with a 200 ms delay. Nowadays, when serving large static files, the data can be sent immediately regardless of the packet size. The delay also affects online applications (ssh, online games, online trading, and so on). By default, the tcp_nodelay directive is set to on which means that the Nagle’s algorithm is disabled. Use this directive only for keepalive connections:
Trying Several Options
The try_files directive can be used to check whether the specified file or directory exists; NGINX makes an internal redirect if it does, or returns a specified status code if it doesn’t. For example, to check the existence of a file corresponding to the request URI, use the try_files directive and the $uri variable as follows:
The file is specified in the form of the URI, which is processed using the root or alias directives set in the context of the current location or virtual server. In this case, if the file corresponding to the original URI doesn’t exist, NGINX makes an internal redirect to the URI specified by the last parameter, returning /www/data/images/default.jpg .
The last parameter can also be a status code (directly preceded by the equals sign) or the name of a location. In the following example, a 404 error is returned if none of the parameters to the try_files directive resolve to an existing file or directory.
In the next example, if neither the original URI nor the URI with the appended trailing slash resolve into an existing file or directory, the request is redirected to the named location which passes it to a proxied server.
For more information, watch the Content Caching webinar on‑demand to learn how to dramatically improve the performance of a website, and get a deep‑dive into NGINX’s caching capabilities.
Enabling sendfile
By default, NGINX handles file transmission itself and copies the file into the buffer before sending it. Enabling the sendfile directive eliminates the step of copying the data into the buffer and enables direct copying data from one file descriptor to another. Alternatively, to prevent one fast connection from entirely occupying the worker process, you can use the sendfile_max_chunk directive to limit the amount of data transferred in a single sendfile() call (in this example, to 1 MB):
Root Directory and Index Files
Here, NGINX searches for a URI that starts with /images/ in the /www/data/images/ directory in the file system. But if the URI ends with the .mp3 or .mp4 extension, NGINX instead searches for the file in the /www/media/ directory because it is defined in the matching location block.
You can list more than one filename in the index directive. NGINX searches for files in the specified order and returns the first one it finds.
The $geo variable used here here is a custom variable set through the geo directive. The value of the variable depends on the client’s IP address.
To return the index file, NGINX checks for its existence and then makes an internal redirect to the URI obtained by appending the name of the index file to the base URI. The internal redirect results in a new search of a location and can end up in another location as in the following example:
Here, if the URI in a request is /path/ , and /data/path/index.html does not exist but /data/path/index.php does, the internal redirect to /path/index.php is mapped to the second location. As a result, the request is proxied.
Optimizing the Backlog Queue
One of the important factors is how fast NGINX can handle incoming connections. The general rule is when a connection is established, it is put into the “listen” queue of a listen socket. Under normal load, either the queue is small or there is no queue at all. But under high load, the queue can grow dramatically, resulting in uneven performance, dropped connections, and increased latency.
Displaying the Listen Queue
To display the current listen queue, run this command:
The output might be like the following, which shows that in the listen queue on port 80 there are 10 unaccepted connections against the configured maximum of 128 queued connections. This situation is normal.
In contrast, in the following command the number of unaccepted connections ( 192 ) exceeds the limit of 128 . This is quite common when a web site experiences heavy traffic. To achieve optimal performance, you need to increase the maximum number of connections that can be queued for acceptance by NGINX in both your operating system and the NGINX configuration.
Tuning the Operating System
Increase the value of the net.core.somaxconn kernel parameter from its default value ( 128 ) to a value high enough for a large burst of traffic. In this example, it’s increased to 4096 .
For FreeBSD, run the command:
Run the command:
Use a text editor to add the following line to /etc/sysctl.conf :
Tuning NGINX
If you set the somaxconn kernel parameter to a value greater than 512 , change the backlog parameter to the NGINX listen directive to match:
nginx вначале решает, какой из серверов должен обработать запрос. Рассмотрим простую конфигурацию, где все три виртуальных сервера слушают на порту *:80:
Параметр default_server появился в версии 0.8.21. В более ранних версиях вместо него следует использовать параметр default .
Следует иметь в виду, что сервер по умолчанию является свойством слушающего порта, а не имени сервера. Подробнее это обсуждается ниже.
Как предотвратить обработку запросов без имени сервера
Если запросы без поля “Host” в заголовке не должны обрабатываться, можно определить сервер, который будет их отклонять:
Здесь в качестве имени сервера указана пустая строка, которая соответствует запросам без поля “Host” в заголовке, и возвращается специальный для nginx код 444, который закрывает соединение.
Начиная с версии 0.8.48 настройка server_name "" является стандартной и может явно не указываться. В более ранних версиях в качестве стандартного имени сервера выступало имя машины (hostname).
Определение виртуального сервера по имени и IP-адресу
Рассмотрим более сложную конфигурацию, в которой некоторые виртуальные серверы слушают на разных адресах:
Как уже говорилось, сервер по умолчанию является свойством слушающего порта, поэтому у разных портов могут быть определены свои серверы по умолчанию:
Конфигурация простого сайта PHP
Теперь посмотрим на то, как nginx выбирает location для обработки запроса на примере обычного простого PHP-сайта:
nginx вначале ищет среди всех префиксных location’ов, заданных строками, максимально совпадающий. В вышеприведённой конфигурации указан только один префиксный location “ / ”, и поскольку он подходит под любой запрос, он и будет использован, если других совпадений не будет найдено. Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location. Если запросу не соответствует ни одно из регулярных выражений, nginx использует максимально совпавший префиксный location, найденный ранее.
Следует иметь в виду, что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов. Так делается потому, что аргументы в строке запроса могут быть заданы различными способами, например:
Кроме того, в строке запроса можно запросить что угодно:
Теперь посмотрим, как бы обрабатывались запросы в вышеприведённой конфигурации:
Директивы break, if, return, rewrite и set обрабатываются в следующем порядке:
- последовательно выполняются директивы этого модуля, описанные на уровне server;
- в цикле:
- ищется location по URI запроса;
- последовательно выполняются директивы этого модуля, описанные в найденном location;
- цикл повторяется, если URI запроса изменялся, но не более 10 раз.
Директивы
Синтаксис: break; Умолчание: — Контекст: server , location , if Если директива указана внутри location, дальнейшая обработка запроса продолжается в этом location.
Синтаксис: if ( условие ) < . > Умолчание: — Контекст: server , location Проверяется указанное условие . Если оно истинно, то выполняются указанные в фигурных скобках директивы этого модуля и запросу назначается конфигурация, указанная внутри директивы if . Конфигурации внутри директив if наследуются с предыдущего уровня конфигурации.
В качестве условия могут быть заданы:
-
имя переменной; ложными значениями переменной являются пустая строка или “ 0 ”;
Синтаксис: return код [ текст ];
return код URL ;
return URL ;Умолчание: — Контекст: server , location , if Завершает обработку и возвращает клиенту указанный код . Нестандартный код 444 закрывает соединение без передачи заголовка ответа.
Начиная с версии 0.8.42 можно задать либо URL перенаправления (для кодов 301, 302, 303, 307 и 308) либо текст тела ответа (для остальных кодов). В тексте тела ответа и URL перенаправления можно использовать переменные. Как частный случай, URL перенаправления может быть задан как URI, локальный для данного сервера, при этом полный URL перенаправления формируется согласно схеме запроса ( $scheme ) и директивам server_name_in_redirect и port_in_redirect.
До версии 0.7.51 можно было возвращать только следующие коды: 204, 400, 402 — 406, 408, 410, 411, 413, 416 и 500 — 504.
См. также директиву error_page.
Синтаксис: rewrite regex замена [ флаг ]; Умолчание: — Контекст: server , location , if Необязательный параметр флаг может быть одним из:
Полный URL перенаправлений формируется согласно схеме запроса ( $scheme ) и директив server_name_in_redirect и port_in_redirect.
Если же эти директивы поместить в location “ /download/ ”, то нужно заменить флаг last на break , иначе nginx сделает 10 циклов и вернёт ошибку 500:
Если в строке замены указаны новые аргументы запроса, то предыдущие аргументы запроса добавляются после них. Если такое поведение нежелательно, можно отказаться от этого добавления, указав в конце строки замены знак вопроса, например:
Если в регулярном выражении встречаются символы “ > ” или “ ; ”, то всё выражение следует заключить в одинарные или двойные кавычки.
Синтаксис: set $переменная значение ; Умолчание: — Контекст: server , location , if Устанавливает значение указанной переменной. В качестве значения можно использовать текст, переменные и их комбинации.
Определяет, нужно ли писать в лог предупреждения о неинициализированных переменных.
Внутреннее устройство
будут транслированы в такие инструкции:
можно сделать на одну инструкцию меньше, если в регулярном выражении перенести первый слэш внутрь скобок:
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Конфигурация Nginx и подводные камни
Не важно новичок вы или опытный профессионал в настройке nginx, рано или позно вы можете столкнутся с непонятными проблемами при написании конфигов. Это подводные камни конфигурции nginx и от них никуда не уйти. Далее в этой статье мы рассмотрим эти ситуации и способы их обхода.
В интернете полно некорректных, зачастую неправильных, инструкций по настройке сервера nginx. Нельзя им слепо следовать не понимая, что делает та или иная директива. Множество инструкций и примеров конфигураций просто ужасны, написаны на коленки и не читабельны. Эта статья была написана как ответ на такие инструкции, которые направляют новичков по ложному пути, запутывая их окончательно и заставля задавать одни и теже вопросы на форумах и IRC каналах.
Root внутри блока Location
ПЛОХО:
Это работает. Помещать директиву root внутри блока location это нормально и правильно. Что не правильно в данном случае, дак это то, что директива root повторяется в каждом блоке location , следовательно, если ни один из локейшенов не сработает, то у нас директива root вообще не будет задана.
Правильным решение является вынос директивы root из блоков location в начало блока server . Ниже приведен пример как надо делать правильно:
ХОРОШО:
Повторяющиеся директивы Index
ПЛОХО:
ХОРОШО:
Ипсользование условий If - зло.
Есть небольшая статья по применению условного оператора if , описывающая почему использование if крайне не рекомендуется. Статья называется if - это Зло. . Очень рекомендуем прочитать вам эту статью, и посмотреть на примерах почему оператор if это зло.
ПЛОХО:
ХОРОШО:
Проверка что файл cуществует
Использовать if для проверки наличия файла это просто ужасно. В nginx для этого есть специальная директива try_files , которая делает жизнь на много проще.
ПЛОХО:
ХОРОШО:
Использование директивы try_files подразумевает, что вы можете тестировать не одно условие, а последовательность (цепочку) из нескольких условий. Например, в данном примере проверяется существует-ли файл по указанному $uri , если файл не найден, то проверяется существует-ли директория $uri/ , если и ее нет, то проверка идет дальше по цепочке. Если ниодно условие так и не стработало, то по-умолчанию, nginx выполнит последнее условие в цепочке (в данном случае это /index.html ). Вот еще один повод, чтобы избавиться от использования директивы if .
Шаблон Front Controller и CMS движки, которые его используют
Шаблон Front Controller сейчас очень популярен и используется во многих CMS движках и современных фреймворках на PHP. Далее показан простой пример, применимый для CMS Drupal, Joomla и др.:
ВНИМАНИЕ Названия параметров могут отличаться для разных CMS. Например:
Некоторым движкам вообще не нужны параметры и они вытаскивают всю необходимую информацию из строки запроса REQUEST_URI (например WordPress):
Конечно, эти параметры для других CMS и фреймворков могут отличаться, здесь приведен лишь общий пример. В некоторых ситуациях вам понадобится более комплексное решение, пробуйте и экспериментируйте.
Также вы можете вообще убрать проверку на наличие директории $uri/ , если вам эта проверка не нужна.
Перенаправление всех запросов в PHP
Многие примеры конфигурации nginx рекомендуют все запросы оканчивающиеся на .php перенаправлять (проксировать) в интерпретатор PHP. Но это, вообще-то, потенциальная угроза безопасности на множестве конфигураций PHP, которая может привести к выполнению вредоносного кода на сервере.
Проблемная секция обычно выглядит так:
Здесь каждый запрос оканчивающийся на .php перенаправляется в бекэнд на FastCGI. Угроза безопасности здесь в том, что конфигурация PHP по-умолчанию всегда пытается выяснить какой файл вы хотите выполнить, даже если запрос идет на не существующий файл.
Например, вот запрос к файлу /forum/avatar/1232.jpg/file.php которого на самом деле нет на сервере, но зато на сервере есть файл /forum/avatar/1232.jpg . В данном случае по-умолчанию PHP обработает этот файл /forum/avatar/1232.jpg . А теперь представьте, что в этом файле содержится вредоносный код для PHP? Соответсвенно он будет выполнен!
Чтобы это исключить, необходимо:
- Установить директиву cgi.fix_pathinfo=0 в php.ini. Это заставит интерпретатор PHP остановиться на выполнении первого запроса и при отсутствии запрашиваемого ресурса не идти далее по цепочке.
- Убедится что nginx отправляет в PHP на обработку только определенные файлы, расчитанные на такую обработку. А не все подряд:
- запретить обработку интерпретатором PHP всех файлов из директории куда пользователи загружают свои файлы:
- Использовать директиву try_files чтобы отбросить запросы на не существующие файлы:
- Использовать вложенные секции location , чтобы исключить проблемные условия:
FastCGI путь в SCRIPT_FILENAME
Во многих руководствах по настройке nginx используются абсолютные пути для указания корневой директории сайта. Это частая практика в PHP блоках конфигурации nginx. Но в подключаемых конфигах для настройки парметров FastCGI include fastcgi_params; этого делать не стоит, для этого есть встроенная переменная $document_root .
ПЛОХО:
ХОРОШО:
Вы спросите, где задается переменная $document_root ? Она задается директивой root , которая должна присутствовать в блоке server . И если в вашем конфиге ее там нет, тогда вы наткнулись на первый подводный камень описанный нами в начале этой статьи: Root внутри блока Location , исправляйте ваш конфиг =)
Не считайте себя гуру в написании регулярных выражений, в любом случае вы ошибетесь и не заметите этого. В сложном регулярном выражении нельзя быть уверенным на сто процентов. Поэтому самое простое, это исключить такие выражения из использования, в пользу более чистого и понятного кода. Вот пример:
ПЛОХО:
ХОРОШО:
ЕЩЕ ЛУЧШЕ:
Посмотрети, на первый вариант, потом на последний, потом опять на первый и опять на последний. Ну что? Первый реврайт запоминает полный путь без учета начального слеша и затем помещает этот путь вместо плейсхолдера $1 . Однако используя встроенную переменную $request_uri мы спокойно можем избавится от всей этой магии с регулярными выражениями.
BAD:
ХОРОШО:
Проксируем все подряд
ПЛОХО:
FFFUUU. В этом примере мы перенаправляем ВСЕ ПОДРЯД. в PHP. Зачем? Для Apache это простительно, но вам нет. Директива try_files придумана не просто так, она проверяет наличие запрашиваемого ресурса (файла) в определнной последовательности. Это значит, что nginx может проверить первое условие, потом второе и т.д. пока по цепочке не дойдет до конца. И если ничего не сработало, то по-умолчанию выполнится последннее условие в цепочке проверок. А это значит, что интерепретатор PHP будет вызываться не каждый раз, а только тогда, кода это действительно необходимо. Обработка запросов при этом ускорится многократно!
Представьте, что идет несколько однотипных запросов на получение файла картинки размеров 1Мб и в примере выше каждый такой запрос будет перенаправлен в PHP.
Ниже показано как избавиться от этого безобразия:
ХОРОШО:
ТОЖЕ ХОРОШО:
Просто, не правда-ли? Мы видим что, если запрашиваемый URI существует, то он будет отработан nginx. Если нет, то проверяется существует ли вообще такая директория $uri/ . Если нет, то уже тогда, по-умолчанию, запрос будет направлен в /index.php и обработан PHP.
Теперь представьте сколько на вашем сайте статического контента (картинок, css-стилей, js-скриптов и т.д.), сколько лишних запросов вы отсекли от обработки через PHP?
Изменения в конфиге не работают
Браузер кеширует запросы! Ваша конфигурация может быть идельной и без единой ошибки, но вы по-прежнему бъетесь головой об стену и пытаетесь понять почему у вас ничего не работает? Что не так? Ответ на этот вопрос: кеш браузера. Когда вы загружаете что-либо, браузер сохраняет это в своем кеше. Он также сохраняет то, как был обработан скачанный файл. Если вы в конфигурации nginx играетесь с блоками <> , скорее всего вы столкнетесь с проблемами кеширования запросов браузером.
- [Вариант 1] в Firefox нажмите Ctrl+Shift+Delete, проерьте кешь, нажмите кнопку Очистить. Если у вас другой браузер, то погуглите как очищается кеш в нем.
- [Варинт 2] Используйте для тестирования curl.
Если действия выше не помогают, и вы запускаете nginx на виртуальной машине, причина может быть в sendfile . Просто закомментируйте директиву или установите ее в значение в off . Эта директива может располагаться где-то в вашем конфиге nginx в файле nginx.conf :
Более подробно на эту тему смотрите в официальной документации по nginx.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Создание виртуального сервера в nginx
Эта заметка является далеко не исчерпывающей по своему содержанию, более того, некоторые моменты сознательно опущены для простоты понимания. Заметка появилась всего-лишь по просьбе коллеги написать краткую простую инструкцию о том, как добавить виртуальный сервер в nginx для разных доменных имен.
Более полная информация, как обычно, содержится в разделе "Веб-сервер" руководства администратора nginx.
Примечание. В заметке речь идет от веб-сервере nginx, установленном на ОС CentOS 6.5
Виртуальный сервер в nginx описывается в файле конфигурации, размещение которого зависит от операционной системы. По умолчанию файл конфигурации называется nginx.conf и может лежать в одном из каталогов:
В данном случае это каталог /etc/nginx .
Файл конфигурации состоит из директив, которые могут быть как простыми - в виде одной строки, так и блочными - выделяемыми фигурными скобками <> , и содержащими в себе простые.
Каждая простая директива должна оканчиваться точкой с запятой ; (частая ошибка - не указывается точка с запятой после редактирования файла конфигурации, что приводит к ошибке запуска веб-сервера).
Еще одним преимуществом отдельного файла для описания виртуального сервера будет являться "чистота" файла. То есть отсутствие лишних директив и акцентирование только на описании непосредственно сервера.
Описание виртуального сервера в файле конфигурации может иметь много особенностей, зависящих от контента, используемого на веб-вервере, размещения этого контента, от технологических моментов работы веб-приложения (например, используемый язык программирования на стороне сервера). Здесь рассматриваются самые общие вопросы конфигурации. За более подробной информацией можно обратиться к документации по директиве server .
При описании нового виртуального сервера следует исходить из того, что в конфигурации nginx уже прописан сервер по умолчанию примерно следующим образом (закомментированные директивы опущены):
- server_name - имя сервера (возможно так же указание нескольких серверов через пробел);
- listen - прослушиваемый порт (может также указываться, как ip-адрес:порт).
При описании дополнительных виртуальных серверов можно и опустить директиву listen . Тогда прослушиваться будет порт по умолчанию. В свою очередь, порт по умолчанию - это может быть порт, указанный в какой-нибудь конфигурации с параметром default_server , как, например:
Если же параметр default_server ни где не указан, то портом по умолчанию считается порт, указанный в конфигурации для первого сервера. Дополнительно можно акцентировать, что параметр default_server относится только к прослушиваемому порту, но не к имени сервера. Так как при установке nginx создается файл конфигурации по умолчанию, в котором уже прописан сервер для порта 80 , то можно считать его портом по умолчанию.
Таким образом, если порт для дополнительного сервера не меняется, то можно начать конфигурацию с директивы server_name .
root определяет корневой каталог файловой системы сервера для заданного виртуального сервера. Надо помнить, что выход за корневой каталог не возможен. То есть, например, указание ../1.jpg не вернет ожидаемого файла, если этот относительный путь указан относительно корневого каталога.
Директива location - блочная, задает конфигурацию сервера в зависимости от запрошенного URI, проверяя его на соответствие заданному в директиве выражению. Это выражение может определяться либо в виде префиксной подстроки, либо в виде регулярного выражения, либо может указываться полное соответствие при помощи модификатора = . Внутри директивы server может быть более одной директивы location .
При поиске соответствия URI сначала проверяются директивы location , значение которых задано в виде префикса. Конфигурация location с самой длинной совпавшей строкой запоминается. После этого идет сравнение со значениям в виде регулярного выражения в порядке, указанном в конфигурационном файле. При первом же совпадении URI с регулярным выражением поиск останавливается и конфигурация location с этим значением применяется. Если же ни одно из регулярных выражений не совпало, то применяется конфигурация location , запомненного при сравнении по префиксу. Если существует значение директивы location с использованием модификатора = , то при при первом же полном соответствии запрошенного URI этому значению поиск останавливается.
Самое простое значение директивы location - это / , что означает конфигурацию для всех URI, указанных для server_name .
Чуть подробнее директива location рассматривается далее.
Если сайт имеет статический контент и нет необходимости размещать какие-либо ресурсы за пределами root , то директива location может либо не понадобиться вовсе, если указать root в контексте server , либо location может иметь самую простую реализацию:
Здесь директива index определяет файлы, которые могут быть использованы как индексные файлы, размещенные по запрашиваемому пути.
Файл конфигурации для каждого сервера будет предельно прост:
Это нормально, что страницы с текстом на разных языках будут размещаться в своих каталогах. Но ведь стили, скрипты, медиа и другие ресурсы вероятно должны быть общими, если контент одинаковый. Нет смысла дублировать ресурсы в каждом из каталогов, разумнее будет поместить их в общий. Однако, как было сказано выше, выход запроса за root не возможен. Здесь и пригодиться директива location , которая переопределит root , когда на сервер поступает запрос ресурса.
Пусть для рассматриваемого сайта стили запрашиваются по пути /css , скрипты - /js , медиа - /images . При этом физически на сервере созданы одноименные каталоги по пути /usr/share/nginx/html/example . Тогда для каждого из серверов необходимо прописать соответствующие location :
Чтобы не повторять в настройках каждого сервера одно и тоже, можно повторяемые директивы вынести в отдельный файл и подключать его в нужном месте. Например, создать файл example_common.conf с содержимым:
а затем подключать его:
Здесь можно обратить внимание на то, что пути /css , /js , /images чисто условны. То есть, размещать в этих каталогах можно все, что угодно и это будет выведено в соответствующем запросе. Но есть способ привязать каталоги к конкретному типу ресурсов. Для этого используются регулярные выражения при указании пути в location . Например, указание пути:
Подобные настройки для скриптов и изображений могут выглядеть следующим образом:
Здесь приведены простые примеры для того, чтобы представить, как работает директива location . Более подробнее можно почитать в документации по location .
Как правило, для работы с nginx используется php-fpm , который является реализацией FastCGI для PHP. Взаимодействие nginx и php-fpm может осуществляться как по TCP/IP протоколу, так и через сокет (Unix Socket). Конкретно, как будет работать php-fmp указывается в его файле конфигурации, и соответствующим образом должно быть настроено в nginx .
- fastcgi_pass - адрес по которому FastCGI-приложение ожидает запрос исполняемого ресурса;
- fastcgi_param - устанавливает значение параметра, передаваемого FastCGI. В данном случае устанавливается параметр SCRIPT_FILENAME значением $document_root$fastcgi_script_name , где в свою очередь:
- $document_root - переменная, содержащая root текущего запроса;
- $fastcgi_script_name - имя запрашиваемого ресурса. Если в запросе имя не указано (запрос заканчивается на / ), то будет подставлено значение, определенное директивой index . Так как index может определять не только исполняемый ресурс, но и статические страницы - *.html, *htm, то для FastCGI можно прописать "свой" индекс в директиве fastcgi_index .
Здесь же include подключает файл fastcgi_params (обычно расположенный рядом с nginx.conf ), в котором необходимые параметры FastCGI определяются соответствующими значениями сервера nginx . Этими параметрами, например, могут быть параметры запроса ( $query_string ), метод запроса ( $request_method ) и многие другие.
В случае, когда php-fpm настроен на работу через сокет, директива fastcgi_pass будет выглядеть следующим образом:
Тут надо понимать, что путь к сокету fastcgi.socket может отличаться от приведенного в примере.
Enabling tcp_nopush
Читайте также: