nginx — Как определить глобальную переменную в файле nginx conf — Qaru

Содержание

Как nginx обрабатывает запросы

Определение виртуального сервера по имени

nginx вначале решает, какой из серверов должен обработать запрос. Рассмотрим простую конфигурацию, где все три виртуальных сервера слушают на порту *:80:

server { listen 80; server_name example.org www.example.org; … } server { listen 80; server_name example.net www.example.net; … } server { listen 80; server_name example.com www.example.com; … }

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

server { listen 80 default_server; server_name example.net www.example.net; … }

Параметр появился в версии 0.8.21. В более ранних версиях вместо него следует использовать параметр .

Следует иметь в виду, что сервер по умолчанию является свойством слушающего порта, а не имени сервера. Подробнее это обсуждается ниже.

Как предотвратить обработку запросов без имени сервера

Если запросы без поля “Host” в заголовке не должны обрабатываться, можно определить сервер, который будет их отклонять:

server { listen 80; server_name «»; return 444; }

Здесь в качестве имени сервера указана пустая строка, которая соответствует запросам без поля “Host” в заголовке, и возвращается специальный для nginx код 444, который закрывает соединение.

Начиная с версии 0.8.48 настройка является стандартной и может явно не указываться. В более ранних версиях в качестве стандартного имени сервера выступало имя машины (hostname).

Определение виртуального сервера по имени и IP-адресу

Рассмотрим более сложную конфигурацию, в которой некоторые виртуальные серверы слушают на разных адресах:

server { listen 192.168.1.1:80; server_name example.org www.example.org; … } server { listen 192.168.1.1:80; server_name example.net www.example.net; … } server { listen 192.168.1.2:80; server_name example.com www.example.com; … }

В этой конфигурации nginx вначале сопоставляет IP-адрес и порт запроса с директивами listen в блоках server. Затем он сопоставляет значение поля “Host” заголовка запроса с директивами server_name в блоках server, которые соответствуют IP-адресу и порту. Если имя сервера не найдено, запрос будет обработан в сервере по умолчанию. Например, запрос , пришедший на порт 192.168.1.1:80, будет обработан сервером по умолчанию для порта 192.168.1.1:80, т.е. первым сервером, т.к. для этого порта не указан в списке имён серверов.

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

server { listen 192.168.1.1:80; server_name example.org www.example.org; … } server { listen 192.168.1.1:80 default_server; server_name example.net www.example.net; … } server { listen 192.168.1.2:80 default_server; server_name example.com www.example.com; … }

Конфигурация простого сайта PHP

Теперь посмотрим на то, как nginx выбирает location для обработки запроса на примере обычного простого PHP-сайта:

