¿Por qué un proxy inverso funciona por dominio pero falla por IP local?

Un proxy inverso funciona por dominio porque sus reglas de enrutamiento y TLS a menudo dependen del nombre de host solicitado, no solo de la IP de destino.

Cuando un cliente doméstico abre https://app.example.com, el DNS proporciona una IP pero el navegador aún envía el dominio durante el apretón de manos TLS y el encabezado HTTP Host. Abrir https://192.168.1.20 cambia esos identificadores, por lo que el proxy puede seleccionar un sitio predeterminado, rechazar el certificado, no encontrar la ruta de la aplicación o redirigir de vuelta a la URL pública configurada. La prueba correcta preserva el nombre de host previsto mientras cambia solo el destino de red.

Compare la Solicitud por Nombre de Host con la Solicitud por IP Directa

Envíe una solicitud al dominio y otra a la IP local, luego compare el código de estado, certificado, encabezados de respuesta, ubicación de redirección y el registro de acceso del proxy inverso. No asuma que ambas solicitudes son equivalentes solo porque llegan a la misma interfaz Ethernet.

Un recorrido por un proxy inverso en un homelab explica que el proxy inspecciona el encabezado HTTP Host para enrutar varios servicios a través de una sola IP y puerto.

Si la solicitud al dominio coincide con una ruta de aplicación mientras que la solicitud a la IP muestra una página predeterminada o un error 404, el proxy está funcionando según lo configurado. La siguiente decisión es si realmente se requiere el acceso por IP directa o si el DNS local debería preservar el dominio.

Pruebe la IP Local Mientras Preserva el Encabezado Host Previsto

Use una herramienta cliente que se conecte a la IP local del proxy mientras envía el dominio de la aplicación como encabezado Host. Para HTTPS, también preserve el dominio como nombre del servidor TLS en lugar de reemplazarlo con la IP.

Server Fault describe cómo un proxy inverso HTTP puede usar el encabezado Host para elegir la ruta de la misma manera que los hosts virtuales basados en nombre.

Si la solicitud con host forzado tiene éxito, la ruta del proxy y el backend están saludables; el fallo con IP directa es una incompatibilidad de identidad. Si aún falla, inspeccione el listener, el firewall local, el punto de entrada del proxy y la prioridad de la ruta antes de cambiar el DNS.

Verifique la Coincidencia de TLS SNI y Certificado

HTTPS añade una decisión de nombre de host antes de la solicitud HTTP. El cliente usualmente envía la Indicación de Nombre de Servidor (SNI) durante el apretón de manos TLS para que el proxy pueda seleccionar el certificado correcto y el host virtual seguro.

Una implementación de proxy inverso con SNI señala que los backends HTTPS se seleccionan usando el nombre SNI del cliente antes de que se puedan examinar los encabezados HTTP ordinarios.

El acceso directo por IP puede presentar un certificado predeterminado o fallar la validación del nombre de host incluso cuando el proxy es accesible. Use el dominio con DNS local, o despliegue un certificado gestionado deliberadamente que contenga la IP solo cuando HTTPS por IP directa sea un requisito operativo real.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Inspeccione el Sitio Predeterminado y la Prioridad de la Ruta

Revise qué host virtual maneja las solicitudes que no coinciden con un dominio configurado. Un sitio predeterminado puede devolver un panel, redirigir a otro nombre de host, cerrar la conexión o mostrar un error genérico.

Una discusión sobre Caddy muestra que una solicitud puede llegar a la IP correcta del proxy mientras que el encabezado Host y el nombre TLS aún determinan si se elige el upstream previsto.

Mantenga la ruta predeterminada explícita y segura. No añada un proxy catch-all amplio a un solo backend solo para que funcione el acceso por IP, porque eso puede enrutar nombres de host desconocidos o tráfico de escaneo hacia una aplicación que debía estar restringida por dominio.

Verifique si la Aplicación Redirige a su URL Canónica

Incluso cuando el proxy acepta la solicitud por IP, el backend puede imponer una URL base pública configurada y redirigir el navegador al dominio. Las cookies de autenticación, callbacks OAuth, orígenes WebSocket y verificaciones CSRF también pueden depender de ese host canónico.

Compare el registro del proxy con el registro de la aplicación e inspeccione el encabezado Location. Una redirección al dominio no es un fallo de enrutamiento; es evidencia de que la aplicación espera una identidad pública única.

Corrija los encabezados de host y protocolo reenviados cuando la aplicación genere la URL externa incorrecta. No reemplace el dominio canónico con una IP privada solo para evitar la redirección, porque eso puede romper certificados y el acceso remoto.

Use DNS Local Cuando el Dominio Sea la Interfaz Prevista

Genere un registro DNS interno que resuelva el dominio de la aplicación a la dirección local del proxy inverso. El navegador entonces usa la ruta eficiente de LAN mientras preserva el mismo encabezado Host, nombre SNI, certificado, cookies y URL de la aplicación.

La comparación de ZimaSpace de proxies inversos y rutas de acceso privadas ayuda a decidir si el dominio debe permanecer como punto de entrada local y público o quedarse detrás de una red privada.

El problema se resuelve cuando el dominio funciona tanto dentro como fuera mediante respuestas DNS intencionadas, mientras que la IP directa o bien llega a un sitio predeterminado documentado o es rechazada deliberadamente. Un proxy enrutado por dominio no necesita comportarse como un servidor de sitio único direccionado por IP.