50 найкращих запитань і відповідей на інтерв’ю Nginx (2026)

Автор: Брайс Лео Брайс Лео
Hours оновлений

Найпопулярніші запитання та відповіді на співбесіді щодо Nginx

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

These roles open paths across cloud infrastructure, performance engineering, and security, where practical configurations matter. Employers value technical experience, domain expertise, and analysis gained from working in the field, helping freshers, mid-level engineers, and senior professionals apply basic to advanced skills within teams under guidance of managers and team leaders. Детальніше ...

👉 Безкоштовне завантаження PDF: Запитання та відповіді для співбесіди з Nginx

Найпопулярніші запитання та відповіді на співбесіді щодо Nginx

1) Поясніть, що таке NGINX і чому він широко використовується у веб-інфраструктурі.

NGINX — це високопродуктивний веб-сервер з відкритим кодом, який також функціонує як зворотний проксі-сервер, балансувальник навантаження та HTTP-кеш. Він підтримує протоколи HTTP, HTTPS, SMTP, POP3 та IMAP. Архітектура використовує event-driven, asynchronous model що дозволяє йому обробляти десятки тисяч одночасних підключень з низьким використанням пам'яті та процесора. Така масштабованість робить NGINX особливо придатним для веб-додатків з високим трафіком, мікросервісів та розподілених архітектур. Наприклад, компанії з великими навантаженнями трафіку (такі як контентні платформи або шлюзи API) часто надають перевагу NGINX для ефективної обробки одночасних підключень та доставки статичного контенту.

2) Як NGINX обробляє HTTP-запити внутрішньо (подійно-керована архітектура)?

Основна сила NGINX полягає в його event-driven, non-blocking architectureЗамість того, щоб створювати окремий потік або процес для кожного запиту (як традиційні сервери), NGINX використовує невеликий набір робочих процесів, які використовують асинхронні цикли подій. Кожен робочий процес може керувати тисячами підключень, очікуючи сповіщень про готовність операційної системи та обробляючи події, коли вони відбуваються. Оскільки NGINX не блокує операції вводу-виводу, він може обслуговувати статичний та проксірований контент з мінімальними ресурсами. Ця модель ідеально підходить для випадків використання з високою паралельністю, що робить її ефективнішою, ніж сервери на основі процесів, при великих навантаженнях.

3) Які основні відмінності між NGINX та Apache?

Хоча NGINX та Apache є популярними веб-серверами, вони відрізняються архітектурою, продуктивністю та цілями дизайну:

Аспект NGINX Apache
Модель паралельності Керований подіями (асинхронний, неблокуючий) На основі процесу / потоків (блокування)
Використання пам'яті Низький рівень на підключення Вище на одне підключення
Найкращий варіант використання Високий трафік, статичний контент, балансування навантаження Динамічний контент та насичена екосистема модулів
масштабованість Масштабується з меншою кількістю ресурсів Потрібно більше обладнання через процеси
Обробка модулів Модулі, вибрані під час компіляції Динамічний під час виконання

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

4) Які ключові компоненти файлу конфігурації NGINX?

Файл конфігурації NGINX (шлях за замовчуванням: /etc/nginx/nginx.conf) складається зі структурованих блоків директив, які визначають поведінку NGINX:

  • Основний контекст: глобальні налаштування, такі як worker_processes, error_log та pid
  • Блок подій: керує підключеннями працівників та багатопроцесорною обробкою
  • Блок HTTP: містить конфігурації для обробки HTTP (стиснення, кешування, gzip тощо)
    • Блок сервера: визначає віртуальні хости (домени та порти)
    • Блок розташування: визначає правила маршрутизації та способи обробки певних URI

Ці блоки працюють разом для маршрутизації запитів, визначення параметрів проксі-сервера та налаштування SSL/TLS і кешування.

5) Як безпечно перезавантажити конфігурацію NGINX без простоїв?

Щоб перезавантажити NGINX з оновленими конфігураціями without interrupting active connections, ви використовуєте таку команду:

nginx -s reload

або на системах, що використовують systemd:

sudo systemctl reload nginx

This command signals the master process to re-read configuration files and gracefully restart workers without dropping existing connections. Knowing how to perform such seamless reloads is essential in environments requiring high availability.

6) Опишіть, як налаштувати NGINX як зворотний проксі-сервер.

Зворотний проксі-сервер пересилає клієнтські запити на сервери бекенду (група вищестоящих серверів), а потім повертає відповідь. Нижче наведено типовий блок зворотного проксі-сервера NGINX:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

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

7) Поясніть процеси NGINX Master та Worker.

У NGINX:

  • Команда Головний процес керує конфігурацією, запускає робочі процеси та обробляє привілейовані операції, такі як прив'язка до портів.
  • Робочі процеси виконувати фактичну обробку запитів — обробку вхідних з’єднань та виконання налаштованих правил.

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

СТАТТІ ПО ТЕМІ

8) Як можна обмежити обробку невизначених імен серверів у NGINX?

Відхилити запити без дійсного Host заголовок у NGINX:

server {
    listen 80;
    server_name "";
    return 444;
}

Ця конфігурація повертає код 444, нестандартний статус NGINX, який закриває з'єднання без відповіді, фактично відхиляючи невизначені хости та покращуючи безпеку.

9) Для чого використовується модуль ngx_http_upstream_module?

Команда ngx_http_upstream_module визначає groups of backend servers (вищепотокові) до яких NGINX може передавати запити за допомогою таких директив, як proxy_pass, fastcgi_passабо uwsgi_passЦе забезпечує гнучкість у масштабуванні програм у середовищах із балансуванням навантаження. Коли кілька серверів бекенду об’єднані в групи, NGINX може розподіляти трафік на основі визначених політик, підтримуючи циклічний режим та інші стратегії.

10) Опишіть, як NGINX використовується для обслуговування статичного та динамічного контенту.

NGINX дуже ефективний в обслуговуванні статичні файли (HTML, CSS, зображення) безпосередньо за допомогою оптимізованого циклу подій та механізмів файлового вводу/виводу. Для динамічний змістNGINX передає запити до бекенд-процесорів, таких як PHP-FPM, Python Сервери WSGI або фреймворки застосунків через механізми FastCGI/проксі. Таке розділення дозволяє NGINX успішно працювати як статичний файловий сервер, водночас використовуючи серверні служби для динамічної генерації, забезпечуючи оптимальну продуктивність та масштабованість.

11) Як працює балансування навантаження в NGINX, і які різні методи доступні?

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

Метод Опис Найкращий варіант використання
Round Robin Метод за замовчуванням, який послідовно перерозподіляє запити між серверами. Рівномірно розподілені робочі навантаження.
Найменше зв'язків Надсилає запити на сервер з найменшою кількістю активних з'єднань. Тривалі сесії.
Хеш IP Використовує IP-адресу клієнта для визначення вибору сервера. Збереження сесії.
Найменший час Баланси базуються на часі відгуку та кількості з’єднань. Застосунки, чутливі до затримки.

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

12) Яка різниця між NGINX з відкритим кодом та NGINX Plus?

NGINX Open Source це версія для спільноти, яка пропонує основні можливості веб-сервера, проксі-сервера та балансування навантаження. NGINX Plus – це комерційна версія, яка розширює ці функції покращеннями корпоративного рівня, такими як розширений моніторинг, збереження сеансу, динамічна реконфігурація та активні перевірки справності.

особливість Відкритий код NGINX NGINX Plus
Балансування навантаження Базовий (круговий аналіз, хешування IP) Розширений (найменший час, динамічна реконфігурація)
Моніторинг Ручні / зовнішні інструменти Вбудована панель інструментів та API
кешування Базовий Покращено контролем продувки
Підтримка Тільки спільнота Підтримка та оновлення для підприємств

Організації з критично важливими робочими навантаженнями часто обирають NGINX Plus завдяки його підвищеній надійності та спостережуваності.

13) Як реалізувати кешування в NGINX?

Кешування в NGINX покращує швидкість відгуку та зменшує навантаження на серверну частину, зберігаючи часто використовуваний контент локально. Воно вмикається за допомогою proxy_cache директива. Приклад конфігурації:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
    }
}

Cached responses are served directly from disk when a matching request arrives, skipping upstream processing. You can control cache expiration using proxy_cache_valid та виключити певні URI за допомогою proxy_no_cacheЦей механізм є критично важливим для середовищ з високим трафіком, таких як новинні сайти або сайти електронної комерції.

14) Поясніть призначення та використання директиви «try_files».

Команда try_files Директива перевіряє наявність файлів у заданому порядку перед передачею запиту до резервного розташування. Зазвичай вона використовується для статична маршрутизація сайту or односторінкові програми (SPA).

приклад:

location / {
    try_files $uri $uri/ /index.html;
}

Тут NGINX спочатку перевіряє, чи відповідає запитуваний URI файлу, потім каталогу, і, нарешті, направляє невідповідні запити до /index.htmlЦе підвищує ефективність та зручність використання, обслуговуючи кешовані або статичні файли безпосередньо, уникаючи непотрібних викликів серверної частини.

15) Як NGINX може обробляти HTTPS та SSL/TLS-термінації?

