Por que a túa URL necesita unha entrada no porto 80 ou 443, non no 45000

Escribe un nome de host nun navegador e o esquema decide o porto de destino: 80 para http, 443 para https. Nada nunha resposta DNS anula iso, e ningunha regra de reenvío na túa máquina pode inventar un oínte na beira do provedor. Cando un provedor de VPN che dá un porto público alto como o 45000, unha URL explícita funciona e unha limpa non. A fenda está no punto de entrada, non dentro da aplicación.

Percorre a ruta do navegador ao proceso unha vez, e as tres opcións de publicación deixan de parecer misteriosas.

Mira onde vai realmente a petición

O navegador resolve o nome a un enderezo e despois conecta con ese enderezo no porto predeterminado do esquema, salvo que a URL indique outro. A beira do teu provedor decide que ocorre coa conexión entrante. Se a súa táboa de reenvío só asigna o 45000 ao teu enderezo interno, unha conexión ao 80 non ten onde ir e rexéitase ou descártase antes de que a túa máquina interveña.

Ese rexeitamento ocorre na beira, por iso os rexistros da túa aplicación non mostran nada. A ausencia de rexistros é proba de onde se detivo o paquete, non proba de que a aplicación estea rota.

Por que unha regra local non pode arranxar a beira

Unha redirección ou unha regra DNAT no host da aplicación actúa sobre paquetes que xa chegaron. Os paquetes enviados ao porto 80 no provedor nunca chegan, así que a regra nunca se avalía. Esta é a hora máis desaproveitada de todo o problema.

DNS tampouco pode levar o porto. especificación HTTP define os valores predeterminados do esquema, e un rexistro A ou AAAA devolve un enderezo mentres que un CNAME devolve outro nome. O navegador segue concatenando o porto do esquema, así que só un porto explícito na URL cambia o destino.

Opción un: conservar o porto explícito

A miúdo a resposta correcta é a pouco glamorosa. Publica a URL completa co porto, termina TLS nunha entrada que o admita e asegúrate de que cada ligazón xerada conserve a mesma orixe. Para un público pequeno e controlado isto é completo, e non custa nada máis alá dun número de porto visible.

Comproba as redireccións e o alcance das cookies mentres estás aí, porque un backend que escribe o seu propio nome de host nunha cabeceira Location desfai o arranxo.

Opción dous: conseguir unha entrada real no porto predeterminado

Algúns provedores e solucións de aloxamento reenvían o 80 e o 443 nun enderezo compartido ou dedicado como servizo documentado. Pregunta que se inclúe realmente en lugar de supor que un enderezo de saída público implica portos entrantes arbitrarios. Un enderezo de saída dedicado non di nada sobre o reenvío entrante.

Confirma a propiedade e a dispoñibilidade por escrito, incluído que ocorre coa entrada cando o túnel se reconecta cun enderezo distinto. Unha entrada que se move co túnel produce caídas que parecen fallos de DNS.

Opción tres: poñer un frontend diante

Un proxy inverso nun enderezo accesible pode escoitar no 443 e terminar TLS e abrir unha conexión separada co backend a través da VPN. Os visitantes ven o nome e o porto predeterminado do frontend, mentres que o frontend fala co porto alto do backend no teu nome. Isto funciona porque cambia a arquitectura en lugar de loitar contra o punto de entrada. O backend entón non necesita ningún porto entrante na internet pública.

Tamén cambia o que operas. O frontend posúe o TLS público, a política de acceso, os rexistros e a dispoñibilidade, e debe limitar a selección de backend ao servizo previsto. Se o salto do frontend ao backend usa HTTPS, mantén a validación do certificado nese salto.

Mantén unha soa orixe

O nome de host público, o esquema e o porto do frontend forman a orixe que usan os visitantes, así que configura a URL externa da aplicación, as redireccións e as cookies para esa orixe. Envía o host orixinal e o esquema reenviado se a aplicación constrúe ligazóns absolutas. Unha resposta que devolve os usuarios a un nome privado ou a un porto alto desfai a entrada limpa que acabas de construír.

Logo decide pensando no público. Unha URL curta pode xustificar un frontend xestionado, e non paga a pena converter por accidente un servizo privado só para VPN nun público.