专用 VPN IP 并不会把你的网站发布出去
专用出口地址与入站送达毫无关系。先核对转发约定，补齐源站一侧，然后再发布高位端口。
从 VPN 服务商买一个专用 IP，感觉就像买下了一扇大门。地址是固定的，隧道也通着，可外网的人依然打不开网站。你买到的其实是 一次地址分配，而不是入站转发规则。两件事在同一家店里出售，却在完全不同的地方配置。
地址是分配，不是转发规则
记下入站的公网地址或主机名、允许的传输方式、被分配的外部端口，以及服务商实际投递到的客户端侧目标。然后确认你选的服务器、协议与账号功能确实支持转发，并且服务商允许在其上架设。
“专用”描述的是地址分配。它并不意味着允许未经请求的入站流量，而且同一家运营商的不同附加功能能力可能不同。专用地址与“专用服务器”产品是最容易被混淆的两个名称，支持页面通常会写明哪一项负责转发。
| 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 |
一份示例约定是这样的：服务商把 TCP 203.0.113.60:45000 投递到你已连接设备的 HTTPS 服务上，端口是 8443。这只是对别人已配置好的映射的描述，并不是你在自己的防火墙里输入一遍就能在他们边界上创建的规则。
把源站一侧补齐
如果 Web 应用就跑在 VPN 客户端本机上，它需要在被投递的端口上监听，并为该端口配置范围受限的本地入站权限。如果客户端把映射后的连接转给另一台主机，则需要目标地址转换、转发策略，以及一条能扛住往返的回应路径。
访问规则要围绕服务商那条路径实际呈现的源地址来设计。它不一定是原始访客，也不一定是 VPN 服务器，这一点在你写只匹配其中一种地址的规则时尤其重要。
端口转换也不会把 HTTP 变成 HTTPS。公网端口与本地应用端口可以自由不同，但协议、证书身份与重定向仍必须与人们真正访问的服务一致。如果证书写的是公网主机名，那么每一跳都要保持这个名字。这里的不一致表现为浏览器警告而不是路由故障，会让人花一小时去查错的日志。
如实公布高位端口
如果访客直接连进来，而服务商分配的是高位端口，就把完整 URL 给他们。普通的 DNS 地址记录无法给默认走 443 的 HTTPS 请求附加端口，再怎么调 TTL 也改变不了这一点。
一个 Web 前端可以解决这个问题：照常在常用端口接待访客，再由它自己连到被转发的源站端口。不过 Cloudflare 默认的代理端口是一份确定的清单，随便分配到的端口不会因为你加了一条代理 DNS 记录就变成受支持的边缘端口。
更改源站的目标端口与更改访客端口是两种不同的操作。Cloudflare 的 Origin Rules 记录了针对后端连接的目标端口改写，且限定在受支持的规则、协议与主机名之内。端口改写并不是面向任意 UDP 或其他协议的通用中继。
当前端终结 TLS 时，两段都要校验：浏览器到前端的证书，以及前端到源站的连接。VPN 那一跳并不能替代其中任何一项检查；内部地址泄漏到重定向或 Cookie 里，通常就说明两项里只有一项是按公网名字配置的。
让映射保持有效
有些服务商在重连之后会分配另一个端口，租用的映射可能需要通过服务商侧的操作来续期。跟踪服务商文档里写的机制，只在当前约定要求的地方更新监听、本地规则、DNS 或前端规则。
公网地址固定，并不等于端口租约固定。仪表盘上还显示着的地址和端口，并不能证明在线会话拥有这条映射，所以验证方式是来自外部的一次全新请求，而不是一张截图。
然后重复你预期会发生的场景：一次正常重连，以及一次 VPN 掉线。如果掉线就该让源站不可用，那就别让更新程序在后台悄悄把直连 ISP 的路径重新发布出去。如果转发约定满足不了站点的稳定性要求，就换一种发布安排，而不是再买一个地址名，指望它像服务器一样行事。