NGINX діє як проксі-сервер для завершення SSL/TLS, обробляючи шифрування та дешифрування на рівні сервера, перш ніж пересилати незашифровані запити до вищих сервісів. Приклад конфігурації:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass http://backend;
    }
}

Він підтримує HTTP / 2, Зшивання OCSP, HSTS та сучасні шифрувальні набори, що забезпечує безпечний та високопродуктивний зв'язок. Припинення дії SSL на NGINX зменшує накладні витрати на шифрування на внутрішніх серверах та спрощує керування сертифікатами.

16) Яка різниця між перезаписом та перенаправленням у NGINX?

обидві переписувати та переадресовувати змінюють спосіб маршрутизації запитів, але вони принципово відрізняються:

Аспект Переписати Перенаправлення
тип Внутрішнє переписування URL-адрес Перенаправлення зовнішнього клієнта
відповідь Code 200 (внутрішній) 301/302 (HTTP-переадресація)
Видимість Прозорий для користувача Клієнт бачить нову URL-адресу
Використовуйте Case SEO-зручні URL-адреси, маршрутизація Міграція домену, забезпечення дотримання HTTPS

приклад:

rewrite ^/oldpage$ /newpage permanent;  # Redirect
rewrite ^/img/(.*)$ /assets/$1 break;   # Rewrite

Розуміння цієї відмінності є ключовим для ефективної оптимізації SEO та логіки маршрутизації.

17) Як захистити NGINX від поширених вразливостей?

Посилення безпеки передбачає поєднання найкращих практик:

  • Вимкнути токени сервера: server_tokens off;
  • Методи запитів обмеження: Дозволяти лише GET, POST, HEAD.
  • Обмеження переповнення буфера: Конфігурувати client_max_body_size та client_body_buffer_size.
  • Використовуйте HTTPS із сучасними шифрами.
  • Увімкнути обмеження швидкості через limit_req_zone.
  • Приховати інформацію про версію та вимкнути список каталогів.

Крім того, використовуючи a Брандмауер веб-додатків (WAF) як ModSecurity with NGINX може фільтрувати шкідливий трафік. Регулярне оновлення NGINX та встановлення патчів безпеки є важливим для запобігання експлойтам нульового дня.

18) Що таке змінні NGINX і як вони використовуються в конфігураціях?

Змінні NGINX зберігають динамічні дані, що використовуються в конфігураціях та обробці журналів. Вони можуть представляти заголовки запитів, IP-адреси клієнтів або обчислені значення. Приклади включають $remote_addr, $host, $uri, $request_method та $upstream_addr.

Наприклад:

log_format custom '$remote_addr - $host - $uri';

Змінні додають гнучкості, дозволяючи умовну маршрутизацію та налаштування журналу. Ви також можете визначити користувацькі змінні за допомогою set директива, яка допомагає в проектуванні модульної конфігурації.

19) Як налаштувати обмеження швидкості в NGINX?

Обмеження швидкості контролює частоту надсилання запитів користувачами, захищаючи від атак методом перебору та DDoS. Воно налаштовується за допомогою limit_req_zone директива:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    location / {
        limit_req zone=mylimit burst=5;
    }
}

Це дозволяє один запит на секунду з пакетом по п'ять запитів. NGINX відкидає надлишкові запити або затримує їх залежно від конфігурації. Обмеження швидкості забезпечує справедливе використання ресурсів і запобігає перевантаженню сервера.

20) Які переваги та недоліки використання NGINX як зворотного проксі-сервера?

NGINX як зворотний проксі пропонує численні переваги, але також має деякі недоліки:

Переваги Недоліки
Висока продуктивність та обробка паралельних процесів Потрібне ручне налаштування для масштабних розгортань
Термінація SSL та централізована безпека Обмежена підтримка динамічних модулів (під час компіляції)
Підтримка балансування навантаження та кешування Складна конфігурація для нових користувачів
Фільтрація прикладного рівня Відсутність виконання нативного динамічного контенту

Його переваги значно переважають обмеження в більшості корпоративних сценаріїв, що робить NGINX незамінним компонентом сучасної веб-інфраструктури.

21) Як можна контролювати продуктивність та стан NGINX у продакшені?

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

  1. Вбудований модуль стану (stub_status):

    Відображає активні з’єднання, оброблені запити та стани читання/запису. Приклад:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. Панель керування NGINX Plus: Надає показники в режимі реального часу через REST API та графічний інтерфейс.
  3. Сторонні інтеграції: Такі інструменти, як Prometheus, Grafana, Datadog або ELK, можуть збирати метрики та журнали.
  4. Журнали доступу та помилок: Регулярна ротація журналів та аналіз за допомогою таких інструментів, як GoAccess або AWStats, покращують спостережуваність.

