proxy_redirect no connecta NGINX amb el teu host VPN
proxy_redirect reescriu capçaleres en una resposta que ja ha arribat; no tria mai l'upstream. Comprova proxy_pass, la ruta cap al backend i després les capçaleres.
El nom conté la paraula redirect, així que s'enganxa dins d'un bloc location quan no es pot arribar a un backend darrere de la VPN. No canvia res, i la conclusió òbvia és que la directiva està trencada o necessita una sintaxi diferent. El que va passar és més simple i menys afalagador: proxy_redirect actua sobre una resposta que ja ha tornat, i en aquest desplegament cap petició no va arribar tan lluny.
Dues directives, dos moments en una petició
Una petició HTTP a través d'un proxy invers passa per diverses decisions en ordre, i les dues directives se situen als extrems oposats d'aquesta seqüència. Una tria on va la petició. L'altra edita certes capçaleres de la resposta que 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 |
Aquest ordre és tota la resposta. Si la segona fila no s'executa mai perquè la primera ha fallat, la segona directiva no està mal configurada, simplement és inabastable. Per molt que reescriguis la segona línia, no crearàs la resposta que havia d'editar. Diagnostica des de la primera fila cap enfora, i el comportament confús es resol en una ruta que falta o una connexió rebutjada.
Triar l'upstream pertoca a proxy_pass
Suposem que NGINX s'executa en un host d'entrada públic i pot arribar a una aplicació a 10.40.0.20:8080 per la seva VPN. El fragment que tria aquesta aplicació té aquest aspecte, dins d'un bloc server existent:
location / {
proxy_pass http://10.40.0.20:8080;
}Utilitza l'esquema, l'adreça i el port reals, i tracta-ho com un fragment i no com un desplegament. L'host d'entrada també ha de mantenir la ruta de la VPN, un camí de reenviament permès i trànsit de retorn funcional cap a aquest servei, perquè un proxy que pot arribar a una adreça sobre el paper encara necessita que el nucli hi estigui d'acord.
La referència del mòdul proxy manté la selecció de l'upstream separada de la reescriptura de capçaleres de resposta, i assenyala que un valor proxy_pass que conté un URI canvia com es substitueix el prefix de location coincident. Afegir o treure components del camí sense comprovar l'URL que l'aplicació espera és una manera fiable de produir un 404 que sembla una fallada d'encaminament.
proxy_redirect arregla respostes que filtren una adreça privada
Un cop hi ha trànsit, un backend pot respondre amb una capçalera Location que indica la seva adreça privada. Un navegador que segueix aquesta capçalera deixa el punt d'entrada públic i intenta arribar a una cosa que no pot resoldre. Una reescriptura de resposta configurada expressament mapeja l'URL privat sobre el públic:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Substitueix els dos costats per valors reals. Entén també l'abast estret: es reescriu el text de les capçaleres Location i Refresh que coincideixen, però els URL incrustats en HTML, JavaScript o fitxers descarregats no.
Si una aplicació construeix enllaços absoluts a tot arreu, la solució duradora és la seva pròpia configuració d'URL extern, no una llista creixent de regles de reescriptura al proxy. Afegir regles fins que la sortida sembli correcta produeix una configuració que falla a la primera pàgina que ningú no ha provat. Un sol paràmetre correcte de l'aplicació substitueix tota la col·lecció.
Què no pot reparar una reescriptura de capçalera
Diversos problemes adjacents semblen problemes de redirecció i no ho són. La capçalera Host enviada a l'upstream pot haver de coincidir amb l'host virtual del backend. Un upstream TLS pot necessitar un nom de servidor concret més verificació del certificat, i reescriure una capçalera de resposta no ajuda en cap dels dos casos.
L'abast de les galetes i els atributs de domini pertanyen a l'aplicació i a la seva configuració. Un proxy pot descartar o reescriure capçaleres tot el dia i encara produir una sessió que falla a la segona petició, perquè la galeta es va emetre per a un host que el navegador no ha visitat mai. Aquesta fallada sembla intermitent, i per això sobreviu tant de temps en una cua de tiquets. Llegir el domini de la galeta normalment tanca la investigació en un minut.
Mantén també l'autenticació i la selecció de backend limitades a l'aplicació prevista. Un proxy invers públic hauria d'exposar una sola aplicació a través de la VPN del servidor en lloc de convertir-se en una passarel·la genèrica cap a cada adreça privada que aquell host pugui abastar. Un sol location genèric que reenvia tot el que demana el sol·licitant converteix un servei exposat en un mapa de la teva xarxa privada. Anomena l'upstream explícitament i deixa'l allà.
Prova en l'ordre en què viatja la petició
Confirma tres coses en seqüència: NGINX va triar el location previst, va completar una petició al backend i el navegador va seguir qualsevol redirecció posterior i va carregar els subrecursos. Cada pas té les seves línies de log, i llegir-les en ordre converteix un 502 vague en una troballa concreta.
La distinció que necessites és entre una connexió d'upstream fallida i un navegador enviat a un nom privat inabastable. La primera apareix al log d'errors del proxy; la segona apareix com una petició que no arriba mai, amb el navegador queixant-se d'un host que no pot resoldre. Dos problemes diferents, dos fitxers diferents, i només un dels dos té res a veure amb proxy_redirect.