Le 50 migliori domande e risposte all'intervista su Nginx (2026)

By: Bryce Leo Bryce Leo
Hours aggiornato

Domande e risposte principali per i colloqui su Nginx

Prepararsi a un colloquio Nginx richiede lungimiranza, chiarezza e consapevolezza di come gli intervistatori valutano oggi le reali conoscenze operative. Le domande del colloquio Nginx rivelano profondità, capacità decisionale, capacità di risoluzione dei problemi e preparazione alla produzione.

Questi ruoli aprono la strada a infrastrutture cloud, performance engineering e sicurezza, dove le configurazioni pratiche sono fondamentali. I datori di lavoro apprezzano l'esperienza tecnica, la competenza di settore e l'analisi acquisite lavorando sul campo, aiutando neolaureati, ingegneri di livello intermedio e professionisti senior ad applicare competenze di base e avanzate all'interno dei team, sotto la guida di manager e team leader. Per saperne di più ...

👉 Download gratuito del PDF: Domande e risposte per il colloquio su Nginx

Domande e risposte principali per i colloqui su Nginx

1) Spiega cos'è NGINX e perché è ampiamente utilizzato nelle infrastrutture web.

NGINX è un server web open source ad alte prestazioni che funge anche da reverse proxy, bilanciatore di carico e cache HTTP. Supporta i protocolli HTTP, HTTPS, SMTP, POP3 e IMAP. L'architettura utilizza un event-driven, asynchronous model Ciò gli consente di gestire decine di migliaia di connessioni simultanee con un utilizzo ridotto di memoria e CPU. Questa scalabilità rende NGINX particolarmente adatto ad applicazioni web ad alto traffico, microservizi e architetture distribuite. Ad esempio, le aziende con carichi di lavoro elevati (come piattaforme di contenuti o gateway API) spesso preferiscono NGINX per gestire in modo efficiente le connessioni simultanee e la distribuzione di contenuti statici.

2) In che modo NGINX gestisce internamente le richieste HTTP (architettura basata sugli eventi)?

Il punto di forza di NGINX risiede nella sua event-driven, non-blocking architectureInvece di generare un thread o un processo separato per ogni richiesta (come i server tradizionali), NGINX utilizza un piccolo set di processi worker che sfruttano cicli di eventi asincroni. Ogni worker può gestire migliaia di connessioni attendendo le notifiche di disponibilità del sistema operativo ed elaborando gli eventi quando si verificano. Poiché non si blocca durante le operazioni di I/O, NGINX può servire contenuti statici e proxy con risorse minime. Questo modello è ideale per casi d'uso ad alta concorrenza, rendendolo più efficiente rispetto ai server basati su processi in presenza di carichi di lavoro elevati.

3) Quali sono le principali differenze tra NGINX e Apache?

Sebbene sia NGINX che Apache siano server web molto diffusi, differiscono per architettura, prestazioni e obiettivi di progettazione:

Aspetto Nginx Apache
Modello di concorrenza Guidato dagli eventi (asincrono, non bloccante) Basato su processo/thread (bloccante)
Utilizzo della memoria Basso per connessione Più alto per connessione
caso d'uso migliore Traffico elevato, contenuto statico, bilanciamento del carico Contenuti dinamici e ricco ecosistema di moduli
Scalabilità Scala con meno risorse Richiede più hardware a causa dei processi
Gestione dei moduli Moduli selezionati in fase di compilazione Dinamico in fase di esecuzione

Il design di NGINX ottimizza le prestazioni sotto carico, mentre Apache offre maggiore flessibilità con moduli dinamici e un ampio supporto linguistico.

4) Quali sono i componenti chiave di un file di configurazione NGINX?

Un file di configurazione NGINX (percorso predefinito: /etc/nginx/nginx.conf) è costituito da blocchi di direttive strutturati che determinano il comportamento di NGINX:

  • Contesto principale: impostazioni globali come worker_processes, error_loge pid
  • Blocco Eventi: gestisce le connessioni dei lavoratori e l'elaborazione multipla
  • Blocco HTTP: contiene configurazioni per la gestione HTTP (compressione, memorizzazione nella cache, gzip, ecc.)
    • Blocco server: definisce gli host virtuali (domini e porte)
    • Blocco posizione: definisce le regole di routing e come vengono gestiti gli URI specifici

Questi blocchi lavorano insieme per instradare le richieste, definire le impostazioni proxy e configurare SSL/TLS e la memorizzazione nella cache.

5) Come ricaricare in modo sicuro la configurazione di NGINX senza tempi di inattività?

Per ricaricare NGINX con configurazioni aggiornate without interrupting active connections, si utilizza il seguente comando:

nginx -s reload

o su sistemi che utilizzano systemd:

sudo systemctl reload nginx

Questo comando segnala al processo master di rileggere i file di configurazione e riavviare correttamente i worker senza interrompere le connessioni esistenti. Sapere come eseguire ricaricamenti fluidi di questo tipo è essenziale negli ambienti che richiedono elevata disponibilità.

6) Descrivi come impostare NGINX come proxy inverso.

Un reverse proxy inoltra le richieste dei client ai server backend (gruppo upstream) e quindi restituisce la risposta. Di seguito è riportato un tipico blocco di reverse proxy 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;
        }
    }
}

