Top 50 întrebări și răspunsuri la interviu Nginx (2026)

prin: Bryce Leo Bryce Leo
Hours Actualizat

Întrebări și răspunsuri importante pentru interviuri Nginx

Pregătirea pentru un interviu Nginx necesită previziune, claritate și conștientizare a modului în care intervievatorii evaluează cunoștințele operaționale reale astăzi. Întrebările pentru interviul Nginx dezvăluie profunzime, luarea deciziilor, capacitatea de depanare și pregătirea pentru producție.

Aceste roluri deschid căi în infrastructura cloud, ingineria performanței și securitatea, unde configurațiile practice contează. Angajatorii apreciază experiența tehnică, expertiza în domeniu și analiza dobândită prin munca în domeniu, ajutând...ping Absolvenții, inginerii de nivel mediu și profesioniștii seniori aplică abilități de bază și avansate în cadrul echipelor sub îndrumarea managerilor și a liderilor de echipă. Citeste mai mult…

👉 Descărcare gratuită în format PDF: Întrebări și răspunsuri pentru interviul Nginx

Întrebări și răspunsuri importante pentru interviuri Nginx

1) Explicați ce este NGINX și de ce este utilizat pe scară largă în infrastructura web.

NGINX este un server web open-source de înaltă performanță care funcționează și ca proxy invers, echilibrator de încărcare și cache HTTP. Acceptă protocoalele HTTP, HTTPS, SMTP, POP3 și IMAP. Arhitectura utilizează o event-driven, asynchronous model ceea ce îi permite să gestioneze zeci de mii de conexiuni simultane cu un consum redus de memorie și CPU. Această scalabilitate face ca NGINX să fie potrivit în special pentru aplicații web cu trafic intens, microservicii și arhitecturi distribuite. De exemplu, companiile cu sarcini de lucru cu trafic intens (cum ar fi platformele de conținut sau gateway-urile API) preferă adesea NGINX pentru gestionarea eficientă a conexiunilor simultane și a livrării de conținut static.

2) Cum gestionează NGINX intern cererile HTTP (arhitectură bazată pe evenimente)?

Punctul forte al NGINX constă în event-driven, non-blocking architectureÎn loc să genereze un fir de execuție sau un proces separat pentru fiecare solicitare (cum ar fi serverele tradiționale), NGINX utilizează un set mic de procese worker care utilizează bucle de evenimente asincrone. Fiecare worker poate gestiona mii de conexiuni așteptând notificări de disponibilitate a sistemului de operare și procesând evenimentele atunci când acestea apar. Deoarece nu se blochează la operațiunile I/O, NGINX poate servi conținut static și proxy cu resurse minime. Acest model este ideal pentru cazurile de utilizare cu concurență ridicată, fiind mai eficient decât serverele bazate pe procese sub sarcini mari.

3) Care sunt principalele diferențe dintre NGINX și Apache?

Deși atât NGINX, cât și Apache sunt servere web populare, ele diferă în ceea ce privește arhitectura, performanța și obiectivele de design:

Aspect Nginx Apache
Model de concurență Bazat pe evenimente (asincron, fără blocare) Bazat pe proces / fire de execuție (blocare)
Folosirea memoriei Scăzut per conexiune Mai mare per conexiune
Cel mai bun caz de utilizare Trafic intens, conținut static, echilibrarea încărcării Conținut dinamic și ecosistem bogat de module
Scalabilitate Scalează cu mai puține resurse Necesită mai mult hardware din cauza proceselor
Manipularea modulelor Module selectate la momentul compilării Dinamic în timpul execuției

Designul NGINX optimizează performanța sub sarcină, în timp ce Apache oferă o flexibilitate mai mare cu module dinamice și suport larg pentru limbaje.

4) Care sunt componentele cheie ale unui fișier de configurare NGINX?

Un fișier de configurare NGINX (calea implicită: /etc/nginx/nginx.conf) constă din blocuri de directive structurate care determină cum se comportă NGINX:

  • Context principal: setări globale, cum ar fi worker_processes, error_log și pid
  • Blocul de evenimente: gestionează conexiunile lucrătorilor și multi-procesarea
  • Bloc HTTP: conține configurații pentru gestionarea HTTP (compresie, cache, gzip etc.)
    • Bloc server: definește gazdele virtuale (domenii și porturi)
    • Bloc de locații: definește regulile de rutare și modul în care sunt gestionate URI-urile specifice

Aceste blocuri lucrează împreună pentru a direcționa cererile, a defini setările proxy și a configura SSL/TLS și cache-ul.

5) Cum reîncarci configurația NGINX în siguranță, fără întreruperi?

Pentru a reîncărca NGINX cu configurații actualizate without interrupting active connections, utilizați următoarea comandă:

nginx -s reload

sau pe sisteme care utilizează systemd:

sudo systemctl reload nginx

Această comandă semnalează procesului principal să citească din nou fișierele de configurare și să repornească corect workerele fără întrerupere.ping conexiuni existente. Cunoașterea modului de efectuare a unor astfel de reîncărcări fără probleme este esențială în mediile care necesită disponibilitate ridicată.

6) Descrieți cum se configurează NGINX ca proxy invers.

