proxy_redirect no conecta NGINX con tu host VPN
proxy_redirect reescribe cabeceras en una respuesta que ya llegó; nunca elige el upstream. Revisa proxy_pass, la ruta hacia el backend y luego las cabeceras.
El nombre contiene la palabra redirect, así que se pega dentro de un bloque location cuando no se puede alcanzar un backend detrás de la VPN. Nada cambia, y la conclusión obvia es que la directiva está rota o necesita otra sintaxis. Lo que ocurrió es más simple y menos halagador: proxy_redirect actúa sobre una respuesta que ya ha vuelto, y en este despliegue ninguna petición llegó tan lejos.
Dos directivas, dos momentos en una petición
Una petición HTTP a través de un proxy inverso pasa por varias decisiones en orden, y las dos directivas viven en extremos opuestos de esa secuencia. Una elige adónde va la petición. La otra edita ciertas cabeceras en la respuesta que vuelve.
| 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 |
Ese orden es toda la respuesta. Si la segunda fila nunca se ejecuta porque la primera falló, la segunda directiva no está mal configurada, simplemente es inalcanzable. Por mucho que reescribas la segunda línea, no crearás la respuesta que debía editar. Diagnostica desde la primera fila hacia fuera, y el comportamiento confuso se resuelve en una ruta que falta o una conexión rechazada.
Elegir el upstream corresponde a proxy_pass
Supongamos que NGINX se ejecuta en un host de entrada público y puede alcanzar una aplicación en 10.40.0.20:8080 por su VPN. El fragmento que elige esa aplicación tiene este aspecto, dentro de un bloque server existente:
location / {
proxy_pass http://10.40.0.20:8080;
}Usa el esquema, la dirección y el puerto reales, y trata esto como un fragmento y no como un despliegue. El host de entrada también debe mantener la ruta de la VPN, una ruta de reenvío permitida y tráfico de retorno funcional hacia ese servicio, porque un proxy que puede alcanzar una dirección sobre el papel todavía necesita que el núcleo esté de acuerdo.
La referencia del módulo proxy mantiene la selección del upstream separada de la reescritura de cabeceras de respuesta, y señala que un valor proxy_pass que contiene un URI cambia cómo se sustituye el prefijo de location coincidente. Añadir o quitar componentes de la ruta sin comprobar la URL que la aplicación espera es una forma fiable de producir un 404 que parece un fallo de enrutamiento.
proxy_redirect arregla respuestas que filtran una dirección privada
Una vez que fluye el tráfico, un backend puede responder con una cabecera Location que nombra su dirección privada. Un navegador que sigue esa cabecera abandona el punto de entrada público e intenta alcanzar algo que no puede resolver. Una reescritura de respuesta configurada a propósito mapea la URL privada sobre la pública:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Sustituye ambos lados por valores reales. Entiende también el alcance estrecho: se reescribe el texto de las cabeceras Location y Refresh que coinciden, pero las URL incrustadas en HTML, JavaScript o archivos descargados no.
Si una aplicación construye enlaces absolutos en todas partes, la solución duradera es su propia configuración de URL externa, no una lista creciente de reglas de reescritura en el proxy. Añadir reglas hasta que la salida parezca correcta produce una configuración que falla en la primera página que nadie probó. Un solo ajuste correcto de la aplicación sustituye toda la colección.
Qué no puede reparar una reescritura de cabecera
Varios problemas adyacentes parecen problemas de redirección y no lo son. La cabecera Host enviada al upstream puede necesitar coincidir con el host virtual del backend. Un upstream TLS puede necesitar un nombre de servidor concreto más verificación del certificado, y reescribir una cabecera de respuesta no ayuda en ninguno de los dos casos.
El alcance de las cookies y los atributos de dominio pertenecen a la aplicación y a su configuración. Un proxy puede descartar o reescribir cabeceras todo el día y aun así producir una sesión que falla en la segunda petición, porque la cookie se emitió para un host que el navegador nunca visitó. Ese fallo parece intermitente, y por eso sobrevive tanto tiempo en una cola de tiquets. Leer el dominio de la cookie normalmente termina la investigación en un minuto.
Mantén también la autenticación y la selección de backend limitadas a la aplicación prevista. Un proxy inverso público debería exponer una sola aplicación a través de la VPN del servidor en lugar de convertirse en una pasarela genérica hacia cada dirección privada que ese host pueda alcanzar. Un único location genérico que reenvía todo lo que pide el solicitante convierte un servicio expuesto en un mapa de tu red privada. Nombra el upstream explícitamente y déjalo ahí.
Prueba en el orden en que viaja la petición
Confirma tres cosas en secuencia: NGINX eligió el location previsto, completó una petición al backend y el navegador siguió cualquier redirección posterior y cargó los subrecursos. Cada paso tiene sus propias líneas de log, y leerlas en orden convierte un 502 vago en un hallazgo concreto.
La distinción que necesitas es entre una conexión de upstream fallida y un navegador enviado a un nombre privado inalcanzable. La primera aparece en el log de errores del proxy; la segunda aparece como una petición que nunca llega, con el navegador quejándose de un host que no puede resolver. Dos problemas distintos, dos archivos distintos, y solo uno de ellos tiene algo que ver con proxy_redirect.