Questa configurazione migliora la sicurezza, fornisce la distribuzione del carico e abilita criteri di memorizzazione nella cache o di limitazione della velocità tra client e server applicativi.

7) Spiegare i processi Master e Worker di NGINX.

In NGINX:

  • . Processo principale gestisce la configurazione, avvia i processi worker e gestisce le operazioni privilegiate come l'associazione alle porte.
  • Processi di lavoro gestire effettivamente le richieste, elaborando le connessioni in entrata ed eseguendo le regole configurate.

La presenza di più worker migliora la concorrenza e può essere ottimizzata in base ai core CPU disponibili e alle richieste di traffico. La suddivisione dei ruoli migliora prestazioni e stabilità.

ARTICOLI CORRELATI

8) Come è possibile limitare l'elaborazione dei nomi di server non definiti in NGINX?

Per abbandonare le richieste senza un valido Host intestazione in NGINX:

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

Questa configurazione restituisce il codice 444, uno stato NGINX non standard che chiude la connessione senza risposta, rifiutando di fatto gli host non definiti e migliorando la sicurezza.

9) A cosa serve ngx_http_upstream_module?

. ngx_http_upstream_module definisce groups of backend servers (upstream) a cui NGINX può passare richieste utilizzando direttive come proxy_pass, fastcgi_pass, o uwsgi_passCiò consente flessibilità nel ridimensionamento delle applicazioni in ambienti con bilanciamento del carico. Quando più server backend sono raggruppati, NGINX può distribuire il traffico in base a policy definite, supportando strategie round-robin e altre strategie.

10) Descrivi come NGINX viene utilizzato per fornire contenuti statici e dinamici.

NGINX è altamente efficiente nel servire file statici (HTML, CSS, immagini) utilizzando direttamente il suo ciclo di eventi ottimizzato e i meccanismi di I/O dei file. Per contenuto dinamico, NGINX passa le richieste ai processori backend come PHP-FPM, Python Server WSGI o framework applicativi tramite meccanismi FastCGI/proxy. Questa separazione consente a NGINX di eccellere come file server statico, sfruttando al contempo i servizi backend per la generazione dinamica, garantendo prestazioni e scalabilità ottimali.

11) Come funziona il bilanciamento del carico in NGINX e quali sono i diversi metodi disponibili?

NGINX fornisce robustezza bilancio del carico tramite la upstream Direttiva che distribuisce il traffico su più server backend per ottimizzare le prestazioni e garantire un'elevata disponibilità. Supporta diversi metodi:

Metodo Descrizione caso d'uso migliore
Round Robin Metodo predefinito che ruota le richieste tra i server in modo sequenziale. Carichi di lavoro distribuiti uniformemente.
Least Connections Invia le richieste al server con il minor numero di connessioni attive. Sessioni di lunga durata.
Hash IP Utilizza l'IP del client per determinare la selezione del server. Persistenza della sessione.
Meno tempo Saldi basati sul tempo di risposta e sul numero di connessioni. Applicazioni sensibili alla latenza.

NGINX può anche eseguire controlli sanitari per rimuovere dinamicamente i server non funzionanti, garantendo un flusso di traffico fluido e resilienza.

12) Qual è la differenza tra NGINX open source e NGINX Plus?

Nginx Open Source è la versione community che offre funzionalità essenziali di server web, proxy e bilanciamento del carico. NGINX Plus è l'edizione commerciale che estende queste funzionalità con miglioramenti di livello aziendale quali monitoraggio avanzato, persistenza della sessione, riconfigurazione dinamica e controlli di integrità attivi.

caratteristica NGINX Codice sorgente aperto NGINX Plus
Bilancio del carico Base (Round Robin, Hash IP) Avanzato (Tempo minimo, Riconfigurazione dinamica)
Controllo Strumenti manuali/esterni Dashboard e API integrate
Caching Basic Migliorato con controllo di spurgo
Assistenza Solo comunità Supporto e aggiornamenti aziendali

Le organizzazioni con carichi di lavoro critici spesso scelgono NGINX Plus per la sua maggiore affidabilità e osservabilità.

13) Come si implementa la memorizzazione nella cache in NGINX?

La memorizzazione nella cache in NGINX migliora la velocità di risposta e riduce il carico del backend memorizzando localmente i contenuti a cui si accede frequentemente. È abilitata utilizzando proxy_cache direttiva. Esempio di configurazione:

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

Le risposte memorizzate nella cache vengono fornite direttamente dal disco quando arriva una richiesta corrispondente, saltando l'elaborazione upstream. È possibile controllare la scadenza della cache utilizzando proxy_cache_valid ed escludere URI specifici con proxy_no_cacheQuesto meccanismo è fondamentale per ambienti ad alto traffico come siti di notizie o di e-commerce.

14) Spiega lo scopo e l'uso della direttiva "try_files".

. try_files La direttiva verifica l'esistenza di file in un ordine specificato prima di passare una richiesta alla posizione di fallback. È comunemente utilizzata per routing del sito statico or applicazioni a pagina singola (SPA).

Esempio:

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

Qui, NGINX controlla prima se l'URI richiesto corrisponde a un file, poi a una directory e infine indirizza le richieste non corrispondenti a /index.htmlCiò migliora l'efficienza e l'esperienza utente, poiché fornisce direttamente file memorizzati nella cache o statici, evitando chiamate backend non necessarie.

15) Come può NGINX gestire la terminazione HTTPS e SSL/TLS?

NGINX funge da proxy di terminazione SSL/TLS, gestendo la crittografia e la decrittografia a livello server prima di inoltrare le richieste non crittografate ai servizi upstream. Esempio di configurazione:

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

Supporta HTTP / 2, Pinzatura OCSP, HSTSe suite di cifratura moderne, consentendo comunicazioni sicure e ad alte prestazioni. La terminazione del protocollo SSL su NGINX riduce il sovraccarico di crittografia sui server back-end e semplifica la gestione dei certificati.

16) Qual è la differenza tra riscrittura e reindirizzamento in NGINX?

Entrambi riscrivere e reindirizzare modificano il modo in cui le richieste vengono instradate, ma differiscono fondamentalmente:

Aspetto Riscrivere Reindirizzare
Tipo Riscrittura URL interna Reindirizzamento client esterno
Codice di risposta 200 (interno) 301/302 (reindirizzamento HTTP)
Visibilità Trasparente per l'utente Il cliente vede il nuovo URL
Usa caso URL ottimizzati per SEO, routing Migrazione del dominio, applicazione HTTPS

Esempio:

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

Comprendere questa distinzione è fondamentale per ottimizzare efficacemente la SEO e la logica di routing.

17) Come proteggere NGINX dalle vulnerabilità più comuni?

Il rafforzamento della sicurezza implica una combinazione delle migliori pratiche:

  • Disabilita i token del server: server_tokens off;
  • Limita i metodi di richiesta: Consenti solo GET, POST, HEAD.
  • Limita gli overflow del buffer: Configurazione client_max_body_size e client_body_buffer_size.
  • Utilizzare HTTPS con cifrari moderni.
  • Abilita limitazione della velocità via limit_req_zone.
  • Nascondi le informazioni sulla versione e disabilita l'elenco delle directory.

Inoltre, utilizzando a Firewall per applicazioni Web (WAF) piace ModSecurity with NGINX può filtrare il traffico dannoso. Aggiornare regolarmente NGINX e applicare patch di sicurezza è essenziale per prevenire gli exploit zero-day.

18) Cosa sono le variabili NGINX e come vengono utilizzate nelle configurazioni?

Le variabili NGINX memorizzano dati dinamici utilizzati nelle configurazioni e nell'elaborazione dei log. Possono rappresentare intestazioni di richiesta, indirizzi IP dei client o valori calcolati. Alcuni esempi includono $remote_addr, $host, $uri, $request_methode $upstream_addr.

Per esempio:

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

Le variabili aggiungono flessibilità, consentendo il routing condizionale e la registrazione personalizzata. È anche possibile definire variabili personalizzate utilizzando set direttiva, che aiuta nella progettazione della configurazione modulare.

19) Come si può impostare la limitazione della velocità in NGINX?

La limitazione della frequenza controlla la frequenza con cui gli utenti possono inviare richieste, proteggendo dagli attacchi brute force e DDoS. È configurata utilizzando limit_req_zone direttiva:

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

Ciò consente una richiesta al secondo con un burst di cinque. NGINX elimina le richieste in eccesso o le ritarda in base alla configurazione. La limitazione della velocità garantisce un utilizzo equo delle risorse e previene il sovraccarico del server.

20) Quali sono i vantaggi e gli svantaggi dell'utilizzo di NGINX come proxy inverso?

NGINX come proxy inverso offre numerosi vantaggi, ma anche alcuni compromessi:

Vantaggi Svantaggi
Gestione delle prestazioni elevate e della concorrenza Richiede la messa a punto manuale per distribuzioni su larga scala
Terminazione SSL e sicurezza centralizzata Supporto limitato dei moduli dinamici (in fase di compilazione)
Supporto per bilanciamento del carico e memorizzazione nella cache Configurazione complessa per i nuovi utenti
Filtraggio del livello applicativo Mancanza di esecuzione di contenuti dinamici nativi

I suoi vantaggi superano di gran lunga i limiti nella maggior parte degli scenari aziendali, rendendo NGINX un componente indispensabile della moderna infrastruttura web.

21) Come è possibile monitorare le prestazioni e lo stato di salute di NGINX in produzione?

Il monitoraggio di NGINX è fondamentale per identificare colli di bottiglia, guasti e comportamenti anomali del traffico. È possibile utilizzare diversi approcci:

  1. Modulo di stato integrato (stub_status):

    Visualizza le connessioni attive, le richieste gestite e gli stati di lettura/scrittura. Esempio:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. Dashboard NGINX Plus: Fornisce metriche in tempo reale tramite REST API e GUI.
  3. Integrazioni di terze parti: Strumenti come Prometheus, Grafana, Datadog o ELK possono raccogliere metriche e log.
  4. Registri di accesso ed errori: La rotazione regolare dei log e l'analisi con strumenti come GoAccess o AWStats migliorano l'osservabilità.

