Cos'è un reverse proxy? Una guida pratica a DNS e web

Un reverse proxy è un server che riceve richieste per conto di uno o più server backend e le inoltra alla destinazione appropriata. Dal punto di vista di un visitatore, il proxy è spesso l'endpoint pubblico; il browser non si connette direttamente al server applicativo. Un reverse proxy può terminare l'HTTPS, instradare le richieste per hostname o percorso, bilanciare il traffico, mettere in cache le risposte, comprimere i contenuti e applicare controlli di sicurezza. Il DNS di solito punta un hostname pubblico al proxy o a un indirizzo gestito dal provider davanti a esso. Il proxy poi usa la propria configurazione di instradamento per raggiungere l'applicazione upstream.

Reverse proxy contro forward proxy

Un forward proxy agisce per conto dei client: il client invia le richieste attraverso di esso per raggiungere servizi esterni, spesso per motivi di policy, privacy o accesso alla rete. Un reverse proxy agisce per conto dei server: i client esterni si connettono a esso, che inoltra le richieste ai servizi backend. La parola «proxy» da sola è quindi ambigua. In un'architettura web, un reverse proxy di solito presenta l'endpoint pubblico del servizio e nasconde i dettagli del pool backend. Può instradare più domini sulla stessa infrastruttura e dirigere percorsi diversi verso applicazioni diverse mantenendo un unico punto di connessione pubblico.

DNS e reverse proxy risolvono parti diverse della connessione. Il DNS associa un hostname a un indirizzo pubblico o a un alias. Una volta che il client si connette, il proxy usa le informazioni sull'host HTTP, la server-name indication di TLS e la propria configurazione per scegliere il servizio corretto. Questo spiega perché richiedere un IP nudo può mostrare una pagina predefinita o un avviso sul certificato anche quando il dominio funziona: la richiesta potrebbe non includere il contesto dell'hostname atteso. Allo stesso modo, cambiare il DNS non crea automaticamente una route del proxy corrispondente né emette un certificato. Entrambi i livelli devono concordare su hostname e destinazione.

Modi comuni in cui il proxy diventa parte di un'interruzione

Un dominio può risolversi correttamente mentre il reverse proxy punta a un upstream morto, usa la porta sbagliata o rifiuta un hostname che non è stato configurato per servire. Possono verificarsi errori TLS se all'edge manca un certificato valido o se un upstream cifrato è configurato male. Un proxy può anche restituire un timeout quando un backend è sovraccarico o irraggiungibile. Al contrario, un'applicazione sana può sembrare non disponibile se il DNS dirige i client all'indirizzo proxy sbagliato. Parti registrando la risposta DNS, poi ispeziona nell'ordine la risposta HTTP, la connessione TLS, i log del proxy e lo stato di salute del backend.

• Conferma che il DNS punti all'endpoint proxy pubblico previsto.
• Verifica che il proxy abbia una regola host e un upstream sano per il dominio.
• Controlla le impostazioni TLS sia dell'edge sia dell'upstream quando l'HTTPS fallisce.
• Usa i log del proxy per distinguere gli errori di instradamento da quelli applicativi.
• Evita di supporre che un lookup IP riveli il server backend.

Confini di sicurezza e operativi

Un reverse proxy può ridurre l'esposizione diretta dei servizi backend, ma non è automaticamente un confine di sicurezza a meno che le regole di accesso siano configurate e mantenute. L'origine dovrebbe accettare traffico solo attraverso i percorsi previsti, dove l'architettura lo consente. Le interfacce amministrative non dovrebbero stare su route pubbliche senza un'autenticazione adeguata. Mantieni aggiornato il software del proxy, limita l'accesso di gestione e valida gli header inoltrati, perché il proxy diventa un interprete attendibile delle informazioni del client e dell'upstream. Documenta quale team è responsabile di DNS, regole del proxy, certificati e backend, così la risposta agli incidenti non si blocca mentre ogni gruppo ritiene che sia responsabile un altro livello.

Per il rapporto tra l'edge pubblico e il backend, leggi cos'è un server di origine. Per le reti proxy globali, vedi come le CDN usano il DNS. Un controllo da dominio a IP pubblico può confermare l'indirizzo presentato dal DNS, ma la route del reverse proxy e lo stato di salute dell'applicazione richiedono controlli operativi propri. Tenere distinte queste responsabilità rende il debug più preciso e impedisce che il risultato di un indirizzo venga scambiato per una diagnosi completa dell'infrastruttura.

Rendere esplicita la responsabilità delle regole del proxy

Un reverse proxy si trova in un punto critico di passaggio di consegne, quindi registra chi è responsabile di DNS, instradamento host, certificati, definizioni degli upstream e policy di accesso. Una modifica può essere corretta in un livello e fallire comunque perché un altro livello non è stato aggiornato: il DNS punta al proxy, ma il proxy non ha un virtual host; la route esiste, ma il certificato è per un nome diverso; oppure l'upstream è sano, ma un firewall blocca la subnet del proxy. Tieni un semplice diagramma del percorso e una richiesta di riferimento valida per ogni hostname di produzione. Durante un incidente, confronta la risposta DNS pubblica, il log di accesso del proxy, lo stato dell'upstream e il log dell'applicazione usando lo stesso timestamp della richiesta o lo stesso ID di correlazione.