Una IP de VPN dedicada no publica tu sitio web
Una dirección de salida dedicada no dice nada sobre la entrega entrante. Comprueba el contrato de reenvío, completa el lado del origen y luego publica un puerto alto.
Comprar una IP dedicada a un proveedor de VPN se siente como comprar una puerta de entrada. La dirección es estable, el túnel está levantado y, aun así, el sitio no carga para nadie de fuera. Lo que has comprado es una asignación, no una regla de reenvío entrante. Ambas cosas se venden en la misma tienda y se configuran en lugares completamente distintos.
La dirección es una asignación, no una regla de reenvío
Anota la dirección pública entrante o el nombre de host, el transporte permitido, el puerto externo asignado y el destino del lado del cliente al que entrega el proveedor. Después confirma que el servidor, el protocolo y la función de cuenta que elegiste admiten realmente el reenvío, y que el proveedor permite alojar en él.
Dedicada describe la asignación de dirección. No significa que se permita tráfico entrante no solicitado, y distintos complementos del mismo operador pueden tener capacidades diferentes. La dirección dedicada y el producto de servidor dedicado son las dos etiquetas que más se confunden, y las páginas de soporte suelen aclarar cuál de las dos reenvía.
| 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 |
Un contrato ilustrativo se ve así: el proveedor entrega TCP 203.0.113.60:45000 al servicio HTTPS de tu dispositivo conectado en el puerto 8443. Eso describe una asignación que configuró otra persona, no una regla que puedas crear en su borde escribiéndola en tu propio cortafuegos.
Completa el lado del origen
Si la aplicación web se ejecuta en el propio cliente de VPN, necesita un oyente en el puerto entregado y un permiso de entrada local acotado para ese puerto. Si el cliente reenvía la conexión asignada a otro host, necesita la traducción de destino, la política de reenvío y una ruta de respuesta que sobreviva a la ida y vuelta.
Diseña las reglas de acceso en torno a la dirección de origen que la ruta del proveedor presenta realmente. No siempre es el visitante original, y tampoco siempre es el servidor de VPN, lo que importa cuando escribes una regla que solo coincidiría con una de esas direcciones.
La traducción de puertos tampoco convierte HTTP en HTTPS. El puerto público y el puerto local de la aplicación pueden diferir libremente, pero el esquema, la identidad del certificado y las redirecciones siguen teniendo que coincidir con el servicio que la gente alcanza de verdad. Si el certificado nombra al host público, mantén ese nombre en cada salto. Una discrepancia aquí aparece como un aviso del navegador y no como un fallo de enrutamiento, lo que manda a la gente a los registros equivocados durante una hora.
Publica el puerto alto con honestidad
Si los visitantes se conectan directamente y el proveedor asignó un puerto alto, dales la URL completa. Un registro de dirección DNS normal no puede añadir un puerto a una petición HTTPS que por defecto usa 443, y ningún ajuste del TTL lo cambia.
Un frontend web puede resolverlo aceptando visitantes en el puerto habitual y haciendo su propia conexión al puerto de origen reenviado. Sin embargo, los puertos proxy por defecto de Cloudflare son una lista definida, y un puerto asignado arbitrario no se convierte en un puerto de borde admitido solo porque hayas añadido un registro DNS proxificado.
Cambiar el puerto de destino del origen es una operación distinta de cambiar el puerto del visitante. Las Origin Rules de Cloudflare documentan una sustitución del puerto de destino para la conexión con el backend, limitada a una regla, un esquema y un nombre de host admitidos. Una sustitución de puerto no es un relé genérico para UDP arbitrario ni para otros protocolos.
Cuando un frontend termina TLS, valida ambos saltos: el certificado del navegador al frontend y la conexión del frontend al origen. El salto de VPN no sustituye ninguna de las dos comprobaciones, y que una dirección interna se filtre en redirecciones o cookies es la señal habitual de que solo una de las dos se configuró pensando en el nombre público.
Mantén viva la asignación
Algunos proveedores asignan un puerto distinto tras una reconexión, y una asignación alquilada puede requerir renovación mediante una acción del proveedor. Sigue el mecanismo que documenta tu proveedor y actualiza el oyente, las reglas locales, el DNS o la regla del frontend solo donde el contrato actual lo exija.
Una dirección pública estática no hace estático el alquiler del puerto. Una dirección y un puerto que aún se muestran en un panel no son prueba de que la sesión activa posea la asignación, por eso la prueba es una petición nueva desde fuera y no una captura de pantalla.
Luego repite los casos que esperas: una reconexión normal y una pérdida de VPN. Si la pérdida debe dejar el origen inaccesible, no dejes que un actualizador vuelva a publicar en silencio una ruta directa del ISP en segundo plano. Y si el contrato de reenvío no puede cumplir los requisitos de estabilidad del sitio, elige otra disposición de publicación en lugar de comprar otra etiqueta de dirección y esperar que se comporte como un servidor.