nginx location php location
Рекомендации по настройке Nginx
Пятница, 24 Апрель 2015 00:00
Nginx представляет собой постоянно развивающийся веб-сервер, стремительно набирающий популярность. В июле 2013 года nginx стал самым используемым веб-сервером среди 1000 самых популярных сайтов. К сожалению, в документации nginx описан интерфейс приложения и не расписано, как работает сам nginx. В этой статье рассмотрим наиболее важные аспекты настройки nginx в логическом порядке.
Основы настройки Nginx
Nginx является простым сервером HTTP, однако, большинство людей раньше использовали Apache привыкли к LAMP, поэтому существует несколько вещей в настройке nginx, которых нужно остерегаться при использовании данного веб-сервера. Важными факторами является, во-первых, то, что nginx является инвертированным прокси-сервером и во-вторых HTTP сервером, в первую очередь это касается не файлов, а URL, что изменяет способ, которым будет настраиваться nginx.
Первое, что нужно знать, файл конфигурации nginx использует иерархию наследования, директивы, указанные в верхнем блоке, будут принимать значения нижних блоков, в качестве значения по умолчанию, следовательно, нужно указывать директивы в верхних блоках, если это возможно. Директивы верхних блоков принимают значения по умолчанию, однако в большинстве случаев значение можно изменить.
Блоки имеют смысловое значение. Блок server в Apache рассматривается, как виртуальный хост. Блок location относится к URI.
При использовании документации ключевые слова определяют, в каком блоке может использоваться директива, как говорилось ранее, директиву лучше использовать в самом верхнем блоке.
Виртуальные хосты
Эти формы основные для виртуальных хостов, пример:
Здесь имеется два виртуальных хоста. Первый, когда drach.pro или любой под домен drach.pro, кроме www передаётся, как заголовок HOST в браузере. Дело в том, что nginx всегда будет выбирать наиболее точное соответствие и при посещении www.drach.pro это точно будет относиться ко второму блоку.
Это также означает, что можно создать виртуальных хост, который будет ловить все домены, без необходимого совпадения. Thankfully this is as simple as adding the default_server flag to the listen directive. This causes all request without a HOST header or without another vhost matching the HOST header to be sent to this vhost instead. Examples are requests accessing the IP directly or if someone points a random domain at your IP. Использование директивы server_name позволяет избежать подмены (использования фальшивых адресов) на уровне заголовка. Если Вас этот вопрос не волнует, конечно, можно не использовать эту директиву.
Блок Location
Запросы на /forum теперь успешно передаются на новый под домен, в то время, как запросы к файлам, не находящимся в /forum подаются по стандартному /home/drach.pro.
Обработка PHP
Однако ошибку можно исправить в PHP, задав cgi.fix_pathinfo=0 в файле php.ini.
В результате существующие файлы с расширением.php будут переданы через fastcgi на процессы PHP, запущенные на порте 9000.
Поисковая оптимизация
Когда выполнены установка и настройка, и уже всё работает, каждый из нас спрашивает себя, а будут ли поддерживаться ЧПУ (понятные человеку адреса) на моём сайте? Ведь в настоящее время использование ЧПУ существенно отражается на отношении поисковых систем к любым сайтам в интернете. Обычно, на сервере Apache используются перенаправления, прописанные в файле. htaccess, однако на сервере nginx нужно доработать файл конфигурации, причём зачастую получаем изящное решение в одну строку:
Запросы отладки
Nginx время от времени является сложным сервером, но благодаря журналу ошибок всегда можно понять, что пошло не так. Директива журнала ошибок в документации принимает второй аргумент. Это позволяет определить количество выходной информации nginx. Значение ошибок позволит Вам отладить большинство проблем.
Nginx location, примеры использования и принципу выбора location
Веб-сервером Nginx location выбирается сравнивая URI поступившего запроса с обозначением location
1) с полным URI сравниваются все выражения, не включающие регулярные выражения
2) сначала сверяются все блоки с =
3) если совпадений нет проверяется ^
и сразу задействуется самый длинный из них
4) не найдя таких Nginx ищет опять же самое длинное совпадение и резервирует результат поиска
5) проверка с учетом регулярных выражений — выбирается первое выражение среди подходящих под самый длинный префикс
6) при отсутствии результата используется блок, зарезервированный на шаге 4
Изменить эту логику и заставить какой-то блок обрабатываться вперед остальных проще всего используя = или ^
Переход в другой location
Перенаправление в другой блок выполняется за счет одной из приведенных ниже директив:
try_files
rewrite
error_page
Перенаправление за счет try_files
location /none <
root /var/sites/new;
>
Такого нет, далее следует поиск request.html и каталога request. Если таких нет, то запрос переадресуется в резервный location на страницу /none/index.html
Веб-сервер выдаст пользователю содержимое /var/sites/new/none/index.html
За счет rewrite
Запрос к example.com/newrequest/someurl будет обрабатываться location / без какой-либо переадресации
return работает также, но используется обычно для переадресации на URL, а не в другой location
Его добавляют, когда нужно перенаправить пользователя на другой домен или другую версию сайта (например без www или с https)
За счет error_page
Это скорее не редирект, а способ задания собственных страниц ошибок. Перенаправление будет происходить каждый раз когда не найдена запрашиваемая страница
location / <
error_page 404 /somefolder/errorpage.html;
>
Практический пример поясняющие использование Nginx location взятый с официального сайта
Типовая конфигурация для сайта на PHP при которой применяется Nginx с FPM, статика обрабатывается самим веб-сервером, для изображений дополнительно задается кэширование.
server <
listen 80;
server_name example.com;
root /data/www;
location / <
index index.html index.php;
>
\.php$ <
fastcgi_pass localhost:9000;
…
При обращении к /data/www/script.html за отсутствием других совпадений будет выбран location /data/www, если в URL php скрипт он обработается другим блоком и запрос передастся на обработку на порт 9000, на котором работает PHP-FPM.
Для изображений будет выбран блок в котором устанавливается заголовок expires, затем запрос обрабатывается тем выражением, которое задано для /, т.е. картинки будут запрашиваться в /data/www, если их там нет возникнет ошибка 404.
Полезные сниппеты для Nginx конфигов
Готовые конфиги:
Команды Nginx
Основные команды для выполнения базовых операций во время работы Nginx.
Location блок на PHP
Простой шаблон для быстрой и легкой установки PHP, FPM или CGI на ваш сайт.
Rewrite и Redirection
Force www
Корректный способ определить удаленный сервер по домену без www и перенаправить его c www:
Также работает для HTTPS.
Force no-www
Корректный способ определить удаленный сервер по домену c www и перенаправить его без www:
Force HTTPS
Способ для переадресации с HTTP на HTTPS:
Force Trailing Slash
Данная строка добавляет слэш / в конце каждого URL, только в том случаее если в URL нет точки или параметров. Тоесть после example.com/index.php или example.com/do?some=123 слэш не поставится.
Редирект на страницу
Редирект на сайт
Редирект на определенный путь в URI
Производительность
Кэширование
Навсегда разрешить браузерам кэшировать статические содержимое. Nginx установит оба заголовка: Expires и Cache-Control.
Запретить кэширование браузерам (например для отслеживания запросов) можно следующим образом:
Gzip сжатие
Кэш файлов
Если у вас кешируется большое количество статических файлов через Nginx, то кэширование метаданных этих файлов позволит сэкономить время задержки.
SSL кэш
Подключение SSL кэширования позволит возобновлять SSL сессии и сократить время к следующим обращениям к SSL/TLS протоколу.
Поддержка Upstream
Активация кеширования c использованием Upstream подключений:
Мониторинг
По умолчанию Stub Status модуль не собирается, его сборку необходимо разрешить с помощью конфигурационного параметра —with-http_stub_status_module и активировать с помощью:
Данная настройка позволит вам получать статус в обычном текстовом формате по общему количеству запросов и клиентским подключениям (принятым, обработанным, активным).
Более информативный статус от Nginx можно получить с помощью Luameter, который несколько сложнее в установке и требует наличия Nginx Lua модуля. Это предоставит следующие метрики по различным конфигурационным группам в формате JSON:
Также для сбора статистики отлично подходит ngxtop.
Безопасность
Активация базовой аунтификации
Для начала вам потребуется создать пароль и сохранить его в обычной текстовом файле:
Затем установить найтройки для server/location блока, который необходимо защитить:
Открыть только локальный доступ
Защита SSL настроек
Прочее
Подзапросы после завершения
Распределение ресурсов между источниками
Самый простой и наиболее известный способ кросс-доменного запроса на ваш сервер:
How to serve html/php in nginx location
Heyo, front end guy moving website from shared hosting to SPA droplet. I have a Headless CMS in /build, a Node SendGrid Mailserver in /mail, and am trying to have some html and php in /wp-content/themes/webdev/projects/trackjob/point_card/. (it’s a php proxy) The reason is an old client used an iframe to this url from my old site and its just best to copy it over.
The card_api_js_v2.html will need to make an AJAX request to a php file in the same parent directory.
I am just getting more familiar with nginx. Advice?
Currently, I have this.
2 Answers 2
You are misunderstanding on how the root directive works. When you use this location block
and got a /wp-content/themes/webdev/projects/trackjob/point_card/card_api_js_v2.html incoming request, nginx concatenates the $document_root (which is /var/www/wp-content/themes/webdev/projects/trackjob/point_card ) and $uri (which is /wp-content/themes/webdev/projects/trackjob/point_card/card_api_js_v2.html ) variables and searches for the file /var/www/wp-content/themes/webdev/projects/trackjob/point_card/wp-content/themes/webdev/projects/trackjob/point_card/card_api_js_v2.html (which is obviously would not be found). This is the main difference between the root and alias nginx directives. Your location block should be the
Update
If you need to serve the PHP scripts inside this location, change it to
Алгоритмы выбора блоков server и location в Nginx
Nginx – один из популярнейших веб-серверов в мире. Он может обрабатывать высокие нагрузки и большое количество одновременных подключений. Также Nginx можно использовать в качестве балансировщика, почтового сервера или обратного прокси.
Данный мануал расскажет, как Nginx обрабатывает клиентские запросы. Понимание этого механизма поможет вам оптимизировать обработку запросов.
Конфигурация блоков Nginx
Nginx логически делит конфигурации, предназначенные для обслуживания различного контента, на блоки, которые собираются в иерархическую структуру. Обработку каждого запроса клиента Nginx начинает с определения необходимых блоков конфигурации. Этот процесс принятия решений будет центральной темой данного мануала.
Основные блоки, которые мы обсудим, называются server и location.
Блок server – это подмножество конфигурации Nginx, которая определяет виртуальный сервер, используемый для обработки запросов определенного типа. Администраторы часто настраивают несколько блоков server, где каждый блок обрабатывает соединения на основе запрошенного домена, порта и IP-адреса.
Блок location находится в блоке server и используется для того, чтобы Nginx мог обрабатывать запросы для разных ресурсов и URI родительского сервера. С помощью этого блока администратор может разделить пространство URI требуемым образом. Это чрезвычайно гибкая модель.
1: Поиск блока server
Nginx позволяет определять несколько блоков server, которые функционируют как отдельные экземпляры виртуальных веб-серверов. Потому Nginx необходима процедура определения того, какой из этих блоков будет использоваться для обработки запроса.
Для этого Nginx применяет определенную систему проверок, которые используются для поиска наилучшего совпадения. Основные директивы блока server, которые помогают Nginx определить требуемый блок, – это listen и server_name.
Директива listen
Сначала Nginx смотрит на IP-адрес и порт запроса. Он сопоставляет эти значения с директивой listen каждого блока server и создает список блоков, которые могут обслужить запрос.
Директива listen обычно определяет IP-адрес и порт блока server. По умолчанию любой блок server, в котором нет директивы listen, получает параметры 0.0.0.0:80 (или 0.0.0.0:8080, если Nginx запускается обычным пользователем без полномочий root). Это позволяет таким блокам отвечать на запросы на любом интерфейсе по порту 80. Но это стандартное значение не имеет большого веса в процессе выбора блока.
Директива listen может указывать:
Последний вариант, как правило, используется только при передаче запросов между разными серверами.
Сначала Nginx попробует выбрать блок на основе директивы listen, используя следующие правила:
Важно понимать, что Nginx будет оценивать директиву server_name только тогда, когда ему нужно выбрать один блок из списка блоков, отобранных по директиве listen. Например, если домен example.com размещен на порту 80 по адресу 192.168.1.10, запрос на example.com всегда будет обслуживаться первым блоком в пример ниже, несмотря на директиву server_name во втором блоке.
Если же Nginx отобрал несколько блоков с одинаковым уровнем специфичности, далее он проверит директиву server_name.
Директива server_name
Для дальнейшей оценки запросов, имеющих одинаковые определения директивы listen, Nginx проверяет заголовок Host запроса. Это значение содержит домен или IP-адрес, который запрашивает клиент.
Nginx ищет наилучшее совпадение этого значения в директиве server_name каждого блока, прошедшего предыдущий этап отбора. Nginx оценивает эту директиву по этой формуле:
Для каждой комбинации IP-адреса и порта существует блок server по умолчанию, который используется в случае, если веб-сервер не смог найти другой блок. Как правило, это либо первый блок в конфигурации, либо блок, который содержит параметр default_server как часть директивы listen (она переопределяет алгоритм поиска первого совпадения). Для каждой комбинации IP-адреса и порта может быть только одно объявление default_server.
Примеры
Если в конфигурации есть блок с директивой server_name, значение которой полностью совпадает с заголовком Host запроса, запрос передается на обработку этому блоку.
К примеру, если заголовок Host запроса – host1.example.com, веб-сервер выберет для его обслуживания второй блок server:
Если Nginx не находит точных совпадений, он будет искать блок, в котором server_name начинается со специального символа. Если Nginx найдет несколько совпадений, для обслуживания запроса будет использоваться наиболее точное из них. Например, если в запросе указан заголовок Host www.example.org, Nginx выберет второй блок:
Если найти блок по специальному символу в начале директивы не удалось, Nginx будет искать блок, значение server_name которого заканчивается специальным символом. Если он найдет несколько совпадений, он использует наиболее точное из них. К примеру, для обработки запроса с заголовком Host www.example.com веб-сервер использует третий блок server:
Если найти блок по специальному символу не получилось, Nginx будет искать директивы server_name, которые содержат регулярные выражения. Для обработки запроса будет использоваться первый блок, чье регулярное выражение в директиве совпало с заголовком запроса.
К примеру, для обслуживания запроса с заголовком Host www.example.com веб-сервер выберет второй блок server:
Если ни один из механизмов поиска не дал результатов, веб-сервер применит блок server по умолчанию.
2: Поиск блока location
Похожий алгоритм Nginx использует для поиска блока location.
Синтаксис блока location
Для начала следует ознакомиться с синтаксисом блока location. Блоки location находятся внутри блоков server (или других блоков location) и используются для определения способа обработки URI запроса (той части запроса, которая идет после имени домена или IP-адреса/порта).
Как правило, блок location имеет такой вид:
location_match в приведенном выше примере указывает, что Nginx должен проверить URI запроса. Наличие или отсутствие модификатора в приведенном выше примере влияет на то, как Nginx будет искать блок location.
Существуют такие модификаторы блоков location:
: такой блок будет интерпретироваться как совпадение по регулярному выражению с учетом регистра.
: если этот блок выбран как наиболее точное совпадение без регулярного выражения, то веб-сервер не будет проводить поиск по регулярному выражению.
Примеры синтаксиса блока location
В качестве примера поиска по префиксу можно использовать следующий блок location для ответа на запросы URI (/site, /site/page1/index.html, или /site/index.html).
Ниже вы найдете пример точного совпадения URI. Такой блок всегда будет использоваться для обслуживания URI
/page1. Он не будет отвечать на URI запроса /page1/index.html. Имейте в виду, что если выбран этот блок и запрос обслуживается индексной страницей, произойдет внутреннее перенаправление в другой блок location, который будет фактическим обработчиком запроса.
Интерпретация блока location как регулярного выражения с учетом регистра происходит в следующем примере. Этот блок будет использован для обработки запросов для /tortoise.jpg, но не для /FLOWER.PNG:
В следующем примере происходит интерпретация блока location как регулярного выражения без учета регистра. Такой блок сможет обработать запросы и для /tortoise.jpg, и для /FLOWER.PNG.
Следующий блок отключит поиск по регулярному выражению, если он выбран как наилучшее совпадение без регулярных выражений. Он может обрабатывать запросы для /costumes/ninja.html:
Как видите, модификаторы указывают, как следует интерпретировать блок location. Тем не менее, это не определяет алгоритм, который Nginx использует, чтобы решить, какому блоку location отправить запрос.
Выбор блока location
Nginx выбирает блок location аналогично тому, как он выбирает блок server. Он запускает процесс, который определяет лучший блок location для конкретного запроса. Понимание этого процесса является важнейшим требованием для надежной и точной настройки Nginx.
Имея в виду типы объявлений, которые мы рассмотрели выше, Nginx оценивает возможные контексты location путем сравнения URI запроса с каждым из местоположений. Он делает это, используя следующий алгоритм:
Важно понимать, что по умолчанию Nginx будет обслуживать регулярные выражения, отдавая предпочтение совпадениям по префиксам. Однако сначала он оценивает префиксные location-ы, позволяя администратору переопределять это поведение, указав location-ы с помощью модификаторов = и ^
Также важно отметить, что, хотя префиксные location-ы обычно выбираются на основе префикса максимальной длины (наиболее точного совпадения), Nginx перестанет оценивать регулярные выражения при обнаружении первого подходящего location-а. Это означает, что расположение в конфигурации блоков location с регулярными выражениями имеет огромное значение.
Оценка блоков location
Теперь нужно разобраться, в каких случаях оценка блоков location переходит к другим location-ам.
В целом, с того момента, как блок location выбран для обслуживания запроса, запрос обрабатывается целиком в этом контексте. Только выбранный блок location и унаследованные директивы определяют, как обрабатывается запрос, а соседние блоки location не могут вмешиваться в этот процесс.
Это общее правило, которое позволит вам спроектировать блоки location предсказуемым образом. Но при этом важно понимать, что бывают случаи, когда определенные директивы запускают новый поиск location-а внутри выбранного блока location. Исключения из правила могут привести к появлению непредсказуемых результатов.
Вот некоторые из директив, которые могут стать причиной такого поведения:
Директива index всегда приводит ко внутреннему перенаправлению, если она используется для обработки запроса. Точные совпадения location-а часто используются для ускорения процесса выбора, потому что это немедленно прекратит выполнение алгоритма. Однако если точное соответствие location-а будет каталогом, есть вероятность, что для фактической обработки запрос будет перенаправлен в другое место.
В этом примере первый location совпадает с URI запроса /exact, но директива index, унаследованная блоком, для обработки запроса инициирует внутреннее перенаправление ко второму блоку:
Если вы хотите, чтобы в приведенном выше случае запрос обрабатывался первым блоком, вам придется придумать другой метод попадания запроса в каталог. Например, вы можете установить для этого блока неправильный index и включить autoindex:
Это один из способов предотвратить перенаправление запроса из первого контекста, но он, вероятно, не подходит для большинства конфигураций. В основном точное совпадение в каталогах может быть полезно для таких операций, как переписывание запроса (что также приводит к новому поиску блока location).
Еще один случай, в котором может начаться новый поиск location-а – это использование директивы try_files. Эта директива говорит Nginx проверить наличие именованного набора файлов или каталогов. Последним параметром может быть URI, на который Nginx сделает внутреннее перенаправление.
Рассмотрим такую конфигурацию:
Если в приведенном выше примере запрос сделан для /blahblah, сначала получит запрос первый location. Он попытается найти файл с именем blahblah в каталоге /var/www/main. Если он не сможет найти его, он будет искать файл с именем blahblah.html. Затем он попытается узнать, есть ли в каталоге /var/www/main каталог blahblah/. Если все эти попытки не принесут результатов, запрос будет перенаправлен на /fallback/index.html. Это вызовет новый поиск location-а, и запрос перейдет второму блоку. Он обслужит файл /var/www/another/fallback/index.html.
Также на поиск блоков влияет директива rewrite. Обрабатывая rewrite без параметров или с параметром last, Nginx будет искать новый блок location на основе результатов перезаписи.
Например, если изменить последний пример и добавить в него перезапись, вы увидите, что запрос иногда передается непосредственно второму блоку location, не полагаясь на директиву try_files:
В приведенном выше примере запрос /rewriteme/hello будет сначала обрабатываться первым блоком location. Он будет переписан в /hello, и веб-сервер будет искать location. В этом случае он снова будет соответствовать первому location-у и обрабатываться директивой try_files (возможно, используя внутреннее перенаправление, чтобы вернуться к /fallback/index.html, если ничего не было найдено).
Однако если запрос сделан для /rewriteme/fallback/hello, первый блок снова будет отвечать запросу. При этом снова применяется перезапись, на этот раз в результате получится /fallback/hello. Затем запрос будет обслуживаться вторым блоком.
Похожая ситуация возникает с директивой return при отправке кодов состояния 301 или 302. Разница в этом случае заключается в том, что она приводит к совершенно новому запросу извне переадресации. Такая же ситуация может возникнуть с директивой rewrite при использовании флагов redirect или permanent.
Директива error_page может привести к внутреннему перенаправлению аналогично тому, как это делает try_files. Эта директива используется для определения действий, которые выполняются при обнаружении определенных кодов состояния. Эти действия, вероятно, никогда не будут выполнены, если установлена директива try_files, так как эта директива обрабатывает весь жизненный цикл запроса.
Рассмотрим такой пример:
root /var/www/main;
location / <
error_page 404 /another/whoops.html;
>
location /another <
root /var/www;
>
Каждый запрос (кроме тех, которые начинаются с /another) будет обрабатываться первым блоком, который будет обслуживать файлы из каталога /var/www/main. Однако если файл не найден (статус 404), произойдет внутреннее перенаправление на /another/whoops.html, что приведет к новому поиску блока location, который в конечном итоге окончится вторым блоком. Этот блок будет обслуживать файл /var/www/another/whoops.html.
Как видите, понимание условий, при которых Nginx запускает новый поиск блока location, может помочь предсказать поведение веб-сервера при выполнении запросов.