proxy_redirect non conecta NGINX co teu host VPN
proxy_redirect reescribe cabeceiras nunha resposta que xa chegou; nunca escolle o upstream. Comproba proxy_pass, a ruta cara ao backend e despois as cabeceiras.
O nome contén a palabra redirect, así que se pega dentro dun bloque location cando non se pode alcanzar un backend detrás da VPN. Nada cambia, e a conclusión obvia é que a directiva está rota ou necesita outra sintaxe. O que ocorreu é máis simple e menos halagador: proxy_redirect actúa sobre unha resposta que xa volveu, e neste despregamento ningunha petición chegou tan lonxe.
Dúas directivas, dous momentos nunha petición
Unha petición HTTP a través dun proxy inverso pasa por varias decisións en orde, e as dúas directivas viven en extremos opostos desa secuencia. Unha elixe a onde vai a petición. A outra edita certas cabeceiras na resposta que volve.
| 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 |
Esa orde é toda a resposta. Se a segunda fila nunca se executa porque a primeira fallou, a segunda directiva non está mal configurada, simplemente é inalcanzable. Por moito que reescribas a segunda liña, non crearás a resposta que debía editar. Diagnostica desde a primeira fila cara a fóra, e o comportamento confuso resólvese nunha ruta que falta ou nunha conexión rexeitada.
Escoller o upstream corresponde a proxy_pass
Supoñamos que NGINX se executa nun host de entrada público e pode alcanzar unha aplicación en 10.40.0.20:8080 pola súa VPN. O fragmento que escolle esa aplicación ten este aspecto, dentro dun bloque server existente:
location / {
proxy_pass http://10.40.0.20:8080;
}Usa o esquema, o enderezo e o porto reais, e trata isto como un fragmento e non como un despregamento. O host de entrada tamén debe manter a ruta da VPN, un camiño de reenvío permitido e tráfico de retorno funcional cara a ese servizo, porque un proxy que alcanza un enderezo sobre o papel aínda necesita que o núcleo estea de acordo.
A referencia do módulo proxy mantén a selección do upstream separada da reescritura de cabeceiras de resposta, e sinala que un valor proxy_pass que contén un URI cambia como se substitúe o prefixo de location coincidente. Engadir ou quitar compoñentes da ruta sen comprobar a URL que a aplicación espera é unha forma fiable de producir un 404 que parece un fallo de encamiñamento.
proxy_redirect arranxa respostas que filtran un enderezo privado
Unha vez que flúe o tráfico, un backend pode responder cunha cabeceira Location que nomea o seu enderezo privado. Un navegador que segue esa cabeceira abandona o punto de entrada público e tenta alcanzar algo que non pode resolver. Unha reescritura de resposta configurada a propósito mapea a URL privada sobre a pública:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Substitúe ambos os lados por valores reais. Entende tamén o alcance estreito: reescríbese o texto das cabeceiras Location e Refresh que coinciden, pero as URL incrustadas en HTML, JavaScript ou ficheiros descargados non.
Se unha aplicación constrúe ligazóns absolutas en todas partes, a solución duradeira é a súa propia configuración de URL externa, non unha lista crecente de regras de reescritura no proxy. Engadir regras ata que a saída pareza correcta produce unha configuración que falla na primeira páxina que ninguén probou. Un só axuste correcto da aplicación substitúe toda a colección.
Que non pode reparar unha reescritura de cabeceira
Varios problemas adxacentes parecen problemas de redirección e non o son. A cabeceira Host enviada ao upstream pode ter que coincidir co host virtual do backend. Un upstream TLS pode necesitar un nome de servidor concreto máis verificación do certificado, e reescribir unha cabeceira de resposta non axuda en ningún dos dous casos.
O alcance das cookies e os atributos de dominio pertencen á aplicación e á súa configuración. Un proxy pode descartar ou reescribir cabeceiras todo o día e aínda así producir unha sesión que falla na segunda petición, porque a cookie se emitiu para un host que o navegador nunca visitou. Ese fallo parece intermitente, e por iso sobrevive tanto tempo nunha cola de tíckets. Ler o dominio da cookie normalmente remata a investigación nun minuto.
Mantén tamén a autenticación e a selección de backend limitadas á aplicación prevista. Un proxy inverso público debería expor unha soa aplicación a través da VPN do servidor en lugar de converterse nunha pasarela xenérica cara a cada enderezo privado que ese host poida alcanzar. Un único location xenérico que reenvía todo o que pide o solicitante converte un servizo exposto nun mapa da túa rede privada. Nomea o upstream explicitamente e déixao aí.
Proba na orde na que viaxa a petición
Confirma tres cousas en secuencia: NGINX escolleu o location previsto, completou unha petición ao backend e o navegador seguiu calquera redirección posterior e cargou os subrecursos. Cada paso ten as súas propias liñas de log, e lelas en orde converte un 502 vago nun achado concreto.
A distinción que necesitas é entre unha conexión de upstream fallida e un navegador enviado a un nome privado inalcanzable. A primeira aparece no log de erros do proxy; a segunda aparece como unha petición que nunca chega, co navegador queixándose dun host que non pode resolver. Dous problemas distintos, dous ficheiros distintos, e só un deles ten algo que ver con proxy_redirect.