Uno degli utilizzi più comuni del server Nginx è quello di reverse proxy. Un reverse proxy è un server web che si frappone tra i client HTTP(s) ed il/i server utilizzato/i. I client interrogano il server proxy inviando le proprie richieste HTTP. Il server proxy funge da client interrogando il server interno che contiene la risorsa richiesta, elabora la risposta ottenuta e la ritrasmette al client.
Un reverse proxy trova applicazione in svariati contesti: si può ricorrere ad un reverse proxy qualora le risorse di un'applicazione o di un sito web siano servite da più server ma si voglia accedere alle stesse da un dominio comune; utilizzando un reverse proxy il client effettuerà le richieste ad un unico server, senza sapere che queste sono in realtà reindirizzate altrove.
Un altro tipico utilizzo di un reverse proxy è quello di load balancer (bilanciatore di carico). Si immagini il caso in cui vi siano più server web in grado di fornire esattamente gli stessi contenuti. Un reverse proxy potrebbe fungere da entry point per raggiungere detti server, interrogandoli a turno in modo da distribuire il carico (le richieste provenienti dall'esterno) in modo uniforme.
Infine, un reverse proxy permette facilmente di aggiungere delle funzionalità ad applicazioni esistenti. Ad esempio, si può ricorrere ad un reverse proxy per dotare di supporto a TLS un'applicazione che ne sia sprovvista. Si pensi ad una semplice applicazione scritta in Node.js, che accetta richieste HTTP: interponendo tra di essa ed il mondo esterno un reverse proxy configurato con TLS. I client utilizzeranno HTTPS per dialogare con il servizio, ed il reverse proxy provvederà ad interrogare l'applicazione Node.js, senza richiedere alcuna modifica.
In generale, questi utilizzi sono spesso assolti da Nginx in contesti in cui si fa largo uso di container. Ad esempio, Nginx è uno degli Ingress controllers disponibili in Kubernetes.
Configurazione
La configurazione di Nginx come reverse proxy avviene semplicemente specificando una Location con la direttiva proxy_pass. Ad esempio:
location /mia/location/ {
proxy_pass http://www.example.com/link/;
}Quando i client richiederanno al server l'indirizzo /mia/location, Nginx effettuerà una richiesta al server www.example.com, richiedendo la risorsa /link e restituendo il risultato della richiesta al client.
Si noti che l'intera location viene mappata sul server esterno. Ad esempio, se si richiede al server l'indirizzo /mia/location/sub/pagina.html il server Nginx richiederà al server esterno la risorsa /link/sub/pagina.html.
Come si evince, il funzionamento del reverse proxy si basa sul matching di URI. In altre parole, bisogna specificare quali URI sono serviti direttamente dal server Nginx e quali invece sono mappati su risorse esterne.
Numeri di porta
La direttiva proxy_pass accetta un URL valido. Pertanto è possibile effettuare delle richieste su porte differenti da 80 o 443. Per farlo è sufficiente specificare il numero di porta nell'URL indicato nella direttiva proxy_pass. Ad esempio, supponendo che il server example.com sia in ascolto sulla porta 3000, la configurazione da utilizzare sarà:
location /mia/location/ {
proxy_pass http://www.example.com:3000/link/;
}Intestazioni
Un'altra importante direttiva è proxy_set_header. Come si evince dal nome, essa consente di personalizzare le intestazioni inviate al server interno, permettendo di ridefinire il valore di quelli inviati dal client. Ad esempio, si supponga di voler ridefinire il valore dell'intestazione Accept-Encoding per prevenire una risposta compressa (tipicamente i client moderni supportano almeno la compressione gzip): per farlo è sufficiente inserire la direttiva proxy_set_header, come mostrato di seguito:
location /mia/location/ {
proxy_set_header Accept-Encoding "";
proxy_pass http://www.example.com/link/;
}Buffering
Per impostazione predefinita, Nginx utilizza un buffer per elaborare le risposte ricevute dai server interni. In altre parole, le risposte vengono prima memorizzate in un buffer e poi successivamente inviate al client. In alcuni casi può rendersi necessaria un'attenta configurazione di questa opzione. Se da una parte il buffering aiuta a migliorare le performance con client lenti, dall'altra impiega risorse del server proxy per ogni connessione ed in generale aumenta la latenza.
Due direttive permettono rispettivamente di regolare il numero di buffer da utilizzare e la loro dimensione, proxy_buffers, e la dimensione del buffer contenente solo la prima parte della risposta, proxy_buffer_size.
Quest'ultimo buffer è presente poichè si rende necessario per poter eventualmente elaborare le intestazioni prima di inviarle al client.
Con i parametri utilizzati nell'esempio sottostante, le richieste indirizzate a /mia/location impiegheranno fino a 16 buffer ognuno da 4 KB, ed un buffer di 2K per le intestazioni.
location /mia/location/ {
proxy_buffers 16 4k;
proxy_buffer_size 2k;
proxy_pass http://www.example.com/link/;
}
Inoltre è possibile disattivare completamente il buffering con la direttiva proxy_buffering impostata su off:
location /mia/location/ {
proxy_buffering off;
proxy_pass http://www.example.com/link/;
}