Il monitoraggio aiuta a garantire tempi di attività, un rapido rilevamento dei guasti e la pianificazione della capacità.

22) Qual è la differenza tra le direttive proxy_pass e fastcgi_pass?

Entrambe le direttive inoltrano le richieste ai servizi backend, ma sono progettate per protocolli diversi:

Direttiva Missione Protocollo backend Esempio di utilizzo
proxy_pass Inoltra le richieste HTTP o HTTPS ai server backend HTTP RevAPI Web proxy o microservizi
fastcgi_pass Invia richieste a un processore FastCGI Fast CGI PHP-FPM, Python Applicazioni FastCGI

Esempio:

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

In sintesi, utilizzare proxy_pass per backend HTTP generici e fastcgi_pass per runtime di linguaggio dinamici come PHP.

23) Come si configura la compressione gzip in NGINX e quali sono i suoi vantaggi?

L'abilitazione della compressione Gzip in NGINX riduce l'utilizzo della larghezza di banda e migliora i tempi di caricamento comprimendo le risposte basate su testo prima di inviarle ai client.

Configurazione di esempio:

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

Vantaggi:

  • Riduce le dimensioni del trasferimento dei file fino al 70%.
  • Migliora i punteggi Time-to-First-Byte (TTFB) e delle prestazioni della pagina.
  • Consente di risparmiare sui costi di larghezza di banda, particolarmente vantaggioso per gli utenti di dispositivi mobili.

Tuttavia, non dovrebbe essere applicato a file già compressi (ad esempio, .zip, .jpg, .png) per evitare un sovraccarico della CPU.

24) Quali sono le best practice per ottimizzare NGINX per un traffico elevato?

L'ottimizzazione ad alto traffico implica un'attenta messa a punto delle risorse e dei parametri di configurazione:

Zona Direttiva Pratica consigliata
Lavoratori worker_processes auto; Abbina i core della CPU
Connessioni worker_connections 4096; Aumentare la concorrenza
Mantieni vivo keepalive_timeout 65; Ottimizzare il riutilizzo del client
Compila il Descriptori OS ulimit -n Aumentare i limiti per i socket aperti
Caching proxy_cache_path Ridurre il carico del backend
gzip gzip on; Comprimi le risposte di testo

Inoltre, utilizzando I/O asincrono del disco, bilancio del caricoe controlli sanitari a monte garantisce stabilità e velocità anche in caso di richieste simultanee di grandi dimensioni.

25) Come gestisce NGINX le connessioni WebSocket?

I WebSocket consentono la comunicazione bidirezionale tra client e server, fondamentale per le applicazioni in tempo reale. NGINX supporta questa funzionalità in modo nativo tramite un corretto inoltro degli header.

Configurazione di esempio:

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

Punti chiave:

  • . Upgrade e Connection le intestazioni sono obbligatorie.
  • Assicurarsi che NGINX utilizzi HTTP/1.1 per le connessioni TCP persistenti.
  • I WebSocket con bilanciamento del carico potrebbero richiedere sessioni persistenti utilizzando ip_hash.

Questa configurazione supporta applicazioni come chat, trading azionario o giochi.

26) Qual è lo scopo della direttiva “worker_rlimit_nofile”?

worker_rlimit_nofile Definisce il numero massimo di descrittori di file aperti disponibili per i processi worker. Questo limite influisce direttamente sul numero di connessioni simultanee che NGINX può gestire. Esempio:

worker_rlimit_nofile 100000;

L'aumento di questo limite è fondamentale per i sistemi ad alta concorrenza (come gateway API o piattaforme di streaming). Tuttavia, il limite del sistema operativo (ulimit -n) deve essere aumentato per corrispondere a questo valore per coerenza.

27) Come si può utilizzare NGINX per la riscrittura degli URL o il reindirizzamento automatico a HTTPS?

Il reindirizzamento da HTTP a HTTPS garantisce una comunicazione sicura. Esempio:

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

Questa configurazione emette un 301 reindirizzamento permanente da HTTP a HTTPS. Per un controllo più preciso, le regole di riscrittura possono imporre un reindirizzamento specifico del percorso:

rewrite ^/oldpath$ /newpath permanent;

L'applicazione automatica dell'HTTPS migliora il posizionamento SEO, previene gli attacchi man-in-the-middle e mantiene un'esperienza utente coerente.

28) Quali sono alcune delle cause più comuni degli errori "502 Bad Gateway" in NGINX?

Un errore "502 Bad Gateway" indica che NGINX, che funge da proxy, non è riuscito a ricevere una risposta valida da un server upstream. Le cause più comuni includono:

  • Arresto anomalo o indisponibilità del server backend.
  • sbagliato proxy_pass URL o percorso socket.
  • Timeout upstream (proxy_read_timeout troppo basso).
  • Firewall o SELinux che bloccano le connessioni upstream.
  • Parametri FastCGI non configurati correttamente (per PHP).

Per eseguire il debug, controllare i registri degli errori (/var/log/nginx/error.log), verificare la raggiungibilità upstream e testare le risposte backend direttamente tramite curl.

29) In che modo NGINX supporta i microservizi e le architetture basate su container (ad esempio, Docker, Kubernetes)?