Un proxy invers redirecționează cererile clienților către serverele backend (grupul upstream) și apoi returnează răspunsul. Mai jos este un bloc tipic de proxy invers 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;
        }
    }
}

Această configurație îmbunătățește securitatea, oferă distribuția încărcării și activează politici de caching sau de limitare a ratei între clienți și serverele de aplicații.

7) Explicați procesele NGINX Master și Worker.

În NGINX:

  • Proces principal gestionează configurația, pornește procesele worker și gestionează operațiuni privilegiate, cum ar fi legarea la porturi.
  • Procesele lucrătorilor se ocupă de gestionarea propriu-zisă a cererilor — procesarea conexiunilor primite și executarea regulilor configurate.

Mai mulți lucrători îmbunătățesc concurența și pot fi ajustați în funcție de nucleele CPU disponibile și de cerințele de trafic. Împărțirea rolurilor îmbunătățește performanța și stabilitatea.

Nu ratați:

8) Cum poți restricționa procesarea numelor de server nedefinite în NGINX?

Pentru a renunța la cereri fără un valid Host antet în NGINX:

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

Această configurație returnează cod 444, o stare NGINX non-standard care închide conexiunea fără răspuns, respingând efectiv gazdele nedefinite și îmbunătățind securitatea.

9) La ce se folosește modulul ngx_http_upstream_module?

ngx_http_upstream_module definește groups of backend servers (în amonte) cărora NGINX le poate transmite cereri folosind directive precum proxy_pass, fastcgi_pass, uwsgi_passAcest lucru permite flexibilitate în scalarea aplicațiilor în spatele mediilor cu sarcină echilibrată. Atunci când sunt grupate mai multe servere backend, NGINX poate distribui traficul pe baza unor politici definite, suportând strategii round-robin și alte strategii.

10) Descrieți cum este utilizat NGINX pentru a servi conținut static și dinamic.

NGINX este extrem de eficient în deservirea fișiere statice (HTML, CSS, imagini) direct folosind bucla sa de evenimente optimizată și mecanismele de intrare/ieșire a fișierelor. Pentru conținut dinamic, NGINX transmite cereri către procesoare backend precum PHP-FPM, Python Servere WSGI sau framework-uri de aplicații prin mecanisme FastCGI/proxy. Această separare permite NGINX să exceleze ca server de fișiere static, utilizând în același timp servicii backend pentru generare dinamică, asigurând performanță și scalabilitate optime.

11) Cum funcționează echilibrarea încărcării în NGINX și care sunt diferitele metode disponibile?

NGINX oferă servicii robuste echilibrarea încărcăturii prin upstream directivă, distribuind traficul pe mai multe servere backend pentru a optimiza performanța și a asigura o disponibilitate ridicată. Aceasta acceptă mai multe metode:

Metodă Descriere Cel mai bun caz de utilizare
Round Robin Metodă implicită care rotește secvențial cererile între servere. Sarcini de lucru distribuite uniform.
Cele mai puține conexiuni Trimite cereri către serverul cu cele mai puține conexiuni active. Sesiuni de lungă durată.
IP Hash Folosește adresa IP a clientului pentru a determina selecția serverului. Persistența sesiunii.
Cel mai mic timp Solduri bazate pe timpul de răspuns și numărul de conexiuni. Aplicații sensibile la latență.

NGINX poate, de asemenea, să efectueze controale de sănătate pentru a elimina dinamic serverele nesănătoase, asigurând un flux de trafic fără probleme și reziliență.

12) Care este diferența dintre NGINX open source și NGINX Plus?

Nginx Open Source este versiunea comunitară care oferă funcții esențiale de server web, proxy și echilibrare a încărcării. NGINX Plus este ediția comercială care extinde aceste caracteristici cu îmbunătățiri la nivel de întreprindere, cum ar fi monitorizare avansată, persistența sesiunilor, reconfigurare dinamică și verificări active ale stării de funcționare.

Caracteristică NGINX Open Source NGINX Plus
Load Balancing De bază (Round Robin, IP Hash) Avansat (Timp minim, Reconfigurare dinamică)
Monitorizarea Instrumente manuale / externe Tablou de bord și API încorporate
Caching pachet de bază Îmbunătățit cu control al purjării
Asistență Doar comunitate Asistență și actualizări pentru întreprinderi

Organizațiile cu sarcini de lucru critice aleg adesea NGINX Plus pentru fiabilitatea și observabilitatea sa sporite.

13) Cum se implementează cache-ul în NGINX?

Caching-ul în NGINX îmbunătățește viteza de răspuns și reduce încărcarea backend-ului prin stocarea locală a conținutului accesat frecvent. Este activat folosind proxy_cache directivă. Exemplu de configurație:

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

Răspunsurile memorate în cache sunt livrate direct de pe disc atunci când sosește o solicitare potrivită, săriți pesteping procesare în amonte. Puteți controla expirarea memoriei cache folosind proxy_cache_valid și exclude URI-uri specifice cu proxy_no_cacheAcest mecanism este crucial pentru mediile cu trafic intens, cum ar fi site-urile de știri sau de comerț electronic.

14) Explicați scopul și utilizarea directivei „try_files”.

try_files Directiva verifică existența fișierelor într-o ordine specificată înainte de a transmite o solicitare către locația de rezervă. Este utilizată în mod obișnuit pentru rutare statică a site-ului or aplicații cu o singură pagină (SPA).

Exemplu:

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

Aici, NGINX verifică mai întâi dacă URI-ul solicitat se potrivește cu un fișier, apoi cu un director și în final direcționează cererile nepotrivite către /index.htmlAcest lucru îmbunătățește eficiența și experiența utilizatorului prin servirea directă a fișierelor din cache sau statice, evitând apelurile backend inutile.

15) Cum poate NGINX să gestioneze terminarea HTTPS și SSL/TLS?

NGINX acționează ca un proxy de terminare SSL/TLS, gestionând criptarea și decriptarea la nivelul serverului înainte de a redirecționa cererile necriptate către serviciile din amonte. Exemplu de configurație:

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

Aceasta susține HTTP / 2, Capsare OCSP, HSTS și suite de cifrare moderne, permițând comunicații sigure și de înaltă performanță. Terminarea SSL la NGINX reduce costurile de criptare pe serverele backend și simplifică gestionarea certificatelor.

16) Care este diferența dintre rescriere și redirecționare în NGINX?

Ambele rescrie și redirecționa modifică modul în care sunt direcționate cererile, dar acestea diferă fundamental:

Aspect Rescrie Redirecţiona
Tip Intern URL rescrierea Redirecționare client extern
Răspuns Code 200 (intern) 301/302 (redirecționare HTTP)
Vizibilitate Transparent pentru utilizator Clientul vede nou URL
Utilizare caz SEO Friendly URLs, rutare Migrarea domeniului, aplicarea HTTPS

Exemplu:

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

Înțelegerea acestei distincții este esențială pentru optimizarea eficientă a SEO și a logicii de rutare.

17) Cum securizezi NGINX de vulnerabilități comune?

Consolidarea securității implică o combinație de bune practici:

  • Dezactivați token-urile serverului: server_tokens off;
  • Metode de solicitare limită: Se permit doar GET, POST și HEAD.
  • Restricționarea depășirilor de buffer: Configurați client_max_body_size și client_body_buffer_size.
  • Folosește HTTPS cu cifruri moderne.
  • Activează limitarea ratei de limit_req_zone.
  • Ascundeți informațiile despre versiune și dezactivați listarea directoarelor.

În plus, folosind a Firewall pentru aplicații web (WAF) precum ModSecurity with NGINX poate filtra traficul malițios. Actualizarea regulată a NGINX și aplicarea patch-urilor de securitate sunt esențiale pentru a preveni exploatările zero-day.

18) Ce sunt variabilele NGINX și cum sunt utilizate în configurații?

Variabilele NGINX stochează date dinamice utilizate în configurații și procesarea jurnalelor. Acestea pot reprezenta anteturi de solicitare, adrese IP ale clienților sau valori calculate. Exemplele includ $remote_addr, $host, $uri, $request_method și $upstream_addr.

De exemplu:

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

Variabilele adaugă flexibilitate, permițând rutarea condiționată și înregistrarea în jurnal personalizată. De asemenea, puteți defini variabile personalizate folosind set directivă, care ajută la proiectarea configurației modulare.

19) Cum poți configura limitarea ratei în NGINX?

Limitarea ratei controlează frecvența cu care utilizatorii pot trimite solicitări, protejând împotriva atacurilor brute force și DDoS. Este configurată folosind limit_req_zone directivă:

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

Aceasta permite o solicitare pe secundă, cu o intensitate de cinci. NGINX elimină solicitările în exces sau le întârzie în funcție de configurație. Limitarea ratei asigură o utilizare echitabilă a resurselor și previne supraîncărcarea serverului.

20) Care sunt avantajele și dezavantajele utilizării NGINX ca proxy invers?

NGINX ca proxy invers oferă numeroase beneficii, dar și unele compromisuri:

Avantaje Dezavantaje
Performanță ridicată și gestionarea concurenței Necesită reglare manuală pentru implementări la scară largă
Terminare SSL și securitate centralizată Suport limitat pentru module dinamice (la compilare)
Suport pentru echilibrarea încărcării și memorarea în cache Configurație complexă pentru utilizatori noi
Filtrarea la nivelul aplicației Lipsa execuției native de conținut dinamic

Avantajele sale depășesc cu mult limitările în majoritatea scenariilor de întreprindere, ceea ce face ca NGINX să fie o componentă indispensabilă a infrastructurii web moderne.

21) Cum poți monitoriza performanța și starea de funcționare a NGINX în producție?

Monitorizarea NGINX este crucială pentru identificarea blocajelor, defecțiunilor și comportamentului anormal al traficului. Se pot utiliza mai multe abordări:

  1. Modul de stare încorporat (stub_status):

    Afișează conexiunile active, cererile gestionate și stările de citire/scriere. Exemplu:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. Tablou de bord NGINX Plus: Oferă indicatori în timp real prin intermediul API-ului REST și al interfeței grafice.
  3. Integrari terte parti: Instrumente precum Prometheus, Grafana, Datadog sau ELK pot colecta metrici și jurnale.
  4. Jurnale de acces și erori: Rotația regulată a jurnalelor și analiza cu instrumente precum GoAccess sau AWStats îmbunătățesc observabilitatea.

