Nginx – це популярний та продуктивний веб-сервер та зворотний проксі-сервер.

Nginx має багато переваг, проте його налаштування досить складні і не завжди зрозумілі новачкам. Даний посібникдопоможе розібратися з основними параметрами, синтаксисом та конфігураційними файлами Nginx.

Примітка: Керівництво виконано на Ubuntu 12.04

Ієрархія каталогів 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-available та sites-enabled. Ці каталоги визначають конфігурацію сайтів. Файли зазвичай створюються та зберігаються у sites-available; у sites-enabled зберігаються лише конфігурації включених сайтів. Для цього потрібно створити символічне посилання із sites-available у sites-enabled.

Каталог conf.d також можна використовувати для зберігання конфігурацій. Кожен файл з розширенням.conf читатиметься під час запуску Nginx. Синтаксис таких файлів не повинен містити помилки.

Майже всі файли, що залишилися, зберігаються в /etc/nginx, який містить відомості про конфігурацію конкретних процесів або додаткових компонентів.

Основним конфігураційним файлом Nginx є nginx.conf.

Файл nginx.conf

Файл 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. Він керує обробкою з'єднань Nginx. За ним іде блок http. Перш ніж продовжити ознайомлення із конфігураціями веб-сервера, потрібно зрозуміти, як відформатовано конфігураційний файл Nginx.

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

Конфігураційний файл Nginx поділяється на блоки.

Перший блок - events, за ним йде http і починається головна ієрархія конфігурацій.

Деталі конфігурації блоку http діляться на рівні за допомогою закритих блоків, які успадковують властивості блоку, в якому вони розташовані. У блоці http зберігається більшість загальних конфігурацій Nginx, які діляться на блоки server, які, своєю чергою, діляться на блоки location.

Під час налаштування Nginx важливо пам'ятати наступне правило: чим вище рівень конфігурації, тим більше блоків успадковує цю конфігурацію; чим нижчий рівень конфігурації, тим вона «індивідуальніша». Тобто, якщо параметр Х повинен застосовуватися у кожному блоці server, такий параметр потрібно помістити в блок http.

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

Наприклад, щоб налаштувати стиснення файлів, потрібно встановити такі параметри:

gzip on;
gzip_disable "msie6";

Це включить підтримку gzip для стиснення даних, що відправляються клієнту, і відключить gzip для Internet Explorer 6 (оскільки цей браузер не підтримує стиснення даних).

Якщо будь-який параметр повинен мати різне значення в кількох блоках server, такий параметр можна задати на вищому рівні, а потім перевизначити його всередині самих блоків сервера. В результаті Nginx виконає параметр нижчого рівня.

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

Блок http у файлі nginx.conf закінчується так:

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

Це говорить про те, що блоки server та location, які визначають налаштування конкретних сайтів та URL-адрес, зберігатимуться за межами цього файлу.

Це дозволяє підтримувати модульну архітектуру конфігурацій, де можна створювати нові файли для обслуговування нових сайтів. Також це дозволяє групувати схожі файли.

Закрийте файл nginx.conf. Тепер потрібно вивчити налаштування окремих сайтів.

Віртуальні блоки Nginx

Блоки server у Nginx є аналогом віртуальних хостів Apache(Але для зручності їх також прийнято називати віртуальними хостами). По суті, блоки server – це технічні характеристикиокремих веб-сайтів, які розміщені на одному сервері.

У каталозі sites-available можна знайти файл блоку сервер за промовчанням, який постачається разом із сервером. Цей файл містить усі необхідні дані для обслуговування сайту.

cd sites-available
sudo nano default

root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / (

}
location /doc/ (

alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;

Файл за промовчанням дуже добре закоментований, але в прикладі вище коментарі опущені для простоти та зручності.

Блок server включає всі налаштування, поміщені між фігурними дужками:

server (
. . .
}

Цей блок розміщений у файлі nginx.conf ближче до кінця блоку http за допомогою директиви include.

Директива root визначає каталог, в якому зберігатиметься контент сайту. У цьому каталозі Nginx шукатиме запитані користувачем файли. За промовчанням це каталог /usr/share/nginx/www.

Зверніть увагу: всі рядки закінчуються крапкою з комою. Так Nginx відокремлює одну директиву від іншої. Якщо точки з комою не буде, Nginx прочитає дві директиви (або кілька директив) як одну директиву з додатковими аргументами.

Директива index визначає файли, які будуть використовуватися як індекс. Веб-сервер перевірятиме файли в порядку їх перерахування. Якщо жодна сторінка не була запитана, блок server знайде та поверне файл index.html. Якщо він не зможе знайти файл, він спробує обробити index.htm.

Директива server_name

Директива server_name містить список доменних імен, які будуть обслуговувати цей блок server. Кількість доменів необмежена; домени у списку слід розділяти пробілами.

Символ зірочки (*) на початку або в кінці домену задає ім'я з маскою, де зірочка відповідає частині (або кільком частинам) імені. Наприклад, ім'я *.example.com буде відповідати іменам forum.example.com та www.animals.example.com.

Якщо запитувана url-адреса відповідає декільком директивам server_name, вона спочатку відповість тій, з якою збігається повністю.

Якщо адреса не виявить збігів, вона шукатиме саме довге ім'яз маскою, що закінчується зірочкою. Якщо він не знайде такого імені, він поверне першу відповідність до регулярних виразів.

Імена сервера, які використовують регулярні вирази, починаються з тильди (~). На жаль, дана темавиходить за рамки цієї статті.

Блоки location

Рядок location / вказує, що директиви в дужках будуть застосовуватися до всіх запитуваних ресурсів, які не відповідають жодним іншим блокам location.

Такі блоки можуть містити шлях uri (наприклад /doc/). Щоб встановити повну відповідність між location та uri, використовується символ =. Символ ~ встановлює відповідність до регулярних виразів.

Тільда ​​включає чутливий до регістру режим, а тільда ​​зі зірочкою – реєстронезалежний режим.

Якщо запит повністю відповідає блоку location, сервер зупиняє пошук і використовує такий блок. Якщо сервер не знаходить повністю відповідного блоку location, він порівнює URI з параметрами директив location. Nginx вибере блок, у якому використовується поєднання символів ^~ і який збігається з URI.

Якщо опція ^~ не використовується, Nginx вибере найближчий збіг і виконає пошук за регулярними виразами, щоб спробувати підібрати один з доступних шаблонів. Якщо він знайде такий вислів, він використовує його. Якщо такого виразу немає, сервер використовує знайдений раніше збіг з URI.

Як висновок слід зазначити, що Nginx воліє точні відповідності. Якщо таких відповідей немає, він шукає регулярний вираз, а потім виконує пошук за URI. Щоб змінити пріоритетність пошуку URI, використовуйте комбінацію символів ^~.

Директива try_files

Директива try_files – дуже корисний інструмент, який перевіряє наявність файлів у заданому порядку та використовує перший знайдений файл для обробки запиту.

Це дозволяє за допомогою додаткових параметрів визначити, як Nginx буде обслуговувати запити.

У конфігураційному файлі за замовчуванням є рядок:

try_files $uri $uri/ /index.html;

Це означає, що при надходженні запиту, який обслуговує блок location, Nginx спочатку спробує обслужити uri як файл (таку поведінку ставить змінна $uri).

Якщо сервер не виявляє відповідності змінної $uri, він спробує використати uri як каталог.

За допомогою слеша наприкінці сервер перевіряє існування каталогу, наприклад $uri/.

Якщо жоден файл або каталог не знайдено, Nginx виконує файл за замовчуванням (у даному випадкуце index.html у root-каталозі блоку server). Кожна директива try_files використовує останній параметр як запасний варіант, тому файл повинен існувати в системі.

Якщо веб-сервер не виявив збігів у попередніх параметрах, він може повернути сторінку помилки. Для цього використовується знак і код помилки.

Наприклад, якщо блок location / не може знайти запитуваний ресурс, замість файлу index.html він може повернути помилку 404:

try_files $uri $uri/ =404;

Для цього потрібно поставити знак і задати код помилки як останній параметр (=404).

Додаткові параметри

Директива alias дозволяє Nginx обслуговувати сторінки блоку location поза заданим каталогом (наприклад, поза root).

Наприклад, файли, що запитуються /doc/, будуть обслужені з /usr/share/doc/.

Директива autoindex on дозволяє включати листинг директорій Nginx для заданої директиви location.

Рядки allow і deny керують доступом до каталогів.

Висновок

Веб- сервер Nginxє багатофункціональним і дуже продуктивним засобом, проте його термінологія та параметри можуть здатися заплутаними.

Розібравшись із конфігураціями Nginx і навчившись працювати з ними, ви отримаєте всі переваги цього потужного та легковажного інструменту.

Tags: ,

Тема правильної налаштування nginxдуже велика, і, боюся, в рамках однієї статті на хабрі ніяк не вміщується. У цьому тексті я постарався розповісти про загальну структуруконфіга, більш цікаві дрібниці та зокрема, можливо, будуть пізніше. :)

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

Почнемо з загальних налаштувань. Спочатку вкажемо користувача, від імені якого працюватиме nginx (від рута працювати погано, всі знають:))

Тепер скажемо nginx-у, скільки робочих процесів породити. Зазвичай, гарним виборомбуває число процесів, що дорівнює числу процесорних ядеру вашому сервері, але з цим налаштуванням має сенс поекспериментувати. Якщо очікується високе навантаженняна жорсткий диск, можна зробити за процесом на кожен фізичний жорсткий диск, оскільки вся робота буде все одно обмежена його продуктивністю.

Worker_processes 2;

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

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

Тепер йде дуже цікава секція Events. У ній можна поставити максимальна кількістьз'єднань, які одночасно буде обробляти один процес-воркер, і метод, який використовуватиметься для отримання асинхронних повідомлень про події в ОС. Звичайно, можна вибрати тільки ті методи, які доступні на вашій ОС і були включені при компіляції.

Ці параметри можуть вплинути на продуктивність вашого сервера. Їх треба підбирати індивідуально, залежно від ОС та заліза. Я можу навести лише кілька загальних правил.

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

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

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

Наступна секція – найбільша, і містить найцікавіше. Це опис віртуальних серверів та деяких параметрів, спільних для них усіх. Я опущу стандартні налаштування, які є у кожному конфізі, типу шляхів до логів.

Http (
# Весь код нижче буде всередині цієї секції %)
# ...
}

Усередині цієї секції можуть бути кілька досить цікавих параметрів.

Системний виклик sendfile з'явився на Linux відносно недавно. Він дозволяє відправити дані до мережі, минаючи етап їх копіювання в адресний простір програми. У багатьох випадках це істотно підвищує продуктивність сервера, тому параметр sendfile краще завжди включати.

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

Keepalive_timeout 15;

Окремо варто виділити налаштування проксіювання nginx. Найчастіше, nginx використовується саме як сервер-проксі, відповідно вони мають досить велике значення. Зокрема, розмір буфера для запитів, що проксуються, має сенс встановлювати не менше, ніж очікуваний розмір відповіді від сервера-бекенда. При повільних (або, навпаки, дуже швидких) бекендах, є сенс змінити таймаути очікування відповіді від бекенда. Пам'ятайте, чим більше ці таймати, тим довше чекатимуть відповіді ваші користувачі, при гальмах бекенда.

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

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

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

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

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

Інші, швидше за все, опишуть свій віртуальний хост прямо в основному конфізі.

Server (
listen 80;

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

Встановимо кодування для віддачі за замовчуванням.

Charset UTF-8;

І скажемо, що ми не хочемо приймати від клієнтів запити довжиною більш ніж 1 мегабайт.

Client_max_body_size 1m;

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

Ssi on;
ssi_value_length 1024;

І, нарешті, опишемо два локейшні, один з яких вестиме на бекенд, до апачу, запущеному на порту 9999, а другий віддаватиме статичні картинки з локальної файлової системи. Для двох локейшнів це малоосмислено, але для більшого їх числа має сенс також відразу визначити змінну, в якій зберігатиметься кореневий каталог сервера, і потім використовуватиме її в описах локацій.

14 серпня 2009 о 19:29

Налаштування nginx

• Nginx

Тема правильного налаштування nginx дуже велика, і, боюся, в рамках однієї статті на хабрі ніяк не вміщується. У цьому тексті я постарався розповісти про загальну структуру конфігу, цікавіші дрібниці і зокрема, можливо, будуть пізніше. :)

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

Почнемо із загальних налаштувань. Спочатку вкажемо користувача, від імені якого працюватиме nginx (від рута працювати погано, всі знають:))

Тепер скажемо nginx-у, скільки робочих процесів породити. Зазвичай, хорошим вибором буває число процесів, що дорівнює кількості процесорних ядер у вашому сервері, але з цим налаштуванням має сенс поекспериментувати. Якщо очікується високе навантаження на жорсткий диск, можна зробити по процесу на кожен фізичний жорсткий диск, оскільки вся робота буде все одно обмежена його продуктивністю.

Worker_processes 2;

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

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

Тепер йде дуже цікава секція Events. У ній можна задати максимальну кількість з'єднань, які одночасно оброблятиме один процес-воркер, і метод, який використовуватиметься для отримання асинхронних повідомлень про події в ОС. Звичайно, можна вибрати тільки ті методи, які доступні на вашій ОС і були включені при компіляції.

Ці параметри можуть вплинути на продуктивність вашого сервера. Їх треба підбирати індивідуально, залежно від ОС та заліза. Я можу навести лише кілька загальних правил.

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

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

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

Наступна секція – найбільша, і містить найцікавіше. Це опис віртуальних серверів та деяких параметрів, спільних для них усіх. Я опущу стандартні налаштування, які є у кожному конфізі, типу шляхів до логів.

Http (
# Весь код нижче буде всередині цієї секції %)
# ...
}

Усередині цієї секції можуть бути кілька досить цікавих параметрів.

Системний виклик sendfile з'явився на Linux відносно недавно. Він дозволяє відправити дані до мережі, минаючи етап їх копіювання в адресний простір програми. У багатьох випадках це істотно підвищує продуктивність сервера, тому параметр sendfile краще завжди включати.

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

Keepalive_timeout 15;

Окремо варто виділити налаштування проксіювання nginx. Найчастіше nginx використовується саме як сервер-проксі, відповідно вони мають досить велике значення. Зокрема, розмір буфера для запитів, що проксуються, має сенс встановлювати не менше, ніж очікуваний розмір відповіді від сервера-бекенда. При повільних (або, навпаки, дуже швидких) бекендах, є сенс змінити таймаути очікування відповіді від бекенда. Пам'ятайте, чим більше ці таймати, тим довше чекатимуть відповіді ваші користувачі, при гальмах бекенда.

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

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

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

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

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

Інші, швидше за все, опишуть свій віртуальний хост прямо в основному конфізі.

Server (
listen 80;

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

Встановимо кодування для віддачі за замовчуванням.

Charset UTF-8;

І скажемо, що ми не хочемо приймати від клієнтів запити довжиною більш ніж 1 мегабайт.

Client_max_body_size 1m;

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

Ssi on;
ssi_value_length 1024;

І, нарешті, опишемо два локейшні, один з яких вестиме на бекенд, до апачу, запущеному на порту 9999, а другий віддавати статичні картинки з локальної файлової системи. Для двох локейшнів це малоосмислено, але для більшого їх числа має сенс також відразу визначити змінну, в якій зберігатиметься кореневий каталог сервера, і потім використовуватиме її в описах локацій.

Один із найпопулярніших веб-серверів

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 розділені на рівні за допомогою закритих блоків. Вони успадковують характеристики з батьківського, тобто. того, у якому розташовуються. Цей блокзберігає більшість конфігурацій сервера. Вони поділяються на блоки сервера, всередині яких розташовані місцезнаходження.

Коли ви налаштовуєте сервер 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 розташовуються налаштування, укладені у фігурні дужки:

Цей блок розміщується за допомогою директиви 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, він буде використаний, а пошук зупиниться. Коли неповний збіг, URI буде порівнюватися з параметрами директив location. Використовується блок із поєднанням ^~, що збігається з URI для вибору блоку. Якщо цю опціюне задіяти, сервер вибирає оптимальний збіг, а також здійснить пошук з використанням регулярних виразів. Це необхідно для вибору одного з відповідних шаблонів. Якщо відповідний вираз буде знайдено, його буде використано. В іншому випадку, застосовується попередній збіг з URI. Однак майте на увазі, що Nginx більше любить повні відповідності. Якщо їх немає, почнеться пошук регулярних виразів, а потім URI. Паритетність пошуку визначається комбінацією символів ^~.

Правило try_files

Це дуже корисний інструмент, здатний перевіряти наявність файлів у установленому порядку. Він застосовує перший відповідний критеріям обробки запиту. Ви можете використовувати Додаткові параметри, щоб встановити, яким чином сервер обслуговує запити. У конфігураторі є такий рядок за умовчанням:

try_files $uri $uri/ /index.html;

Що вона означає? Якщо надходить запит, який обслуговується блоком location, сервер спочатку спробує обробити uri як файл. Це забезпечує змінна $uri. Коли відповідей не буде, uri буде оброблений як каталог. Можна перевірити його існування, задавши слєш в кінці $uri/. Бувають ситуації, коли ні файл, ні каталог не буде знайдено. У такому разі завантажиться файл за замовчуванням – index.html. Правило try_files застосовує останній параметр як запасний варіант. Саме тому даний файлмає бути в системі. Однак якщо збігів взагалі не знайдено, Nginx поверне сторінку помилки. Щоб її задати, пропишіть = та код помилки:

Додаткові опції

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

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