NGINX è ideale per ambienti di microservizi Grazie al suo design leggero e alla funzionalità di reverse proxy, in Docker o Kubernetes funge da:

  • Controller di ingresso: Gestisce il traffico HTTP/S esterno verso i servizi interni.
  • Gateway di servizio: Esegue il routing, il bilanciamento del carico e l'autenticazione.
  • Proxy Sidecar: Migliora la resilienza e l'osservabilità nelle reti di servizi (ad esempio, Istio).

Le configurazioni NGINX possono essere aggiornate dinamicamente tramite Kubernetes ConfigMaps, consentendo il controllo centralizzato del traffico e la gestione SSL. Il suo approccio modulare si adatta perfettamente alle distribuzioni containerizzate e cloud-native.

30) Quali sono i diversi modi per migliorare la sicurezza NGINX per i sistemi di produzione?

Per migliorare la sicurezza di NGINX è necessaria una configurazione multilivello:

  1. Protezione SSL/TLS: Utilizzare cifrari moderni, disattivare SSLv3/TLSv1.0.
  2. Limita i metodi HTTP: Consentire solo verbi sicuri (GET, POST, HEAD).
  3. Intestazioni di sicurezza: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Nascondi informazioni sulla versione: server_tokens off;
  5. Abilitare la limitazione della velocità e i controlli di accesso.
  6. Integrare WAF o Fail2Ban per prevenire gli attacchi di forza bruta.

Insieme, queste misure creano un ambiente NGINX rinforzato, di livello produttivo e resistente agli exploit più comuni.

31) Come è possibile risolvere efficacemente i problemi di NGINX?

Il debug di NGINX prevede l'analisi sistematica di log, file di configurazione e stati dei processi. I passaggi chiave includono:

  1. Controlla la sintassi:
    2. nginx -t
  2. Convalida la configurazione prima del ricaricamento.

    3. Abilita la registrazione del debug:

    error_log /var/log/nginx/error.log debug;
  3. Fornisce una diagnostica dettagliata del runtime.

    4. Analizza i registri di accesso: Rileva i codici di risposta e i modelli di richiesta utilizzando:

    tail -f /var/log/nginx/access.log
  4. Connettività di prova: Usa il curl -v or wget per verificare la raggiungibilità del backend.
  5. Monitora le connessioni attive: via stub_status or netstat.

La comprensione dei processi worker, dei limiti del buffer e delle risposte upstream di NGINX aiuta a individuare rapidamente i colli di bottiglia nei sistemi di produzione.

32) Come si configura la registrazione NGINX e quali sono i formati di registro personalizzati?

NGINX fornisce meccanismi di registrazione flessibili attraverso access_log e error_log direttive.

Configurazione di esempio:

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;

Puoi definire formati personalizzati per includere metriche come $upstream_addr, $request_time, o $bytes_sent.

Per un'osservabilità avanzata, i registri vengono spesso spediti a ELK, Loki o Splunk per analisi e dashboarding in tempo reale.

33) Qual è il ruolo della direttiva proxy_buffering in NGINX?

proxy_buffering controlla se NGINX memorizza nel buffer le risposte provenienti dai server upstream prima di inviarle ai client.

Configurazione Descrizione Usa caso
proxy_buffering on; Bufferè l'intera risposta per una produttività ottimizzata Predefinito; migliora le prestazioni
proxy_buffering off; Trasmette i dati direttamente ai client senza buffering Streaming in tempo reale o API

Ad esempio, per disattivare il buffering:

location /stream/ {
    proxy_buffering off;
}

Disabilitare il buffering è l'ideale per i servizi di chat o streaming, ma potrebbe ridurre la velocità di trasmissione per il normale traffico web.

34) Spiega come la memorizzazione nella cache di NGINX può essere invalidata o eliminata.

NGINX Open Source non include la pulizia della cache integrata, ma questa può essere eseguita in diversi modi:

  1. Spurgo manuale: Rimuovere i file dalla directory della cache. 
    rm -rf /var/cache/nginx/*
  2. Modulo di terze parti: Usa il ngx_cache_purge per eliminare tramite richiesta HTTP: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. Funzionalità NGINX Plus: Consente la pulizia dinamica della cache basata su API.

L'eliminazione garantisce che i contenuti obsoleti vengano sostituiti tempestivamente, mantenendone l'aggiornamento e la coerenza nelle distribuzioni CDN o multi-nodo.

35) Come gestisce NGINX i timeout di connessione?

NGINX fornisce più direttive di timeout per controllare il tempo di attesa delle risposte del client o upstream:

Direttiva Missione Predefinito (i)
client_body_timeout Tempo di attesa per il corpo del cliente 60
client_header_timeout Tempo di attesa per l'intestazione del client 60
keepalive_timeout Connessioni keepalive inattive 75
send_timeout È ora di inviare i dati al cliente 60
proxy_read_timeout Tempo di attesa per la risposta upstream 60

Una corretta messa a punto evita disconnessioni non necessarie e garantisce esperienze utente più fluide in condizioni di rete variabili.

36) Come si implementa la distribuzione blue-green utilizzando NGINX?

In un distribuzione blu-verde, due ambienti (Blu = attivo, Verde = standby) vengono eseguiti simultaneamente. NGINX funge da router di traffico tra di essi.

Configurazione di esempio:

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

Quando la nuova versione (verde) viene testata e verificata, il traffico viene commutato aggiornando la definizione upstream e ricaricando NGINX (nginx -s reload).

Questo metodo garantisce zero tempi di inattività durante gli aggiornamenti o i rollback delle applicazioni.

37) Che cosa è il rate limiting burst e in che modo migliora le prestazioni di NGINX?

. scoppio parametro nella limitazione della velocità consente il passaggio temporaneo di brevi picchi di traffico senza un rifiuto immediato.

Esempio:

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

In questo caso, vengono accettate immediatamente cinque richieste extra prima di applicare la limitazione.

Questa tecnica attenua i picchi di traffico, mantenendo un'esperienza utente coerente senza sovraccaricare i sistemi backend.

38) Come gestisce NGINX gli ambienti IPv6 e dual-stack?

NGINX supporta pienamente IPv6 sia nelle configurazioni server che upstream. Esempio:

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

Il supporto dual-stack (IPv4 + IPv6) è ottenuto includendo entrambi:

listen 80;
listen [::]:80;

La compatibilità IPv6 garantisce una maggiore accessibilità, soprattutto per i clienti mobili e internazionali, ed è fondamentale per la conformità agli standard Internet moderni.

39) Come si configurano le sessioni sticky nel bilanciamento del carico NGINX?

Le sessioni sticky garantiscono che le richieste provenienti dallo stesso client vengano sempre indirizzate allo stesso server backend.

  1. utilizzando ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. Cookie appiccicoso NGINX Plus:
    Persistenza avanzata della sessione con cookie configurabili.

Le sessioni sticky sono essenziali per le applicazioni con stato, come dashboard utente o carrelli della spesa, in quanto garantiscono la coerenza dei dati della sessione senza archiviazione condivisa.

40) Quali sono i principali livelli di log in NGINX e in che modo differiscono?

NGINX supporta livelli di registro gerarchici per controllare il livello di dettaglio nel registro degli errori.

Livello Descrizione
debug Informazioni dettagliate per la risoluzione dei problemi (molto dettagliate)
info Informazioni generali sul runtime
notice Eventi significativi ma non critici
warn Potenziali problemi o configurazioni errate
error Operaerrori nazionali che richiedono attenzione
crit, alert, emerg Guasti critici e avvisi di sistema

Configurazione di esempio:

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

La regolazione dei livelli di log in base all'ambiente (debug in staging, avviso in produzione) aiuta a mantenere un equilibrio tra visibilità e prestazioni.

41) Come si confrontano le prestazioni di NGINX?

Il benchmarking di NGINX prevede la misurazione di throughput, latenza e concorrenza per identificare i colli di bottiglia della configurazione. Gli strumenti più comuni includono:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • I test richiedono volume e concorrenza.
  • lavoro: Fornisce percentili di latenza dettagliati e frequenze di richiesta.
  • assedio / httperf: Simula il carico del traffico reale.
  • Grafana + Prometeo: Monitora le metriche delle prestazioni in tempo reale.

Il benchmarking dovrebbe misurare parametri come requests per second (RPS), time per requeste error rate.

Variabili di ottimizzazione come worker_processes, worker_connectionse keepalive_timeout migliora significativamente la produttività osservata.

42) Come può NGINX integrarsi con le pipeline CI/CD?

NGINX si integra perfettamente con CI / CD per la distribuzione automatizzata, i test e la gestione della configurazione. Gli approcci più comuni includono:

  • Infrastruttura come codice (IaC): Gestisci le configurazioni con i grafici Ansible, Terraform o Helm.
  • Contenitori Docker: Crea e distribuisci immagini NGINX utilizzando strumenti CI (Jenkins, GitLab CI o GitHub Actions).
  • Test automatizzati: Convalidare le configurazioni utilizzando nginx -t nelle fasi di pipeline.
  • Blu-Verde / Canary Automazione della distribuzione: Aggiornare dinamicamente i server upstream durante il rollout.

Esempio di frammento di codice CI di GitLab:

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

La distribuzione automatizzata garantisce implementazioni NGINX coerenti, affidabili e controllate dalle versioni.

43) Spiega il ruolo di NGINX Ingress Controller in Kubernetes.

. Controller di ingresso NGINX Gestisce il traffico in entrata verso i servizi Kubernetes. Traduce dinamicamente le risorse Kubernetes Ingress in configurazioni NGINX.

Funzioni principali:

  • Instrada le richieste HTTP/S al servizio corretto.
  • Fornisce terminazione SSL, limitazione della velocità e riscrittura degli URL.
  • Supporta il bilanciamento del carico tra i pod.
  • Abilita annotazioni per un controllo dettagliato (ad esempio, riscrittura-destinazione, dimensione-corpo-proxy).

Esempio di Ingress 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

Questa architettura separa la logica di routing del traffico dalle distribuzioni dei container per una scalabilità flessibile.

44) Come gestisce NGINX HTTP/2 e quali sono i suoi vantaggi?

NGINX supporta pienamente HTTP / 2, il successore di HTTP/1.1, che migliora l'efficienza tramite multiplexing e compressione dell'intestazione.

Per abilitare HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

vantaggi:

caratteristica Descrizione
Multiplexing Richieste multiple per connessione TCP
Compressione dell'intestazione (HPACK) Riduce l'utilizzo della larghezza di banda
Server push Invia preventivamente le risorse ai clienti
TLS più veloce Strette di mano sicure e semplificate

HTTP/2 riduce drasticamente la latenza e i tempi di caricamento delle pagine, in particolare per le moderne applicazioni web con numerose risorse.

45) Qual è la differenza tra keepalive upstream e riutilizzo della connessione in NGINX?

Keepalive a monte mantiene connessioni persistenti ai server backend, riducendo il sovraccarico dell'handshake TCP. Esempio:

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

Differenza:

Aspetto Mantieni vivo Riutilizzo della connessione
Obbiettivo Tra NGINX e upstream Tra NGINX e i clienti
Missione Ottimizzazione del backend Prestazioni frontend
Configurazione keepalive interno upstream keepalive_timeout in server bloccare

Entrambe le tecniche riducono la latenza ma servono livelli di comunicazione diversi (lato client vs. lato server).

46) Come è possibile riconfigurare dinamicamente NGINX senza riavviarlo?

Per applicare dinamicamente nuove configurazioni senza tempi di inattività, Usa il reload meccanismo:

nginx -t && nginx -s reload

Questo segnala il processo principale per generare nuovi lavoratori con configurazioni aggiornate, chiudendo con eleganza quelli vecchi.

In NGINX Plus, è possibile apportare modifiche tramite API (ad esempio, aggiungendo server upstream in modo dinamico):

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

Questa funzionalità supporta distribuzioni senza tempi di inattività nelle moderne pipeline DevOps.

47) Quali sono le principali differenze tra reverse proxy e forward proxy in NGINX?

Aspetto Revaltro Proxy Proxy di inoltro
Visibilità del cliente I clienti non sono a conoscenza dei server backend I server non sono a conoscenza dell'identità del client
Uso primario Bilanciamento del carico, memorizzazione nella cache, terminazione SSL Filtraggio, anonimato, controllo degli accessi
Caso d'uso comune Distribuzione del traffico web Navigazione aziendale o sicura in uscita
Supporto NGINX Nativo e ampiamente utilizzato Richiede una configurazione personalizzata

Esempio (proxy in avanti):

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

RevIl proxying rimane il caso d'uso dominante, soprattutto per i gateway API e le architetture di microservizi.

48) Come può essere utilizzato NGINX per la limitazione e la limitazione della velocità delle API?

La limitazione della velocità protegge le API dagli abusi e ne garantisce un utilizzo corretto. Esempio di configurazione:

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

Meccanismo:

  • limit_req_zone: Definisce la zona e la velocità della memoria condivisa.
  • burst: Consente picchi temporanei limitati.
  • nodelay: Fa rispettare immediatamente i limiti.

Questa configurazione garantisce che ogni IP client possa effettuare solo 10 richieste al secondo, consentendo al contempo brevi raffiche.

49) Quali sono i casi d'uso tipici di NGINX negli ambienti DevOps aziendali?

Negli ecosistemi DevOps aziendali, NGINX svolge molteplici ruoli critici:

  1. Server Web: Distribuzione di contenuti statici ad alte prestazioni.
  2. Reverse Proxy / Load Balancer: Gestione del traffico tra microservizi.
  3. Gateway API: Autenticazione, routing e limitazione.
  4. Controller di ingresso: Per i cluster Kubernetes.
  5. Livello di memorizzazione nella cache dei contenuti: Riduce il carico del backend.
  6. Endpoint di terminazione SSL: Gestione centralizzata dei certificati.
  7. Endpoint di monitoraggio: Integrazione di metriche e osservabilità.

Il suo ingombro ridotto e il design modulare rendono NGINX indispensabile nelle pipeline CI/CD, nei cloud ibridi e nei cluster ad alta disponibilità.

50) Quali sono le principali differenze tra NGINX e HAProxy per il bilanciamento del carico?

Entrambi sono bilanciatori di carico ad alte prestazioni, ma differiscono per focus e architettura:

caratteristica Nginx HAProxy
Ruolo primario Server web + proxy inverso Bilanciatore di carico TCP/HTTP dedicato
Semplicità di configurazione Più semplice per i carichi di lavoro basati sul Web Controllo complesso ma più granulare
Supporto dei livelli L7 (HTTP), parziale L4 L4 e L7 completi
Riconfigurazione dinamica Limitato (open source) Aggiornamenti runtime nativi
Cookie di prestazione Ottimo per carichi di lavoro misti Superiore per il bilanciamento del carico grezzo
Caratteristiche aggiuntive Caching, compressione, contenuto statico Controlli sanitari, tavoli di controllo

Le imprese spesso si uniscono NGINX (frontend) e HAProxy (backend) per un routing e una scalabilità ottimali.

🔍 Le migliori domande per i colloqui NGINX con scenari reali e risposte strategiche

1) Che cos'è NGINX e perché è comunemente utilizzato negli ambienti di produzione?

Requisiti richiesti al candidato: L'intervistatore vuole valutare la tua conoscenza di base di NGINX e la tua comprensione del suo valore pratico nei sistemi del mondo reale.

Esempio di risposta: "NGINX è un server web e reverse proxy ad alte prestazioni, noto per la sua architettura basata sugli eventi. È comunemente utilizzato negli ambienti di produzione perché è in grado di gestire un gran numero di connessioni simultanee in modo efficiente, consumando meno risorse di sistema rispetto ai server web tradizionali."

2) Puoi spiegare la differenza tra NGINX e Apache?

Requisiti richiesti al candidato: L'intervistatore valuterà la tua capacità di confrontare le tecnologie e di scegliere lo strumento giusto in base ai casi d'uso.

Esempio di risposta: "NGINX utilizza un'architettura asincrona e non bloccante, che lo rende più efficiente nella gestione di traffico elevato e contenuti statici. Apache utilizza un modello basato sui processi che può essere più flessibile per le configurazioni dinamiche, ma può consumare più risorse in condizioni di carico elevato."

3) In che modo NGINX agisce come proxy inverso?

Requisiti richiesti al candidato: L'intervistatore desidera verificare la tua comprensione dei concetti di reverse proxy e di come NGINX si inserisce nelle architetture moderne.

Esempio di risposta: "NGINX funge da proxy inverso ricevendo le richieste dei client e inoltrandole ai server back-end. Restituisce quindi le risposte del server al client, migliorando la sicurezza, la distribuzione del carico e le prestazioni complessive."

4) Descrivi una situazione in cui hai utilizzato NGINX per il bilanciamento del carico.

Requisiti richiesti al candidato: L'intervistatore è alla ricerca di esperienza pratica e della capacità di applicare le funzionalità di NGINX in scenari reali.

Esempio di risposta: "Nel mio ruolo precedente, ho configurato NGINX per distribuire il traffico su più server applicativi utilizzando algoritmi round-robin e least-connections. Questo approccio ha migliorato la disponibilità delle applicazioni e ha impedito che un singolo server diventasse un collo di bottiglia."

5) Come si gestisce la configurazione SSL e HTTPS in NGINX?

Requisiti richiesti al candidato: L'intervistatore vuole valutare la tua comprensione delle migliori pratiche di sicurezza e della gestione della configurazione.

Esempio di risposta: "In una posizione precedente, ho configurato SSL installando certificati, abilitando listener HTTPS e applicando suite di crittografia avanzate. Ho anche implementato il reindirizzamento da HTTP a HTTPS per garantire comunicazioni sicure tra tutti gli endpoint."

6) Quali passaggi seguiresti per risolvere un errore 502 Bad Gateway in NGINX?

Requisiti richiesti al candidato: L'intervistatore sta testando le tue capacità di problem-solving e la tua metodologia di risoluzione dei problemi.

Esempio di risposta: "Inizierei controllando i log degli errori di NGINX per identificare problemi di connettività backend. Quindi verificherei che i server upstream siano in esecuzione, confermerei le impostazioni proxy corrette e mi assicurerei che i timeout siano configurati correttamente."

7) Come si ottimizzano le prestazioni di NGINX per le applicazioni ad alto traffico?

Requisiti richiesti al candidato: L'intervistatore vuole sapere come affronti l'ottimizzazione delle prestazioni e la scalabilità.

Esempio di risposta: "Nel mio precedente lavoro, ho ottimizzato NGINX abilitando la compressione gzip, ottimizzando i processi worker e configurando la memorizzazione nella cache per i contenuti statici. Queste modifiche hanno ridotto significativamente i tempi di risposta e il carico del server."

8) Puoi spiegare come NGINX gestisce i contenuti statici e dinamici?

Requisiti richiesti al candidato: L'intervistatore valuterà la tua comprensione della gestione delle richieste e dell'ottimizzazione delle prestazioni.

Esempio di risposta: "NGINX gestisce i contenuti statici direttamente e in modo molto efficiente dal file system. Per i contenuti dinamici, inoltra le richieste ai server applicativi o a servizi come PHP-FPM, consentendo a ciascun componente di concentrarsi su ciò che sa fare meglio."

9) Come si gestiscono e si testano in modo sicuro le modifiche alla configurazione di NGINX?

Requisiti richiesti al candidato: L'intervistatore vuole capire il tuo approccio all'affidabilità e alla riduzione del rischio.

Esempio di risposta: "Convalido le modifiche alla configurazione utilizzando il comando di test di configurazione NGINX prima di ricaricare il servizio. Applico le modifiche anche durante le finestre di manutenzione e monitoro attentamente i log dopo la distribuzione."

10) Descrivi una situazione in cui hai dovuto risolvere rapidamente un'interruzione relativa a NGINX.

Requisiti richiesti al candidato: L'intervistatore valuterà la tua capacità di reagire sotto pressione e di comunicare efficacemente durante gli incidenti.

Esempio di risposta: "Nel mio ultimo ruolo, si è verificata un'interruzione a causa di un servizio upstream configurato in modo errato. Ho identificato rapidamente il problema tramite i log, ho ripristinato la configurazione e ho comunicato gli aggiornamenti di stato alle parti interessate fino al completo ripristino del servizio."

Riassumi questo post con: