Dejar un proveedor por cable: ¿Starlink te da una IP pública?

Sin una dirección IPv4 pública en tu router, una redirección de puertos en él no basta

Si tu router tiene una dirección IPv4 pública, una redirección de puertos en él envía las conexiones de internet a un equipo de casa. Si no la tiene, esa dirección la tiene un dispositivo entre tu router e internet que hace traducción de direcciones de red (NAT), tuyo o de tu proveedor, y una redirección de puertos en tu router solo llega a internet si ese NAT también redirige el puerto. Cuando ese NAT intermedio es el NAT de nivel de operador de un proveedor, RFC 6269 dice que, si hay un CGN, el puerto también debe abrirse en el CGN, y que el CGN hace que los suscriptores dependan de su proveedor para esa función ("If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality."; sección 5.2.1, consultado en octubre de 2026). RFC 6888 añade que los suscriptores tienen poco o ningún control ("limited or no control") sobre un NAT de nivel de operador (sección 2, consultado en octubre de 2026).

La página 1, la guía para alojar un servidor sin una dirección IPv4 pública, probó una conexión doméstica de Starlink. Su traza de la ruta de salida encaja con un CGNAT pero no lo demuestra, porque el segundo salto nunca respondió. Desde un equipo de la red de casa, las conexiones salientes por IPv4 al puerto 25 agotaron el tiempo de espera, y no se ve dónde se descartaron. La página 1 también probó puertos entrantes desde un servidor privado virtual (VPS), un servidor en la nube.

La propia página de ayuda de Starlink What IP address does Starlink provide? dice que los routers WiFi de Starlink no admiten redirección de puertos ni reglas de cortafuegos para IPv4 ni IPv6 ("Starlink WiFi routers do not support port forwarding or firewall rules for IPv4 or IPv6."). La misma página dice que los puertos salientes TCP/25 (SMTP) y TCP/445 (SMB) están bloqueados para todos los clientes, según las buenas prácticas de seguridad de la información ("Outbound ports TCP/25 (SMTP) and TCP/445 (SMB) are blocked for all customers per information security best practices."). Ambas líneas se consultaron en octubre de 2026.

Lo que depende de una dirección IPv4 pública en casa:

• un servidor al que se conectan otras personas, como un servidor de juegos, un sitio web o un escritorio remoto;
• una aplicación que abre puertos en el router por sí sola;
• un servidor de correo que recibe correo de otros servidores;
• cualquier cosa ligada a una dirección que no cambia, como una lista de permitidos o un registro DNS (más abajo).

Una aplicación abre puertos pidiéndoselo al router de tus instalaciones, el CPE en los términos de RFC 6269. Los routers domésticos abren puertos entrantes a mano o con un protocolo como UPnP IGD ("either manually, or with a protocol such as" UPnP IGD), dice el RFC, y con un NAT de nivel de operador en el camino, el CPE y el CGN tendrán que cooperar para que funcione la redirección de puertos ("CPE and CGN will need to cooperate in order for port forwarding functionality to work"; sección 5.2.1). Un protocolo para eso, el Port Control Protocol (PCP), permite a un host IPv6 o IPv4 controlar cómo un traductor de direcciones de red (NAT) o un cortafuegos simple traduce y reenvía los paquetes IPv6 o IPv4 entrantes ("allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall"; RFC 6887, resumen, consultado en octubre de 2026). El requisito REQ-9 de RFC 6888 dice que un CGN debe implementar un protocolo que dé a los suscriptores control explícito sobre las asignaciones del NAT, y que ese protocolo debería ser el Port Control Protocol ("A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol"): un requisito para quien construye uno, que no dice nada de lo que usa un proveedor concreto.

En octubre de 2026, la comprobación de red de Tailscale, tailscale netcheck, en un equipo de la red de casa no listó ninguno de los servicios de asignación de puertos que busca (UPnP, NAT-PMP y PCP). La referencia de la CLI de Tailscale dice que, si algún campo está vacío, Tailscale no pudo medir esa propiedad de la red ("If any fields are blank, it means Tailscale wasn't able to measure that network property"; validada por última vez en julio de 2026, consultada en octubre de 2026), así que un campo vacío no muestra que no exista ese servicio.

El correo entre servidores viaja por el puerto 25. RFC 6409 dice que la retransmisión de mensajes no cambia y sigue usando SMTP por el puerto 25 ("Message relay is unaffected, and continues to use SMTP over port 25"), mientras que los programas de correo envían los mensajes normalmente por el puerto 587 ("normally over port 587"; resumen, consultado en octubre de 2026). Un servidor de correo en casa recibe el correo de otros servidores por el puerto 25.

Comprueba si tu router tiene ahora una dirección IPv4 pública

Lo que te quita el cambio depende de lo que te da hoy tu conexión, y tu propio router lo muestra.

1. Desactiva cualquier red privada virtual (VPN), proxy o nodo de salida en el dispositivo que uses para esto. Después compara la dirección WAN o de internet de la página de estado de tu router con la dirección IPv4 pública que un servicio de consulta indica para tu conexión. Si coinciden, el router tiene una dirección IPv4 pública, y una redirección de puertos en él puede recibir conexiones.
2. Si no coinciden, un NAT entre tu router e internet tiene la dirección pública, y la propia dirección WAN del router dice de quién es. Dentro de 100.64.0.0/10, el bloque que RFC 6598 reserva como espacio de direcciones compartido para el NAT de nivel de operador, es del proveedor. Dentro de 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16, los bloques privados de RFC 1918, es otro NAT, un router tuyo o del proveedor. En cualquier caso, una redirección de puertos en tu router solo llega a internet si ese NAT también redirige el puerto, y que las dos direcciones no coincidan no dice, por sí solo, si lo hace.

Los dos pasos se basan en los RFC de arriba (consultados en octubre de 2026); esta página no hizo la comparación en ninguna conexión.

Quién tiene que llegar al servidor decide el sustituto

Sin una dirección IPv4 pública en tu router, un servidor en casa necesita otra vía de entrada. Esta página describe cinco a partir de las páginas de sus propios proveedores y no prueba ninguna.

Vía de entrada	Quién puede llegar al servidor
La opción de IPv4 pública de Starlink	Quién puede llegar al servidorCualquiera, en los puertos que redirija tu propio router
Un VPS de reenvío	Quién puede llegar al servidorCualquiera, en los puertos que reenvíe el VPS
Un túnel saliente (Cloudflare Tunnel)	Quién puede llegar al servidorCualquiera con un navegador, para un servicio web; para otros servicios, solo los visitantes que usen el cliente de Cloudflare
Una VPN en malla (Tailscale o Headscale)	Quién puede llegar al servidorSolo los dispositivos que añadas a ella
IPv6 entrante, con tu propio router	Quién puede llegar al servidorNo lo dice la página de ayuda de Starlink, que remite a un router de terceros a los clientes que necesitan tráfico entrante

Lo que dice Starlink que cambia su opción de IPv4 pública

La página de ayuda What IP address does Starlink provide? nombra dos políticas de IPv4, "default" (predeterminada) y "public" (pública). La política "default", dice, no permite tráfico entrante ("does not allow inbound traffic"). Cuando hace falta tráfico IPv4 entrante ("IPv4 inbound traffic is needed"), remite a un plan de servicio de Starlink con la opción de IPv4 pública ("a Starlink service plan with the public IPv4 option"; consultada en octubre de 2026).

La página de ayuda de Starlink sobre cómo poner una IP pública dice que la posibilidad de cambiar la política de IP a una IP pública solo está disponible en los planes de servicio Local Priority y Global Priority ("The ability to update the IP policy to a Public IP is only available to the Local and Global Priority service plans."; consultada en octubre de 2026).

La página de ayuda de Starlink sobre referidos enumera ocho planes elegibles, todos Residential o Roam, y ningún plan Priority (octubre de 2026).

Esta página no ha probado la opción de IPv4 pública.

Un VPS de reenvío, para un servidor al que llegan otras personas

Un VPS de reenvío es un VPS con su propia IP pública que pasa las conexiones de los visitantes por un túnel hasta un servidor en casa. Esta página no ha probado ninguno. La página del servidor de juegos prueba uno: un reenvío TCP en una VM gratuita en la nube, para un servidor de Minecraft en casa con Starlink.

La conexión empieza en casa: el servidor de casa mantiene un túnel abierto hacia el VPS, por ejemplo con WireGuard. La Quick Start de WireGuard dice que un par detrás de un NAT debe mantener válida la asignación del NAT o del cortafuegos enviando periódicamente paquetes keepalive ("must keep the NAT/firewall mapping valid, by periodically sending keepalive packets"), que un intervalo razonable que funciona con una gran variedad de cortafuegos es de 25 segundos ("A sensible interval that works with a wide variety of firewalls is 25 seconds"), y que eso permite al par recibir conexiones entrantes mucho después de que el tráfico de red se haya quedado en silencio ("receive incoming connections long after network traffic has gone silent"; sección "NAT and Firewall Traversal Persistence", consultada en octubre de 2026). En el VPS, los puertos que elijas se reenvían por el túnel, o un proxy inverso pasa las solicitudes web: la directiva reverse_proxy de Caddy hace de proxy de las solicitudes hacia uno o varios backends ("Proxies requests to one or more backends"; consultada en octubre de 2026).

Los visitantes se conectan a la IP pública del VPS, y tu proveedor de VPS lleva el tráfico. Todo lo que el VPS reenvía queda abierto a internet, así que reenvía solo el puerto que quieras publicar.

Un túnel saliente, para servicios web

Un túnel saliente conecta un servidor de casa a la red de un proveedor desde dentro, y los visitantes llegan al servidor a través de ese proveedor. No se probó ninguno para esta página.

La página de Cloudflare sobre Cloudflare Tunnel dice que conecta recursos a Cloudflare sin una dirección IP enrutable públicamente ("without a publicly routable IP address"), que su conector, cloudflared, crea solo conexiones salientes ("creates outbound-only connections") y que puede conectar servidores web HTTP, servidores SSH, escritorios remotos y otros protocolos ("HTTP web servers, SSH servers, remote desktops, and other protocols"; página actualizada por última vez en agosto de 2026, consultada en octubre de 2026). Su página sobre los protocolos de las aplicaciones publicadas dice que una ruta de aplicación publicada indica a Cloudflare que haga de proxy de las solicitudes a tu nombre de host público hacia un servicio que funciona de forma privada detrás de cloudflared ("to proxy requests for your public hostname to a service running privately behind cloudflared"), y que los servicios que no son HTTP exigen instalar cloudflared en el cliente para que los usuarios finales se conecten ("Non-HTTP services require installing cloudflared on the client for end users to connect"): para TCP y SSH, los usuarios finales ejecutan cloudflared access tcp o cloudflared access ssh (consultada en octubre de 2026).

Así que un visitante de un servicio web solo necesita un navegador. Para SSH, un escritorio remoto u otro servicio que no sea HTTP, cada visitante necesita el cliente de Cloudflare. La red de Cloudflare lleva el tráfico.

Una VPN en malla, para tus propios dispositivos

Una VPN en malla conecta tus propios dispositivos entre sí, así que solo los dispositivos que añadas pueden llegar a un servidor en casa, no los visitantes. Esta página tampoco prueba ninguna.

Tailscale es una. Headscale se describe como una implementación de código abierto y autoalojada del servidor de control de Tailscale ("an open source, self-hosted implementation of the Tailscale control server"), limitada a una sola red de Tailscale (tailnet), adecuada para uso personal ("a single Tailscale network (tailnet), suitable for a personal use"; consultada en octubre de 2026); tailnet es el nombre que da Tailscale a una de esas redes. La página de Tailscale sobre los tipos de conexión dice que todas las conexiones empiezan retransmitidas a través de un servidor DERP ("All connections start as relayed through a DERP server"), los servidores de retransmisión de Tailscale, y que en la mayoría de los entornos Tailscale consigue establecer conexiones directas, pero algunas configuraciones de red (NAT difícil) pueden impedirlo ("In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this"; validada por última vez en junio de 2026, consultada en octubre de 2026). Cuando no se forma una ruta directa, los servidores de retransmisión de Tailscale llevan el tráfico. Su artículo de 2020 How NAT traversal works dice que no puedes reconfigurar el CGNAT del proveedor ("you can't reconfigure the ISP's CGNAT") y que, aparte de los protocolos de asignación de puertos, todo su repertorio de trucos actual funciona bien en un mundo con CGNAT ("Aside from the port mapping protocols, everything from our current bag of tricks works fine in a CGNAT world"; agosto de 2020, consultado en octubre de 2026).

La comprobación de Tailscale en la red de casa, en octubre de 2026, también encontró que el NAT de delante mantenía la misma asignación fuera cual fuera el destino (MappingVariesByDestIP: false). La referencia de la CLI de Tailscale lo contrasta con un NAT difícil que cambia la dirección IP del dispositivo según el destino ("a difficult NAT that varies the device's IP address depending on the destination"). La comprobación muestra el NAT en el momento en que se ejecutó, sin ninguna conexión entre dos dispositivos que observar, así que no muestra si se formaría una ruta directa.

Lo que dice Starlink sobre IPv6

La página de ayuda de Starlink What IP address does Starlink provide? dice que Starlink admite IPv6 nativo en todos sus routers, versiones de kit y planes de servicio ("Starlink supports native IPv6 across all Starlink routers, kit versions, and service plans."). También dice que a cada Starlink se le asigna una dirección IPv4 por DHCPv4 y un prefijo IPv6 /56 delegado por DHCPv6-PD ("Each Starlink is allocated one IPv4 address via DHCPv4 and a delegated /56 IPv6 prefix via DHCPv6-PD."). Sobre el tráfico entrante: los clientes que lo necesitan deberían plantearse usar un router de terceros y, si hace falta tráfico IPv4 entrante, un plan de servicio de Starlink con la opción de IPv4 pública ("Customers needing inbound traffic should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option."). Su nota sobre la redirección de puertos, citada más arriba, nombra tanto IPv6 como IPv4. Y, como afirmación general, dice que, a medida que Starlink sigue ampliando y mejorando su servicio global de internet, los usuarios pueden notar cambios como direcciones enrutables públicamente y configuraciones sin CGNAT ("As Starlink continues to expand and upgrades its global internet service, users may experience changes such as publicly routable addresses and non-CGNAT configurations."). Todo se consultó en octubre de 2026.

Son afirmaciones de Starlink, y esta página no prueba ninguna. Aquí no se muestra si una conexión por IPv6 llega a un servidor en casa.

Lo que dice la página de ayuda de Starlink sobre una IP fija

En la página de ayuda de Starlink What IP address does Starlink provide?, el párrafo sobre la opción de IPv4 pública dice que, aunque las IP realmente estáticas no están disponibles, un sistema de reservas mantiene la dirección IPv4 pública y el prefijo IPv6 aunque el sistema se apague o se reinicie, pero que mover el Starlink o las actualizaciones de software pueden cambiar esas direcciones ("Although truly static IPs are not available, a reservation system retains the public IPv4 address and IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses."; consultada en octubre de 2026).

Una dirección que cambia rompe lo que esté ligado a ella: una lista de permitidos, un registro DNS, un cliente remoto configurado con una dirección. Con un sustituto, los visitantes usan algo que no cambia con la dirección de casa. Con un VPS de reenvío, es la IP pública del VPS; la página principal de WireGuard dice que el servidor descubre el extremo de sus pares examinando de dónde vienen los datos correctamente autenticados ("the server discovers the endpoint of its peers by examining from where correctly authenticated data originates") y que, por tanto, hay itinerancia de IP completa en ambos extremos ("Thus, there is full IP roaming on both ends"; consultada en octubre de 2026), algo que esta página no ha probado. Con Cloudflare Tunnel, es el nombre de host público que Cloudflare dirige a tu servicio.

El DNS dinámico mantiene un nombre apuntando a una dirección que cambia. Sin una dirección IPv4 pública en tu router, la única dirección IPv4 pública a la que puede apuntar ese nombre es la del NAT intermedio, que solo deja pasar una conexión si redirige el puerto (RFC 6269, sección 5.2.1, para un NAT de nivel de operador).

Lo que dice la Acceptable Use Policy de Starlink sobre los servidores

La Acceptable Use Policy de Starlink (su política de uso aceptable), en su versión de octubre de 2026, no menciona tener un servidor. Tampoco menciona el alojamiento ni las conexiones entrantes.

La política enumera 13 ejemplos de infracciones. El último es cualquier conducta que SpaceX, a su criterio, determine razonablemente que es un mal uso de los Servicios o del kit de Starlink ("any conduct that SpaceX, in its discretion, reasonably determines to be a misuse of the Services or Starlink Kit"), lo que deja esa decisión a SpaceX. Bajo "EXCESSIVE USE OF NETWORK RESOURCES" (uso excesivo de los recursos de la red), dice que SpaceX se reserva el derecho a hacer una gestión razonable de la red para proteger la red en su conjunto ("SpaceX reserves the right to engage in reasonable network management to protect the overall network").

Quédate con tu línea, o cambia con un plan

Tu comprobación decide cuál es tu caso.

1. Si el paso 1 no mostró una dirección IPv4 pública en tu router y el paso 2 apunta al NAT de tu proveedor, una redirección de puertos en tu router solo llega hoy a internet donde ese NAT también redirige el puerto (RFC 6269, sección 5.2.1). Sin esa redirección por parte de tu proveedor, hoy no tienes redirección de puertos IPv4 entrante, y el cambio no te quita eso. Si el paso 2 apunta a otro router tuyo más cerca de internet, revisa primero ese router.
2. Si solo tus propios dispositivos necesitan llegar a tus servicios, es el caso de la VPN en malla. La documentación de Tailscale lo describe, y esta página no lo ha probado.
3. Si otras personas necesitan llegar a un servidor en casa, planifica el sustituto antes de cambiar: un VPS de reenvío o un túnel saliente, según su documentación y sin probar aquí, o la opción de IPv4 pública de un plan Priority, según las páginas de ayuda de Starlink.
4. Si tienes en casa un servidor de correo que envía correo directamente a otros servidores, quédate con la línea en la que funciona. El correo entre servidores usa el puerto 25 (RFC 6409), y la página de ayuda de Starlink dice que el TCP/25 saliente está bloqueado para todos los clientes ("blocked for all customers"). En la prueba de la página 1, las conexiones salientes por IPv4 al puerto 25 agotaron el tiempo de espera desde un equipo de la red de casa, y no se ve dónde se descartaron. El correo a través de un VPS de reenvío no se prueba aquí.

Aún sin probar aquí

Las cinco vías de entrada: la opción de IPv4 pública de Starlink, un VPS de reenvío, un túnel saliente, una VPN en malla e IPv6 entrante.

Si un reenvío sigue funcionando cuando cambia la dirección de la conexión de casa. La página principal de WireGuard dice que sigue a un par cuya dirección cambia; nada de aquí lo prueba.

El correo enviado a través de un reenvío.

Dónde se descartan las conexiones salientes al puerto 25, algo que la página 1 deja abierto.