Héberger un serveur de jeu sur Starlink avec un relais sur un VPS gratuit

Comment les joueurs atteignent un serveur à la maison sans ouvrir de port

Si votre routeur n’a pas d’adresse IPv4 publique, les connexions des joueurs venues d’Internet arrivent d’abord sur le NAT de votre opérateur, et une redirection de port (port forwarding) sur votre propre routeur ne les reçoit que si ce NAT redirige lui aussi le port. Le guide pour héberger un serveur sans adresse IPv4 publique montre à quoi cela ressemble depuis une connexion Starlink à la maison.

La page d’aide de Starlink « What IP address does Starlink provide? » (quelle adresse IP Starlink fournit-il ?) indique que sa configuration IPv4 par défaut utilise un NAT au niveau de l’opérateur (CGNAT), et que cette politique « default » (par défaut) « does not allow inbound traffic » (n’autorise pas le trafic entrant ; consultée en octobre 2026). Une adresse IPv4 publique sur la ligne elle-même est une option des forfaits Priority, selon la page d’aide de Starlink sur le passage à une IP publique.

Un relais inverse le sens de la connexion. Le chemin compte quatre étapes :

1. Le jeu d’un joueur se connecte à l’adresse IPv4 publique d’une VM dans le cloud, la VM relais, sur le port du jeu.
2. Un programme relais sur la VM accepte la connexion et ouvre sa propre connexion vers l’adresse du serveur de jeu sur un tailnet, le réseau privé que vos machines rejoignent avec le client de Tailscale.
3. Le tailnet transporte cette connexion jusqu’à la maison, directement entre les deux machines ou par un serveur relais DERP. La page de Tailscale sur les types de connexion indique que toute connexion commence relayée par DERP et passe en direct quand elle le peut, et que certains réseaux, qu’elle appelle hard NAT, empêchent le chemin direct (consultée en octobre 2026).
4. Le serveur de jeu répond par le même chemin, en sens inverse.

Les joueurs ne se connectent qu’à l’adresse publique de la VM relais, et c’est le relais, pas le joueur, qui ouvre la connexion vers votre maison.

À travers le relais, Minecraft Java a répondu à 30 sur 30 pings de liste de serveurs

J’héberge ainsi un serveur Minecraft Java Edition, dans Docker, à la maison sur une connexion Starlink. Les joueurs se connectent à une VM gratuite dans le cloud qui a une adresse IPv4 publique, où socat relaie chaque connexion TCP sur le port 25565, par mon tailnet Headscale, qui tourne sur WireGuard, jusqu’au serveur de jeu. J’ai réglé la politique du tailnet pour que la VM relais puisse atteindre ce seul port à la maison, et rien d’autre.

Une lecture sur le serveur de jeu en octobre 2026 a trouvé l’image itzg/minecraft-server avec online-mode, la liste blanche (whitelist) et enforce-whitelist tous activés. Docker publie vers elle TCP 25565, pas UDP.

Le test a tourné en octobre 2026 depuis un ordinateur relié par câble au réseau domestique, en trois séances de 10 tours chacune, toutes le même jour, chaque sonde au moins 2 s après la précédente. Chaque tour faisait une simple connexion TCP vers l’adresse publique de la VM relais sur le port 25565, puis un ping de liste de serveurs à travers le relais : la requête d’état qu’envoie un client Minecraft pour afficher un serveur dans sa liste, suivie d’un ping et d’un pong sur la même connexion. Il n’ouvre jamais de session. Avant chaque séance, la route vers l’adresse de la VM a été vérifiée : elle sortait par la route par défaut de la connexion de la maison, pas par le tailnet. Dans chaque séance, la réponse d’état à travers le relais correspondait à celle lue directement sur le serveur de jeu par le tailnet ; le relais menait donc bien à ce serveur.

Le seul ping direct qui a échoué, et deux qui ne se sont connectés qu’après le renvoi de leur premier paquet, passaient par le chemin direct du tailnet à l’intérieur du réseau domestique. Le relais a répondu normalement dans les mêmes tours. La raison du blocage du chemin direct n’a pas été examinée, puisque ce n’était qu’un contrôle.

Les pings du test n’ont laissé aucune ligne dans le journal du serveur de jeu. Les lignes de joueurs déjà présentes dans le journal, issues de connexions antérieures, portent toutes une même adresse privée, du réseau que Docker a mis en place sur cette machine : jamais l’adresse de la VM relais sur le tailnet, ni l’adresse propre d’un joueur. Le journal ne montre pas par où ces joueurs sont arrivés.

Le tronçon du relais, de la VM au serveur de jeu et retour, a pris environ 20 ms (une estimation)

Un aller-retour à travers le relais couvre le tronçon du joueur à la VM relais et le tronçon du relais : de la VM, par le tailnet, jusqu’au serveur de jeu et retour, avec le transfert propre au relais. Le tronçon du relais a pris environ 20 ms, selon une estimation. C’est la médiane de 27 tours, et les médianes des trois séances allaient de 17,9 à 23,6 ms. La comparaison des services d’Internet par satellite met cette estimation à côté de l’aller-retour minimal par un satellite géostationnaire.

Pour chaque tour, l’estimation prend le temps du ping au pong à travers le relais, moins l’aller-retour de cette même connexion jusqu’à la VM, mesuré un instant avant, et moins le temps de réponse propre du serveur de jeu, mesuré directement par le tailnet. Les parties n’ont pas été mesurées au même instant, et l’aller-retour de la connexion de la maison change d’une seconde à l’autre, comme le montre le guide sur la latence. Trois tours ont été écartés parce que leur connexion directe, sur laquelle repose l’estimation, a échoué ou a dû renvoyer un paquet.

L’ordinateur de test et le serveur de jeu partagent la connexion de la maison ; chaque sonde à travers le relais est donc sortie de la maison par Starlink jusqu’à la VM et revenue par Starlink à l’intérieur du tailnet. Pour un joueur ailleurs, son propre tronçon jusqu’à la VM remplace celui de l’ordinateur de test, et le tronçon du relais reste le même.

Un relais TCP transporte les jeux en TCP ; les jeux en UDP ont besoin d’un relais UDP

Un relais TCP ne transporte que du TCP. La documentation ou le wiki de chaque jeu indique le protocole qu’utilise son serveur (consultés en octobre 2026) :

Les lignes viennent des pages du Minecraft Wiki sur server.properties et Bedrock Dedicated Server, un wiki communautaire ; de la page Server de l’Official Terraria Wiki ; de la page Multiplayer du Factorio Wiki, qui indique « Factorio uses UDP only » (Factorio n’utilise que l’UDP) ; de la page Requirements du Palworld Server Guide de Pocketpair ; de la page Dedicated server setup de l’ARK Official Community Wiki ; et de la page Dedicated servers de l’Official Satisfactory Wiki. Chacun permet de changer le port par défaut. La page de Terraria indique que son serveur « runs on TCP port 7777 by default » (tourne par défaut sur le port TCP 7777), et sa note pour les fournisseurs de cloud dit d’ouvrir 7777 en TCP et en UDP. Celle de Satisfactory indique « Port redirection is not supported at the moment for the standard port » (la redirection de port n’est pas prise en charge pour le moment pour le port standard) ; un relais garde donc là le numéro de ce port, 7777 par défaut, le même des deux côtés. Son port de messagerie fiable, TCP 8888 par défaut, « can be remapped » (peut être réaffecté) avec le paramètre de ligne de commande -ExternalReliablePort=, indique la même page.

À l’adresse du relais testé, un paquet UDP, le ping de découverte qu’envoie un client Bedrock pour trouver des serveurs, n’a reçu aucune réponse en 5 s sur le port 25565. Le même paquet vers le port 25566, que rien ne sert, a rencontré le même silence, alors qu’un ping de liste de serveurs en TCP sur 25565 a répondu dans la même minute. Sur le serveur de jeu, Docker publie 25565 pour TCP seulement.

Les VM gratuites dans le cloud ont des conditions à vérifier d’abord

Le relais a besoin d’une VM avec une adresse IPv4 publique qui reste en marche pendant que les gens jouent. Plusieurs fournisseurs de cloud publient des offres gratuites : l’AWS Free Tier, les services gratuits d’Azure, les fonctionnalités gratuites de Google Cloud et l’Oracle Cloud Free Tier (pages consultées en octobre 2026). Les offres gratuites changent, alors lisez la page actuelle du fournisseur avant de bâtir sur l’une d’elles. Vérifiez :

• si la VM reste gratuite sans date de fin, ou seulement pendant une période d’essai ;
• si la VM gratuite comprend une adresse IPv4 publique, et si cette adresse est facturée à part ;
• quelle quantité de données sortantes est gratuite chaque mois ;
• si le fournisseur peut reprendre une VM qu’il juge inactive ;
• ce que demande l’inscription, comme une carte de paiement.

Un relais fait passer le trafic de chaque joueur par la VM ; ses données sortantes augmentent donc avec le nombre de joueurs et le temps de jeu.

Le monter avec un port ouvert, une règle de tailnet et les contrôles de connexion du jeu

Ces étapes utilisent Minecraft Java Edition. Pour un autre jeu en TCP, utilisez son port, d’après le tableau ci-dessus.

1. À la maison, lancez le serveur de jeu dans Docker avec les contrôles de connexion du jeu activés. L’image itzg/minecraft-server prend ses réglages sous forme de variables d’environnement, selon sa documentation (consultée en octobre 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 publie le port en TCP. La page de Docker sur la publication de ports associe un port au TCP sauf s’il se termine par /udp (consultée en octobre 2026).
   • EULA=TRUE accepte le contrat de licence utilisateur final de Minecraft, que la documentation de l’image dit « always include », c’est-à-dire de toujours inclure.
   • ONLINE_MODE=TRUE garde online-mode activé, que le Minecraft Wiki décrit comme « Whether to only allow players verified with the Minecraft account database to join » (s’il faut n’autoriser à rejoindre que les joueurs vérifiés auprès de la base de comptes Minecraft). Il est activé par défaut.
   • WHITELIST active la liste blanche et liste qui peut rejoindre. Mettez les noms de profil Java Edition de vos joueurs à la place de your-friend-1,your-friend-2 ; la documentation de l’image dit d’utiliser ceux-là, « not Xbox gamertags » (pas les gamertags Xbox).
   • ENFORCE_WHITELIST=true règle enforce-whitelist. Quand il est activé, indique le Minecraft Wiki, « players not present on the whitelist get kicked from the server after the server reloads the whitelist file » (les joueurs absents de la liste blanche sont expulsés du serveur une fois que le serveur a rechargé le fichier de liste blanche).
   • -v "$PWD/data:/data" garde le monde dans un dossier data là où vous lancez la commande, puisque l’image stocke les données du serveur dans le /data du conteneur.

   Les autres jeux ont leurs propres contrôles d’accès, comme le mot de passe du serveur dans la commande de lancement d’ARK, sur la même page de wiki que ses ports.

2. Prenez une VM dans le cloud avec une adresse IPv4 publique (ce qu’il faut vérifier dans une offre gratuite). Le relais n’a besoin que du client de Tailscale et de socat sur cette VM.

3. Faites rejoindre un même tailnet à la machine du serveur de jeu et à la VM relais. Avec Headscale, que cette page ne met pas en place, chaque machine lance tailscale up --login-server avec l’adresse de votre serveur Headscale, et vous l’approuvez sur le serveur Headscale (les méthodes d’enregistrement de Headscale, consultées en octobre 2026). Le guide pour quitter un FAI filaire explique ce qu’un tailnet atteint à lui seul.

4. Autorisez la VM relais à atteindre le port du jeu et rien d’autre. La page de Headscale sur la politique indique que par défaut « no policy is loaded which means that Headscale allows all traffic between nodes » (aucune politique n’est chargée, ce qui signifie que Headscale autorise tout le trafic entre les nœuds), qu’il lit le fichier indiqué par le réglage policy.path de sa configuration, et qu’il « needs to be reloaded to pick up changes » (doit être rechargé pour prendre en compte les modifications ; consultée en octobre 2026). Ce fichier de politique n’autorise qu’une chose : que la VM relais ouvre des connexions TCP vers le port 25565 du serveur de jeu. Sur Headscale 0.29.7, en octobre 2026, cette politique s’est chargée, headscale nodes tag a appliqué les deux étiquettes (tags) et refusé une étiquette que la politique ne définit pas, et les règles que Headscale en a tirées n’autorisaient que le TCP vers le port 25565 du serveur de jeu, depuis le relais ; aucun client n’était connecté pour cette vérification.

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

   La référence de syntaxe de Tailscale pour le fichier de politique, dont Headscale utilise le format, indique que les règles d’accès « deny access by default » (refusent l’accès par défaut). Une fois cette politique chargée, tout ce qu’elle n’autorise pas est donc bloqué : si d’autres appareils de votre tailnet doivent se joindre entre eux, ajoutez des règles pour eux. Sans "proto": "tcp", indique la même référence, une règle « applies to all TCP and UDP traffic » (s’applique à tout le trafic TCP et UDP). Dans la syntaxe de Tailscale, une liste vide sous tagOwners est un raccourci pour les administrateurs du tailnet ; sur Headscale, l’administrateur pose les étiquettes avec la commande headscale nodes tag de l’étape suivante. La page de Headscale sur la politique recommande les grants, la syntaxe de règles plus récente de Tailscale, et prend aussi en charge des règles comme celle-ci.

5. Étiquetez les deux machines sur le serveur Headscale, avec les identifiants que headscale nodes list affiche pour elles à la place de 1 et 2, comme le décrit la page de Headscale sur les tags (consultée en octobre 2026) :

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

6. Sur la VM relais, lancez le relais. game-server désigne le nom ou l’adresse du serveur de jeu sur le tailnet :

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

   Le manuel de socat appelle une adresse TCP4-LISTEN associée à une adresse TCP4 « a simple TCP port forwarder » (un simple redirecteur de port TCP). Avec fork, socat « handles its channel in a child process » (traite son canal dans un processus enfant) pour chaque connexion ; plusieurs joueurs peuvent donc se connecter en même temps. reuseaddr « Allows other sockets to bind to an address even if parts of it (e.g. the local port) are already in use by socat » (permet à d’autres sockets de se lier à une adresse même si une partie de celle-ci, par exemple le port local, est déjà utilisée par socat ; consultée en octobre 2026). Lancez la commande sous le gestionnaire de services de la VM pour qu’elle reparte après un redémarrage.

7. Ouvrez un seul port. Dans le pare-feu du fournisseur pour la VM, et dans le pare-feu de la VM elle-même s’il y en a un, autorisez TCP 25565 depuis n’importe où. Gardez tous les autres ports fermés, à part celui par lequel vous vous connectez à la VM si vous vous y connectez par Internet.

8. Donnez aux joueurs l’adresse IPv4 publique de la VM relais, comme 203.0.113.10 dans les exemples de cette page, ou un nom DNS que vous faites pointer vers elle, comme mc.example.com.

Trois façons de relayer un jeu en UDP, d’après leur documentation

L’UDP n’a pas de connexion qu’un relais pourrait accepter. Le manuel de socat indique qu’avec l’UDP « no real connection is established; data has to arrive from the peer first » (aucune vraie connexion n’est établie, les données doivent d’abord arriver du pair), et que « no end-of-file condition is specified in UDP » (aucune condition de fin de fichier n’est définie en UDP). Un relais UDP suit donc chaque joueur et doit l’abandonner après un certain temps sans données.

Dans chaque méthode ci-dessous, le serveur de jeu publie son port en UDP (-p 34197:34197/udp dans Docker), et la règle de la politique prend "proto": "udp" et le port du jeu. Le port de Factorio, 34197, sert d’exemple.

socat en mode UDP

Sur la VM relais :

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

-T est le « Total inactivity timeout » (délai d’inactivité total) de socat, que le manuel dit « Useful with protocols like UDP that cannot transfer EOF » (utile avec des protocoles comme l’UDP, qui ne peuvent pas transmettre de fin de fichier). Ici, il met fin au processus enfant d’un joueur après 60 secondes sans données. Jusqu’à socat 1.8.0.0, -T 0 signifiait aucun délai ; depuis 1.8.0.1, il signifie 0, indique le manuel ; donnez-lui donc un nombre.

Le NAT de destination dans le noyau de la VM

La page du wiki nftables sur le NAT montre les deux règles nécessaires : une règle dnat to dans une chaîne prerouting de type nat, qui envoie les paquets du port du jeu vers l’adresse du serveur de jeu sur le tailnet, et masquerade dans une chaîne postrouting, où « the source address is automagically set to the address of the output interface » (l’adresse source prend automagiquement l’adresse de l’interface de sortie), ici l’adresse de la VM sur le tailnet, pour que le serveur de jeu réponde à la VM. Le noyau doit aussi transmettre les paquets entre ses interfaces, ce que règle net.ipv4.ip_forward : « Forward Packets between interfaces » (transmettre les paquets entre les interfaces), dans la documentation du noyau.

Le module stream de nginx

Dans le module stream core de nginx, listen 34197 udp reuseport; dans un bloc server ouvre un socket « for working with datagrams » (pour travailler avec des datagrammes) ; la page indique que reuseport « should also be specified » (devrait aussi être indiqué) pour que les paquets d’une même adresse et d’un même port restent dans une même session. Le module stream proxy les transmet au serveur de jeu avec proxy_pass, et proxy_timeout, 10 minutes par défaut, ferme une session quand « no data is transmitted within this time » (aucune donnée n’est transmise pendant ce délai). La page du module core indique qu’il « is not built by default » (n’est pas compilé par défaut) et demande l’option de compilation --with-stream ; vérifiez donc que votre nginx l’a.

Bedrock Edition peut avoir besoin de plusieurs ports. La copie, sur le Minecraft Wiki, du fichier server.properties livré avec Bedrock Dedicated Server 1.26.60.6 règle transport=nethernet et server-udp-ports=19132, un réglage qui « Configures UDP client transport ports » (configure les ports de transport UDP des clients) : c’est un « Single UDP port shared by all clients » (port UDP unique partagé par tous les clients). S’il n’est pas réglé, indique le fichier, « UDP ports are allocated from the operating system's ephemeral port range » (les ports UDP sont attribués dans la plage de ports éphémères du système d’exploitation), et un relais devrait aussi transporter ces ports. Avec ce transport, le réglage du port IPv6 du fichier est ignoré, et l’IPv6 utilise aussi 19132. Cette page n’a pas essayé Bedrock à travers un relais.

Les tunnels gérés se passent de la VM, d’après leurs propres pages

Aucun n’a été testé ici. Chacun gère pour vous l’extrémité publique ; il n’y a donc pas de VM à installer ni à mettre à jour ; en contrepartie, leur réseau transporte le trafic de vos joueurs. Toutes les pages ont été consultées en octobre 2026.

playit.gg se présente comme « a global proxy that lets you host a server without port forwarding » (un proxy mondial qui vous permet d’héberger un serveur sans redirection de port), avec un agent sur votre machine : « Only you run the agent, your players just connect. » (Vous seul faites tourner l’agent, vos joueurs se connectent simplement.) Sa page d’accueil cite une offre gratuite et une formule Premium payante ; sa liste de jeux place Minecraft Java et Bedrock, Palworld, Terraria, Factorio et une simple entrée « UDP » sous « Free » (gratuit), et de simples entrées « TCP » et « TCP+UDP », avec quelques autres jeux, sous « Requires Playit Premium » (nécessite Playit Premium).

La page des tarifs de ngrok indique que sur son offre Free, « TCP endpoints also need a verified credit card, and ngrok doesn't charge it » (les points de terminaison TCP demandent aussi une carte de crédit vérifiée, que ngrok ne débite pas).

Tailscale Funnel « can only listen on ports 443, 8443, and 10000 » (ne peut écouter que sur les ports 443, 8443 et 10000) et « only works over TLS-encrypted connections » (ne fonctionne que sur des connexions chiffrées par TLS). Le port par défaut de Minecraft Java Edition, TCP 25565, n’en fait pas partie. Sur la page des fonctionnalités de Headscale, Funnel fait partie des éléments sans coche.

Cloudflare Tunnel demande le client de Cloudflare sur la machine de chaque joueur pour tout ce qui n’est pas un service web, comme le cite le guide pour quitter un FAI filaire. La page de Cloudflare Spectrum indique « Custom TCP/UDP applications require an Enterprise plan with Spectrum as a paid add-on » (les applications TCP/UDP personnalisées exigent une offre Enterprise avec Spectrum en option payante ; mise à jour pour la dernière fois en avril 2026). Son tableau des protocoles par offre (mis à jour pour la dernière fois en août 2026) liste Minecraft, une application, sur les offres Pro et Business aussi, où Spectrum est une option payante.

Un VPN maillé (mesh VPN) que chaque joueur rejoint n’a besoin d’aucun relais, mais chaque joueur installe le client et rejoint votre tailnet (ce qu’atteint un VPN maillé).

Pas encore testé ici

• Un joueur sur un autre réseau. Toutes les sondes sont parties de la connexion de la maison qu’utilise le serveur de jeu.
• Une vraie partie. Aucune sonde n’a ouvert de session ni joué ; l’aller-retour qu’affiche le jeu, plusieurs joueurs à la fois et une session entière ne sont donc pas testés.
• L’UDP à travers un relais quel qu’il soit, Bedrock Edition et tous les jeux sauf Minecraft Java Edition.
• Le côté de la VM relais. Si son chemin vers la maison était direct ou passait par un serveur relais DERP, sa charge, ses réglages de pare-feu et si la politique du tailnet l’empêche d’atteindre quoi que ce soit d’autre à la maison n’ont pas été vérifiés depuis la VM.
• Ce que le serveur de jeu inscrit dans son journal pour un joueur venu par le relais. Les lignes de joueurs du journal viennent de connexions antérieures dont le chemin n’est pas connu.
• Une VM dans une autre région, d’autres jours et d’autres heures, les tunnels gérés, et faire tourner le jeu sur la VM elle-même.

Voir comment les tests faits à la maison s’assemblent pour un homelab.