server { listen 80; server_name example.org www.example.org; root /data/www; location / { index index.html index.php; } location ~* \.(gif|jpg|png)$ { expires 30d; } location ~ \.php$ { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

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

Следует иметь в виду, что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов. Так делается потому, что аргументы в строке запроса могут быть заданы различными способами, например:

/index.php?user=john&page=1 /index.php?page=1&user=john

Кроме того, в строке запроса можно запросить что угодно:

/index.php?page=1&something+else&user=john

Теперь посмотрим, как бы обрабатывались запросы в вышеприведённой конфигурации:

  • Запросу “” во-первых соответствует префиксный location “”, а во-вторых — регулярное выражение “”, поэтому он обрабатывается location’ом регулярного выражения. Согласно директиве “” запрос отображается в файл , который и посылается клиенту.
  • Запросу “” также во-первых соответствует префиксный location “”, а во-вторых — регулярное выражение “”. Следовательно, он обрабатывается location’ом регулярного выражения и запрос передаётся FastCGI-серверу, слушающему на localhost:9000. Директива fastcgi_param устанавливает FastCGI-параметр в “”, и сервер FastCGI выполняет указанный файл. Переменная равна значению директивы root, а переменная равна URI запроса, т.е. “”.
  • Запросу “” соответствует только префиксный location “”, поэтому запрос обрабатывается в нём. Согласно директиве “” запрос отображается в файл , который и посылается клиенту.
  • Обработка запроса “” более сложная. Ему соответствует только префиксный location “”, поэтому запрос обрабатывается в нём. Затем директива index проверяет существование индексных файлов согласно своих параметров и директиве “”. Если файл не существует, а файл существует, то директива делает внутреннее перенаправление на “” и nginx снова сопоставляет его с location’ами, как если бы такой запрос был послан клиентом. Как мы видели ранее, перенаправленный запрос будет в конечном итоге обработан сервером FastCGI.
автор: Игорь Сысоев
редактор: Brian Mercer

Вы можете сделать небольшой трюк. Если это значение должно быть доступно из каждого блока в одном блоке , вы можете использовать директиву . Как это будет работать?
Директива позволяет вам использовать переменную где угодно в блоке , значение которой будет вычисляться на каком-либо ключевом ключе. Всеобъемлющий пример:

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

В этом примере мы вычисляем значение по значению , но на самом деле не имеет значения, что , потому что мы всегда будем устанавливать lalalala как значение для нашей переменной по умолчанию и без другие варианты.

Nginx multiple server names and $_SERVER[‘SERVER_NAME’]

Теперь везде в вашем коде, когда вы будете использовать так же, как и все другие доступные переменные (например, созданные с помощью директивы ), вы получите значение lalalala

И почему это лучше, чем просто использовать директиву ? Поскольку директива , поскольку doc говорит, что директива set nginx доступна только внутри блоков , поэтому ее нельзя использовать для создания глобальной переменной для нескольких блоков .

Документы о директиве доступны здесь: директива карты

ответ дан emka86 22 янв. '13 в 0:12

источникподелиться

Один из самых популярных веб-серверов

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

Иерархия каталогов

Все конфигурационные файлы сервера располагаются в каталоге /etc/nginx. Кроме того, внутри директории расположены еще несколько папок, а также модульные конфигурационные файлы.

cd /etc/nginx
ls –F
conf.d/   koi-win   naxsi.rules   scgi_params   uwsgi_params
fastcgi_params   mime.types   nginx.conf   sites-available/   win-utf
koi-utf   naxsi_core.rules   proxy_params   sites-enabled/

Если вы пользовались Apache, то должны быть знакомы с каталогами sites-enabled и sites-available. Они и определяют конфигурацию сайтов. Созданные файлы хранятся в последнем каталоге. Папка sites-enabled нужна для хранения конфигураций только активированных страниц. Чтобы их связать, нужна символическая ссылка между папками. Конфигурации можно также хранить в каталоге conf.d. При этом, во время запуска Nginx каждый файл с расширением .conf будет читаться по новой. При написании конфигурационных файлов, набирайте код без ошибок и соблюдайте синтаксис. Все остальные файлы располагаются в /etc/nginx. Конфигуратор содержит сведения о конкретных процессах, а также дополнительных компонентах.

Главный конфигурационный файл Nginx – это nginx.conf.

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

sudo nano /etc/nginx/nginx.conf

На экране появятся вот такие строки:

user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
http {
. . .

Первая – это общие сведения о Nginx. Фраза user www-data указывает на пользователя, который запускает сервер. Директива pid показывает, где располагаются PID-процессы, предназначенные для внутреннего использования. Строчка worker_processes показывает сколько процессов может одновременно запускать Nginx. Кроме того, здесь можно указать логи (например, лог ошибок определяется за счет директивы error_log). Ниже располагается раздел events. Он нужен для обработки соединений сервера. После него располагается блок http.

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

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

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

gzip on;
gzip_disable «msie6»;

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

Последними строками файла nginx.conf выступают:

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

Они свидетельствуют о том, что блоки location и server хранятся вне данного файла. Они определяют настройки url-адресов и конкретных файлов. Такая структура необходима для поддерживания модульной структуры конфигураций. Внутри нее получится создавать новые директории, файлы для различный сайтов. Кроме того, похожие файлы вы сможете сгруппировать. После рассмотрения вы можете закрывать файл nginx.conf.

Виртуальные блоки

Они являются аналогами виртуальных хостов в Apache. Блоки раздела server включают в себя характеристики отдельных сайтов, которые располагаются на сервере. В папке sites-available вы найдете файл блока server, который применяется по умолчанию. Внутри него можно найти вне нужные данные, которые могут потребоваться при обслуживании сайтов.

cd sites-available
sudo nano default
server {
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}

В вышеуказанном примере было намеренно убрано комментирование. Это было сделано для удобства восприятия. Внутри блоки server располагаются настройки, заключенные в фигурные скобки:

server {
. . .
}

Этот блок размещается с помощью директивы include в конце http, прописанном в файле nginx.conf. Посредством директивы root определяется каталог, где будет располагаться контент сайта. В нем программа и будет искать файлы, которые пользователь будет запрашивать. Путь такой по умолчанию: /usr/share/nginx/www. Nginx отделяет строчки или директивы одна от другой посредством точки с запятой. Если знак препинания не проставить, несколько строчек прочтуться как одна. Чтобы прописать правила, которые будут использоваться в качестве индекса, воспользуйтесь директивой index. Сервер проверит их в порядке перечисления. Если ни одна из имеющихся страничек не была запрошена пользователем, вернется index.html. Если его не будет, то сервер будет искать index.htm.

Правило server_name

Она включает в себя список доменных имен, которые должен будет обработать блок server. Их можно прописать любое количество, разделяя пробелами. Если поставить * в конце или начале домена, удастся задать имя с маской. Звездочка соответствует части имени. Если прописать *.com.ua, то сюда будут относиться все адреса указанной доменной зоны. Если адрес подходит под описание нескольких директив, то он ответит той, которой подходит полностью. При отсутствии совпадений ответ будет на самое длинное имя, у которого есть маска. В противном случае будет выполнено соответствие регулярным выражениям. Имена сервера, которые используют регулярные выражения, начинаются с тильды (~).

Location-блоки

Следующий на очереди у нас будет блок location. Он нужен для определения способа обработки определенных запросов. Если ресурсы не соответствуют никаким иным блокам location, то к ним будут применяться директивы, указанные в скобках. Эти блоки могут включать путь вроде /doc/. Для установления полного соответствия между uri и location, применяется знак =. Применяя тильду, получится задать соответствие регулярным выражениям. Вы также можете установить чувствительность к регистру, поставив ~. Если добавить звездочку, регистр не будет играть никакой роли.

Имейте ввиду: когда запрос будет полностью соответствовать блоку location, он будет использован, а поиск остановится.

Правильное указание servername Настройка Nginx как Frontend к Web-серверу Apache?

Когда совпадение неполное, URI будет сравниваться с параметрами директив location. Используется блок с сочетанием ^~, совпадающий с URI для выбора блока. Если данную опцию не задействовать, сервер выбирает оптимальное совпадение, а также произведет поиск с использованием регулярных выражений. Это необходимо для подбора одного из подходящих шаблонов. Если подходящее выражение будет найдено, оно будет использовано. В противном случае, применится предыдущее совпадение с URI. Однако имейте ввиду, что Nginx больше любит полные соответствия. Если их нет, начнется поиск регулярных выражений, а потом по URI. Паритетность поиска задается комбинацией символов ^~.

Правило try_files

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

try_files $uri $uri/ /index.html;

Что же она означает? Если поступает запрос, который обслуживается блоком location, сервер сначала попытается обработать uri как файл.

Это обеспечивает переменная $uri. Когда соответствий ей не будет, uri будет обработан как каталог. Можно проверить его существование, задав слеш в конце: $uri/. Бывают ситуации, когда ни файл, ни каталог не будет найден. В таком случае загрузится файл по умолчанию – index.html. Правило try_files применяет последний параметр как запасной вариант. Именно поэтому данный файл должен быть в системе. Однако, если совпадений вообще не найдено, Nginx вернет страничку ошибки. Чтобы ее задать, пропишите = и код ошибки:

try_files $uri $uri/ =404;

Дополнительные опции

Если применить правило alias, получится обслужить страницы блока location вне каталога root, например. Когда нужны файлы из doc, они будут запрошены из /usr/share/doc/. Кроме того, правило autoindеx on запускает листинг директорий сервера, для указанной директивы location. Если прописать строки deny и allow, получится изменить доступ к каталогам.

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

Опубликовано: Март 13, 2017

Почему nginx отвечает на любое доменное имя?

Странное поведение nginx на 2 IP

March 21, 2011 05:08AM Registered: 7 years ago
Posts: 6
Есть сервер, nginx (nginx/0.7.62) ->apache2(Apache/2.2.12 (Ubuntu), mod_php)
На сервере 2 внешних IP.

Есть несколько сайтов на одном IP, подключил второй IP, и стал наблюдать такую ситуацию:

При обращении к любому домену сайта, направленному на 2 IP, происходит обработка первым правилом (первым в смысле в списке в mc первым, не правилом default) в конфигах nginx (оно ведет на первый IP). Также при обращении к несуществующему поддомену любого сайта на 1 IP происходит обработка тем же правилом.

чтобы было понятнее пример:
сайт domen.com — 1IP, конфиг в nginx:

server {
listen 1IP:80;
server_name domen.com www.domen.com *.domen.com domen3.com www.domen3.com domen3.com www.domen3.com domen4.com www.domen4.com
server_name_in_redirect off;
index index.php;
error_page 500 502 503 504 /500.html;
error_page 404 /404.php;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
client_max_body_size 1024M;
client_body_buffer_size 4M;

location / {
expires 3d;
root /home/domen.com/public_html;
}

location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
root /home/domen.com/public_html;
error_page 404 = @fallback;
}

location ~ (/|\.php)$ {
proxy_pass http://127.0.0.1:8888;
}

location ~ (/|\.html)$ {
proxy_pass http://127.0.0.1:8888;
}

location @fallback {
proxy_pass http://127.0.0.1:8888;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location ~ /\.ht {
deny all;
}
}

domen2.com — 2IP, конфиг в nginx:

server {
listen 2IP:80;
server_name domen2.com *.domen2.com;
server_name_in_redirect on;
index index.php;
error_page 500 502 503 504 /500.html;
error_page 404 /404.php;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
client_max_body_size 1024M;
client_body_buffer_size 4M;

location / {
expires 3d;
root /home/domen2.com/public_html;
}

location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
root /home/domen2.com/public_html;
error_page 404 = @fallback;
}

location ~ (/|\.php)$ {
proxy_pass http://127.0.0.1:8888;
proxy_set_header X-Server-Address $server_addr;
}

location ~ (/|\.html)$ {
proxy_pass http://127.0.0.1:8888;
}

location @fallback {
proxy_pass http://127.0.0.1:8888;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Server-Address $server_addr;
}
location ~ /\.ht {
deny all;
}
}

при обращении к domen2.com/1.php открывается страница 1.php с сайта domen1.com, и переменная [DOCUMENT_ROOT] => /home/domen.com/public_html

При обращении к sub.domen1.com/1.php открывается страница 1.php с сайта domen1.com, и переменная [DOCUMENT_ROOT] => /home/domen.com/public_html

domen1.com имеет практически идентичный конфиг с сайтом domen.com, разница в location / и доменных адресах.

Не могу понять куда надо копать и что делать, вроде бы все указал как в доках написано, но почему то обработка происходит не тем конфигом, которым нужно…

Subject Author Posted

Странное поведение nginx на 2 IP

chinchevoy March 21, 2011 05:08AM

Re: Странное поведение nginx на 2 IP

kav March 21, 2011 07:14PM

Re: Странное поведение nginx на 2 IP

chinchevoy March 22, 2011 06:21AM

Re: Странное поведение nginx на 2 IP

kav March 22, 2011 07:32AM

Re: Странное поведение nginx на 2 IP

chinchevoy March 24, 2011 02:53AM

Re: Странное поведение nginx на 2 IP

chinchevoy March 24, 2011 04:06AM

Re: Странное поведение nginx на 2 IP

chinchevoy March 29, 2011 05:25AM

Re: Странное поведение nginx на 2 IP

Igor Sysoev March 24, 2011 04:08AM

Re: Странное поведение nginx на 2 IP

kav March 24, 2011 08:02AM

Re: Странное поведение nginx на 2 IP

Maxim Dounin March 29, 2011 06:58AM

Re: Странное поведение nginx на 2 IP

chinchevoy March 30, 2011 01:49AM

Re: Странное поведение nginx на 2 IP

Igor Sysoev March 30, 2011 02:00AM

Online Users

Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 214 on March 20, 2018

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

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

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется и расположен в каталоге , или .

Запуск, остановка, перезагрузка конфигурации

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

nginx -s сигнал

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

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

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

nginx -s quit

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

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

nginx -s reload

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

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

kill -s QUIT 1628

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

ps -ax | grep nginx

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

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

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

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

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

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

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

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

Далее, откройте конфигурационный файл.

What is nginx server_name and how it works?

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

http { server { } }

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

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

location / { root /data/www; }

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

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

location /images/ { root /data; }

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

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

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

Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу . В ответ на запросы, URI которых начинаются с , сервер будет отправлять файлы из каталога . Например, на запрос nginx отправит в ответ файл . Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на , будут отображены на каталог . Например, в результате запроса в ответ будет отправлен файл .

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал главному процессу nginx, выполнив:

nginx -s reload

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

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

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

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

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

server { listen 8080; root /data/up1; location / { } }

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

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

server { location / { proxy_pass http://localhost:8080; } location /images/ { root /data; } }

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

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

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

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

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

server { location / { proxy_pass http://localhost:8080/; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

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

Чтобы применить новую конфигурацию, отправьте сигнал nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

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

Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы , и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу . Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву на директиву и измените параметр на . В PHP параметр используется для определения имени скрипта, а в параметре передаются параметры запроса. Получится следующая конфигурация:

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; } }

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

.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *