Why your URL needs a port 80 or 443 entry, not 45000

Type a hostname into a browser and the scheme decides the destination port: 80 for http, 443 for https. Nothing in a DNS answer overrides that, and no forwarding rule on your machine can invent a listener at the provider's edge. When a VPN provider hands you a high public port such as 45000, an explicit URL works and a clean one does not. The gap sits at the entry point, not inside the application.

Walk the path from browser to process once, and the three publishing options stop looking mysterious.

Watch where the request actually goes

The browser resolves the name to an address, then connects to that address on the scheme's default port unless the URL names another. Your provider's edge decides what happens to the arriving connection. If its forwarding table maps only 45000 to your internal address, a connection to 80 has nowhere to go and is refused or dropped before your machine is involved.

That refusal happens at the edge, which is why your application logs show nothing at all. Absence of logs is evidence about where the packet stopped, not evidence that the application is broken.

Why a local rule cannot fix the edge

A redirect or a DNAT rule on the application host acts on packets that already arrived. Packets sent to port 80 at the provider never arrive, so the rule is never evaluated. This is the most common wasted hour in the whole problem.

DNS cannot carry the port either. The HTTP specification defines the scheme defaults, and an A or AAAA record returns an address while a CNAME returns another name. The browser still concatenates the scheme's port, so only an explicit port in the URL changes the destination.

Option one: keep the explicit port

Often the correct answer is the unglamorous one. Publish the full URL with the port, terminate TLS on an entry that supports it, and make sure every generated link keeps the same origin. For a small, controlled audience this is complete, and it costs nothing beyond a visible port number.

Check redirects and cookie scope while you are there, because a backend that writes its own hostname into a Location header undoes the arrangement.

Option two: get a real default-port entry

Some providers and hosting arrangements forward 80 and 443 on a shared or dedicated address as a documented service. Ask what is actually included instead of assuming that a public exit address implies arbitrary inbound ports. A dedicated outbound address says nothing about inbound forwarding.

Confirm ownership and availability in writing, including what happens to the entry when the tunnel reconnects with a different address. An entry that moves with the tunnel produces outages that look like DNS failures.

Option three: put a frontend in front

A reverse proxy on a reachable address can listen on 443, terminate TLS, and open a separate connection to the backend over the VPN. Visitors see the frontend's name and default port, while the frontend speaks to the backend's high port on your behalf. This works because it changes the architecture rather than fighting the entry point. The backend then needs no inbound port on the public internet at all.

It also changes what you operate. The frontend owns public TLS, access policy, logs and availability, and it must limit backend selection to the intended service. If the frontend-to-backend hop uses HTTPS, keep certificate validation on that hop.

Keep one origin

The frontend's public hostname, scheme and port form the origin visitors use, so configure the application's external URL, redirects and cookies for that origin. Send the original host and forwarded scheme if the application builds absolute links. A response that bounces users to a private name or a high port undoes the clean entry you just built.

Then decide with the audience in mind. A short URL can justify a managed frontend, and it is not worth accidentally turning a private VPN-only service into a public one.