Cómo solucionar un proxy inverso que dirige un dominio a la aplicación incorrecta después de añadir una regla general
Un proxy inverso puede enviar un dominio a la aplicación equivocada cuando una nueva ruta general coincide de forma más amplia o tiene prioridad sobre la regla de host prevista.
Esto es más específico que una redirección genérica al dominio equivocado o un problema de DNS. La prueba clave es comprobar si el dominio correcto sigue llegando a la IP de proxy y al certificado esperados, pero el proxy selecciona el backend equivocado únicamente después de que existe la nueva ruta predeterminada. Compara las coincidencias y prioridades de las rutas antes de cambiar el DNS, las URL base de la aplicación o los certificados.
Demuestra que la regla general cambió la selección del backend
Envía la misma solicitud de dominio antes y después de desactivar únicamente la nueva ruta general o predeterminada. Registra el acceso del proxy, el enrutador o bloque de servidor seleccionado, la dirección del backend, el indicador de respuesta y el certificado.
Una guía práctica sobre servidores predeterminados de Nginx advierte que las reglas generales pueden capturar tráfico incluso cuando ya existen varios hosts virtuales explícitos.
Si al desactivar la ruta alternativa se restablece inmediatamente la aplicación prevista, mantén sin cambios el DNS y la aplicación del backend. La siguiente tarea es hacer que la ruta específica gane sin eliminar el comportamiento seguro de fallback para nombres de host desconocidos.
Comprueba si la regla del host específico sigue coincidiendo exactamente
Compara el nombre de host solicitado con la regla de ruta prevista carácter por carácter, incluidos el subdominio, los límites de los comodines, los puntos finales en las herramientas de prueba y si la regla escucha en el mismo punto de entrada HTTP o HTTPS que la ruta general.
Una guía de proxy inverso para varias aplicaciones muestra que las reglas de nombre de host seleccionan distintos backends solo cuando el host entrante coincide con la regla que el proxy cargó realmente.
Corrige un selector de host incompleto o mal escrito antes de ajustar la prioridad. Aumentar la prioridad de una regla que nunca coincide solo hace que la configuración sea más difícil de entender.
Compara la prioridad de la ruta con la ruta general
En los proxies que admiten prioridades explícitas o derivadas, revisa qué regla gana cuando tanto el host específico como el fallback amplio pueden coincidir con la misma solicitud. Registra la regla evaluada, no solo el orden del archivo de configuración.
Un ejemplo de ruta general de Traefik asigna deliberadamente al fallback una prioridad inferior a la de las rutas reales, de modo que los servicios específicos se evalúen primero.
Coloca el fallback por debajo de todas las rutas de aplicaciones previstas y vuelve a probar. No resuelvas el problema asignando números enormes y arbitrarios a cada enrutador; mantén un esquema de prioridades sencillo y documentado que siga funcionando al añadir aplicaciones en el futuro.
Inspecciona el servidor predeterminado en proxies basados en Nginx
En Nginx y configuraciones similares, determina qué bloque de servidor se convierte en el predeterminado para esa dirección y puerto de escucha cuando no se encuentra ninguna coincidencia de nombre de host. El primer bloque cargado puede convertirse en el fallback si no se define explícitamente un servidor predeterminado.
Un artículo específico de solución de problemas de Nginx explica por qué los hosts sin coincidencia llegan a servidores predeterminados en lugar de rechazarse silenciosamente.
Usa una respuesta predeterminada neutral o un servicio de error en lugar de convertir una aplicación real en el fallback. Así, un nombre de host desconocido o mal escrito no podrá exponer accidentalmente otra aplicación autoalojada.
Comprueba por separado los fallbacks de HTTP y HTTPS
Una ruta general añadida para el puerto 80 no se comporta automáticamente igual en el puerto 443. El enrutamiento TLS, SNI, los puntos de entrada independientes o una segunda ruta general pueden hacer que solo las solicitudes HTTPS lleguen a la aplicación equivocada.
Un caso de solución de problemas de Caddy describe una ruta general que se comporta de forma distinta según el protocolo y muestra por qué la ruta específica del protocolo debe probarse directamente.
Solicita el mismo nombre de host mediante HTTP y HTTPS y registra el controlador seleccionado. Corrige el fallback en el punto de entrada afectado en lugar de cambiar la ruta de protocolo que funciona.
Mantén el fallback neutral y vuelve a probar todos los dominios conocidos
Después de corregir el alcance o la prioridad de las coincidencias, haz que el fallback devuelva un error 404, 421 o una página de error controlada y neutral, en lugar de enviar cada nombre de host desconocido a una aplicación de producción. Después, prueba una vez cada dominio autoalojado conocido.
Una descripción general de la arquitectura de un proxy inverso destaca que el proxy decide el backend después de que la solicitud llega al proxy, por lo que la corrección del DNS por sí sola no puede demostrar que el enrutamiento sea correcto.
La corrección está completa cuando cada nombre de host conocido llega a su aplicación prevista y un nombre de host desconocido llega únicamente al fallback neutral. El artículo relacionado de ZimaSpace sobre un proxy inverso que redirige a otro dominio es la siguiente línea de investigación cuando el proxy selecciona el backend correcto, pero la aplicación cambia de dominio posteriormente.
Preguntas frecuentes
¿Puede el DNS hacer que gane una ruta general?
El DNS puede enviar la solicitud a la IP de proxy equivocada, pero una vez que el proxy correcto recibe el nombre de host previsto, la coincidencia de rutas es una decisión del proxy. Verifica ambas capas por separado.
¿La ruta general debería enviar las solicitudes a una aplicación de panel?
Por lo general, no. Un destino de error neutral es más seguro, porque los errores tipográficos y los nombres de host desconocidos no pueden exponer accidentalmente una aplicación real de administración o multimedia.
¿Por qué solo HTTPS llega a la aplicación equivocada?
HTTPS puede utilizar un listener, una ruta SNI, un sitio de certificado o una regla de fallback diferentes de los de HTTP. Prueba ambos puntos de entrada de forma independiente antes de cambiar el enrutamiento global.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
