¿Qué hace que el DNS local devuelva la IP correcta, pero el servicio equivocado?
El DNS local puede devolver la IP correcta del NAS y, aun así, abrir el servicio equivocado cuando el proxy inverso compartido dirige el nombre de host a otro host virtual.
En un servidor doméstico ZimaSpace, varias aplicaciones pueden compartir una dirección LAN detrás de Nginx, Traefik, Caddy u otro proxy inverso. El DNS solo elige la IP de destino. El navegador sigue enviando un nombre de host mediante SNI de TLS y el encabezado HTTP Host, y el proxy decide qué contenedor recibe la solicitud.
Verifica que la respuesta de DNS dividido sea realmente la prevista
Compara el registro local con el registro público y confirma que ambos nombres de host deben terminar en el mismo proxy inverso.
Un artículo especializado sobre DNS dividido para laboratorios domésticos en DNS dividido puede devolver una ruta privada ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Mantén sin cambios el nombre de host del navegador y modifica únicamente la dirección que devuelve el DNS interno.
Demuestra que el proxy enruta por nombre de host
Envía solicitudes con el nombre de host esperado y compáralas con el acceso mediante IP directa al mismo NAS.
Una guía especializada sobre proxies inversos para laboratorios domésticos en el encabezado Host selecciona el backend ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Si la IP directa abre una aplicación predeterminada mientras que el nombre de host abre la aplicación correcta, el DNS no es el problema; el enrutamiento del host virtual funciona según lo previsto.
Comprueba si se está reescribiendo el encabezado Host
Inspecciona los encabezados Host y forwarded-host en el proxy y en el backend.
Un artículo especializado sobre seguridad y HTTP en los cambios en el encabezado Host pueden alterar el enrutamiento ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Corrige únicamente la capa que reescribe el nombre de host. No añadas registros DNS duplicados para compensar un error de enrutamiento HTTP.
Comprueba el SNI de TLS antes del enrutamiento HTTP
Varias aplicaciones HTTPS en una misma IP deben seguir presentando el nombre de host necesario para seleccionar el certificado y el host virtual previstos.
Una guía práctica especializada sobre SNI en SNI permite seleccionar entre varios sitios HTTPS en una sola IP ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Compara el nombre del certificado con la ruta del backend. Un certificado correspondiente a otra aplicación indica que la selección falló antes de que la solicitud llegara al servicio previsto.
Inspecciona el host virtual predeterminado
Si ninguna regla coincide con el nombre de host, muchos proxies devuelven un servidor predeterminado que puede pertenecer a otra aplicación.
Un artículo especializado de solución de problemas de Nginx en un nombre de host sin coincidencia puede llegar al servidor predeterminado ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Crea reglas explícitas para los nombres de host y una respuesta predeterminada neutra, en lugar de permitir que una aplicación se convierta en el destino general de todos los dominios desconocidos.
Mantén separado el enrutamiento DNS del enrutamiento del proxy
Considera el DNS como la selección de direcciones y el proxy inverso como la selección de aplicaciones.
Un artículo especializado sobre DNS frente a proxies inversos en el DNS y los proxies inversos resuelven distintas capas de enrutamiento ayuda a aislar esta posibilidad porque aborda el mismo microproblema, en lugar de limitarse a definir el protocolo subyacente.
Vuelve a probar con el nombre de host exacto de la aplicación desde un cliente de la LAN. El resultado correcto debe mostrar el certificado esperado, la ruta del proxy y el backend correctos, sin usar marcadores de acceso mediante IP directa.
Vuelve a probar la ruta exacta del servidor doméstico
Después de cambiar una variable, repite el mismo flujo de trabajo del NAS o del servicio autoalojado desde el mismo cliente, en lugar de cambiar a una prueba distinta que podría usar otra ruta.
La guía relacionada de ZimaSpace en la ruta de red doméstica relacionada ayuda a mantener la verificación final vinculada al mismo entorno autoalojado.
La solución solo estará completa cuando el síntoma original siga resuelto después de volver a conectarse, reiniciar el servicio y realizar una segunda transferencia o solicitud controlada.
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...
