2026 : Palworld 1.0 inaccessible ? Vérifiez d’abord les ports du serveur

Le 10 juillet 2026, Palworld 1.0 a été annoncé officiellement ; la date de publication figure dans l’annonce officielle de la version 1.0. Pour un serveur dédié Palworld inaccessible depuis l’extérieur, le bon ordre est le suivant : vérifier le port réellement écouté, autoriser ce trafic dans le pare-feu du serveur, puis tester depuis un autre réseau. Sur une machine louée, il n’est généralement pas nécessaire de configurer la redirection du routeur domestique. Le port d’écoute et PublicPort ont des rôles distincts : le second ne remplace pas le premier.

Ce parcours s’adresse aux responsables d’un serveur Palworld 1.0 que les joueurs ne peuvent joindre qu’en partie, ou pas du tout.
Il convient aussi aux administrateurs qui préparent un serveur communautaire et hésitent entre le port d’écoute et le port annoncé.
Les responsables d’un monde maintenu en ligne qui envisagent une migration y trouveront les vérifications réseau à consigner avant le transfert.

Dernière vérification : 1er novembre 2026. Les informations de version ont été rapprochées de l’annonce officielle ; les paramètres de serveur doivent être revérifiés dans la documentation Palworld au moment du déploiement.

Diagnostic selon le symptôme

Avant de modifier les règles réseau, distinguez trois situations qui se ressemblent pour les joueurs, mais qui n’appellent pas les mêmes contrôles.

• Le processus du serveur n’est pas démarré ou s’arrête au lancement. Une règle de pare-feu ne peut pas rendre joignable un service qui ne fonctionne pas. Vérifiez l’état du processus, les messages de démarrage et le journal de l’instance. La documentation officielle distingue les exigences du serveur et son déploiement ; consultez les prérequis officiels du serveur Palworld et le guide de déploiement d’un serveur dédié.
• La connexion locale fonctionne, mais une personne sur Internet reçoit un délai d’attente ou un refus. Cette différence oriente le diagnostic vers le port d’écoute, le pare-feu ou un autre filtre réseau sur le chemin. Notez le message exact : un délai d’attente et un refus de connexion ne décrivent pas forcément le même blocage.
• La connexion directe fonctionne, mais le serveur n’apparaît pas dans la liste communautaire. Ne concluez pas immédiatement que le port de jeu est fermé. Le service peut être joignable directement alors que les paramètres d’annonce ou d’enregistrement communautaire sont incorrects. Traitez ces deux chemins comme des vérifications séparées.

Un essai effectué depuis le même réseau que le serveur ne suffit pas à prouver qu’un accès Internet fonctionne. Certaines configurations locales utilisent un chemin différent pour joindre l’adresse publique ; demandez donc à un testeur réellement extérieur de reproduire la connexion. Relevez l’adresse saisie, le port indiqué et le résultat observé, sans partager d’identifiants d’administration.

Point de contrôle : si le processus ne confirme pas un démarrage normal, ne modifiez pas encore le pare-feu. Résolvez d’abord le problème de lancement ; sinon, un test réseau négatif ne permettra pas de déterminer si le port est en cause.

Port d’écoute et PublicPort

Le paramètre -port sert à changer le port sur lequel le serveur écoute. La documentation officielle indique 8211 comme valeur par défaut et précise le rôle de ce paramètre dans les arguments de lancement Palworld. Cette valeur ne doit pas être copiée aveuglément : si l’instance a été personnalisée, la configuration active et les paramètres de lancement priment sur une valeur par défaut publiée dans un guide.

-publicport répond à une autre fonction. Il indique le port externe à utiliser pour la publication d’un serveur communautaire ; il ne modifie pas le port d’écoute du processus. Les détails de l’enregistrement sont aussi à examiner dans le guide officiel des serveurs communautaires. Confondre ces paramètres peut produire un résultat déroutant : le serveur semble renseigné pour être publié, mais le trafic des joueurs n’atteint pas le port réellement écouté.

Pour éviter cette confusion, gardez trois valeurs distinctes dans votre fiche d’exploitation :

1. le port d’écoute chargé par l’instance ;
2. le port autorisé dans le pare-feu et, s’il y en a une, dans une couche réseau supplémentaire ;
3. le port annoncé pour la publication communautaire.

Les trois peuvent être identiques dans une configuration simple, mais il ne faut pas supposer qu’ils le sont. Après toute modification de -port, redémarrez l’instance et vérifiez de nouveau le paramètre effectivement chargé. Changer une règle de pare-feu sans redémarrer une instance dont les paramètres ont changé, ou modifier seulement PublicPort, ne corrige pas une divergence entre la configuration et le service.

