Cómo solucionar problemas con una aplicación remota que funciona mediante IP, pero no mediante dominio

Si una aplicación funciona mediante IP, pero no mediante dominio, el servidor es accesible y el fallo suele estar en el DNS, el enrutamiento basado en el nombre de host, TLS o las redirecciones.

El acceso remoto mediante IP demuestra que alguna ruta de red llega al servidor doméstico, pero una solicitud a un dominio añade información de identidad mediante el DNS, el nombre del servidor TLS, la cabecera HTTP Host y la URL pública configurada en la aplicación. El diagnóstico más rápido mantiene el mismo cliente, puerto y servidor mientras comprueba cada capa de identidad en orden, en lugar de cambiar el proxy inverso, el certificado y los registros DNS al mismo tiempo.

Confirma que la prueba mediante IP llega al servicio previsto

Registra la dirección IP exacta, el puerto, el protocolo y la respuesta que funcionan de forma remota. Comprueba si la IP abre la aplicación real, una página predeterminada del proxy inverso, el inicio de sesión del router u otro servicio que comparta la misma dirección pública.

Una guía sobre proxies inversos para homelabs explica que un proxy puede alojar varias aplicaciones en una sola dirección porque examina la cabecera Host solicitada antes de elegir el servicio ascendente.

Si la IP solo llega a un sitio predeterminado, demuestra que se puede acceder al proxy, pero no que funcione la ruta de la aplicación objetivo. Conserva un marcador de respuesta conocido, como el título de una página o una cabecera, para que las pruebas posteriores identifiquen el host virtual correcto.

Compara el DNS público con la dirección IP que funciona

Consulta el dominio mediante un servidor de nombres autoritativo y al menos un resolvedor recursivo externo. Registra todas las respuestas A y AAAA, el TTL y si un CNAME apunta a otro nombre de host.

Las guías de autoalojamiento señalan que las respuestas almacenadas en caché pueden permanecer hasta que expire el TTL anterior, por lo que un cambio reciente puede hacer que algunos clientes sigan utilizando un destino DNS antiguo después de corregir el registro autoritativo.

Si el registro A difiere de la IP que funciona, corrige el registro o el actualizador DDNS. Si A es correcto, pero AAAA apunta a una ruta IPv6 inaccesible, prueba cada familia de direcciones por separado y elimina o repara el registro defectuoso.

Conéctate a la IP funcional conservando el dominio

Utiliza un cliente que pueda conectarse a la IP conocida mientras envía el dominio como cabecera HTTP Host y nombre del servidor TLS. Esto cambia el destino sin descartar la identidad que esperan el proxy y el certificado.

Server Fault explica que un proxy inverso HTTP puede utilizar la cabecera Host para seleccionar una ruta, del mismo modo que los hosts virtuales basados en nombres.

Si la solicitud con el dominio conservado funciona, el DNS es la capa que falla. Si llega al proxy, pero devuelve el sitio equivocado o un error 404, revisa la coincidencia de hosts virtuales y la prioridad de las rutas; si TLS falla antes de HTTP, revisa SNI y la selección del certificado.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comprueba SNI de TLS y la identidad del certificado

Compara el certificado devuelto para el dominio con el certificado devuelto para la IP sin más. Registra los nombres del sujeto, el emisor, la caducidad y si el proxy presenta un certificado predeterminado.

SNI transporta el nombre de host en el ClientHello de TLS antes de la solicitud HTTP cifrada, lo que permite al proxy seleccionar el host virtual seguro. Por tanto, una solicitud que solo utiliza la IP puede carecer del nombre de host utilizado durante la selección de TLS, aunque llegue al mismo listener.

Corrige el certificado del dominio y la ruta SNI en lugar de esperar que exista un certificado para una IP privada o dinámica. Si hay una CDN o un proxy TCP delante, confirma que transmite o termina SNI para el nombre de host previsto.

Verifica que el DNS interno y externo no envíen por rutas distintas

Compara el resultado del dominio desde datos móviles, un resolvedor público y la LAN doméstica. El DNS dividido puede devolver intencionadamente una dirección privada del proxy en casa y una dirección pública de forma remota, pero ambas respuestas deben llegar a la misma ruta lógica del nombre de host.

Una conversación de Level1Techs sobre homelabs muestra que el acceso local al proxy inverso puede requerir su propio diseño de DNS cuando el DNS público y el enrutamiento doméstico toman rutas internas y externas diferentes.

Si solo un resolvedor devuelve la dirección equivocada, corrige esa vista del DNS. Si la dirección pública funciona mediante IP, pero el dominio falla en todas partes, centra la investigación en Host, SNI, el certificado y la identidad de la aplicación, no en el DNS dividido.

Comprueba las URL canónicas y las redirecciones antes de dar por corregido el DNS

Inspecciona cada redirección después de que el dominio llegue a la aplicación. El proxy inverso o la aplicación pueden enviar a los clientes a un nombre de host interno, un dominio antiguo, un esquema incorrecto, un puerto privado o una URL de callback obsoleta.

El artículo de ZimaSpace sobre si el DNS dividido puede solucionar un fallo exclusivo del acceso interno aborda el caso relacionado en el que el nombre de host es correcto, pero la ruta varía según la ubicación.

El problema solo se resuelve cuando el DNS autoritativo devuelve la dirección prevista, el dominio selecciona el certificado y la ruta de proxy correctos, las redirecciones conservan el nombre de host público y todo el flujo de trabajo remoto funciona sin sustituir el dominio por la IP.