Monitorizarea ajută la asigurarea timpului de funcționare, detectarea rapidă a defecțiunilor și planificarea capacității.

22) Care este diferența dintre directivele proxy_pass și fastcgi_pass?

Ambele directive transmit cererile către serviciile backend, dar sunt concepute pentru protocoale diferite:

Directivă Scop Protocol backend Exemplu de utilizare
proxy_pass Redirecționează cererile HTTP sau HTTPS către serverele backend HTTP Reverse proxy-ul API-urilor web sau al microserviciilor
fastcgi_pass Trimite cereri către un procesor FastCGI FastCGI PHP-FPM, Python Aplicații FastCGI

Exemplu:

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

Pe scurt, folosiți proxy_pass pentru backend-uri HTTP generice și fastcgi_pass pentru runtime-uri de limbaje dinamice precum PHP.

23) Cum poți configura compresia gzip în NGINX și care sunt beneficiile acesteia?

Activarea compresiei Gzip în NGINX reduce utilizarea lățimii de bandă și îmbunătățește timpul de încărcare prin comprimarea răspunsurilor text înainte de a le trimite clienților.

Exemplu de configurare:

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

Beneficii:

  • Reduce dimensiunile fișierelor transferate cu până la 70%.
  • Îmbunătățește scorurile de performanță ale paginii (Time-to-First-Byte - TTFB).
  • Economisește costurile de lățime de bandă, benefic în special pentru utilizatorii de dispozitive mobile.

Totuși, nu ar trebui aplicat fișierelor deja comprimate (de exemplu, .zip, .jpg, .png) pentru a evita suprasolicitarea procesorului.

24) Care sunt câteva dintre cele mai bune practici pentru optimizarea NGINX pentru trafic intens?

Optimizarea pentru trafic intens implică reglarea atentă a resurselor și a parametrilor de configurare:

Zonă Directivă Practică recomandată
Muncitorii worker_processes auto; Potriviți nucleele procesorului
Conexiuni worker_connections 4096; Creșterea concurenței
Ține în viață keepalive_timeout 65; Optimizați reutilizarea clienților
Fișier Descriptors OS ulimit -n Creșterea limitelor pentru socketurile deschise
Caching proxy_cache_path Reduceți sarcina backend
gzip gzip on; Comprimați răspunsurile text

În plus, folosind I/O pe disc asincron, echilibrarea încărcăturii și verificări ale stării de sănătate în amonte asigură stabilitate și viteză în cazul unor solicitări simultane masive.

25) Cum gestionează NGINX conexiunile WebSocket?

WebSocket-urile permit comunicarea bidirecțională între client și server — crucială pentru aplicațiile în timp real. NGINX acceptă acest lucru nativ prin redirecționarea corectă a antetelor.

Exemplu de configurare:

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

Puncte cheie:

  • Upgrade și Connection anteturile sunt obligatorii.
  • Asigurați-vă că NGINX folosește HTTP/1.1 pentru conexiunile TCP persistente.
  • Echilibrarea încărcării WebSockets poate necesita sesiuni persistente folosind ip_hash.

Această configurație acceptă aplicații precum chat, tranzacționare bursieră sau jocuri.

26) Care este scopul directivei „worker_rlimit_nofile”?

worker_rlimit_nofile definește numărul maxim de descriptori de fișiere deschise disponibili pentru procesele worker. Această limită afectează direct câte conexiuni simultane poate gestiona NGINX. Exemplu:

worker_rlimit_nofile 100000;

Creșterea acestei limite este vitală pentru sistemele cu concurență ridicată (cum ar fi gateway-urile API sau platformele de streaming). Cu toate acestea, limita sistemului de operare (ulimit -n) trebuie, de asemenea, crescută pentru a se potrivi cu această valoare pentru consecvență.

27) Cum poate fi folosit NGINX pentru URL rescrierea sau redirecționarea automată către HTTPS?

Redirecționarea HTTP către HTTPS asigură o comunicare securizată. Exemplu:

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

Această configurație emite o Redirecționare permanentă 301 de la HTTP la HTTPS. Pentru un control mai fin, regulile de rescriere pot impune redirecționarea specifică căii:

rewrite ^/oldpath$ /newpath permanent;

Aplicarea automată a protocolului HTTPS îmbunătățește clasamentul SEO, previne atacurile de tip „man-in-the-middle” și menține o experiență consistentă pentru utilizatori.

28) Care sunt câteva motive comune pentru erorile „502 Bad Gateway” în NGINX?

Un mesaj „502 Bad Gateway” indică faptul că NGINX, acționând ca proxy, nu a reușit să primească un răspuns valid de la un server din amonte. Cauzele frecvente includ:

  • Prăbușire sau indisponibilitate a serverului backend.
  • Incorect proxy_pass URL sau calea socketului.
  • Expirare în amonte (proxy_read_timeout prea scăzut).
  • Firewall sau SELinux blochează conexiunile în amonte.
  • Parametri FastCGI configurați greșit (pentru PHP).

Pentru depanare, verificați jurnalele de erori (/var/log/nginx/error.log), verificați accesibilitatea în amonte și testați răspunsurile backend direct prin curl.

29) Cum oferă NGINX suport pentru microservicii și arhitecturi bazate pe containere (de exemplu, Docker, Kubernetes)?

NGINX este ideal pentru medii de microservicii datorită designului său ușor și funcționalității de proxy invers. În Docker sau Kubernetes, servește ca:

  • Controlor de intrare: Gestionează traficul HTTP/S extern către serviciile interne.
  • Gateway de servicii: Efectuează rutare, echilibrarea încărcării și autentificarea.
  • Proxy Sidecar: Îmbunătățește reziliența și observabilitatea în rețelele de servicii (de exemplu, Istio).

Configurațiile NGINX pot fi actualizate dinamic prin intermediul Kubernetes ConfigMaps, permițând controlul centralizat al traficului și gestionarea SSL. Abordarea sa modulară se aliniază perfect cu implementările containerizate și cloud-native.

30) Care sunt diferitele modalități de a îmbunătăți securitatea NGINX pentru sistemele de producție?

Îmbunătățirea securității NGINX necesită o configurare pe mai multe niveluri:

  1. Întărire SSL/TLS: Folosește cifruri moderne, dezactivează SSLv3/TLSv1.0.
  2. Limitarea metodelor HTTP: Se permit doar verbe sigure (GET, POST, HEAD).
  3. Anteturi de securitate: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Ascundeți informațiile despre versiune: server_tokens off;
  5. Activați limitarea ratei și controalele de acces.
  6. Integrați WAF sau Fail2Ban pentru prevenirea prin forță brută.

Combinate, aceste măsuri creează un mediu NGINX consolidat, de nivel de producție, rezistent la exploatările comune.

31) Cum poți depana eficient problemele NGINX?

Depanarea NGINX implică analiza sistematică a jurnalelor, fișierelor de configurare și stărilor proceselor. Pașii cheie includ:

  1. Verificați sintaxa:
    2. nginx -t
  2. Validează configurația înainte de reîncărcări.

    3. Activează înregistrarea în jurnal a depanării:

    error_log /var/log/nginx/error.log debug;
  3. Oferă diagnosticare detaliată în timpul execuției.

    4. Analizați jurnalele de acces: Detectează codurile de răspuns și modelele de solicitări folosind:

    tail -f /var/log/nginx/access.log
  4. Testați conexiunea: Utilizare curl -v or wget pentru a verifica accesibilitatea backend-ului.
  5. Monitorizați conexiunile active: Prin intermediul stub_status or netstat.

Înțelegerea proceselor de lucru NGINX, a limitelor tampon și a răspunsurilor din amonte ajută la identificarea rapidă a blocajelor în sistemele de producție.

32) Cum configurezi jurnalizarea NGINX și care sunt formatele de jurnal personalizate?

NGINX oferă mecanisme flexibile de înregistrare prin access_log și error_log directivelor.

Exemplu de configurare:

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;

Puteți defini formate personalizate să includă indicatori precum $upstream_addr, $request_time, $bytes_sent.

Pentru o observabilitate avansată, jurnalele sunt adesea expediate către ELK, Loki sau Splunk pentru analiză în timp real și tablouri de bord.

33) Care este rolul directivei proxy_buffering în NGINX?

proxy_buffering controlează dacă NGINX stochează în buffer răspunsurile de la serverele din amonte înainte de a le trimite clienților.

reglaj Descriere Utilizare caz
proxy_buffering on; Bufferîntregul răspuns pentru un randament optimizat Implicit; îmbunătățește performanța
proxy_buffering off; Transmite date direct către clienți fără buffering Streaming în timp real sau API-uri

De exemplu, pentru a dezactiva buffering-ul:

location /stream/ {
    proxy_buffering off;
}

Dezactivarea buffering-ului este ideală pentru serviciile de chat sau streaming, dar poate reduce debitul pentru traficul web obișnuit.

34) Explicați cum poate fi invalidată sau eliminată memoria cache NGINX.

NGINX Open Source nu include curățarea memoriei cache încorporată, dar aceasta poate fi realizată în mai multe moduri:

  1. Purjare manuală: Eliminați fișierele din directorul cache. 
    rm -rf /var/cache/nginx/*
  2. Modul terț: Utilizare ngx_cache_purge pentru a șterge prin cerere HTTP: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. Caracteristici NGINX Plus: Permite curățarea dinamică a memoriei cache bazată pe API.

Eliminarea asigură înlocuirea promptă a conținutului învechit, menținând prospețimea și consecvența conținutului în implementările CDN sau cu mai multe noduri.

35) Cum gestionează NGINX expirarea conexiunilor?

NGINX oferă mai multe directive de timeout pentru a controla cât timp așteaptă răspunsurile clientului sau ale surselor din amonte:

Directivă Scop Implicit(e)
client_body_timeout Timp de așteptare pentru corpul clientului 60
client_header_timeout Timp de așteptare pentru antetul clientului 60
keepalive_timeout Conexiuni keepalive inactive 75
send_timeout Timpul pentru trimiterea datelor către client 60
proxy_read_timeout Timp de așteptare pentru răspunsul din amonte 60

Reglarea corectă evită deconectările inutile și asigură experiențe mai fluide pentru utilizatori în condiții variabile de rețea.

36) Cum implementați o implementare blue-green folosind NGINX?

Într-o desfășurare albastru-verde, două medii (Albastru = activ, Verde = standby) rulează simultan. NGINX acționează ca un router de trafic între ele.

Exemplu de configurare:

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

Când noua versiune (Verde) este testată și verificată, traficul este comutat prin actualizarea definiției din amonte și reîncărcarea NGINX (nginx -s reload).

Această metodă asigură timp de oprire zero în timpul actualizărilor sau revenirilor la versiuni anterioare ale aplicațiilor.

37) Ce este o rată de limitare a ratei de rafale și cum îmbunătățește performanța NGINX?

spargere Parametrul din limitarea ratei permite trecerea temporară a unor vârfuri scurte de trafic fără respingere imediată.

Exemplu:

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

Aici, cinci solicitări suplimentare sunt acceptate instantaneu înainte de aplicarea limitării.

Această tehnică uniformizează supratensiunile de trafic, menținând o experiență consistentă pentru utilizatori, fără a suprasolicita sistemele backend.

38) Cum gestionează NGINX mediile IPv6 și dual-stack?

NGINX acceptă complet IPv6 atât în ​​configurațiile server, cât și în cele upstream. Exemplu:

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

Suportul dual-stivă (IPv4 + IPv6) se realizează prin includerea ambelor:

listen 80;
listen [::]:80;

Compatibilitatea cu IPv6 asigură o accesibilitate mai largă, în special pentru clienții mobili și internaționali, și este esențială pentru conformitatea cu standardele moderne de internet.

39) Cum configurezi sesiunile sticky în echilibrarea încărcării NGINX?

Sesiunile persistente asigură că cererile de la același client sunt întotdeauna direcționate către același server backend.

  1. Utilizarea ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. Fursec lipicios NGINX Plus:
    Persistență avansată a sesiunii cu cookie-uri configurabile.

Sesiunile persistente sunt vitale pentru aplicațiile cu stare, cum ar fi tablourile de bord ale utilizatorilor sau magazinul.ping cărucioare, asigurând consecvența datelor de sesiune fără stocare partajată.

40) Care sunt principalele niveluri de jurnalizare în NGINX și cum diferă acestea?

NGINX acceptă niveluri ierarhice de jurnal pentru a controla verbositatea din jurnalul de erori.

Nivel Descriere
debug Informații detaliate pentru depanare (foarte detaliate)
info Informații generale despre rulare
notice Evenimente semnificative, dar necritice
warn Probleme potențiale sau configurații greșite
error Operaerori naționale care necesită atenție
crit, alert, emerg Defecțiuni critice și alerte de sistem

Exemplu de configurare:

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

Ajustarea nivelurilor de jurnalizare în funcție de mediu (depanare în staging, avertizare în producție) ajută la menținerea unui echilibru între vizibilitate și performanță.

41) Cum evaluezi performanța NGINX?

Analiza comparativă a NGINX implică măsurarea debitului, latenței și concurenței pentru a identifica blocajele de configurare. Instrumentele comune includ:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Volumul solicitărilor de testare și concurența.
  • lucru: Oferă percentile detaliate de latență și rate de solicitare.
  • asediu / httperf: Simulează încărcarea traficului din lumea reală.
  • Grafana + Prometeu: Monitorizează indicatorii de performanță live.

Analiza comparativă ar trebui să măsoare parametri precum requests per second (RPS), time per request și error rate.

Variabile de reglare precum worker_processes, worker_connections și keepalive_timeout îmbunătățește semnificativ debitul observat.

42) Cum se poate integra NGINX cu conductele CI/CD?

NGINX se integrează perfect cu CI / CD pentru implementare automată, testare și gestionare a configurației. Abordările comune includ:

  • Infrastructură ca Code (IaC): Gestionați configurațiile cu diagrame Ansible, Terraform sau Helm.
  • Containere Docker: Construiți și implementați imagini NGINX folosind instrumente CI (Jenkins, GitLab CI sau Acțiuni GitHub).
  • Testare automată: Validați configurațiile folosind nginx -t în etapele conductei.
  • Albastru-Verde / Canary Automatizare implementare: Actualizați serverele din amonte în mod dinamic în timpul implementării.

Exemplu de fragment de CI GitLab:

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

Implementarea automată asigură implementări NGINX consistente, controlate în funcție de versiune și fiabile.

43) Explicați rolul controlerului de intrare NGINX în Kubernetes.

Controler de intrare NGINX gestionează traficul de intrare către serviciile Kubernetes. Traduce dinamic resursele Kubernetes Ingress în configurații NGINX.

Funcții cheie:

  • Dirijează cererile HTTP/S către serviciul corect.
  • Oferă terminare SSL, limitare a ratei și URL rescrierea.
  • Acceptă echilibrarea încărcării între pod-uri.
  • Activează adnotările pentru un control detaliat (de exemplu, rewrite-target, proxy-body-size).

Exemplu de fișier YAML Ingress:

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

Această arhitectură decuplează logica de rutare a traficului de implementările containerelor pentru o scalabilitate flexibilă.

44) Cum gestionează NGINX HTTP/2 și care sunt avantajele sale?

NGINX suportă pe deplin HTTP / 2, succesorul HTTP/1.1, îmbunătățind eficiența prin multiplexare și compresie a antetelor.

Pentru a activa HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

avantaje:

Caracteristică Descriere
multiplexing Cereri multiple per conexiune TCP
Compresia antetului (HPACK) Reduce utilizarea lățimii de bandă
Server Push Trimite preventiv active clienților
TLS mai rapid Strângeri de mână sigure și optimizate

HTTP/2 reduce drastic latența și timpii de încărcare a paginilor, în special pentru aplicațiile web moderne cu numeroase resurse.

45) Care este diferența dintre keepalive în upstream și reutilizarea conexiunii în NGINX?

Keevalive în amonte menține conexiuni persistente la serverele backend, reducând costurile suplimentare de handshake TCP. Exemplu:

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

Diferență:

Aspect Ține în viață Reutilizarea conexiunii
domeniu Între NGINX și în amonte Între NGINX și clienți
Scop Optimizare backend Performanța front-end-ului
Configuraţie keepalive în interiorul upstream keepalive_timeout in server bloca

Ambele tehnici reduc latența, dar deservesc niveluri de comunicare diferite (client vs. server).

46) Cum poți reconfigura dinamic NGINX fără a-l reporni?

Pentru a aplica dinamic noile configurații fără timp de nefuncţionare, folosește reload mecanism:

nginx -t && nginx -s reload

Aceasta semnalează proces principal pentru a genera noi worker-i cu configurații actualizate, în timp ce îi închide cu succes pe cei vechi.

În NGINX Plus, se pot face modificări prin API (de exemplu, adăugarea dinamică a serverelor din amonte):

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"}'

Această capacitate acceptă implementări fără întreruperi în conductele DevOps moderne.

47) Care sunt diferențele cheie dintre proxy-ul invers și proxy-ul direct în NGINX?

Aspect Reverse Împuternicire Redirecționați proxy
Vizibilitatea clientului Clienții nu sunt conștienți de serverele backend Serverele nu cunosc identitatea clientului
Utilizare primară Echilibrarea încărcării, memorarea în cache, terminarea SSL Filtrare, anonimat, control acces
Caz de utilizare comună Distribuția traficului web Navigare externă corporativă sau securizată
Suport NGINX Nativ și utilizat pe scară largă Necesită configurație personalizată

Exemplu (proxy de redirecționare):

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

Reverse Proxy-ul rămâne cazul de utilizare dominant, în special pentru gateway-urile API și arhitecturile de microservicii.

48) Cum poate fi utilizat NGINX pentru limitarea și accelerarea ratei API?

Limitarea ratei protejează API-urile de abuz și asigură o utilizare corectă. Exemplu de configurație:

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

Mecanism:

  • limit_req_zoneDefinește zona și rata de memorie partajată.
  • burstPermite vârfuri temporare limitate.
  • nodelayImpune imediat limite.

Această configurație asigură că fiecare IP client poate face doar 10 cereri pe secundă, permițând în același timp rafale scurte.

49) Care sunt cazurile de utilizare tipice ale NGINX în mediile DevOps ale întreprinderilor?

În ecosistemele DevOps ale întreprinderilor, NGINX îndeplinește mai multe roluri critice:

  1. Server web: Livrare de conținut static de înaltă performanță.
  2. Reverse Proxy / Echilibrator de sarcină: Gestionarea traficului în cadrul microserviciilor.
  3. Gateway API: Autentificare, rutare și limitare a traficului.
  4. Controlor de intrare: Pentru clustere Kubernetes.
  5. Stratul de cache al conținutului: Reduce încărcarea backend-ului.
  6. Punct final de terminare SSL: Gestionare centralizată a certificatelor.
  7. Punct final de monitorizare: Integrarea metricilor și a observabilității.

Amprenta sa redusă și designul modular fac ca NGINX să fie indispensabil în pipeline-urile CI/CD, cloud-urile hibride și clusterele cu disponibilitate ridicată.

50) Care sunt principalele diferențe dintre NGINX și HAProxy pentru echilibrarea încărcării?

Ambele sunt sisteme de echilibrare a încărcării de înaltă performanță, dar diferă în ceea ce privește focalizarea și arhitectura:

Caracteristică Nginx HAProxy
Rolul primar Server web + proxy invers Echilibrator de încărcare TCP/HTTP dedicat
Simplitate de configurare Mai ușor pentru sarcinile de lucru bazate pe web Control complex, dar mai granular
Suport strat L7 (HTTP), L4 parțial L4 și L7 pline
Reconfigurare dinamică Limitat (open-source) Actualizări native în timpul rulării
Performanţă Excelent pentru sarcini de lucru mixte Superior pentru echilibrarea încărcării brute
Caracteristici suplimentare Cache, compresie, conținut static Controale medicale, mese stick

Întreprinderile se combină adesea NGINX (interfață) și HAProxy (backend) pentru rutare și scalabilitate optime.

🔍 Întrebări de interviu de top pentru NGINX cu scenarii din lumea reală și răspunsuri strategice

1) Ce este NGINX și de ce este utilizat frecvent în mediile de producție?

Așteptat de la candidat: Intervievatorul dorește să evalueze cunoștințele dumneavoastră fundamentale despre NGINX și înțelegerea valorii sale practice în sistemele din lumea reală.

Exemplu de răspuns: „NGINX este un server web de înaltă performanță și un proxy invers, cunoscut pentru arhitectura sa bazată pe evenimente. Este frecvent utilizat în mediile de producție, deoarece poate gestiona eficient un număr mare de conexiuni simultane, consumând în același timp mai puține resurse de sistem decât serverele web tradiționale.”

2) Poți explica diferența dintre NGINX și Apache?

Așteptat de la candidat: Intervievatorul evaluează capacitatea ta de a compara tehnologiile și de a alege instrumentul potrivit pe baza cazurilor de utilizare.

Exemplu de răspuns: „NGINX folosește o arhitectură asincronă, fără blocaje, ceea ce o face mai eficientă pentru gestionarea traficului intens și a conținutului static. Apache folosește un model bazat pe procese care poate fi mai flexibil pentru configurații dinamice, dar poate consuma mai multe resurse sub sarcină mare.”

3) Cum acționează NGINX ca un proxy invers?

Așteptat de la candidat: Intervievatorul dorește să confirme înțelegerea conceptelor de proxy invers și modul în care NGINX se integrează în arhitecturile moderne.

Exemplu de răspuns: „NGINX acționează ca un proxy invers, primind cererile clienților și redirecționându-le către serverele backend. Apoi returnează răspunsurile serverului către client, ceea ce îmbunătățește securitatea, distribuția încărcării și performanța generală.”

4) Descrie o situație în care ai folosit NGINX pentru echilibrarea încărcării.

Așteptat de la candidat: Intervievatorul caută experiență practică și capacitatea dumneavoastră de a aplica funcționalitățile NGINX în scenarii reale.

Exemplu de răspuns: „În rolul meu anterior, am configurat NGINX pentru a distribui traficul pe mai multe servere de aplicații folosind algoritmi round-robin și least-connections. Această abordare a îmbunătățit disponibilitatea aplicațiilor și a împiedicat orice server să devină un blocaj.”

5) Cum gestionați configurarea SSL și HTTPS în NGINX?

Așteptat de la candidat: Intervievatorul dorește să evalueze înțelegerea dumneavoastră privind cele mai bune practici de securitate și gestionarea configurației.

Exemplu de răspuns: „Într-o poziție anterioară, am configurat SSL prin instalarea de certificate, activarea listenerelor HTTPS și impunerea unor suite de cifru puternice. De asemenea, am implementat redirecționarea HTTP către HTTPS pentru a asigura o comunicare securizată pe toate endpoint-urile.”

6) Ce pași ați urma pentru a depana o eroare 502 Bad Gateway în NGINX?

Așteptat de la candidat: Intervievatorul îți testează abilitățile de rezolvare a problemelor și metodologia de depanare.

Exemplu de răspuns: „Aș începe prin a verifica jurnalele de erori NGINX pentru a identifica problemele de conectivitate backend. Apoi aș verifica dacă serverele upstream rulează, aș confirma setările proxy corecte și aș asigura că timeout-urile sunt configurate corect.”

7) Cum optimizați performanța NGINX pentru aplicațiile cu trafic intens?

Așteptat de la candidat: Intervievatorul vrea să știe cum abordați optimizarea performanței și scalabilitatea.

Exemplu de răspuns: „La jobul meu anterior, am optimizat NGINX prin activarea compresiei gzip, reglarea proceselor de lucru și configurarea memoriei cache pentru conținutul static. Aceste modificări au redus semnificativ timpii de răspuns și încărcarea serverului.”

8) Puteți explica cum gestionează NGINX conținutul static față de cel dinamic?

Așteptat de la candidat: Intervievatorul evaluează înțelegerea dumneavoastră privind gestionarea solicitărilor și optimizarea performanței.

Exemplu de răspuns: „NGINX servește conținut static direct și foarte eficient din sistemul de fișiere. Pentru conținut dinamic, redirecționează cererile către servere de aplicații sau servicii precum PHP-FPM, permițând fiecărei componente să se concentreze pe ceea ce face cel mai bine.”

9) Cum gestionați și testați în siguranță modificările de configurație NGINX?

Așteptat de la candidat: Intervievatorul vrea să înțeleagă abordarea dumneavoastră privind fiabilitatea și reducerea riscurilor.

Exemplu de răspuns: „Validez modificările de configurație folosind comanda de testare a configurării NGINX înainte de a reîncărca serviciul. De asemenea, aplic modificările în timpul ferestrelor de întreținere și monitorizez îndeaproape jurnalele după implementare.”

10) Descrieți o situație în care a trebuit să rezolvați rapid o întrerupere legată de NGINX.

Așteptat de la candidat: Intervievatorul îți evaluează capacitatea de a performa sub presiune și de a comunica eficient în timpul incidentelor.

Exemplu de răspuns: „În ultimul meu rol, a avut loc o întrerupere din cauza unui serviciu upstream configurat greșit. Am identificat rapid problema prin intermediul jurnalelor, am anulat configurația și am comunicat actualizări de stare părților interesate până când serviciul a fost restabilit complet.”

Rezumați această postare cu: