¿Sirve Starlink para un homelab? Veredicto de cinco pruebas
En la única conexión doméstica de Starlink probada, los paquetes de 1500 bytes cruzaron por IPv4 y por IPv6 en octubre de 2026, y los tiempos de ida y vuelta por IPv4 tuvieron picos en cuatro segundos fijos de cada minuto en una de dos pruebas de una hora, con 901 de 143 462 pings perdidos entre las dos; las formas de sortear el NAT de nivel de operador (CGNAT), como un túnel que se inicia dentro de tu red, no se prueban aquí. En cambio, no sirve para ofrecer servicios directamente a internet por IPv4 sin una dirección IPv4 pública: desde un VPS, en octubre de 2026, ninguno de los 8 puertos respondió en la dirección IPv4 pública de esa conexión, y una traza desde dentro encaja con CGNAT sin demostrarlo; con CGNAT, una redirección de puertos en tu propio router no puede recibir esas conexiones. Cada resultado sale de una conexión doméstica, detrás de su router de casa, en octubre de 2026; el IPv6 entrante tampoco se prueba aquí.
Lo que necesita un homelab, y lo que encontraron las pruebas
Cada resultado de abajo sale de una de las tres guías del sitio, que dan los comandos, la salida y los límites completos.
| Lo que necesita un homelab | Lo que se probó | Resultado | Hasta dónde llegan los datos | Guía |
|---|---|---|---|---|
| Llegar desde internet a un servidor en casa por IPv4 | Desde un VPS, una conexión TCP a cada uno de los 8 puertos de la dirección IPv4 pública de la conexión de casa, 6 segundos cada una, sin redirección de puertos | no respondió ninguno | no muestra dónde se detuvieron las conexiones | Desde fuera |
| Saber si la dirección IPv4 pública es compartida (CGNAT) | una traza de la ruta de salida desde un equipo de la red de casa | una dirección privada de la red de Starlink apareció antes que la primera pública | el segundo salto no respondió, así que encaja con un CGNAT y no lo demuestra | La traza |
| Abrir conexiones salientes en los puertos de correo y de compartición de archivos | TCP saliente por IPv4 hacia un servidor público de pruebas de puertos, tiempo de espera de 10 segundos | el 25 y el 445 agotaron el tiempo de espera; el 465, el 587, el 80 y el 8080 conectaron | no se sabe dónde se descartaron el 25 y el 445 | Puertos salientes |
| Llevar los paquetes de un túnel | pings de 1500 bytes con DF (no fragmentar) activado hacia tres hosts públicos de prueba, por IPv4 y por IPv6 | todos los pings llegaron a su host y volvieron | no se pudo probar nada mayor; no se ejecutó ningún túnel | Path MTU |
| Una conexión estable para el acceso remoto | pings, cinco por segundo, hacia dos resolutores DNS públicos por familia de direcciones, dos sesiones de una hora | IPv4 tuvo picos en los segundos 12, 27, 42 y 57 de cada minuto en una sesión; 901 de 143 462 pings perdidos entre las dos | lecturas en milisegundos enteros, dos horas en una conexión | Picos de ping |
| Llegar a un servidor en casa por IPv6 | no probado | Aún sin probar |
Desde fuera, nada respondió en la dirección IPv4 pública
En octubre de 2026, un script en un VPS intentó una conexión TCP a cada uno de los 8 puertos de la dirección IPv4 pública de la conexión de casa, entre ellos el 22, el 80 y el 443, y esperó 6 segundos por cada uno. Ninguno respondió. Antes, el script se comprobó a sí mismo contra destinos con respuestas conocidas, y para la prueba no se configuró ninguna redirección de puertos.
Desde dentro, una traza desde un equipo de la red de casa pasó por una dirección privada de la red de Starlink antes que por la primera pública. Eso encaja con un NAT de nivel de operador (CGNAT), que RFC 6888 describe como una función de la red del proveedor que comparte una dirección IPv4 entre varios suscriptores (sección 2, consultado en octubre de 2026). El segundo salto no respondió, así que la traza no lo demuestra.
Los suscriptores tienen poco o ningún control sobre un NAT de nivel de operador ("limited or no control"), dice el RFC, así que con CGNAT una redirección de puertos en tu propio router no puede recibir las conexiones enviadas a la dirección IPv4 pública. Sin embargo, no se sabe dónde se detuvieron las conexiones de la prueba desde fuera, y un CGNAT y un router de casa que descarta las conexiones que nadie de dentro pidió se verían igual desde el VPS. La página 1 trae completas la prueba desde fuera y la traza.
Los puertos salientes 25 y 445 agotaron el tiempo de espera
Desde un equipo de la red de casa, las conexiones TCP por IPv4 hacia un servidor público preparado para probar puertos agotaron el tiempo de espera en el puerto 25 (SMTP) y en el 445 (SMB), cada una tras 10.3 segundos. Los puertos 465 y 587, los de envío de correo, conectaron, y también el 80 y el 8080.
No se sabe dónde se descartaron el 25 y el 445: en el router de casa, en la red de Starlink o en la propia red del servidor de prueba. El servidor de prueba usa el puerto 25 para uno de sus propios servicios, así que ese puerto no es la misma prueba que los demás. Los detalles están en la sección de puertos salientes de la página 1.
Los paquetes de 1500 bytes cruzaron por IPv4 y por IPv6
En dos lecturas separadas por unos minutos en octubre de 2026, pings de 1500 bytes con DF (no fragmentar) activado fueron desde un equipo conectado por cable a la red de casa hasta tres hosts públicos de prueba y volvieron, por IPv4 y por IPv6, y ningún salto informó de una MTU menor. No se pudo probar nada mayor, porque la propia MTU de enlace del equipo es de 1500 bytes.
No se ejecutó ningún túnel. Un túnel añade sus propias cabeceras a cada paquete: el driver de WireGuard para Linux cuenta 80 bytes de cabeceras y empieza una interfaz nueva en 1420 bytes (device.c, Linux 6.18, consultado en octubre de 2026). La sección de túneles de la guía Path MTU da esa cuenta y la de Tailscale, y nada de ello se probó en esta conexión.
En una de dos horas, los tiempos de ida y vuelta por IPv4 tuvieron picos en cuatro segundos fijos
Los pings salieron, cinco por segundo, desde un equipo conectado por cable a la red de casa hacia dos resolutores DNS públicos por familia de direcciones, durante una hora cada vez, en dos sesiones de octubre de 2026. En la segunda sesión, los tiempos de ida y vuelta por IPv4 cambiaron más, y tuvieron picos, en los segundos 12, 27, 42 y 57 de cada minuto. En la primera sesión, y por IPv6, la regla de la prueba no encontró ese patrón.
De 143 462 pings en las dos sesiones, 901 quedaron sin respuesta. Los enviados en esos cuatro segundos se perdieron 1.9 veces más a menudo que los enviados en los demás segundos.
Los investigadores que midieron Starlink desde varias ubicaciones informan de cambios en esos mismos cuatro segundos, y la explicación de esos cambios es suya; la guía de latencia los cita. Los tiempos de ida y vuelta se leyeron en milisegundos enteros, así que un escalón de uno o dos milisegundos puede pasar inadvertido, y la prueba abarca una conexión en dos horas. No se probó ningún juego, llamada ni escritorio remoto.
Formas de sortear el CGNAT, sin probar aquí
Las formas de sortear el CGNAT, cada una según su propia documentación y ninguna probada aquí, están en la página sobre dejar un proveedor por cable. La Acceptable Use Policy de Starlink para Estados Unidos (su política de uso aceptable), en su versión de octubre de 2026, no menciona ejecutar un servidor. Un reenvío TCP a través de una VM en la nube está probado en la página del servidor de juegos.
Las ofertas tienen su propia página
Las ofertas de Starlink y el crédito por referido de USD 100 en Estados Unidos están en la página de ofertas y créditos. Si puedes instalar Starlink tú mismo se explica en la página sobre la instalación, y si puedes cambiar de plan más adelante, en la página sobre el cambio de plan.
Si puedes tener Starlink en un apartamento se explica en la página sobre los apartamentos.
Lo que estas pruebas no muestran
El IPv6 entrante. Ninguna prueba intentó llegar a un servidor en casa por IPv6.
Cualquier forma de sortear el CGNAT, como un túnel que se inicia dentro de tu red.
La velocidad de subida y el uso de datos.
El clima, los cortes de luz y la disponibilidad a lo largo de semanas.
Otras conexiones, otros routers y el modo bypass del router de Starlink.
Fuentes
- RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs), IETF, consultado en
- Cloudflare Tunnel, Cloudflare, consultado en
- Acceptable Use Policy (US), Starlink, consultado en
- drivers/net/wireguard/device.c, Linux 6.18, Linux kernel, consultado en
- Starlink tiene un programa de recomendaciones?, Starlink, consultado en
Registro de pruebas
Guías relacionadas
- ¿Puedes alojar un servidor con Starlink sin una IP pública IPv4?
No directamente por IPv4: sin una dirección IPv4 pública, las conexiones desde internet llegan al NAT de tu proveedor, y una redirección de puertos en tu propio router no llega hasta él.
- Starlink MTU size: la path MTU medida fue de 1500 bytes
La MTU de la ruta desde una conexión doméstica de Starlink fue de 1500 bytes tanto por IPv4 como por IPv6, en todas las rutas probadas.
- Starlink ping spikes: picos de latencia segundo a segundo en casa
En una de dos sesiones de una hora, los tiempos de ida y vuelta por IPv4 cambiaron más, y tuvieron picos, en los segundos 12, 27, 42 y 57 de cada minuto; en la otra sesión, y por IPv6, la regla de la prueba no encontró ese patrón.