Моніторинг допомагає забезпечити безперебійну роботу, швидке виявлення збоїв та планування потужностей.

22) Яка різниця між директивами proxy_pass та fastcgi_pass?

Обидві директиви пересилають запити до бекенд-сервісів, але розроблені для різних протоколів:

Directive Мета Протокол бекенду Приклад використання
proxy_pass Пересилає HTTP- або HTTPS-запити на внутрішні сервери HTTP Revпроксування веб-API або мікросервісів
fastcgi_pass Надсилає запити до процесора FastCGI FastCGI PHP-FPM, Python FastCGI-додатки

приклад:

location /api/ {
    proxy_pass http://backend;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

Підсумовуючи, використовуйте proxy_pass для загальних HTTP-бекендів та fastcgi_pass для динамічних мовних середовищ, таких як PHP.

23) Як налаштувати gzip-стиснення в NGINX та які його переваги?

Увімкнення стиснення Gzip у NGINX зменшує використання пропускної здатності та покращує час завантаження, стискаючи текстові відповіді перед їх надсиланням клієнтам.

Приклад конфігурації:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_vary on;

Переваги:

  • Зменшує розмір файлів, що передаються, до 70%.
  • Покращує показники часу до першого байта (TTFB) та продуктивності сторінок.
  • Зменшує витрати на пропускну здатність, особливо корисно для мобільних користувачів.

Однак, його не слід застосовувати до вже стиснутих файлів (наприклад, .zip, .jpg, .png), щоб уникнути накладних витрат на процесор.

24) Які найкращі практики для налаштування NGINX для високого трафіку?

Оптимізація високого трафіку передбачає ретельне налаштування ресурсів та параметрів конфігурації:

Область Directive Рекомендована практика
Робітники worker_processes auto; Зіставлення ядер процесора
Зв'язки worker_connections 4096; Збільшення паралельності
Залишатися живим keepalive_timeout 65; Оптимізуйте повторне використання клієнта
Файл Descriptор OS ulimit -n Підвищити ліміти для відкритих сокетів
кешування proxy_cache_path Зменшення навантаження на серверну частину
Gzip gzip on; Стиснути текстові відповіді

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

25) Як NGINX обробляє з'єднання WebSocket?

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

Приклад конфігурації:

location /ws/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Ключові моменти:

  • Команда Upgrade та Connection заголовки обов'язкові.
  • Переконайтеся, що NGINX використовує HTTP/1.1 для постійних TCP-з'єднань.
  • Балансування навантаження для WebSockets може вимагати закріплених сесій з використанням ip_hash.

Ця конфігурація підтримує такі програми, як чат, торгівля акціями або ігри.

26) Яке призначення директиви «worker_rlimit_nofile»?

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

worker_rlimit_nofile 100000;

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

27) Як можна використовувати NGINX для автоматичного перезапису URL-адрес або перенаправлення на HTTPS?

Перенаправлення HTTP на HTTPS забезпечує безпечне з’єднання. Приклад:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Ця конфігурація видає 301 постійне перенаправлення з HTTP на HTTPS. Для кращого контролю правила перезапису можуть забезпечити перенаправлення на основі шляху:

rewrite ^/oldpath$ /newpath permanent;

Автоматичне застосування HTTPS покращує рейтинг SEO, запобігає атакам типу «посередник» та забезпечує стабільний користувацький досвід.

28) Які поширені причини помилок «502 Bad Gateway» у NGINX?

«502 Bad Gateway» означає, що NGINX, який діє як проксі-сервер, не зміг отримати коректну відповідь від сервера вищого рівня. Найпоширеніші причини включають:

  • Збій або недоступність бекенд-сервера.
  • неправильний proxy_pass URL-адреса або шлях до сокета.
  • Тайм-аут висхідного потоку (proxy_read_timeout занадто низько).
  • Брандмауер або SELinux блокують з'єднання з вищим рівнем.
  • Неправильно налаштовані параметри FastCGI (для PHP).

Для налагодження перевірте журнали помилок (/var/log/nginx/error.log), перевіряйте доступність вищезгаданого потоку та тестуйте відповіді сервера безпосередньо через curl.

29) Як NGINX підтримує мікросервіси та контейнерні архітектури (наприклад, Docker, Kubernetes)?

NGINX ідеально підходить для мікросервісних середовищ завдяки своїй легкій конструкції та функції зворотного проксі. У Docker або Kubernetes він виконує такі функції:

  • Контролер вхідного сигналу: Керує зовнішнім HTTP/S-трафіком до внутрішніх служб.
  • Шлюз обслуговування: Виконує маршрутизацію, балансування навантаження та автентифікацію.
  • Проксі-сервер для сайдкара: Підвищує стійкість та спостережуваність у сервісних сітках (наприклад, Istio).

Конфігурації NGINX можна динамічно оновлювати за допомогою Kubernetes ConfigMaps, що забезпечує централізоване керування трафіком та SSL. Його модульний підхід ідеально поєднується з контейнерними та хмарними розгортаннями.

30) Які існують різні способи покращення безпеки NGINX для виробничих систем?

Покращення безпеки NGINX вимагає багаторівневої конфігурації:

  1. Захист SSL/TLS: Використовуйте сучасні шифри, вимкніть SSLv3/TLSv1.0.
  2. Обмеження методів HTTP: Дозволяйте лише безпечні дієслова (GET, POST, HEAD).
  3. Заголовки безпеки: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Приховати інформацію про версію: server_tokens off;
  5. Увімкнути обмеження швидкості та контроль доступу.
  6. Інтегруйте WAF або Fail2Ban для запобігання грубій силі.

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

31) Як можна ефективно налагоджувати проблеми NGINX?

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

  1. Перевірте синтаксис:
    2. nginx -t
  2. Перевіряє конфігурацію перед перезавантаженням.

    3. Увімкнути ведення журналу налагодження:

    error_log /var/log/nginx/error.log debug;
  3. Забезпечує детальну діагностику під час виконання.

    4. Аналіз журналів доступу: Виявлення кодів відповідей та шаблонів запитів за допомогою:

    tail -f /var/log/nginx/access.log
  4. Перевірка підключення: Скористайтеся кнопкою curl -v or wget щоб перевірити доступність бекенду.
  5. Моніторинг активних з'єднань: через stub_status or netstat.

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

32) Як налаштувати ведення журналу NGINX та які існують користувацькі формати журналів?

NGINX забезпечує гнучкі механізми ведення журналу через access_log та error_log директиви.

Приклад конфігурації:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$request_time"';

access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;

Ви можете визначити користувацькі формати включити такі показники, як $upstream_addr, $request_timeабо $bytes_sent.

Для поглибленого спостереження журнали часто надсилаються до ЛОСЬ, Локі або Спланк для аналізу та панелі інструментів у режимі реального часу.

33) Яка роль директиви proxy_buffering в NGINX?

proxy_buffering контролює, чи буферизує NGINX відповіді від серверів вищої ланки перед надсиланням їх клієнтам.

Установка Опис Використовуйте Case
proxy_buffering on; Bufferвесь відгук для оптимізованої пропускної здатності За замовчуванням; покращує продуктивність
proxy_buffering off; Передає дані безпосередньо клієнтам без буферизації Потокове передавання в реальному часі або API

Наприклад, щоб вимкнути буферизацію:

location /stream/ {
    proxy_buffering off;
}

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

