Servidor de juegos con Starlink y un VPS gratis de reenvío

Cómo llegan los jugadores a un servidor en casa sin abrir puertos

Si tu router no tiene una dirección IPv4 pública, las conexiones de los jugadores desde internet llegan primero al NAT de tu proveedor, y una redirección de puertos en tu propio router solo las recibe si ese NAT también redirige el puerto. La guía para alojar un servidor sin una dirección IPv4 pública muestra cómo se ve eso desde una conexión doméstica de Starlink.

La página de ayuda de Starlink What IP address does Starlink provide? dice que su configuración IPv4 predeterminada usa un NAT de nivel de operador (CGNAT), y que esa política "default" (predeterminada) no permite tráfico entrante ("does not allow inbound traffic"; consultada en octubre de 2026). Una dirección IPv4 pública en la propia línea es una opción de los planes Priority, dice la página de ayuda de Starlink sobre cómo poner una IP pública.

Un reenvío le da la vuelta a la conexión. El camino tiene cuatro pasos:

1. El juego de un jugador se conecta a la dirección IPv4 pública de una VM en la nube, la VM de reenvío, en el puerto del juego.
2. Un programa de reenvío en la VM acepta la conexión y abre su propia conexión a la dirección del servidor de juegos en una tailnet, la red privada a la que se unen tus máquinas con el cliente de Tailscale.
3. La tailnet lleva esa conexión a casa, directamente entre las dos máquinas o a través de un servidor de retransmisión DERP. La página de Tailscale sobre los tipos de conexión dice que toda conexión empieza retransmitida a través de DERP y pasa a ser directa donde puede, y que algunas redes, que llama NAT difícil (hard NAT), impiden la ruta directa (consultada en octubre de 2026).
4. El servidor de juegos responde por el mismo camino de vuelta.

Los jugadores solo se conectan a la dirección pública de la VM de reenvío, y es el reenvío, no el jugador, quien abre la conexión hacia tu casa.

Minecraft Java respondió a 30 de 30 pings de la lista de servidores a través del reenvío

Alojo así un servidor de Minecraft Java Edition, en Docker, en casa, con una conexión de Starlink. Los jugadores se conectan a una VM gratuita en la nube con una dirección IPv4 pública, donde socat reenvía cada conexión TCP del puerto 25565 por mi tailnet de Headscale, que funciona sobre WireGuard, hasta el servidor de juegos. Configuré la política de la tailnet para que la VM de reenvío pueda llegar a ese único puerto de casa y a nada más.

Una lectura en el servidor de juegos en octubre de 2026 encontró la imagen itzg/minecraft-server con online-mode, la whitelist (lista blanca) y enforce-whitelist activados. Docker le publica TCP 25565, no UDP.

La prueba se hizo en octubre de 2026 desde un equipo conectado por cable a la red de casa, en tres sesiones de 10 rondas cada una, todas el mismo día, cada sonda al menos 2 s después de la anterior. Cada ronda hizo una conexión TCP simple a la dirección pública de la VM de reenvío en el puerto 25565 y después un ping de la lista de servidores a través del reenvío: la solicitud de estado que envía un cliente de Minecraft para mostrar un servidor en su lista, seguida de un ping y un pong en la misma conexión. Nunca inicia sesión. Antes de cada sesión se comprobó la ruta hacia la dirección de la VM: salía por la ruta predeterminada de la conexión de casa, no por la tailnet. En todas las sesiones, la respuesta de estado a través del reenvío coincidió con la leída directamente del servidor de juegos por la tailnet, así que el reenvío llevaba a este servidor.

El único ping directo que falló, y dos que solo conectaron después de retransmitir su primer paquete, iban por la ruta directa de la tailnet dentro de la red de casa. El reenvío respondió con normalidad en esas mismas rondas. No se examinó por qué se atascó la ruta directa, ya que solo era un control.

Los pings de la prueba no dejaron ninguna línea en el registro del servidor de juegos. Las líneas de jugadores que ya había en el registro, de inicios de sesión anteriores, llevan todas una misma dirección privada de la red que Docker creó en esa máquina: nunca la dirección de la VM de reenvío en la tailnet y nunca la dirección propia de un jugador. El registro no muestra por dónde entraron esos jugadores.

El tramo del reenvío, de la VM al servidor de juegos y vuelta, fue de unos 20 ms (una estimación)

Un viaje de ida y vuelta a través del reenvío cubre el tramo del jugador a la VM de reenvío y el tramo del reenvío: de la VM por la tailnet al servidor de juegos y vuelta, con lo que tarda el propio reenvío en pasar la conexión. El tramo del reenvío fue de unos 20 ms, como estimación. Es la mediana de 27 rondas, y las medianas de las tres sesiones fueron de 17.9 a 23.6 ms. La comparación de internet satelital pone esta estimación junto al viaje de ida y vuelta mínimo a través de un satélite geoestacionario.

Para cada ronda, la estimación toma el tiempo entre el ping y el pong a través del reenvío, le resta el tiempo de ida y vuelta (RTT) de esa misma conexión hasta la VM, medido un momento antes, y le resta el tiempo de respuesta del propio servidor de juegos, medido directamente por la tailnet. Las partes no se midieron en el mismo instante, y el RTT de la conexión de casa cambia de un segundo a otro, como muestra la guía sobre los picos de latencia. Se dejaron fuera tres rondas porque su conexión directa, en la que se basa la estimación, falló o necesitó retransmitir un paquete.

El equipo de prueba y el servidor de juegos comparten la conexión de casa, así que cada sonda a través del reenvío salió de casa por Starlink hacia la VM y volvió a entrar por Starlink dentro de la tailnet. Para un jugador en otro lugar, su propio tramo hasta la VM sustituye al del equipo de prueba, y el tramo del reenvío se mantiene.

Un reenvío TCP lleva los juegos TCP; los juegos UDP necesitan un reenvío UDP

Un reenvío TCP solo lleva TCP. La documentación o la wiki de cada juego dice qué protocolo usa su servidor (consultadas en octubre de 2026):

Las filas salen de las páginas de la Minecraft Wiki sobre server.properties y Bedrock Dedicated Server, una wiki de la comunidad; de la página Server de la Official Terraria Wiki; de la página Multiplayer de la Factorio Wiki, que dice que Factorio solo usa UDP ("Factorio uses UDP only"); de la página Requirements de la Palworld Server Guide de Pocketpair; de Dedicated server setup en la ARK Official Community Wiki; y de la página Dedicated servers de la Official Satisfactory Wiki. Todas permiten cambiar el puerto predeterminado. La página de Terraria dice que su servidor funciona en el puerto TCP 7777 por defecto ("runs on TCP port 7777 by default"), y su nota para proveedores en la nube dice que se abra el 7777 en TCP y UDP. La de Satisfactory dice que por ahora no se admite la redirección de puertos para el puerto estándar ("Port redirection is not supported at the moment for the standard port"), así que un reenvío para ese juego mantiene el número de ese puerto, 7777 por defecto, igual en los dos lados. Su puerto de mensajería fiable, TCP 8888 por defecto, se puede reasignar ("can be remapped") con el parámetro de línea de comandos -ExternalReliablePort=, dice la misma página.

En la dirección del reenvío probado, un paquete UDP, el ping de descubrimiento que envía un cliente de Bedrock para encontrar servidores, no obtuvo respuesta en 5 s en el puerto 25565. El mismo paquete al puerto 25566, que no sirve nada, obtuvo el mismo silencio, mientras que un ping de la lista de servidores por TCP en el 25565 respondió en el mismo minuto. En el servidor de juegos, Docker publica el 25565 solo para TCP.

Las VM gratuitas en la nube traen condiciones que conviene revisar antes

El reenvío necesita una VM con una dirección IPv4 pública que siga encendida mientras la gente juega. Varios proveedores de nube publican ofertas gratuitas: el AWS Free Tier, los servicios gratuitos de Azure, las funciones gratuitas de Google Cloud y el Oracle Cloud Free Tier (páginas consultadas en octubre de 2026). Las ofertas gratuitas cambian, así que lee la página actual del proveedor antes de montar nada sobre una. Busca:

• si la VM sigue siendo gratuita sin fecha de fin, o solo durante un periodo de prueba;
• si la VM gratuita incluye una dirección IPv4 pública, y si esa dirección se factura aparte;
• cuántos datos salientes son gratis cada mes;
• si el proveedor puede recuperar una VM que considere inactiva;
• qué pide el registro, como una tarjeta de pago.

Un reenvío pasa por la VM todo el tráfico de cada jugador, así que sus datos salientes crecen con los jugadores y el tiempo de juego.

Móntalo con un puerto abierto, una regla de la tailnet y el inicio de sesión del propio juego

Estos pasos usan Minecraft Java Edition. Para otro juego TCP, usa su puerto de la tabla de arriba.

1. En casa, ejecuta el servidor de juegos en Docker con las comprobaciones de inicio de sesión del propio juego activadas. La imagen itzg/minecraft-server toma su configuración como variables de entorno, según su documentación (consultada en octubre de 2026):

   docker run -d -it --name mc -p 25565:25565 \
     -e EULA=TRUE -e ONLINE_MODE=TRUE \
     -e WHITELIST=your-friend-1,your-friend-2 \
     -e ENFORCE_WHITELIST=true \
     -v "$PWD/data:/data" itzg/minecraft-server

   • -p 25565:25565 publica el puerto para TCP. La página de Docker sobre la publicación de puertos asigna un puerto a TCP salvo que termine en /udp (consultada en octubre de 2026).
   • EULA=TRUE acepta el contrato de licencia de usuario final de Minecraft, que la documentación de la imagen dice que se incluya siempre ("always include").
   • ONLINE_MODE=TRUE mantiene activado online-mode, que la Minecraft Wiki describe como la opción de dejar entrar solo a los jugadores verificados con la base de datos de cuentas de Minecraft ("Whether to only allow players verified with the Minecraft account database to join"). Está activado por defecto.
   • WHITELIST activa la whitelist (lista blanca) y enumera quién puede entrar. Pon los nombres de perfil de Java Edition de tus jugadores en lugar de your-friend-1,your-friend-2; la documentación de la imagen dice que se usen esos, no los gamertags de Xbox ("not Xbox gamertags").
   • ENFORCE_WHITELIST=true activa enforce-whitelist. Con él activado, dice la Minecraft Wiki, los jugadores que no están en la whitelist son expulsados del servidor cuando este vuelve a cargar el archivo de la whitelist ("players not present on the whitelist get kicked from the server after the server reloads the whitelist file").
   • -v "$PWD/data:/data" guarda el mundo en una carpeta data donde ejecutes el comando, ya que la imagen guarda los datos del servidor en el /data del contenedor.

   Otros juegos tienen sus propias comprobaciones de acceso, como la contraseña del servidor en el comando de inicio de ARK, en la misma página de la wiki que sus puertos.

2. Consigue una VM en la nube con una dirección IPv4 pública (qué revisar en una oferta gratuita). El reenvío solo necesita en ella el cliente de Tailscale y socat.

3. Une a una misma tailnet la máquina del servidor de juegos y la VM de reenvío. Con Headscale, que esta página no configura, cada máquina ejecuta tailscale up --login-server con la dirección de tu servidor de Headscale, y tú la apruebas en el servidor de Headscale (los métodos de registro de Headscale, consultados en octubre de 2026). La guía sobre dejar un proveedor por cable cubre hasta dónde llega una tailnet por sí sola.

4. Permite que la VM de reenvío llegue al puerto del juego y a nada más. La página de Headscale sobre las políticas dice que, por defecto, no se carga ninguna política, lo que significa que Headscale permite todo el tráfico entre nodos ("no policy is loaded which means that Headscale allows all traffic between nodes"), que lee el archivo indicado en el ajuste policy.path de su configuración y que hay que recargarla para que tome los cambios ("needs to be reloaded to pick up changes"; consultada en octubre de 2026). Este archivo de política permite una sola cosa: que la VM de reenvío abra conexiones TCP al puerto 25565 del servidor de juegos. Con Headscale 0.29.7, en octubre de 2026, esta política se cargó, headscale nodes tag aplicó las dos etiquetas y rechazó una etiqueta que la política no define, y las reglas que Headscale construyó a partir de ella solo permitían TCP al puerto 25565 del servidor de juegos, desde el reenvío; no había ningún cliente conectado para esa comprobación.

   {
     "tagOwners": {
       "tag:game-relay": [],
       "tag:game-server": []
     },
     "acls": [
       {
         "action": "accept",
         "src": ["tag:game-relay"],
         "proto": "tcp",
         "dst": ["tag:game-server:25565"]
       }
     ]
   }

   La referencia de sintaxis de las políticas de Tailscale, cuyo formato de archivo usa Headscale, dice que las reglas de acceso deniegan el acceso por defecto ("deny access by default"). Así que, una vez cargada esta política, se bloquea todo lo que no permite: si otros dispositivos de tu tailnet necesitan llegar unos a otros, añade reglas para ellos. Sin "proto": "tcp", dice la misma referencia, una regla se aplica a todo el tráfico TCP y UDP ("applies to all TCP and UDP traffic"). En la sintaxis de Tailscale, una lista vacía en tagOwners es una forma abreviada de indicar a los administradores de la tailnet; en Headscale, el administrador pone las etiquetas con el comando headscale nodes tag del paso siguiente. La página de Headscale sobre las políticas recomienda los grants, la sintaxis de reglas más nueva de Tailscale, y también admite reglas como esta.

5. Etiqueta las dos máquinas en el servidor de Headscale, con los ID que muestra headscale nodes list para ellas en lugar de 1 y 2, como describe la página de Headscale sobre las etiquetas (consultada en octubre de 2026):

   headscale nodes list
   headscale nodes tag -i 1 -t tag:game-server
   headscale nodes tag -i 2 -t tag:game-relay

6. En la VM de reenvío, arranca el reenvío. game-server representa el nombre o la dirección del servidor de juegos en la tailnet:

   socat TCP4-LISTEN:25565,fork,reuseaddr \
     TCP4:game-server:25565

   El manual de socat llama a una dirección TCP4-LISTEN con una dirección TCP4 un reenviador de puertos TCP sencillo ("a simple TCP port forwarder"). Con fork, socat gestiona su canal en un proceso hijo ("handles its channel in a child process") para cada conexión, así que varios jugadores pueden conectarse a la vez. reuseaddr permite que otros sockets se vinculen a una dirección aunque socat ya esté usando partes de ella, por ejemplo el puerto local ("Allows other sockets to bind to an address even if parts of it (e.g. the local port) are already in use by socat"; consultado en octubre de 2026). Ejecuta el comando con el gestor de servicios de la VM para que vuelva a arrancar después de un reinicio.

7. Abre un puerto. En el cortafuegos del proveedor para la VM, y en el propio cortafuegos de la VM si tiene uno, permite TCP 25565 desde cualquier lugar. Mantén cerrados todos los demás puertos, salvo el que uses para iniciar sesión en la VM si lo haces por internet.

8. Da a los jugadores la dirección IPv4 pública de la VM de reenvío, como 203.0.113.10 en los ejemplos de esta página, o un nombre DNS que apuntes a ella, como mc.example.com.

Tres formas de reenviar un juego UDP, según su documentación

UDP no tiene una conexión que un reenvío pueda aceptar. El manual de socat dice que con UDP no se establece una conexión real y los datos tienen que llegar primero desde el otro extremo ("no real connection is established; data has to arrive from the peer first"), y que UDP no especifica ninguna condición de fin de archivo ("no end-of-file condition is specified in UDP"). Así que un reenvío UDP lleva la cuenta de cada jugador y tiene que soltarlo tras un tiempo sin datos.

En cada método de abajo, el servidor de juegos publica su puerto para UDP (-p 34197:34197/udp en Docker), y la regla de la política lleva "proto": "udp" y el puerto del juego. El puerto de Factorio, 34197, es el ejemplo.

socat en modo UDP

En la VM de reenvío:

socat -T 60 UDP4-LISTEN:34197,fork,reuseaddr \
  UDP4:game-server:34197

-T es el tiempo máximo de inactividad total de socat ("Total inactivity timeout"), que el manual considera útil con protocolos como UDP que no pueden transmitir EOF ("Useful with protocols like UDP that cannot transfer EOF"). Aquí termina el proceso hijo de un jugador tras 60 segundos sin datos. Hasta socat 1.8.0.0, -T 0 significaba sin tiempo máximo; desde 1.8.0.1 significa 0, dice el manual, así que dale un número.

NAT de destino en el kernel de la VM

La página de la wiki de nftables sobre NAT muestra las dos reglas que hacen falta: una regla dnat to en una cadena prerouting de tipo nat, que envía los paquetes del puerto del juego a la dirección del servidor de juegos en la tailnet, y masquerade en una cadena postrouting, donde la dirección de origen se pone automágicamente en la dirección de la interfaz de salida ("the source address is automagically set to the address of the output interface"), aquí la dirección de la VM en la tailnet, para que el servidor de juegos responda a la VM. El kernel también debe reenviar paquetes entre sus interfaces, que es el ajuste net.ipv4.ip_forward: reenviar paquetes entre interfaces ("Forward Packets between interfaces"), según la documentación del kernel.

El módulo stream de nginx

En el módulo stream core de nginx, listen 34197 udp reuseport; en un bloque server abre un socket para trabajar con datagramas ("for working with datagrams"); la página dice que también debe indicarse reuseport ("should also be specified") para que los paquetes de una misma dirección y puerto se queden en una sesión. El módulo stream proxy los pasa con proxy_pass al servidor de juegos, y proxy_timeout, 10 minutos por defecto, cierra una sesión cuando no se transmiten datos en ese tiempo ("no data is transmitted within this time"). La página del módulo core dice que no se compila por defecto ("is not built by default") y que necesita la opción de compilación --with-stream, así que comprueba que tu nginx lo tenga.

Bedrock Edition puede necesitar más de un puerto. La copia en la Minecraft Wiki del archivo server.properties que acompaña a Bedrock Dedicated Server 1.26.60.6 pone transport=nethernet y server-udp-ports=19132, un ajuste que configura los puertos de transporte UDP de los clientes ("Configures UDP client transport ports"): es decir, un único puerto UDP compartido por todos los clientes ("Single UDP port shared by all clients"). Si no está puesto, dice el archivo, los puertos UDP se asignan del rango de puertos efímeros del sistema operativo ("UDP ports are allocated from the operating system's ephemeral port range"), y un reenvío tendría que llevar también esos puertos. Con ese transporte, se ignora el ajuste de puerto IPv6 del archivo e IPv6 también usa el 19132. Esta página no ha probado Bedrock a través de un reenvío.

Los túneles gestionados se ahorran la VM, según sus propias páginas

Ninguno se probó aquí. Cada uno gestiona por ti el extremo público, así que no hay ninguna VM que configurar ni actualizar; a cambio, su red lleva el tráfico de tus jugadores. Todas las páginas se consultaron en octubre de 2026.

playit.gg se describe como un proxy global que te permite alojar un servidor sin redirección de puertos ("a global proxy that lets you host a server without port forwarding"), con un agente en tu máquina: solo tú ejecutas el agente, y tus jugadores simplemente se conectan ("Only you run the agent, your players just connect."). Su página principal nombra un nivel gratuito y un plan Premium de pago; su lista de juegos pone Minecraft Java y Bedrock, Palworld, Terraria, Factorio y una entrada "UDP" a secas en "Free" (gratis), y las entradas "TCP" y "TCP+UDP" a secas, con algunos otros juegos, en "Requires Playit Premium" (requiere Playit Premium).

La página de precios de ngrok dice que en su plan Free los endpoints TCP también necesitan una tarjeta de crédito verificada, y que ngrok no hace ningún cargo en ella ("TCP endpoints also need a verified credit card, and ngrok doesn't charge it").

Tailscale Funnel solo puede escuchar en los puertos 443, 8443 y 10000 ("can only listen on ports 443, 8443, and 10000"), y solo funciona con conexiones cifradas con TLS ("only works over TLS-encrypted connections"). El puerto predeterminado de Minecraft Java Edition, TCP 25565, no es uno de esos puertos. En la página de funciones de Headscale, Funnel es uno de los elementos sin marcar.

Cloudflare Tunnel necesita el cliente de Cloudflare en la máquina de cada jugador para cualquier cosa que no sea un servicio web, como cita la guía sobre dejar un proveedor por cable. La página de Cloudflare Spectrum dice que las aplicaciones TCP/UDP personalizadas requieren un plan Enterprise con Spectrum como complemento de pago ("Custom TCP/UDP applications require an Enterprise plan with Spectrum as a paid add-on"; actualizada por última vez en abril de 2026). Su tabla de protocolos por plan (actualizada por última vez en agosto de 2026) también incluye Minecraft, una sola aplicación, en los planes Pro y Business, donde Spectrum es un complemento de pago.

Una VPN en malla a la que se une cada jugador no necesita ningún reenvío, pero cada jugador instala el cliente y se une a tu tailnet (hasta dónde llega una VPN en malla).

Aún sin probar aquí

• Un jugador en otra red. Todas las sondas salieron de la misma conexión de casa que usa el servidor de juegos.
• El juego real. Ninguna sonda inició sesión ni jugó, así que el RTT que muestra el juego, varios jugadores a la vez y una sesión completa quedan sin probar.
• UDP a través de cualquier reenvío, Bedrock Edition y todos los juegos salvo Minecraft Java Edition.
• El lado de la VM de reenvío. Desde la VM no se comprobó si su ruta a casa fue directa o pasó por un servidor de retransmisión DERP, su carga, la configuración de su cortafuegos ni si la política de la tailnet le impide llegar a cualquier otra cosa de casa.
• Lo que registra el servidor de juegos para un jugador que llegó a través del reenvío. Las líneas de jugadores del registro vienen de inicios de sesión anteriores cuya ruta no se conoce.
• Una VM en otra región, otros días y horas, los túneles gestionados y ejecutar el juego en la propia VM.

Consulta cómo encajan las pruebas de casa en un homelab.