Nginx

Nginx використовує подієво-орієнтовану модель неблокуючого введення-виведення. Головний процес зчитує конфігураційний файл і запускає один або кілька робочих процесів. Кожен робочий процес може керувати тисячами одночасних з'єднань, використовуючи невеликий набір дескрипторів файлів. Коли надходить HTTP-запит, Nginx аналізує рядок запиту, порівнює URI із визначеними блоками location і або видає статичний файл із диска, або перенаправляє запит на сервер upstream за допомогою директиви proxy_pass. Потім відповідь повертається клієнту. Така архітектура дозволяє Nginx досягати високої пропускної здатності та низької затримки, споживаючи при цьому відносно мало пам'яті.

Встановіть Nginx за допомогою менеджера пакетів вашої операційної системи або скомпілюйте його з вихідного коду. Після встановлення створіть блок сервера у /etc/nginx/sites‑available/, де вкажіть доменне ім'я, кореневу директорію та будь-які правила проксі або перенаправлення. Увімкніть сайт, створивши символьне посилання у /etc/nginx/sites‑enabled/, а потім перевірте конфігурацію за допомогою nginx -t. Якщо перевірка пройшла успішно, перезавантажте Nginx за допомогою systemctl reload nginx або надішліть сигнал HUP головному процесу. Для підвищення продуктивності встановіть worker_processes відповідно до кількості ядер CPU, увімкніть з'єднання keepalive та розгляньте можливість додавання proxy_cache для повторюваних запитів.

Nginx записує кожен запит до логу доступу (/var/log/nginx/access.log), фіксуючи IP клієнта, метод запиту, код стану та розмір відповіді. Помилки записуються у /var/log/nginx/error.log. Ви можете використовувати інструменти тестування навантаження, такі як ab (Apache Bench) або wrk, щоб надсилати одночасні запити та вимірювати затримку та пропускну здатність. Опціональний модуль nginx‑status надає вебсторінку, яка відображає активні з'єднання, загальну кількість запитів і поточний стан читання/запису, що корисно для моніторингу в реальному часі.

• Пропуск nginx -t перед перезавантаженням, що може призвести до помилки в конфігурації.
• Використання директиви root за замовчуванням без файлу index, що призводить до відображення списку файлів у директорії.
• Пряме відкриття порту бекенд-додатка в інтернет замість маршрутизації через Nginx.
• Відсутність налаштування client_max_body_size для завантаження файлів, що призводить до помилок 413.
• Неправильне налаштування proxy_pass із похилою рискою в кінці, що змінює URI, який передається на upstream-сервер.

Nginx оптимізований для роздачі статичних файлів та роботи як реверс-проксі, але він не є універсальним сервером додатків. Він не може безпосередньо виконувати код Python, Ruby або PHP; ці мови потребують окремого процесу, такого як uWSGI, Gunicorn або PHP-FPM. Вбудовані алгоритми балансування навантаження обмежені методами round-robin, least connections та IP hash; для складнішої маршрутизації можуть знадобитися зовнішні інструменти. Крім того, кожен робочий процес може обробляти обмежену кількість з'єднань, визначену параметром worker_connections, тому дуже висока конкурентність може потребувати налаштування або додаткових робочих процесів.

server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend:8080;
}
}

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

• Robots Exclusion Protocol (RFC 9309)
• Nginx
• Wikidata — Q306144