34) Поясніть, як кешування NGINX можна зробити недійсним або видалити.

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

  1. Ручне очищення: Видалити файли з каталогу кешу. 
    rm -rf /var/cache/nginx/*
  2. Модуль стороннього розробника: Скористайтеся кнопкою ngx_cache_purge для очищення через HTTP-запит: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. Функція NGINX Plus: Дозволяє динамічне очищення кешу на основі API.

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

35) Як NGINX обробляє тайм-аути з'єднання?

NGINX надає кілька директив тайм-ауту для керування часом очікування відповідей клієнта або основного потоку:

Directive Мета За замовчуванням
client_body_timeout Час очікування тіла клієнта 60
client_header_timeout Час очікування заголовка клієнта 60
keepalive_timeout Неактивні з'єднання keepalive 75
send_timeout Час надсилання даних клієнту 60
proxy_read_timeout Час очікування відповіді вихідного коду 60

Правильне налаштування дозволяє уникнути непотрібних розривів з'єднання та забезпечує плавнішу роботу користувачів за змінних мережевих умов.

36) Як реалізувати синьо-зелене розгортання за допомогою NGINX?

В синьо-зелене розгортання, два середовища (синій = активний, зелений = режим очікування) працюють одночасно. NGINX діє як маршрутизатор трафіку між ними.

Приклад конфігурації:

upstream app_cluster {
    server blue.example.com;
    #server green.example.com; # Uncomment during switch
}
server {
    location / {
        proxy_pass http://app_cluster;
    }
}

Коли нова версія (зелена) буде протестована та перевірена, трафік перемикається шляхом оновлення визначення вихідного потоку та перезавантаження NGINX (nginx -s reload).

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

37) Що таке обмеження швидкості пакетної передачі даних, і як це покращує продуктивність NGINX?

Команда вибух Параметр обмеження швидкості дозволяє тимчасово пропускати короткі піки трафіку без негайного відхилення.

приклад:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
}

Тут миттєво приймаються п'ять додаткових запитів перед застосуванням дроселювання.

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

38) Як NGINX обробляє IPv6 та двостекові середовища?

NGINX повністю підтримує IPv6 як у серверній, так і в вихідній конфігурації. Приклад:

server {
    listen [::]:80 ipv6only=on;
    server_name example.com;
}

Підтримка подвійного стеку (IPv4 + IPv6) досягається шляхом включення обох:

listen 80;
listen [::]:80;

Сумісність з IPv6 забезпечує ширшу доступність, особливо для мобільних та міжнародних клієнтів, і є критично важливою для дотримання сучасних інтернет-стандартів.

39) Як налаштувати закріплені сесії в балансуванні навантаження NGINX?

Закріплені сесії гарантують, що запити від одного й того ж клієнта завжди спрямовуються на один і той самий сервер.

  1. використання ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. Липкий файл cookie NGINX Plus:
    Розширене збереження сеансу за допомогою налаштовуваних файлів cookie.

Sticky sessions are vital for stateful applications like user dashboards or shopping carts, ensuring session data consistency without shared storage.

40) Які основні рівні логування в NGINX і чим вони відрізняються?

NGINX підтримує ієрархічні рівні журналу для контролю деталізації журналу помилок.

рівень Опис
debug Детальна інформація для усунення несправностей (дуже детальна)
info Загальна інформація про виконання
notice Значні, але не критичні події
warn Потенційні проблеми або неправильні конфігурації
error Operaційні помилки, що потребують уваги
crit, alert, emerg Критичні збої та системні сповіщення

Приклад конфігурації:

error_log /var/log/nginx/error.log warn;

Налаштування рівнів журналювання відповідно до середовища (налагодження в проміжній версії, попередження в продакшені) допомагає підтримувати баланс між видимістю та продуктивністю.

41) Як ви оцінюєте продуктивність NGINX?

Бенчмаркінг NGINX включає вимірювання пропускної здатності, затримки та паралельності для виявлення вузьких місць у конфігурації. Серед поширених інструментів:

ApacheBench (аб):

ab -n 10000 -c 100 http://example.com/
  • Тести запитують обсяг та паралельність.
  • робота: Надає детальні процентилі затримки та частоту запитів.
  • облога / httperf: Моделює реальне дорожнє навантаження.
  • Графана + Прометей: Відстежує показники продуктивності в реальному часі.

Бенчмаркінг повинен вимірювати такі параметри, як requests per second (RPS), time per request та error rate.

Налаштування змінних, таких як worker_processes, worker_connections та keepalive_timeout значно покращує спостережувану пропускну здатність.

42) Як NGINX може інтегруватися з конвеєрами CI/CD?

NGINX бездоганно інтегрується з CI/CD для автоматизованого розгортання, тестування та керування конфігурацією. Загальні підходи включають:

  • Інфраструктура як Code (Інтеграційний центр): Керуйте конфігураціями за допомогою діаграм Ansible, Terraform або Helm.
  • Контейнери Docker: Створюйте та розгортайте образи NGINX за допомогою інструментів неінтегрованої інтеграції (Jenkins, GitLab CI або GitHub Actions).
  • Автоматизоване тестування: Перевірте конфігурації за допомогою nginx -t на етапах трубопроводу.
  • Синьо-зелений / Canary Автоматизація розгортання: Динамічно оновлювати сервери вищої ланки під час розгортання.

Приклад фрагмента коду GitLab CI:

deploy:
  script:
    - nginx -t
    - systemctl reload nginx

Автоматизоване розгортання забезпечує послідовне, контрольоване версіями та надійне розгортання NGINX.

43) Поясніть роль контролера вхідного потоку NGINX у Kubernetes.

Команда Контролер входу NGINX керує вхідним трафіком до сервісів Kubernetes. Він динамічно перетворює ресурси Kubernetes Ingress у конфігурації NGINX.

Основні функції:

  • Направляє HTTP/S-запити до правильного сервісу.
  • Забезпечує завершення SSL-підключень, обмеження швидкості та перезапис URL-адрес.
  • Підтримує балансування навантаження між подами.
  • Вмикає анотації для детального контролю (наприклад, rewrite-target, proxy-body-size).

Приклад вхідного YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Ця архітектура відокремлює логіку маршрутизації трафіку від розгортання контейнерів для гнучкої масштабованості.

44) Як NGINX обробляє HTTP/2 та які його переваги?

NGINX повністю підтримує HTTP / 2, наступник HTTP/1.1, що підвищує ефективність завдяки мультиплексуванню та стисненню заголовків.

Щоб увімкнути HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

переваги:

особливість Опис
Мультиплексування Кілька запитів на одне TCP-з'єднання
Стиснення заголовків (HPACK) Зменшує використання пропускної здатності
Сервер натиснути Превентивно надсилає активи клієнтам
Швидший TLS Оптимізовані безпечні рукостискання

HTTP/2 значно зменшує затримку та час завантаження сторінок, особливо для сучасних вебзастосунків з численними ресурсами.

45) Яка різниця між keepalive для вихідного коду та повторним використанням з’єднання в NGINX?

Підтримка активності вище за течією підтримує постійні з’єднання з внутрішніми серверами, зменшуючи накладні витрати на TCP-підтвердження. Приклад:

upstream backend {
    server app1.example.com;
    keepalive 32;
}

Різниця:

Аспект Залишатися живим Повторне використання підключення
Сфера Між NGINX та апстрімом Між NGINX та клієнтами
Мета Оптимізація бекенду Продуктивність фронтенду
конфігурація keepalive всередині upstream keepalive_timeout in server блок

Обидва методи зменшують затримку, але обслуговують різні рівні зв'язку (клієнтський та серверний).

46) Як можна динамічно переналаштувати NGINX без його перезапуску?

Щоб динамічно застосовувати нові конфігурації без простоїв, використовувати reload механізм:

nginx -t && nginx -s reload

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

У NGINX Plus можна вносити зміни через API (наприклад, динамічне додавання серверів вищої ланки):

curl --request POST \
  --url http://localhost:8080/api/3/http/upstreams/backend/servers \
  --header 'Content-Type: application/json' \
  --data-raw '{"server":"10.0.0.12"}'

Ця можливість підтримує розгортання з нульовим часом простою в сучасних DevOps-конвеєрах.

47) Які ключові відмінності між зворотним проксі та прямим проксі в NGINX?

Аспект Reverse Проксі Переслати проксі
Видимість клієнта Клієнти не знають про внутрішні сервери Сервери не знають про особу клієнта
Основне використання Балансування навантаження, кешування, завершення SSL Фільтрація, анонімність, контроль доступу
Загальний випадок використання Розподіл веб-трафіку Корпоративний або безпечний вихідний перегляд веб-сторінок
Підтримка NGINX Рідний та широко використовуваний Потрібна власна конфігурація

Приклад (прямий проксі-сервер):

location / {
    proxy_pass $scheme://$http_host$request_uri;
    proxy_set_header Host $http_host;
}

RevПроксування залишається домінуючим варіантом використання, особливо для шлюзів API та мікросервісних архітектур.

48) Як NGINX можна використовувати для обмеження та дроселювання швидкості API?

Обмеження швидкості захищає API від зловживань та забезпечує чесне використання. Приклад конфігурації:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Механізм:

  • limit_req_zoneВизначає зону та швидкість спільної пам'яті.
  • burstДозволяє обмежені тимчасові спайки.
  • nodelayНегайно застосовує обмеження.

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

49) Які типові випадки використання NGINX у корпоративних DevOps-середовищах?

У корпоративних DevOps-екосистемах NGINX виконує кілька критично важливих ролей:

  1. Веб-сервер: Високопродуктивна доставка статичного контенту.
  2. RevІнший проксі-сервер / балансувальник навантаження: Управління трафіком між мікросервісами.
  3. Шлюз API: Аутентифікація, маршрутизація та дроселювання.
  4. Контролер вхідного сигналу: Для кластерів Kubernetes.
  5. Шар кешування контенту: Зменшує навантаження на серверну частину.
  6. Кінцева точка завершення SSL: Централізоване управління сертифікатами.
  7. Кінцева точка моніторингу: Інтеграція метрик та спостережуваності.

Його легкий розмір та модульна конструкція роблять NGINX незамінним у конвеєрах CI/CD, гібридних хмарах та кластерах високої доступності.

50) Які основні відмінності між NGINX та HAProxy для балансування навантаження?

Обидва є високопродуктивними балансувальниками навантаження, але вони відрізняються за фокусом та архітектурою:

особливість NGINX HAProxy
Основна роль Веб-сервер + зворотний проксі-сервер Виділений балансувальник навантаження TCP/HTTP
Простота конфігурації Легше для веб-навантажень Складний, але більш детальний контроль
Підтримка рівня L7 (HTTP), частково L4 L4 та L7 повністю
Динамічна реконфігурація Обмежений (з відкритим кодом) Оновлення рідного середовища виконання
продуктивність Чудово підходить для змішаних навантажень Чудово підходить для балансування навантаження
Додаткові можливості Кешування, стиснення, статичний контент Перевірки здоров'я, таблиці з палицями

Підприємства часто об'єднуються NGINX (інтерфейс) та HAProxy (бекенд) для оптимальної маршрутизації та масштабованості.

🔍 Найпопулярніші питання на співбесіді з NGINX з реальними сценаріями та стратегічними відповідями

1) Що таке NGINX і чому його зазвичай використовують у виробничих середовищах?

Очікується від кандидата: Інтерв'юер хоче оцінити ваші базові знання про NGINX та ваше розуміння його практичної цінності в реальних системах.

Приклад відповіді: «NGINX — це високопродуктивний веб-сервер і зворотний проксі-сервер, відомий своєю подієво-керованою архітектурою. Він широко використовується у виробничих середовищах, оскільки може ефективно обробляти велику кількість одночасних підключень, споживаючи при цьому менше системних ресурсів, ніж традиційні веб-сервери».

2) Чи можете ви пояснити різницю між NGINX та Apache?

Очікується від кандидата: Інтерв'юер оцінює вашу здатність порівнювати технології та вибирати правильний інструмент на основі варіантів використання.

Приклад відповіді: «NGINX використовує асинхронну, неблокувальну архітектуру, що робить її ефективнішою для обробки високого трафіку та статичного контенту. Apache використовує процесно-орієнтовану модель, яка може бути більш гнучкою для динамічних конфігурацій, але може споживати більше ресурсів під час великого навантаження».

3) Як NGINX працює як зворотний проксі?

Очікується від кандидата: Інтерв'юер хоче підтвердити ваше розуміння концепцій зворотного проксі-сервера та того, як NGINX вписується в сучасні архітектури.

Приклад відповіді: «NGINX діє як зворотний проксі-сервер, отримуючи запити клієнтів та пересилаючи їх на сервери бекенду. Потім він повертає відповіді сервера клієнту, що покращує безпеку, розподіл навантаження та загальну продуктивність».

4) Опишіть ситуацію, коли ви використовували NGINX для балансування навантаження.

Очікується від кандидата: Інтерв'юер очікує практичного досвіду та вашої здатності застосовувати функції NGINX у реальних сценаріях.

Приклад відповіді: «На моїй попередній посаді я налаштував NGINX для розподілу трафіку між кількома серверами додатків, використовуючи алгоритми циклічного перебору та найменшої кількості з’єднань. Такий підхід покращив доступність додатків і запобіг перетворенню будь-якого окремого сервера на вузьке місце».

5) Як ви обробляєте конфігурацію SSL та HTTPS у NGINX?

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

Приклад відповіді: «На попередній посаді я налаштовував SSL, встановлюючи сертифікати, увімкнувши HTTPS-слухачі та забезпечуючи використання надійних шифрів. Я також впровадив перенаправлення HTTP на HTTPS, щоб забезпечити безпечний зв’язок між усіма кінцевими точками».

6) Які кроки ви б зробили для усунення помилки 502 Bad Gateway у NGINX?

Очікується від кандидата: Інтерв'юер перевіряє ваші навички вирішення проблем та методологію усунення несправностей.

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

7) Як оптимізувати продуктивність NGINX для застосунків з високим трафіком?

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

Приклад відповіді: «На попередній роботі я оптимізував NGINX, увімкнувши стиснення gzip, налаштувавши робочі процеси та налаштувавши кешування для статичного контенту. Ці зміни значно зменшили час відгуку та навантаження на сервер».

8) Чи можете ви пояснити, як NGINX обробляє статичний та динамічний контент?

Очікується від кандидата: Інтерв'юер оцінює ваше розуміння обробки запитів та оптимізації продуктивності.

Приклад відповіді: «NGINX обслуговує статичний контент безпосередньо та дуже ефективно з файлової системи. Для динамічного контенту він пересилає запити на сервери додатків або сервіси, такі як PHP-FPM, дозволяючи кожному компоненту зосередитися на тому, що він робить найкраще».

9) Як безпечно керувати змінами конфігурації NGINX та тестувати їх?

Очікується від кандидата: Інтерв'юер хоче зрозуміти ваш підхід до надійності та зниження ризиків.

Приклад відповіді: «Я перевіряю зміни конфігурації за допомогою команди NGINX configuration test перед перезавантаженням служби. Я також застосовую зміни під час періодів обслуговування та уважно стежу за журналами після розгортання».

10) Опишіть випадок, коли вам довелося швидко вирішити проблему з NGINX.

Очікується від кандидата: Інтерв'юер оцінює вашу здатність працювати під тиском та ефективно спілкуватися під час інцидентів.

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

Підсумуйте цей пост за допомогою: