Головна > Windows > Налаштування конфігурації nginx на хостингу. Тонка настройка Nginx


Налаштування конфігурації nginx на хостингу. Тонка настройка Nginx




N ginx вимовляється як «engine x» – це безкоштовний високопродуктивний HTTP та зворотний проксі-сервер з , що відповідає за завантаження деяких з найбільших сайтів в Інтернеті. Він може використовуватися як автономний веб-сервер та як зворотний проксі-сервер для Apache та інших веб-серверів.

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

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

Перш ніж ви почнете

Усі команди повинні бути виконані від імені або root і повинні працювати в будь-якому сучасному дистрибутиві Linux, такому як CentOS 7 і Debian 9.

Запустити Nginx

Запуск Nginx є досить простим. Просто запустіть наступну команду:

Sudo systemctl start nginx

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

Якщо ви використовуєте дистрибутив Linux без systemd для запуску типу Nginx:

Sudo service start nginx

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

Sudo systemctl enable nginx

Зупинити Nging

Stop Nginx швидко зупинить усі робочі процеси Nginx, навіть якщо є відкриті з'єднання.

Щоб зупинити Nginx, виконайте одну з наступних команд:

Sudo systemctl stop nginx sudo service stop nginx

Перезапустіть Nginx

Параметр restart – це швидкий спосібзупинити та запустити сервер Nginx.

Використовуйте одну з наведених нижче команд для перезапуску Nginx:

sudo systemctl restart nginx sudo service restart nginx

Це команда, яку ви, ймовірно, використовуватимете найчастіше.

Перезавантажити Nginx

Вам необхідно перезапустити Nginx щоразу, коли ви вносите зміни до його конфігурації.

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

Щоб перезавантажити Nginx, використовуйте одну з наступних команд:

Sudo systemctl reload nginx sudo service reload nginx

Тестування конфігурації Nginx

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

Використовуйте наступну команду для перевірки конфігурації Nginx на наявність будь-яких синтаксичних або системних помилок:

Sudo nginx -t

Висновок виглядатиме приблизно так.

Nginx: configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

Якщо є помилки, команда надрукує докладне повідомлення.

Переглянути статус Nginx

Щоб перевірити стан служби Nginx, використовуйте таку команду:

Sudo systemctl status nginx

Висновок виглядатиме приблизно так:

* nginx.service - nginx - High Performance Web Server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/nginx.service.d ` -nofile.conf Active: active (running) since Mon 2019-04-22 10:21:22 MSK; 10h ago Docs: http://nginx.org/en/docs/ Process: 1113 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID : 1183 (nginx) Tasks: 4 Memory: 63.1M CPU: 3min 31.529s CGroup: /system.slice/nginx.service |-1183 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx. |-1184 nginx: worker process |-1185 nginx: worker process `-1186 nginx: worker processs

Перевірте версію Nginx

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

Ви можете перевірити свою версію Nginx, запустивши:

Sudo nginx -v nginx version: nginx/1.14.0 (Ubuntu)

Варіант -V виводитиме версію Nginx разом із можливістю конфігурування.

Sudo nginx-V

Висновок

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

Виділений Web-сервер на основі nginx – відмінний спосібпідвищення продуктивності Web-сайтів. У швидкості обробки статичного контентуйому просто немає рівних: він легко витримує кілька тисяч одночасних з'єднань і може бути легко оптимізований та підігнаний під будь-яку конфігурацію. Проте? виступаючи як фронт-енд для Apache, nginx виявляється найбільш вразливим місцем всієї Web-інфраструктури, тому безпеки nginx необхідно приділити особливу увагу.

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

Встановлення

Пакет nginx доступний у прекомпільованому вигляді для будь-якого дистрибутива. Однак зібравши сервер самостійно, ти зможеш зробити його компактнішим і надійнішим, а також отримаєш можливість змінити рядок вітання Web-сервера, щоб відбити нетямущих скрипт-кідді.

Зміни рядок вітання Web-сервера

Скачай вихідні записи nginx, відкрий файл src/http/ngx_http_header_filter_module.c і знайди наступні два рядки:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server:" NGINX_VER CRLF;

Заміни їх на щось на зразок цього:

static char ngx_http_server_string = "Server: ][ Web Server" CRLF;
static char ngx_http_server_full_string = "Server: ][ Web Server" CRLF;

Видалити всі nginx-модулі, що не використовуються тобою

Деяка частина модулів nginx підключається до Web-серверу безпосередньо під час компіляції, і кожен із них таїть у собі потенційну небезпеку. Можливо, в майбутньому в одному з них буде знайдено вразливість і твій сервер опиниться під загрозою. Вимкнувши непотрібні модулі, ти зможеш значно знизити ризик виникнення такої ситуації.

Виконайте збірку за допомогою наступних команд:

# ./configure --without-http_autoindex_module --without-http_ssi_module
# make
# make install

Так ти отримаєш nginx із заздалегідь відключеними (і в більшості випадків марними) модулями SSI (Server Side Includes) та Autoindex. Щоб дізнатися, які модулі можна безболісно викинути з Web-сервера, запусти скрипт configure з прапором '-help'.

Препаруємо nginx.conf

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

Вимкни показ версії сервера на всіх помилкових сторінках

Додай у файл nginx.conf рядок “server_tokens off”. Це змусить nginx приховувати інформацію про тип та версію Web-сервера на сторінках, що генеруються у відповідь на помилковий запит клієнта.

Налаштувати захист від зриву стека

Додай до секції server наступні рядки:

# vi /etc/nginx/nginx.conf

Максимальний розмір буфера для зберігання тіла запиту клієнта
client_body_buffer_size 1K;
Максимальний розмір буфера для зберігання заголовків запиту клієнта
client_header_buffer_size 1k;
# Максимальний розмір запиту клієнта, прописаний у полі Content-Length заголовка. Якщо сервер повинен підтримувати завантаження файлів, це значення необхідно збільшити
client_max_body_size 1k;
# Кількість та розмір буферів для читання великого заголовка запиту клієнта
large_client_header_buffers 2 1k;

Зверніть увагу на директиву large_client_header_buffers. За умовчанням, для зберігання рядка URI nginx виділяє чотири буфери, розмір кожного з яких дорівнює розміру сторінки пам'яті (для x86 це 4 Кб). Буфери звільняються щоразу, коли після закінчення обробки запиту з'єднання перетворюється на стан keep-alive. Два буфери по 1 Кб можуть зберігати URI довжиною лише 2 Кб, що дозволяє боротися з ботами та DoS-атаками.

Для підвищення продуктивності додай наступні рядки:

# vi /etc/nginx/nginx.conf

# Таймаут під час читання тіла запиту клієнта
client_body_timeout 10;
# Таймаут під час читання заголовка запиту клієнта
client_header_timeout 10;
# Таймаут, після якого keep-alive з'єднання з клієнтом не буде закрито з боку сервера
keepalive_timeout 5 5;
# Таймаут під час передачі відповіді клієнту
send_timeout 10;

Контролюй кількість одночасних з'єднань

Для захисту Web-сервера від перевантаження та спроб здійснити DoS-атаку додай у конфіг наступні рядки:

# vi /etc/nginx/nginx.conf

# Описуємо зону (slimits), де зберігатимуться стану сесій. Зона розміром 1 Мб може зберігати близько 32 000 станів, ми встановлюємо її розмір рівним 5 Мб
limit_zone slimits $binary_remote_addr 5m;
# Задаємо максимальну кількість одночасних з'єднань для однієї сесії. По суті, це число визначає максимальну кількість з'єднань з одного IP
limit_conn slimits 5;

Перша директива повинна знаходитись у секції HTTP, друга – у секції location. Коли кількість з'єднань вийде межі лімітів, клієнт отримає повідомлення «Service unavailable» з кодом 503.

Дозволь коннект тільки до свого домену

Зломщики можуть використовувати ботів для сканування підмереж та пошуку вразливих Web-серверів. Зазвичай роботи просто перебирають діапазони IP-адрес у пошуках відкритих 80 портів і надсилають запит HEAD для отримання інформації про веб-сервер (або головній сторінці). Ти можеш легко запобігти такому скану, заборонивши звернення до сервера за IP-адресою (додати в підсекцію location):

# vi /etc/nginx/nginx.conf

if ($host !~ ^(host.com|www.host.com)$) (
return 444;
}

Обмежити кількість доступних методів звернення до Web-сервера

Деякі боти використовують різні методизвернення до сервера для спроби визначення його типу та/або проникнення, проте в документі RFC 2616 чітко сказано, що Web-сервер не зобов'язаний реалізовувати їх усі, і методи, що не підтримуються, можуть просто не оброблятися. Сьогодні використовуються залишаються лише методи GET (запит документа), HEAD (запит заголовків сервера) і POST (запит на публікацію документа), тому решту можна безболісно відключити за допомогою приміщення наступних рядків у секцію server конфігураційного файлу:

# vi /etc/nginx/nginx.conf

if ($request_method !~ ^(GET|HEAD|POST)$) (
return 444;
}

Відшивай ботів

Інший спосіб блокування ботів, сканерів та іншої нечисті заснований на визначенні типу клієнта (user-agent). Він не надто ефективний, тому що більшість ботів косять під цілком легітимні браузери, але в ряді випадків залишається корисним:

# vi /etc/nginx/nginx.conf

# Блокуємо менеджери завантаження
if ($http_user_agent ~* LWP::Simple|BBBike|wget) (
return 403;
}
# Блокуємо деякі типи ботів
if ($http_user_agent ~* msnbot|scrapbot) (
return 403;
}

Блокуй Referrer-спам

Якщо твій сайт публікує Web-логи в загальнодоступному вигляді, ти легко можеш стати жертвою Referrer-спаму (коли спам-боти звертаються до твого сервера, вказуючи в заголовку referrer – адреса рекламованого сайту). Такий вид спаму може легко зіпсувати SEO рейтинги інтернет-сторінки, тому його необхідно блокувати в обов'язковому порядку. Один із способів зробити це – занести найчастіші слова, що зустрічаються в адресах рекламованих сайтів, до чорного списку.

# vi /etc/nginx/nginx.conf

# Секція server
if ($http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen))
{
return 403;
}

Блокуй хотлінк

Хотлінк – це включення до сторінки зображення (або іншого контенту) з іншого сайту. По суті, це крадіжка, тому що зображення, на яке ти витратив не одну годину свого вільного часу, не тільки вільно використовується іншими, а й створює навантаження на твій Web-сервер, не наводячи на нього відвідувачів. Для боротьби з хотлінками достатньо зробити так, щоб зображення віддавалися клієнту тільки в тому випадку, якщо він запросив їх, вже перебуваючи на сайті (тобто заголовок referrer-запиту повинен містити ім'я твого сайту). Додай до секції server конфігураційного файлу nginx.conf наступні рядки (host.com – це адреса твого сайту):

# vi /etc/nginx/nginx.conf

location /images/ (
valid_referers none blocked www.host.com host.com;
if ($invalid_referer) (
return 403;
}
}

В якості альтернативи ти можеш налаштувати сервер на віддачу спеціального банера з повідомленням про крадіжку замість зображення, що запитується. Для цього заміни рядок «return 403» на рядок:

rewrite ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg last

Захищай важливі каталоги від сторонніх

Як і будь-який інший Web-сервер, nginx дозволяє регулювати доступ до каталогів на основі IP-адрес та паролів. Цю нагоду можна використовувати для закриття деяких частин сайту від сторонніх очей. Наприклад, для відрізання URI від зовнішнього світу:

# vi /etc/nginx/nginx.conf

location /uploads/ (
# Дозволяємо доступ тільки машинам локальної мережі
allow 192.168.1.0/24;
# Відшиваємо всіх інших
deny all;
}

Тепер до документів каталогу uploads матимуть доступ лише користувачі локальної мережі. Для встановлення пароля доведеться зробити більш складні дії. Спочатку необхідно створити приватний для nginx-файл паролів і додати до нього необхідних користувачів (як приклад додамо користувача admin):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

location /admin/ (
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Нових користувачів можна додати за допомогою наступної команди:

# htpasswd -s /etc/nginx/.htpasswd/passwd користувач

Використовуй SSL

Якщо твій сайт працює з приватними даними користувачів, такими як номери кредитних карток, паролі від інших сервісів, або надає доступ до іншої важливої ​​інформації, яка може стати ласим шматочком для третіх осіб, подбайте про шифрування. Nginx добре працює з SSL, і цією можливістю не можна нехтувати.

Для налаштування SSL-шифрування засобами nginx достатньо виконати декілька простих кроків. Спочатку ти маєш створити сертифікат за допомогою наступної послідовності команд:

# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Потім описати сертифікат у конфігураційному файлі nginx:

# vi /etc/nginx/nginx.conf

server (
server_name host.com;
listen 443;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

Після цього можна перезавантажити Web-сервер:

# /etc/init.d/nginx reload

Звичайно, без підтримки з боку самого Web-сайту це робити безглуздо.

Інші способи

Встанови правильні значення системних змінних

Відкрий файл /etc/sysctl.conf і помісти в нього наступні рядки:

# vi /etc/sysctl.conf

# Захист від smurf-атак
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Захист від неправильних ICMP-повідомлень
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Захист від SYN-флуду
net.ipv4.tcp_syncookies = 1
# Забороняємо маршрутизацію від джерела
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Захист від спуфінгу
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Ми не маршрутизатор
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Включаємо ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Розширюємо діапазон доступних портів
net.ipv4.ip_local_port_range = 2000 65000
# Збільшуємо максимальний розмір TCP-буферів
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Розмісти кореневий каталог Web-сервера на виділеному розділі

Помістивши кореневий каталог Web-сервера у виділений розділ та заборонивши на ньому розміщення будь-яких виконуваних файліві файлів-пристроїв, ти убезпечиш решту системи від тих, хто зможе отримати доступ до кореня Web-сервера. При цьому запис у файлі /etc/fstab повинен мати приблизно такий вигляд:

/dev/sda5 /nginx ext4 defaults,nosuid,noexec,nodev 1 2

Помісти nginx в chroot/jail-оточення

Будь-яка сучасна *nix-система дозволяє замкнути програму в ізольованому середовищі виконання. У Linux для цього можна використовувати технології KVM, Xen, OpenVZ і VServer, у FreeBSD – Jail, Solaris – Zones. Якщо жодна з цих технологій не доступна, ти можеш помістити nginx в класичний chroot, який хоч і набагато тендітніший, але більшість зломщиків зупинити зможе.

Встанови правила SELinux для захисту nginx

Гарною альтернативою ізольованим середовищамвиконанням є локальні системи виявлення і запобігання вторгнень, такі як SELinux або AppArmor. Будучи правильно налаштованими, вони зможуть запобігти спробам зламування Web-сервера. За дефолтом жодна з них не налаштована для роботи у зв'язці з nginx, однак у рамках проекту SELinuxNginx(http://sf.net/projects/selinuxnginx/) були створені правила для SELinux, які може використовувати будь-хто. Залишається тільки завантажити та встановити:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
# make
# /usr/sbin/semodule -i nginx.pp

Налаштування брандмауера

Зазвичай nginx встановлюють на виділених машинах, готових до високого навантаження, тому він залишається єдиним мережевим сервісом, що працює на сервері. Щоб убезпечити сервер, достатньо створити зовсім невеликий набір правил, які будуть відкривати 80, 110 і 143 порти (якщо, звичайно, nginx повинен працювати ще й як IMAP/POP3-проксі) і закривати від зовнішнього світу все інше.

Обмежити кількість з'єднань за допомогою брандмауера

Для не надто навантаженого Web-сайту гарною ідеєю буде обмежити кількість спроб з'єднань з однієї IP-адреси на хвилину. Це зможе вберегти тебе від деяких типів DoS-атак та брутфорсу. У Linux це можна зробити за допомогою стандартного iptables/netfilter-модуля state:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m state --state NEW -m recent --update \
--seconds 60 --hitcount 15 -j DROP

Правила урізують ліміт на кількість підключень з одного IP на хвилину до 15. Те саме можна зробити і за допомогою pf:

# vi /etc/pf.conf

webserver_ip="1.1.1.1"
table persist
block in quick from
pass in $ext_if proto tcp to $webserver_ip \
port www flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/60, \
overload flush)

Крім ліміту кількість послідовних підключень (15 за хвилину), це правило встановлює додатковий ліміт кількість одночасних підключень рівний 100.

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

Якщо ти використовуєш nginx у зв'язці з PHP, не забудь налаштувати його. Ось як має виглядати конфігураційний файл /etc/php/php.ini захищеного сервера:

# vi /etc/php/php.ini

# Вимикаємо небезпечні функції
disable_functions = phpinfo, system, mail, exec
# Максимальний час виконання скрипту
max_execution_time = 30
# Максимальний час, який може витратити скрипт на обробку даних запиту
max_input_time = 60
# Максимальна кількість пам'яті, що виділяється кожному скрипту
memory_limit = 8M
# Максимальний розмір даних, що надсилаються скрипту за допомогою методу POST
post_max_size = 8M
# Максимальний розмір файлів, що завантажуються
upload_max_filesize = 2M
# Не показувати помилки PHP-скриптів користувачам
display_errors = Off
# Включаємо Safe Mode
safe_mode = On
# Включаємо SQL Safe Mode
sql.safe_mode = On
# Дозволяємо виконувати зовнішні команди лише у цьому каталозі
safe_mode_exec_dir = /шлях/до/захищеного/каталогу
# Захищаємось від витоку інформації про PHP
expose_php = Off
# Ведемо логи
log_errors = On
# Забороняємо відкриття віддалених файлів
allow_url_fopen = Off

Висновки

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

Про героя дня

Nginx - один з найбільш продуктивних і популярних Web-серверів у світі. Згідно з даними Netcraft, він використовується для підтримки більш ніж 12 мільйонів Web-сайтів по всьому світу, включаючи таких мастодонтів як Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Лібрусек та Taba.ru. Грамотна архітектура, заснована на мультиплексуванні з'єднань за допомогою системних викликів select, epoll (Linux), kqueue (FreeBSD) та механізм управління пам'яттю на основі пулів (невеликих буферів від 1 до 16 Кб), дозволяє nginx не просідати навіть під дуже високими навантаженнями, витримуючи понад 10000 одночасних з'єднань (так звана проблема C10K). Спочатку написаний Ігорем Сисоєвим для компанії Rambler і відкритий у 2004 році під BSD-подібною ліцензією.

Вконтакте

Працюватимемо під обліковим записомзвичайного користувача з sudo правами. Також вам знадобиться встановлений веб-сервер Nginx. За бажання можна встановити повністю LEMP (Linux, Nginx, MySQL та PHP). Щоб встановити Nginx, достатньо виконати наступну команду:

Sudo apt-get update sudo apt-get install nginx

Перш ніж продовжити читати статтю, рекомендуємо виконати вищеописані умови. Наприклад, ми налаштуємо два домени на нашому сервері. Їхні імена - example.com, test.com. Якщо у вас немає двох вільних імен, то просто придумайте два, а пізніше ми покажемо як налаштувати ваш локальний сервер, щоб перевірити їхню працездатність.

Крок 1 - налаштування нової кореневої директорії

За замовчуванням на вашому Nginx сервері активовано лише один віртуальний хост. Він працює з документами на адресу: /usr/share/nginx/html . Ми змінимо це налаштування, оскільки найчастіше доводиться працювати з каталогом /var/www. Nginx не використовує цю директорію за умовчанням, оскільки це суперечить політиці Debian щодо використання пакетів у каталозі /var/www .

Але так як ми прості користувачі, і з питаннями зберігання пакетів рідко стикаємося, проігноруємо цю політику і встановимо цей каталог як кореневий. Точніше, кожен каталог усередині кореневої директорії має відповідати окремому сайту. А всі файли сайту розмістимо в директорії /var/www/site_name/html. Спочатку створимо всі необхідні підкаталоги. Для цього виконаємо таку команду:

Sudo mkdir -p /var/www/example.com/html sudo mkdir -p /var/www/test.com/html

Прапор -р вказує оболонці, щоб вона створювала нові каталоги, якщо їх не існує у вказаному шляху. Тепер передамо права на цей каталог звичайному користувачеві. Скористайтеся змінною оточення $USER , щоб не вводити ім'я свого облікового запису. Після цих дій ми зможемо створювати у каталозі /var/www/ файли, а відвідувачі сайту – ні.

Sudo chown -R $USER:$USER /var/www/example.com/html sudo chown -R $USER:$USER /var/www/test.com/html

Права на кореневий каталог повинні бути налаштовані коректно якщо ви не виправляли значення umask , але про всяк випадок виправимо:

Sudo chmod -R 755 /var/www

Ми повністю підготували структуру нашого сервера, можемо рухатися далі.

Крок 2 – Створюємо шаблон сторінки для кожного сайту

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

Nano /var/www/example.com/html/index.html

Усередині зробимо мінімальне наповнення, щоб розуміти, на якому сайті ми знаходимося. Ось зразковий зміст:

Ласкаво просимо до Example.com!

Це віртуальний хост example.com!

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

Cp /var/www/example.com/html/index.html /var/www/test.com/html/

Внесемо до нього невеликі зміни:

Nano /var/www/test.com/html/index.html Ласкаво просимо до Test.com!

Це віртуальний хост test.com!

Збережіть та закрийте цей файл. Тепер ми будемо бачити, чи правильно налаштовані наші сайти.

Крок 3 - створення файлів віртуальних хостів для кожного домену

Тепер у нас є вміст для кожного сайту, настав час створити віртуальний хости(точніше у Nginx вони називаються server block, але ми будемо користуватися терміном віртуальний хост). За замовчуванням Nginx використовує один віртуальний хост під назвою default. Використовуємо його як шаблон для нашої конфігурації. Спочатку пропрацюємо налаштування для першого домену, яке потім просто скопіюємо та внесемо мінімальні зміни для другого домену.

Створення першого файлу віртуального хоста

Як я вже сказав, скопіюємо файл налаштування default:

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

Відкриємо цей файл із правами адміністратора:

Sudo nano /etc/nginx/sites-available/example.com

Якщо опустити коментарі, то файл має виглядати так:

Server ( listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name localhost; location / ( try_files $uri $uri/ =404 ; ) )

Для початку розберемося з директивою listen. Тільки одному блоку server ми можемо встановити значення default_server. Блок з таким значенням буде обслуговувати запити, якщо не знайдено відповідного блоку (блок - це все що знаходиться в server). Ми відключимо цю директиву у віртуальному хості default для використання default_server на одному з наших доменів. Я залишу цю функцію активованою для першого домену, але за бажання ви можете її перенести на другий.

Наступне що ми зробимо-налаштуємо кореневий каталог за допомогою директиви root. Вона має вказувати на каталог, де лежать усі документи вашого сайту:

Root /var/www/example.com/html;

Нотатка: кожна інструкція Nginx повинна закінчуватись символом “;”.

Server_name example.com www.example.com;

Server ( listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/example.com/html; index index.html index.htm; server_name example.com www.example.com; location / ( try_files $uri $uri/ =404; ) )

На цьому базове налаштуваннязакінчено. Збережіть та закрийте файл.

Створення другого віртуального хоста

Для цього просто скопіюємо файл налаштувань для першого сайту:

Sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

Відкрийте цей файл із правами адміністратора

Sudo nano /etc/nginx/sites-available/test.com

У цьому файлі також почнемо з директиви listen. Якщо опцію default_server ви залишили у першому файлі, то її слід видалити. Також необхідно прибрати опцію ipv6only=on, тому що її вказують тільки для однієї комбінації адрес/порт:

Listen 80; listen [::]: 80;

Встановіть кореневий каталог для другого сайту:

Root /var/www/test.com/html;

Тепер вкажемо server_name для другого домену:

Server_name test.com www.test.com;

Остаточне налаштування має виглядати так:

Server ( listen 80; listen [::]:80; root /var/www/test.com/html; index index.html index.htm; server_name test.com www.test.com; location / ( try_files $uri $ uri/ =404; ) )

Збережіть та закрийте файл.

Крок 4 - активація віртуальних хостів та перезапуск Nginx

Ми налаштували наші віртуальні хости, тепер настав час активувати їх. Для цього потрібно створити символічні посилання на ці файли і покласти їх у каталог sites-enabled, які Nginx зчитує під час запуску. Створити посилання можна наступною командою:

Sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

Тепер Nginx обробить ці файли. Але віртуальний хост default також активований, тому ми отримаємо конфлікт параметра default_server . Вимкнути цю настройку можна просто видаливши посилання на файл. Сам файл залишиться в каталозі sites-available, так що за потреби ми завжди зможемо повернути його на місце.

Sudo rm /etc/nginx/sites-enabled/default

Залишилося ще одне налаштування, яке потрібно виконати у конфігураційному файлі Nginx. Відкрийте його:

Sudo nano /etc/nginx/nginx.conf

Потрібно зняти коментар з одного з рядків:

Server_names_hash_bucket_size: 64;

Ця директива застосовується коли встановлено велику кількість імен серверів, або задані надзвичайно довгі імена. Наприклад, якщо значення за промовчанням дорівнює 32 і ім'я сервера задано як “too.long.server.name.example.org”, то nginx відмовиться запускатися і видасть повідомлення про помилку:

Ви не можете побудувати server_names_hash, ви повинні збільшити server_names_hash_bucket_size: 32

Тому краще збільшити це значення до 64. Тепер можна перезапустити веб-сервер, щоб зміни набули чинності:

Sudo service nginx restart

Ваш сервер повинен обробляти запити до обох доменів.

Крок 5 - Налаштування локального файлу hosts (додатково)

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

Зверніть увагу, що ці зміни слід проводити тільки на локальній машині, а не на VPS сервері. Вам знадобляться root права, також потрібно мати право змінювати системні файли.

Якщо ви використовуєте Mac або Linux систему, то виправлення можна внести так:

Sudo nano /etc/hosts

Якщо ж ви користуєтеся Windows, то інструкції з цієї ОС ви знайдете на офіційному сайті виробника (або google). Вам необхідно знати відкриту IP адресу вашого сервера та доменні імена, які ви хочете прив'язати до нього. Допустимо мою адресу 111.111.111.111 , тоді мені треба додати наступні рядки у файл hosts:

127.0.0.1 localhost 127.0.0.1 guest-desktop 111.111.111.111 example.com 111.111.111.111 test.com

Таким чином, ми перехопимо всі запити до цих доменним іменамта перенаправимо їх на наш сервер. Збережіть та закрийте файл, коли закінчите.

Крок 6 - Перевірка

На цьому етапі ви повинні отримати повністю робоче налаштування. Залишилося лише її перевірити. Для цього перейдемо в браузері за адресою: http://example.com(: target="_blank"). Якщо обидва сайти відображаються коректно, вас можна привітати з повним налаштуваннямсервера Nginx. У цьому етапі, якщо ви вносили зміни у файл hosts , їх слід видалити т.к. перевірка пройшла успішно, і вони вже не потрібні. Щоб відкрити доступ до сайтів для інтернет користувачів, доведеться придбати доменні імена.

Висновок

Ви навчилися повністю настроювати віртуальні хости для кожного сайту на вашому сервері. По суті, немає жодних обмежень на кількість сайтів на одній машині, крім ресурсів самої системи.

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

В одній із попередніх статей ми вже розглядали і налаштування його основних параметрів, у цій статті я хочу більше зупинитися на продуктивності та підготовці веб-сервера до використання в бойових умовах. Що стосується дистрибутива Linux, то сьогодні ми розглядатимемо CentOS, ця система часто використовується на серверах і з налаштуванням Nginx тут можуть виникнути деякі складнощі. Далі буде розглянуто налаштування Nginx CentOS, поговоримо як увімкнути повну підтримку http2, google pagespeed, та налаштувати основний конфігураційний файл.

В офіційних репозиторіях CentOS є Nginx, і він, швидше за все, вже встановлений у вашій системі. Але ми хочемо, щоб сайт працював за протоколом http2, який дозволяє передавати всі дані одним підключенням, а це збільшує продуктивність. Для роботи по http2 вам доведеться налаштувати SSL сертифікат, але про це вже написано в статті отримання сертифіката Lets Encrypt Nginx. Але це ще не все. для перемикання зі звичайного SSL на HTTP2.0 у більшості браузерів зараз використовується протокол ALPN, а він підтримується, починаючи з OpenSSL 1.02. У той час як у репозиторіях є тільки OpenSSL 1.01. Тому потрібно встановити версію Nginx, зібрану з OpenSSL 1.02. Для цього можна використовувати Broken Repo:

sudo yum -y install yum-utils
# sudo yum-config-manager --add-repo https://brouken.com/brouken.repo

Якщо ви використовуєте репозиторій EPEL, то потрібно вказати, що не треба з нього брати Nginx:

sudo yum-config-manager --save --setopt=epel.exclude=nginx*;

Тепер для встановлення правильної версії Nginx достатньо набрати:

sudo yum install nginx

Буде встановлена ​​остання версія Nginx 1.13.2, з повною підтримкою ALPN. Далі перейдемо до налаштування.

2. Налаштування Nginx

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

глобальні опції
events ()
http(
server (
location()
}
server()
}

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

Основні глобальні налаштування ми робитимемо у файлі /etc/nginx/nginx.conf. Далі розглянемо що саме змінюватимемо і які значення бажано встановити. Почнемо з глобальних опцій:

  • user- користувач, від імені якого буде запущено сервер, повинен бути власником каталогу з файлами сайту, і від імені його потрібно запускати php-fpm;
  • worker_processes- кількість процесів Nginx, які будуть запущені, потрібно встановити рівно стільки, скільки у вас є ядер, наприклад, у мене – 4;
  • worker_cpu_affinity- цей параметр дозволяє закріпити кожен процес за окремим ядром процесора, встановіть значення auto, щоб програма сама вибрала, що і до чого кріпити;
  • worker_rlimit_nofile- максимальна кількість файлів, які може відкрити програма, на кожне з'єднання потрібно як мінімум два файли і кожен процес матиме вказану кількість з'єднань, тому формула така: worker_processes * worker_connections* 2, параметр worker_connectionsрозберемо трохи нижче;
  • pcre_jit- увімкніть цей параметр для прискорення обробки регулярних виразів за допомогою компіляції JIT;

У секції events варто налаштувати два параметри:

  • worker_connections- кількість сполук для одного процесу повинна бути достатньою для обробки вхідних сполук. Спочатку нам потрібно знати, скільки цих вхідних сполук є, для цього дивимося статистику за адресою ip_сервера/nginx_status. Як увімкнути розглянемо нижче. У рядку Active Connections бачимо кількість активних з'єднань із сервером, також потрібно врахувати, що з'єднання з php-fpm теж вважаються. Далі зверніть увагу на поля accepted і handled, перше відображає оброблені підключення, друге - кількість прийнятих. Зі значення повинні бути однаковими. Якщо відрізняються значить з'єднань не вистачає. Дивіться приклади, перший знімок проблема, другий – порядок. Для моєї конфігурації оптимальною може бути цифра в 200 з'єднань (всього 800, враховуючи 4 процеси):

  • multi_accept- дозволяє програмі приймати кілька з'єднань одночасно, що теж прискорює роботу, при великій кількості з'єднань;
  • accept_mutex- встановіть значення цього параметра в off, щоб одразу всі процеси отримували повідомлення про нові з'єднання;

Також у секції events рекомендується використовувати директиву use epoll, оскільки цей найефективніший метод обробки вхідних з'єднань для Linux, але цей метод застосовується за умовчанням, тому не бачу сенсу додавати його вручну. Розглянемо ще кілька параметрів із секції http:

  • sendfile- Використовувати метод відправлення даних sendfile. Найефективніший метод для Linux.
  • tcp_nodelay, tcp_nopush- відправляє заголовки та тіло запиту одним пакетом, працює трохи швидше;
  • keepalive_timeout- тайму підтримки з'єднання з клієнтом, якщо у вас немає дуже повільних скриптів, то буде достатньо буде 10 секунд, встановлюємо значення скільки потрібно, щоб користувач міг бути підключений до сервера;
  • reset_timedout_connection- Розривати з'єднання після таймууту.
  • open_file_cache- кешувати інформацію про відкриті файли. Наприклад, open_file_cache max=200000 inactive=120s; max – максимальна кількість файлів у кеші, час кешування.
  • open_file_cache_valid- коли необхідно перевірити актуальність файлів. Наприклад: open_file_cache_valid 120s;
  • open_file_cache_min_uses- кешувати тільки файли, які були відкриті вказану кількість разів;
  • open_file_cache_errors- Запам'ятовувати помилки відкриття файлів.
  • if_modified_since- встановлює, яким чином будуть оброблятися заголовки if-modified-since. За допомогою цього заголовка браузер може отримати відповідь 304, якщо сторінка не змінилася з моменту останнього перегляду. Можливі варіанти - не відправляти - off, відправляти за точного збігу часу - exact, відправляти якщо час збігається точно або більше - before;

Ось якось так виглядатиме налаштування nginx conf:

User nginx;
worker_processes 4;
worker_cpu_affinity auto;
worker_rlimit_nofile 10000;
pcre_jit on;
error_log /var/log/nginx/error.log warn;
load_module "modules/ngx_pagespeed.so";
events (
multi_accept on;
accept_mutex off;
worker_connections 1024;
}
http (
sendfile on;
tcp_nopush on;
tcp_nodelay on;
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 120s;
open_file_cache_errors on;
reset_timedout_connection on;
client_body_timeout 10;
keepalive_timeout 65;
include /etc/nginx/sites-enabled.*.conf
}

3. Налаштування http2

Я не буду докладно описувати налаштування секції server, тому що робив це вже в статті установка Nginx в Ubuntu і тут мені нічого додати, налаштування SSL це досить велика тема і теж буде розглянута в окремій статті. Але, щоб налаштувати http2 вам потрібно мати вже SSL. Далі, просто підправте директиву listen у вашій секції server:

listen 194.67.215.125:443 default_server;

listen 194.67.215.125:443 http2 default_server;

Ось таким простим способомможна увімкнути http2 якщо перед цим була встановлена ​​правильна версія Nginx.

4. Налаштування PageSpeed

Google Pagespeed - це модуль Nginx, який виконує різні оптимізації для того, щоб сторінки вантажилися швидше, веб-сервер працював ефективніше, а користувачі не відчували дискомфорту. Сюди входить кешування, оптимізація html коду, оптимізація картинок, об'єднання javascript та css коду та багато іншого. Все це виконується на рівні Nginx, тому ефективніше, ніж якщо ви це робили в php. Але тут є один недолік, модуль видаляє заголовок Last Modified.

Справа в тому, що PageSpeed ​​встановлює дуже довгий рядок кешування для всіх файлів, а в ім'я файлу додає його хеш. Так швидкість завантаження ресурсів виходить набагато вище, оскільки браузер буде запитувати файли тільки з новим хешем, а LastModified видаляється, щоб користувачі змогли побачити зміни у випадку, якщо який-небудь файл буде змінено. А тепер розглянемо, як встановити модуль. Нам доведеться зібрати його із вихідних кодів.

Спочатку встановіть інструменти для складання, дуже важливо, якщо не встановите, потім отримаєте помилку і не знатимете що робити:

yum install wget gcc cmake unzip gcc-c++ pcre-devel zlib-devel

Завантажте та розпакуйте вихідні дані Nginx для вашої версії, наприклад, 1.13.3:

wget -c https://nginx.org/download/nginx-1.13.3.tar.gz
# tar -xzvf nginx-1.13.3.tar.gz

Налаштування сервера nginx не включає перескладання та заміну програми з репозиторію, ми просто використовуємо ці вихідники для складання модуля. Завантажте та розпакуйте вихідні PageSpeed:

wget -c https://github.com/pagespeed/ngx_pagespeed/archive/v1.12.34.2-stable.zip
# unzip v1.12.34.2-stable.zip

Завантажте та розпакуйте бібліотеку оптимізації PageSpeed ​​у папку з вихідними модулями:

cd ngx_pagespeed-1.12.34.2-stable/
# wget -c https://dl.google.com/dl/page-speed/psol/1.12.34.2-x64.tar.gz
# tar -xvzf 1.12.34.2-x64.tar.gz

Завантажте та розпакуйте вихідні коди OpenSSL 1.02:

wget -c https://www.openssl.org/source/openssl-1.0.2k.tar.gz -O /opt/lib/$OPENSSL.tar.gz
# tar xvpzf openssl-1.0.2k.tar.gz

Тепер нам потрібно зібрати модуль. Спочатку дивимося налаштування, з якими зібраний поточний Nginx:

А тепер переходимо в папку з Nginx, підставляємо всі отримані опції, опцію --add-dynamic-module для PageSpeed, OpenSSL і пробуємо зібрати:

cd nginx-1.13.3
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx .conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx .pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache /nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path= /var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_sub_module --wit h-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt="-O2-g-pipe-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic" --with-ld-opt= --with -openssl=$HOME/openssl-1.0.2k --add-dynamic-module=$HOME/ngx_pagespeed-1.12.34.2-stable $(PS_NGX_EXTRA_FLAGS)
# make

Якщо все було зроблено правильно, то на виході ви отримаєте модуль ngx_pagespeed.so у папці obj, його потрібно скопіювати в папку /etc/nginx/modules:

cp ngx_pagespeed.so /etc/nginx/modules/ngx_pagespeed.so

Створюємо папку для кешу:

mkdir -p /var/ngx_pagespeed_cache
# chown -R nginx:nginx /var/ngx_pagespeed_cache

Тепер додайте такий рядок для включення модуля /etc/nginx/nginx.conf:

load_module "modules/ngx_pagespeed.so";

|

Nginx – це вільний та відкритий веб-сервер, який використовується для обслуговування сайтів та програм будь-якої складності. Nginx відомий своїм низьким впливом на пам'ять, високою масштабованістю та модульною, керованою подіями архітектурою, яка може забезпечити надійну та передбачувану продуктивність. Nginx працює не тільки як веб-сервер, але і як балансувальник навантаження, кешуючий HTTP-сервер та зворотний проксі-сервер.

Звичайно, спочатку може бути складно запам'ятати всі команди та рекомендації щодо керування сервером Nginx. Цей посібник призначений для тих, хто працює з Nginx. Воно охоплює деякі основні команди управління сервісами, а також поради щодо діагностики та вирішення деяких поширених проблем.

Кожен розділ може використовуватись незалежно від інших, тому ви можете пропустити розділи, які вам не потрібні. Усі умовні значення у командах виділено червоним; замість цих значень можна підставити свої дані.

Примітка: Передбачається, що ви працюєте з версією Nginx, встановленою з репозиторію за замовчуванням у Debian-подібному дистрибутиві. Деякі з команд і директив, описаних у цьому посібнику, відсутні в інших дистрибутивах або версіях Nginx, встановлених з інших джерел.

Установка Nginx

Оновіть індекс пакетів і встановіть Nginx:

sudo apt-get update
sudo apt-get install nginx

Перевірка стану Nginx

Щоб перевірити стан веб-сервера на поточній машині, введіть:

sudo systemctl status nginx

Автозавантаження Nginx

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

sudo systemctl disable nginx

Щоб знову додати Nginx до автозавантаження, введіть:

sudo systemctl enable nginx

Управління сервісом Nginx

Щоб зупинити сервер Nginx, введіть наступне:

sudo systemctl stop nginx

Щоб запустити сервер Nginx, введіть:

sudo systemctl start nginx

Щоб зупинити сервіс та запустити його знову, введіть:

sudo systemctl restart nginx

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

sudo systemctl reload nginx

Створення кореневого каталогу для статичного контенту

Під час створення сайтів на Nginx розробники часто використовують віртуальні хости (або блоки server) – це хости, які обслуговують окремі сайти чи домени. Для цього потрібно створити document root, каталог верхнього рівня, який Nginx перевіряє під час обслуговування контенту.

Команди в наведеному нижче блоці створять новий кореневий каталог, передадуть права на нього користувачеві sudo і змінять права доступу до кожного підкаталогу в /var/www/.


sudo chown -R $USER:$USER /var/www/example.com/html
find /var/www-type d-exec chmod 775()\;

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

Пам'ятайте, що права доступу повинні змінюватися відповідно до ситуації.

Створення кореневого каталогу для динамічних файлів

Якщо ваш сайт використовує динамічні модулі типу PHP-FPM, вам може знадобитися передати права на деякі файли групи www-data. Якщо групі потрібне право на запис у каталозі, передайте групі права власності на каталог.

Запропоновані нижче команди створюють новий document root, передають його групі www-data і змінюють права на кожен підкаталог /var/www.

sudo mkdir -p /var/www/example.com/html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www-type d-exec chmod 775()\;

Увімкнення та вимкнення конфігураційних файлів

Щоб увімкнути віртуальний хост, потрібно створити симлінк з каталогу sites-available до каталогу sites-enabled, який Nginx читає під час запуску.

Для цього введіть кімнату:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

Після цього потрібно перезавантажити Nginx, щоб налаштування оновилися.

Усунення несправностей із хеш-таблицею

Nginx використовує хеш-таблиці, щоб швидко обробляти статичні дані (імена серверів, MIME-типи). Якщо ви додали кілька імен серверів, є ймовірність, що заданого розміру хешу імені сервера не вистачатиме, і при внесенні змін ви побачите помилку server_names_hash_bucket_size. Її можна усунути, відредагувавши одне значення у файлі /etc/nginx/nginx.conf.

Відкрийте цей файл:

sudo nano /etc/nginx/nginx.conf

Знайдіть у файлі директиву server_names_hash_bucket_size. Видаліть символ #, щоб коментувати рядок, і збільште значення директиви:

http (
. . .
server_names_hash_bucket_size 64 ;
. . .
}

Це збільшить розмір хеш-таблиць імен серверів Nginx і дозволить сервісу обробляти всі імена серверів, які ви додали. Збережіть і закрийте файл, а потім перезапустіть Nginx, щоб оновити налаштування.

Тестування конфігурації

Щоразу, коли ви вносите зміни до конфігураційних файлів Nginx, обов'язково виконайте наступну команду, щоб перевірити наявність синтаксичних помилок:

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

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Якщо помилок немає, ви можете перезавантажити сервіс:

sudo systemctl restart nginx

Важливі файли та каталоги Nginx

Контент

Каталог /var/www/html зберігає весь контент сайту (це кореневий каталог сайту). Ви можете змінити стандартні налаштування Nginx та вказати інші каталоги у var/www.

Конфігурація сервера

  • /etc/nginx/: конфігураційний каталог Nginx (тут зберігаються всі конфігураційні файли веб-сервера).
  • /etc/nginx/nginx.conf: головний конфігураційний файл веб-сервера, де знаходяться всі глобальні параметри.
  • /etc/nginx/sites-available/default: віртуальний хост Nginx за промовчанням. Інші віртуальні хости також повинні зберігатися в каталозі sites-available (але вони не працюватимуть без сімлінку в sites-enabled).
  • /etc/nginx/sites-enabled/: тут зберігаються файли включених віртуальних хостів. Під час запуску або перезавантаження Nginx читає конфігураційні файли та посилання в цьому каталозі, щоб зібрати повну конфігурацію.

Логи

  • /var/log/nginx/access.log: це лог, який реєструє всі запити Nginx (якщо конфігурації веб-сервера не сказано іншого).
  • /var/log/nginx/error.log: це лог помилок.

Щоб отримати доступ до логів systemd процесу Nginx, запустіть цю команду:

sudo journalctl -u nginx

Висновок

Цей мануал перерахував загальні процедури підтримки сервера Nginx. Щоб дізнатися більше про роботу з Nginx, перегляньте наступні посібники.

Tags: