Starlink convient-il à un homelab ? Le verdict de cinq tests

Ce dont un homelab a besoin, et ce que les tests ont trouvé

Chaque résultat ci-dessous vient de l’un des trois guides du site, qui donnent en entier les commandes, la sortie et les limites.

Ce dont un homelab a besoin	Ce qui a été testé	Résultat	Jusqu’où vont les données	Guide
Joindre un serveur à la maison depuis Internet en IPv4	Ce qui a été testéDepuis un VPS, une connexion TCP vers chacun des 8 ports de l’adresse IPv4 publique de la maison, 6 secondes chacune, aucune redirection de port configurée	Résultataucun n’a répondu	Jusqu’où vont les donnéesne montre pas où les connexions se sont arrêtées	GuideDepuis l’extérieur
Savoir si l’adresse IPv4 publique est partagée (CGNAT)	Ce qui a été testéun tracé de la route vers l’extérieur depuis un ordinateur du réseau domestique	Résultatune adresse privée dans le réseau de Starlink est venue avant la première adresse publique	Jusqu’où vont les donnéesle deuxième saut n’a pas répondu ; cela correspond au CGNAT sans le prouver	GuideLe tracé
Ouvrir des connexions sortantes sur les ports de courrier et de partage de fichiers	Ce qui a été testéTCP sortant en IPv4 vers un serveur public de test de ports, délai de 10 secondes	Résultat25 et 445 ont expiré ; 465, 587, 80 et 8080 se sont connectés	Jusqu’où vont les donnéeson ne sait pas où 25 et 445 ont été bloqués	GuidePorts sortants
Transporter les paquets d’un tunnel	Ce qui a été testépings de 1500 octets avec l’option ne pas fragmenter vers trois hôtes de test publics, en IPv4 et en IPv6	Résultatchaque ping a atteint son hôte, et sa réponse est revenue	Jusqu’où vont les donnéesrien de plus grand n’a pu être testé ; aucun tunnel n’a tourné	GuideMTU du chemin
Une connexion stable pour l’accès à distance	Ce qui a été testécinq pings par seconde vers deux résolveurs DNS publics par famille d’adresses, deux séances d’une heure	Résultatl’IPv4 a connu des pics aux secondes 12, 27, 42 et 57 de la minute dans une séance ; 901 pings perdus sur 143 462 sur les deux	Jusqu’où vont les donnéeslectures en millisecondes entières, deux heures sur une seule connexion	GuidePing instable
Joindre un serveur à la maison en IPv6	Ce qui a été testénon testé			GuidePas encore testé

Depuis l’extérieur, rien n’a répondu sur l’adresse IPv4 publique

En octobre 2026, un script lancé sur un VPS a tenté une connexion TCP vers chacun des 8 ports de l’adresse IPv4 publique de la connexion de la maison, dont 22, 80 et 443, en attendant 6 secondes pour chacun. Aucun n’a répondu. Auparavant, le script s’était vérifié sur des cibles dont la réponse était connue, et aucune redirection de port n’était configurée pour le test.

Depuis l’intérieur, un tracé lancé depuis un ordinateur du réseau domestique est passé par une adresse privée dans le réseau de Starlink avant la première adresse publique. Cela correspond à un NAT au niveau de l’opérateur (CGNAT), que la RFC 6888 décrit comme une fonction du réseau de l’opérateur qui partage une adresse IPv4 entre plusieurs abonnés (section 2, consultée en octobre 2026). Le deuxième saut n’a pas répondu ; le tracé ne le prouve donc pas.

D’après la RFC, les abonnés ont « limited or no control » (peu ou pas de contrôle) sur un NAT au niveau de l’opérateur ; avec le CGNAT, une redirection de port sur votre propre routeur ne peut donc pas recevoir les connexions envoyées à l’adresse IPv4 publique. On ne sait pas pour autant où les connexions du test extérieur se sont arrêtées, et, vus depuis le VPS, le CGNAT et un routeur de la maison qui rejette les connexions que personne à l’intérieur n’a demandées auraient le même aspect. La page 1 donne en entier le test depuis l’extérieur et le tracé.

Les ports sortants 25 et 445 ont expiré

Depuis un ordinateur du réseau domestique, les connexions TCP en IPv4 vers un serveur public conçu pour tester des ports ont expiré sur le port 25 (SMTP) et le port 445 (SMB), chacune au bout de 10,3 secondes. Les ports 465 et 587, les ports de soumission de courrier, se sont connectés, tout comme 80 et 8080.

On ne sait pas où 25 et 445 ont été bloqués : au routeur de la maison, dans le réseau de Starlink ou dans le réseau du serveur de test. Le serveur de test utilise le port 25 pour l’un de ses propres services ; ce port n’est donc pas le même test que les autres. Les détails sont dans la section sur les ports sortants de la page 1.

Des paquets de 1500 octets sont passés en IPv4 et en IPv6

En deux relevés à quelques minutes d’intervalle en octobre 2026, des pings de 1500 octets avec l’option ne pas fragmenter sont partis d’un ordinateur relié par câble au réseau domestique vers trois hôtes de test publics et sont revenus, en IPv4 et en IPv6, et aucun saut n’a signalé de MTU plus petite. Rien de plus grand n’a pu être testé, parce que la MTU du lien de l’ordinateur lui-même est de 1500 octets.

Aucun tunnel n’a tourné. Un tunnel ajoute ses propres en-têtes à chaque paquet : le pilote Linux de WireGuard en compte 80 octets et démarre une nouvelle interface à 1420 octets (device.c, Linux 6.18, consulté en octobre 2026). La section sur les tunnels du guide sur la MTU du chemin donne ce calcul et celui de Tailscale, et rien de tout cela n’a été testé sur cette connexion.

Pendant l’une des deux heures, les allers-retours IPv4 ont connu des pics à quatre secondes fixes

Des pings sont partis cinq fois par seconde d’un ordinateur relié par câble au réseau domestique vers deux résolveurs DNS publics par famille d’adresses, une heure à la fois, en deux séances en octobre 2026. Dans la seconde séance, les allers-retours en IPv4 ont le plus changé, avec des pics, aux secondes 12, 27, 42 et 57 de la minute. Dans la première séance, et en IPv6, la règle du test n’a trouvé aucun motif de ce type.

Sur 143 462 pings envoyés pendant les deux séances, 901 sont restés sans réponse. Ceux envoyés aux quatre secondes ont été perdus 1,9 fois plus souvent que ceux envoyés aux autres secondes.

Des chercheurs qui ont mesuré Starlink depuis plusieurs sites signalent des changements aux mêmes quatre secondes, et l’explication de ces changements est la leur ; le guide sur le ping instable les cite. Les allers-retours ont été lus en millisecondes entières ; un changement d’une ou deux millisecondes peut donc passer inaperçu, et le test porte sur une seule connexion pendant deux heures. Aucun jeu, appel ou bureau à distance n’a été testé.

Contourner le CGNAT, non testé ici

Les moyens de contourner le CGNAT, chacun tiré de sa propre documentation et aucun testé ici, sont sur la page sur ce que l’on perd en quittant un fournisseur d’accès filaire. L’Acceptable Use Policy de Starlink pour les États-Unis (sa politique d’utilisation acceptable), dans sa version d’octobre 2026, ne mentionne pas le fait de faire tourner un serveur. Un relais TCP passant par une VM dans le cloud est testé sur la page sur le serveur de jeu.

Les offres ont leur propre page

Les offres de Starlink et le crédit de parrainage de 100 $US aux États-Unis sont sur la page sur les offres et les crédits. Pour savoir si vous pouvez installer Starlink vous-même, voyez la page sur l’installation et, pour savoir si vous pourrez changer de forfait plus tard, la page sur le changement de forfait.

Pour savoir si vous pouvez avoir Starlink en appartement, voyez la page sur Starlink en appartement.

Ce que ces tests ne montrent pas

L’IPv6 entrant. Aucun test n’a tenté de joindre un serveur à la maison en IPv6.

Tout moyen de contourner le CGNAT, comme un tunnel qui part de l’intérieur de votre réseau.

Le débit montant et la consommation de données.

La météo, les coupures de courant et la disponibilité sur plusieurs semaines.

D’autres connexions, d’autres routeurs, et le mode bypass du routeur Starlink.