Règles du pare-feu du serveur

Une fois le service démarré et son port d’écoute établi, vérifiez les règles de filtrage. Une règle entrante doit correspondre au port réel, au protocole attendu et au bon sens de circulation. Une règle sortante, à elle seule, ne prouve pas que les connexions entrantes vers le serveur sont autorisées. Laissez la règle limitée au trafic nécessaire au service plutôt que d’ouvrir largement l’accès réseau.

Sur un système Ubuntu Server, appuyez-vous sur la documentation de configuration du pare-feu pour examiner les règles appliquées, puis comparez-les au port et au protocole de Palworld. Sur Windows Server, vérifiez une règle entrante adaptée à l’instance ; la documentation Microsoft sur la création de règles de ports entrants décrit les paramètres pertinents du pare-feu. Dans les deux cas, une règle doit être cohérente avec la configuration réellement démarrée, et pas seulement avec la valeur prévue dans un fichier.

Dans un hébergement à domicile, la topologie peut inclure un routeur qui doit transmettre le trafic vers la machine du serveur. Dans un serveur dédié loué, l’administrateur ne configure généralement pas son routeur domestique pour acheminer les joueurs vers la machine hébergée ; il vérifie d’abord le pare-feu du système et les paramètres réseau du service. Si l’environnement de location comporte une règle réseau distincte, elle doit être vérifiée auprès de la documentation correspondante. Il ne faut ni présumer qu’elle existe, ni attribuer au fournisseur une fonction de filtrage non confirmée.

Attention : une règle d’autorisation dans le pare-feu ne garantit pas, à elle seule, l’accessibilité depuis Internet. Elle ne prouve ni que le processus écoute sur cette adresse, ni que le trafic emprunte le bon chemin jusqu’à la machine.

Repères de décision selon le résultat

Ce tableau ne remplace pas l’observation du processus et du journal : il sert à choisir la prochaine vérification, pas à déclarer une cause certaine à partir d’un seul symptôme. Un serveur invisible dans une liste communautaire, notamment, ne prouve pas qu’un port est fermé ; une connexion directe réussie constitue un indice distinct, à conserver dans le compte rendu.

Parcours de vérification avant migration

Pour éviter les changements simultanés qui brouillent le diagnostic, consignez les contrôles dans cet ordre. Ce relevé sera également utile au moment de déplacer le monde vers un hébergement durable.

1. Confirmer le service. Vérifiez que l’instance Palworld a terminé son démarrage et reste active. Relevez le message d’erreur éventuel et la version du serveur indiquée par l’installation. La version publiée étant susceptible d’évoluer, contrôlez la page officielle de déploiement et les paramètres de configuration documentés avant de traiter une ancienne procédure comme toujours valable.
2. Noter la destination utilisée par les joueurs. Consignez l’adresse et le port fournis pour la connexion directe, sans confondre ces informations avec l’adresse de publication dans une liste. Demandez au testeur de confirmer qu’il ne se trouve pas sur le même réseau local que l’hébergeur.
3. Lire les options réellement chargées. Relevez -port et, si le serveur est communautaire, -publicport. Vérifiez que l’instance a bien été redémarrée après une modification des paramètres. Ne déduisez pas le port actif d’un ancien fichier de lancement si celui-ci a été remplacé ou si un panneau démarre le service avec d’autres options.
4. Comparer la règle entrante au service. Confirmez le port, le protocole et le sens entrant ; sur un serveur loué, commencez par le pare-feu du système et l’éventuelle configuration réseau de l’environnement. Une valeur inscrite dans une règle mais absente du processus ne rend pas l’instance joignable.
5. Effectuer un test extérieur contrôlé. Faites tester la connexion directe par un joueur extérieur au réseau du serveur. Notez l’heure, l’adresse et le port employés, le type de résultat — délai d’attente, refus ou connexion réussie — et, séparément, la visibilité dans la liste communautaire.
6. Modifier un seul élément à la fois. Si la connexion directe échoue, revérifiez d’abord écoute et pare-feu ; si elle réussit mais que la liste reste vide, passez aux paramètres communautaires. Après chaque changement, refaites le même test extérieur. Cette discipline évite de prendre une amélioration fortuite pour une correction confirmée.
7. Archiver une fiche d’acceptation. Avant une mise à jour ou une migration, conservez la version de serveur observée, les options de lancement, les règles entrantes et le résultat des tests extérieurs. Après une mise à jour, répétez les contrôles concernés au lieu de supposer que l’ancienne configuration reste applicable.

Un journal de diagnostic minimal peut contenir : date du test, version observée, port d’écoute, valeur éventuelle de PublicPort, règles entrantes vérifiées et réseau depuis lequel le test a été réalisé. Les adresses publiques et les détails d’accès d’administration ne doivent pas être publiés dans un forum de dépannage.

Limites du diagnostic et choix d’hébergement

Les données d’activité du jeu peuvent indiquer qu’il existe encore des joueurs, mais elles ne prouvent ni un volume de recherches ni une panne généralisée. L’historique d’activité du jeu constitue un signal d’activité à une date donnée ; il ne permet pas de conclure que les problèmes de connexion signalés par certains administrateurs touchent tous les serveurs. Les cas publiés par des joueurs doivent rester des cas individuels tant qu’ils ne sont pas corroborés.

La migration vers une machine dédiée ne corrige pas une erreur dans -port, une règle entrante incohérente ou un PublicPort mal renseigné. Elle peut en revanche convenir à une communauté qui maintient durablement un service et souhaite administrer son propre environnement. Avant le transfert, vérifiez le système que l’équipe sait maintenir, les modalités d’accès et les options réseau du plan concerné ; le guide d’accès aux serveurs décrit les modes de connexion disponibles, tandis que la FAQ CloudUDP répond aux questions générales sur le service.

Dans l’offre CloudUDP, les serveurs dédiés sont situés à Tokyo ; les options de bande passante indiquées sont 250 Mbps, 1 Gbps et 2 Gbps, avec trafic illimité. Les configurations mentionnées comprennent un processeur AMD EPYC à 32 cœurs et 64 threads, ainsi que 128 Go ou 256 Go de mémoire ECC ; Linux est administré en SSH et Windows Server en RDP. Ces caractéristiques décrivent l’environnement disponible, elles ne garantissent pas qu’un serveur Palworld donné sera joignable depuis chaque réseau. Les détails à jour doivent être confirmés sur la page des offres CloudUDP.

Questions fréquentes

Connexion locale réussie, accès extérieur impossible

Si le service démarre et qu’un client local peut le joindre, relevez le port chargé par le processus et comparez-le à la règle entrante du pare-feu. Demandez ensuite à une personne sur un réseau distinct de tester l’adresse directe. Si ce test fonctionne mais que la liste communautaire reste vide, traitez l’annonce du serveur séparément : visibilité et connexion directe ne sont pas le même contrôle.

Port à vérifier sur Palworld 1.0

La documentation officielle donne 8211 en UDP comme réglage par défaut du port de jeu. Cette indication ne s’applique pas automatiquement à une instance personnalisée : un paramètre -port différent change le port d’écoute. Après le redémarrage du serveur, vérifiez la valeur effectivement chargée et faites correspondre le pare-feu à cette valeur avant de demander un nouveau test extérieur.

Différence entre PublicPort et le port d’écoute

Le port d’écoute est celui sur lequel le processus du serveur reçoit le trafic de jeu ; il se configure avec -port. PublicPort concerne le port annoncé pour la publication communautaire et ne déplace pas le service. Une connexion directe qui échoue demande donc de contrôler d’abord le port d’écoute et les règles réseau, tandis qu’une absence dans la liste après une connexion directe réussie appelle un contrôle distinct de l’annonce communautaire.

Redirection de routeur sur une machine louée

La redirection de port d’un routeur domestique concerne une machine hébergée derrière ce routeur. Sur un serveur dédié loué, le premier contrôle porte généralement sur le pare-feu du système et les réglages réseau de l’environnement d’hébergement, pas sur le routeur du domicile de l’administrateur. Vérifiez les modalités propres à l’offre utilisée ; n’ajoutez pas une règle de routeur sans savoir qu’elle se trouve réellement sur le chemin du trafic.

Pour une communauté qui migre un monde maintenu en ligne, un serveur dédié peut éviter certaines limites d’une machine domestique ou d’une offre mutualisée, notamment le partage de ressources et la dépendance à une connexion résidentielle ; il ne dispense toutefois ni du contrôle des ports ni d’un test extérieur après chaque changement. Si l’administration durable et les ressources dédiées correspondent au besoin, vérifiez les systèmes, l’accès et les options réseau dans les offres CloudUDP avant de choisir une configuration : aucun résultat de connexion ne peut être garanti sans essai dans les conditions réelles des joueurs.

Questions fréquentes