proxy_redirect non collega NGINX al tuo host VPN
proxy_redirect riscrive intestazioni in una risposta già arrivata; non sceglie mai l’upstream. Controlla proxy_pass, la rotta verso il backend, poi le intestazioni.
Il nome contiene la parola redirect, quindi viene incollato dentro un blocco location quando un backend dietro la VPN non è raggiungibile. Nulla cambia, e la conclusione ovvia è che la direttiva sia rotta o richieda una sintassi diversa. Quello che è successo davvero è più semplice e meno lusinghiero: proxy_redirect agisce su una risposta già tornata, e in questo deployment nessuna richiesta è mai arrivata così lontano.
Due direttive, due momenti in una richiesta
Una richiesta HTTP attraverso un proxy inverso attraversa diverse decisioni in ordine, e le due direttive stanno agli estremi opposti di quella sequenza. Una sceglie dove va la richiesta. L’altra modifica certe intestazioni nella risposta che torna.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Quell’ordine è tutta la risposta. Se la seconda riga non viene mai eseguita perché la prima è fallita, la seconda direttiva non è mal configurata, è semplicemente irraggiungibile. Per quanto si riscriva la seconda riga, la risposta che doveva modificare non nascerà. Diagnostica dalla prima riga verso l’esterno, e il comportamento confuso si riduce a una rotta mancante o a una connessione rifiutata.
Scegliere l’upstream spetta a proxy_pass
Supponiamo che NGINX giri su un host di ingresso pubblico e raggiunga un’applicazione a 10.40.0.20:8080 tramite la sua VPN. Il frammento che sceglie quell’applicazione è così, dentro un blocco server esistente:
location / {
proxy_pass http://10.40.0.20:8080;
}Usa lo schema, l’indirizzo e la porta reali, e tratta questo come un frammento e non come un deployment. L’host di ingresso deve anche tenere la rotta VPN, un percorso di inoltro consentito e traffico di ritorno funzionante verso quel servizio, perché un proxy che raggiunge un indirizzo sulla carta ha ancora bisogno del consenso del kernel.
Il riferimento del modulo proxy tiene la selezione dell’upstream separata dalla riscrittura delle intestazioni di risposta, e nota che un valore proxy_pass contenente un URI cambia il modo in cui il prefisso location corrispondente viene sostituito. Aggiungere o togliere componenti del percorso senza controllare l’URL atteso dall’applicazione è un modo affidabile di produrre un 404 che sembra un guasto di routing.
proxy_redirect corregge le risposte che espongono un indirizzo privato
Una volta che il traffico scorre, un backend può rispondere con un’intestazione Location che nomina il proprio indirizzo privato. Un browser che segue quell’intestazione lascia il punto di ingresso pubblico e prova a raggiungere qualcosa che non riesce a risolvere. Una riscrittura di risposta configurata di proposito mappa l’URL privato su quello pubblico:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Sostituisci entrambi i lati con valori reali. Comprendi anche l’ambito ristretto: il testo delle intestazioni Location e Refresh corrispondenti viene riscritto, mentre gli URL incorporati in HTML, JavaScript o file scaricati no.
Se un’applicazione costruisce link assoluti ovunque, la soluzione duratura è la sua configurazione di URL esterno, non un elenco crescente di regole di riscrittura sul proxy. Aggiungere regole finché l’output sembra corretto produce una configurazione che fallisce sulla prima pagina che nessuno ha provato. Una sola impostazione corretta dell’applicazione sostituisce l’intera raccolta.
Cosa non può riparare una riscrittura di intestazione
Diversi problemi adiacenti sembrano problemi di reindirizzamento e non lo sono. L’intestazione Host inviata all’upstream può dover corrispondere all’host virtuale del backend. Un upstream TLS può richiedere un nome server specifico più la verifica del certificato, e riscrivere un’intestazione di risposta non aiuta né l’uno né l’altro.
L’ambito dei cookie e gli attributi di dominio appartengono all’applicazione e alla sua configurazione. Un proxy può scartare o riscrivere intestazioni tutto il giorno e produrre comunque una sessione che fallisce alla seconda richiesta, perché il cookie è stato emesso per un host che il browser non ha mai visitato. Quel guasto sembra intermittente, ed è per questo che sopravvive così a lungo in coda ai ticket. Leggere il dominio del cookie di solito chiude l’indagine in un minuto.
Tieni anche autenticazione e selezione del backend limitate all’applicazione prevista. Un proxy inverso pubblico dovrebbe esporre una sola applicazione tramite la VPN del server invece di diventare un gateway generico verso ogni indirizzo privato che quell’host può raggiungere. Un solo location generico che inoltra tutto ciò che il chiamante chiede trasforma un servizio esposto in una mappa della tua rete privata. Nomina l’upstream esplicitamente e tienilo lì.
Prova nell’ordine in cui viaggia la richiesta
Conferma tre cose in sequenza: NGINX ha scelto il location previsto, ha completato una richiesta verso il backend, e il browser ha seguito ogni successivo reindirizzamento e caricato le sotto-risorse. Ogni passo ha le sue righe di log, e leggerle in ordine trasforma un 502 vago in un riscontro concreto.
La distinzione che ti serve è tra una connessione upstream fallita e un browser mandato verso un nome privato irraggiungibile. La prima compare nel log degli errori del proxy; la seconda compare come una richiesta che non arriva mai, con il browser che si lamenta di un host che non riesce a risolvere. Due problemi diversi, due file diversi, e solo uno dei due riguarda proxy_redirect.