Por qué tu URL necesita una entrada en el puerto 80 o 443, no en el 45000

Escribe un nombre de host en un navegador y el esquema decide el puerto de destino: 80 para http, 443 para https. Nada en una respuesta DNS anula eso, y ninguna regla de reenvío en tu máquina puede inventar un oyente en el borde de tu proveedor. Cuando un proveedor de VPN te da un puerto público alto como el 45000, una URL explícita funciona y una limpia no. La brecha está en el punto de entrada, no dentro de la aplicación.

Recorre la ruta del navegador al proceso una vez, y las tres opciones de publicación dejan de parecer misteriosas.

Mira adónde va realmente la petición

El navegador resuelve el nombre a una dirección y luego se conecta a esa dirección en el puerto predeterminado del esquema, salvo que la URL indique otro. El borde de tu proveedor decide qué ocurre con la conexión entrante. Si su tabla de reenvío solo asigna el 45000 a tu dirección interna, una conexión al 80 no tiene adónde ir y se rechaza o se descarta antes de que tu máquina intervenga.

Ese rechazo ocurre en el borde, por eso los registros de tu aplicación no muestran nada. La ausencia de registros es prueba de dónde se detuvo el paquete, no prueba de que la aplicación esté rota.

Por qué una regla local no puede arreglar el borde

Una redirección o una regla DNAT en el host de la aplicación actúa sobre paquetes que ya llegaron. Los paquetes enviados al puerto 80 en el proveedor nunca llegan, así que la regla nunca se evalúa. Esta es la hora más desperdiciada de todo el problema.

DNS tampoco puede llevar el puerto. especificación HTTP define los valores predeterminados del esquema, y un registro A o AAAA devuelve una dirección mientras que un CNAME devuelve otro nombre. El navegador sigue concatenando el puerto del esquema, así que solo un puerto explícito en la URL cambia el destino.

Opción uno: conservar el puerto explícito

A menudo la respuesta correcta es la poco glamurosa. Publica la URL completa con el puerto, termina TLS en una entrada que lo admita y asegúrate de que cada enlace generado conserve el mismo origen. Para un público pequeño y controlado esto es completo, y no cuesta nada más allá de un número de puerto visible.

Comprueba las redirecciones y el alcance de las cookies mientras estás ahí, porque un backend que escribe su propio nombre de host en una cabecera Location deshace el arreglo.

Opción dos: conseguir una entrada real en el puerto predeterminado

Algunos proveedores y soluciones de alojamiento reenvían el 80 y el 443 en una dirección compartida o dedicada como servicio documentado. Pregunta qué se incluye realmente en lugar de suponer que una dirección de salida pública implica puertos entrantes arbitrarios. Una dirección de salida dedicada no dice nada sobre el reenvío entrante.

Confirma la propiedad y la disponibilidad por escrito, incluido qué ocurre con la entrada cuando el túnel se reconecta con una dirección distinta. Una entrada que se mueve con el túnel produce caídas que parecen fallos de DNS.

Opción tres: poner un frontend delante

Un proxy inverso en una dirección accesible puede escuchar en el 443 y terminar TLS y abrir una conexión separada con el backend a través de la VPN. Los visitantes ven el nombre y el puerto predeterminado del frontend, mientras que el frontend habla con el puerto alto del backend en tu nombre. Esto funciona porque cambia la arquitectura en lugar de luchar contra el punto de entrada. El backend entonces no necesita ningún puerto entrante en la internet pública.

También cambia lo que operas. El frontend posee el TLS público, la política de acceso, los registros y la disponibilidad, y debe limitar la selección de backend al servicio previsto. Si el salto del frontend al backend usa HTTPS, mantén la validación de certificados en ese salto.

Mantén un solo origen

El nombre de host público, el esquema y el puerto del frontend forman el origen que usan los visitantes, así que configura la URL externa de la aplicación, las redirecciones y las cookies para ese origen. Envía el host original y el esquema reenviado si la aplicación construye enlaces absolutos. Una respuesta que devuelve a los usuarios a un nombre privado o a un puerto alto deshace la entrada limpia que acabas de construir.

Luego decide pensando en el público. Una URL corta puede justificar un frontend gestionado, y no vale la pena convertir por accidente un servicio privado solo para VPN en uno público.