A Dedicated VPN IP Does Not Publish Your Website
A dedicated exit address says nothing about inbound delivery. Check the forwarding contract, finish the origin path, then publish a high port.
Buying a dedicated IP from a VPN provider feels like buying a front door. The address is stable, the tunnel is up, and the website still does not load for anyone outside. What you bought is an assignment, not an inbound forwarding rule. The two are sold in the same shop and configured in completely different places.
The address is an assignment, not a forwarding rule
Record the inbound public address or hostname, the permitted transport, the assigned external port and the client-side destination the provider delivers to. Then confirm that the server, protocol and account feature you selected actually support forwarding, and that the provider permits hosting on it.
Dedicated describes address assignment. It does not mean unsolicited inbound traffic is allowed, and different add-ons from the same operator can have different capabilities. The dedicated address and the dedicated server product are the two labels people mix up most often, and the support pages usually spell out which one forwards.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
An illustrative contract looks like this: the provider delivers TCP 203.0.113.60:45000 to your connected device's HTTPS service on port 8443. That is a description of a mapping someone else configured, not a rule you can create at their edge by typing it into your own firewall.
Finish the origin side
If the web application runs on the VPN client itself, it needs a listener on the delivered port and a scoped local-input permission for that port. If the client forwards the mapped connection to another host, it needs the destination translation, the forwarding policy and a reply path that survives the round trip.
Design access rules around the source address that provider path actually presents. It is not always the original visitor, and it is not always the VPN server either, which matters when you write a rule that only one of those addresses would match.
Port translation also does not convert HTTP into HTTPS. The public port and the local application port can differ freely, but the scheme, certificate identity and redirects still have to match the service people are actually reaching. If the certificate names the public host, keep it named that way on every hop. A mismatch here shows up as a browser warning rather than a routing failure, which sends people to the wrong logs for an hour.
Publish the high port honestly
If visitors connect directly and the provider assigned a high port, give them the complete URL. An ordinary DNS address record cannot append a port to an HTTPS request that defaults to 443, and no amount of TTL tweaking changes that.
A web frontend can solve this by accepting visitors on the usual port and making its own connection to the forwarded origin port. Cloudflare's default proxied ports are a defined list, though, and an arbitrary assigned port does not become a supported edge port because you added a proxied DNS record.
Changing the origin destination port is a different operation from changing the visitor port. Cloudflare's Origin Rules document a destination-port override for the backend connection, scoped to a supported rule, scheme and hostname. A port override is not a generic relay for arbitrary UDP or other protocols.
When a frontend terminates TLS, validate both hops: the browser-to-frontend certificate and the frontend-to-origin connection. The VPN hop replaces neither check, and an internal address leaking into redirects or cookies is the usual sign that only one of the two was configured with the public name in mind.
Keep the mapping alive
Some providers allocate a different port after a reconnect, and a leased mapping can require renewal through a provider-side action. Track the mechanism your provider documents, and update the listener, local rules, DNS or frontend rule only where the current contract requires it.
A static public address does not make the port lease static. An address and port still shown in a dashboard is not proof that the live session owns the mapping, which is why the test is a fresh request from outside rather than a screenshot.
Then repeat the cases you expect to happen: a normal reconnect, and a VPN loss. If loss should make the origin unavailable, do not let an updater quietly republish a direct ISP path in the background. And if the forwarding contract cannot meet the site's stability requirements, choose a different publication arrangement instead of buying another address label and hoping it behaves like a server.