Serveur Palworld qui crash : corriger fuites mémoire et plantages

Si votre serveur dédié Palworld plante sans arrêt, la cause est presque toujours l'une de ces cinq choses, et « il me faudrait une meilleure connexion internet » n'en fait pas partie. Après avoir fait tourner des milliers d'instances Palworld sur notre panneau Pterodactyl, ce sont les mêmes coupables qui reviennent : la fuite mémoire bien connue du moteur, qui tue les serveurs toutes les 30 minutes à 4 heures, une erreur de binding au démarrage qui empêche le processus de se lancer, une corruption de Level.sav après un arrêt brutal, une explosion du nombre d'entités pals dans une base haut niveau, et un décalage de version entre le binaire du serveur et le client après un patch. Ce guide déroule chaque solution dans l'ordre où vous devez les essayer, avec les lignes de log exactes qui vous disent laquelle vous concerne et les configurations à changer.

Commencez par identifier le crash auquel vous avez affaire

La phrase « mon serveur a planté » recouvre au moins trois modes de panne complètement différents. Ouvrez la console de votre serveur (dans Pterodactyl, l'onglet Console) et cherchez l'un de ces motifs dans les 200 dernières lignes :

LogMemory: Out of memory                       # memory leak / OOM kill
bind: Address already in use                   # startup port conflict
LogPalSav: Failed to load Level.sav            # save corruption
LogPalNetworkConnection: ProtocolMismatch      # version drift after a patch
Fatal error: [File:...UE5...World.cpp]         # pal entity overflow

La ligne vous dit vers quelle section aller. Si vous n'en voyez aucune, remontez au-delà de la dernière ligne « Server started » et lisez vers le haut. Le crash est presque toujours consigné juste avant la sortie du processus.

Solution 1 : la fuite mémoire (le tueur des 30 minutes et des 4 heures)

C'est de loin la première raison pour laquelle un serveur Palworld plante, et c'est celle que la plupart des guides « ajustez vos paramètres » traitent de travers. Le binaire du serveur dédié Palworld fuit de la mémoire à un rythme à peu près linéaire, selon le nombre de joueurs et le nombre total de pals. Un serveur à 4 joueurs avec 80 pals dans le monde passe généralement de 3 Go au démarrage à plus de 8 Go en 4 heures. Un serveur communautaire à 16 joueurs peut atteindre 12 Go en 30 minutes. Quand la machine tue le processus parce qu'il dépasse sa limite mémoire, vos joueurs voient « server connection lost » et le monde passe hors ligne.

Le symptôme dans les logs ne laisse aucun doute :

LogMemory: Out of memory - process killed

Il n'existe pas de correctif propre par configuration pour la fuite elle-même. C'est un bug côté moteur que Pocketpair grignote depuis la sortie sans l'avoir éliminé. Ce que vous pouvez faire :

• Allouez assez de RAM dès le départ. Notre recommandation minimale pour un serveur Palworld sérieux est de 8 Go pour 4 à 8 joueurs, 12 Go pour 8 à 16 joueurs et 16 Go pour 16 à 32. En dessous, la fuite atteint le plafond avant votre première nuit.
• Programmez un redémarrage quotidien. Un redémarrage toutes les 4 à 6 heures (ou une fois dans la nuit, pendant les heures creuses de vos joueurs) ramène la mémoire fuitée à son niveau de départ. Sur DoomHosting, cela se règle dans l'onglet Planification. Choisissez « Restart server » et un cron comme 0 */6 * * * pour toutes les 6 heures.
• Plafonnez votre nombre de pals. Dans PalWorldSettings.ini, faites passer BaseCampWorkerMaxNum=15 à 10 si votre groupe garde toutes ses bases au maximum. Chaque pal capturé dans une base fait tourner son IA à chaque frame, même quand personne n'est connecté.
• Évitez le réflexe « plus de workers ». WorkerThreadsForUE4=0 et un NumberOfWorkerThreadsServer plus élevé ne réduisent pas la fuite. Ils l'accélèrent, en laissant le serveur simuler plus d'entités par tick. Laissez les deux par défaut.

Si la fuite est votre problème, un redémarrage programmé à la moitié de l'intervalle où votre serveur meurt aujourd'hui est la solution la moins coûteuse en effort qui fonctionne vraiment.

Solution 2 : le serveur plante au démarrage (l'erreur de binding)

Si le serveur meurt dans les 10 premières secondes et n'atteint jamais la ligne « World loaded », ce n'est presque jamais un problème de sauvegarde. C'est un conflit de port ou une erreur de lecture de la configuration. Le log affiche l'une de ces lignes :

bind: Address already in use
Couldn't bind to UDP port 8211
LogConfig: Failed to parse PalWorldSettings.ini at line 47

Palworld utilise par défaut l'UDP 8211 et l'API REST le TCP 8212. Sur une machine auto-hébergée, tout ce qui occupe déjà ces ports (un ancien processus Palworld mal terminé, un autre serveur de jeu ou un service système) empêche le nouveau processus de se lier. Arrêtez le service concurrent ou changez le port Palworld dans vos arguments de démarrage (-port=8214 -publiclobby) et le binding passe.

Pour l'erreur de lecture de la configuration, la faute est dans PalWorldSettings.ini et le log nomme la ligne en cause. Le piège le plus courant : le fichier utilise un format OptionSettings=(...) sur une seule ligne, et une virgule manquante entre deux options casse silencieusement tout le fichier à partir de la ligne suivante. Ouvrez-le, regardez le numéro de ligne donné par le log, puis ajoutez la virgule manquante ou refermez la parenthèse.

Sur DoomHosting, nous attribuons les ports automatiquement et validons la configuration avant chaque démarrage : l'erreur de binding et l'erreur de lecture sont donc écartées d'avance. Si vous vous auto-hébergez à la maison et que vous tombez sans arrêt sur « Address already in use », lancez ss -tulnp | grep 8211 pour trouver le processus qui tient le port.

Solution 3 : corruption de Level.sav (le crash au chargement)

Si le serveur se chargeait très bien hier et refuse de se charger aujourd'hui, ou s'il se charge, tourne quelques minutes puis retombe au même état à chaque redémarrage, votre sauvegarde est probablement corrompue. Cela arrive surtout après un arrêt brutal : un hébergeur qui coupe tout en pleine sauvegarde, un OOM pendant l'écriture de l'autosave, ou une coupure de courant sur une machine auto-hébergée.

LogPalSav: Failed to load Level.sav - end of file at position xxxx
Fatal error: [File:...SaveGame.cpp:...] World save unrecoverable

Palworld ne fait pas de sauvegardes automatiques par défaut. Les options de récupération, dans l'ordre :

1. Cherchez un fichier .bak dans votre dossier de sauvegarde. Si vous (ou votre hébergeur) avez utilisé le mod de backup non officiel ou un snapshot côté panneau, restaurez le .bak le plus récent en le renommant en Level.sav.
2. Regardez le dossier Players/. Les fichiers de sauvegarde des joueurs (Players/<steamid>.sav) sont séparés de la sauvegarde du monde et survivent en général quand Level.sav ne survit pas. Si vous devez recréer le monde, vos joueurs gardent leurs inventaires et leurs niveaux.
3. Cherchez Level.sav.tmp. Palworld écrit un .tmp à chaque sauvegarde puis le renomme. Si le renommage a été interrompu, le .tmp contient peut-être encore une sauvegarde antérieure valide. Renommez-le en Level.sav et essayez de le charger.

Sur DoomHosting, nous prenons un snapshot quotidien du dossier de sauvegarde. Si vous en êtes arrivé là, ouvrez un ticket et nous restaurons le snapshot de la nuit précédente en moins de cinq minutes.

La solution qui ne répare rien mais évite la prochaine fois : mettez en place une vraie planification de sauvegardes. Dans l'onglet Planification, choisissez « Create backup » avec un cron de 6 heures et vous avez un filet de sécurité pour le jour où cela se reproduira.

Solution 4 : débordement d'entités pals (le crash de base en fin de partie)

Un crash bien particulier touche les joueurs qui ont de très grandes bases. Imaginez 15 pals ou plus qui travaillent sur une rangée de raffineries, des lampes sphériques partout, beaucoup de décorations fabriquées. Le serveur reste stable pour les nouveaux joueurs, mais plante dès que quelqu'un se téléporte dans la base à forte densité. Le log :

Fatal error: [File:...UE5/Engine/Source/.../PrimitiveSceneProxy.cpp]
LogPal: Entity count exceeds streaming limit

C'est le scene proxy d'Unreal qui abandonne sur le buffer de distance d'affichage de ce chunk. Les correctifs :

• Passez BaseCampWorkerMaxNum=15 à 10 dans PalWorldSettings.ini. Cela plafonne le nombre de pals au travail par base, de loin le premier facteur du nombre d'entités.
• Vérifiez que bIsMultiplay=True est bien défini. Certains templates personnalisés le laissent à false, ce qui applique les limites de streaming du solo et fait planter plus tôt.
• Déplacez la base la plus problématique. Si votre base raffinerie jouxte votre base d'élevage, le scene proxy charge les deux en même temps quand un joueur approche. 200 mètres de séparation suffisent à régler le problème.

Solution 5 : décalage de version après un patch (surtout autour de la 1.0)

Palworld pousse les mises à jour serveur via SteamCMD, et un client fraîchement patché peut refuser de se connecter à un serveur qui tourne encore sur l'ancien binaire. Le serveur reste en ligne et accepte les connexions, puis déconnecte chaque client en plein handshake.

LogPalNetworkConnection: Disconnect reason=ProtocolMismatch
LogPal: Server version 0.7.x, client version 1.0.x

Solution : relancez SteamCMD pour mettre à jour le serveur dédié. Sur un hébergeur managé comme le nôtre, c'est un bouton « Reinstall » dans le panneau et votre monde est préservé. Si vous vous auto-hébergez :

steamcmd +login anonymous +force_install_dir ./palworld_server +app_update 2394010 validate +quit

Avec la sortie de Palworld 1.0 le 10 juillet 2026, ce problème va toucher beaucoup de serveurs pendant la première semaine. Mettez le serveur à jour dans l'heure qui suit l'arrivée du patch client et vous évitez toute la question.

Toujours des plantages ? Lancez ces diagnostics

Si aucune des cinq solutions ci-dessus ne correspond à ce que vous observez, récupérez ceci avant d'ouvrir un ticket. Tout hébergeur a besoin de l'ensemble pour trier vite :

# server-side
tail -300 /home/container/Pal/Saved/Logs/PalServer.log
free -m
ps aux | grep PalServer
ss -tulnp | grep 8211

# from a player who keeps disconnecting
ping -c 50 your-server-ip

La fin du log donne la raison de la sortie. free -m montre s'il reste vraiment de la mémoire sur la machine pour le serveur. ps aux confirme que le processus est vivant après le crash signalé (parfois le « crash » n'est qu'une déconnexion côté client, ce qui appelle une autre solution). ss confirme que le serveur écoute bien sur l'UDP 8211. Le ping côté joueur vous dit si le chemin réseau lui-même est sain.

Hébergez votre serveur Palworld avec DoomHosting

La plupart des correctifs ci-dessus se réduisent à un clic sur un hébergeur managé. La RAM évolue sans perdre votre monde. L'onglet Planification gère le redémarrage toutes les 6 heures, donc la fuite mémoire n'atteint jamais le plafond. Les snapshots quotidiens survivent à une corruption de Level.sav. Les mises à jour SteamCMD se lancent en un clic le jour du patch. Si vous en avez assez de déboguer des crashs la veille du raid de votre groupe, hébergez votre serveur Palworld sur DoomHosting : installation instantanée sur matériel Ryzen 9, UDP 8211 déjà ouvert, FTP complet, protection DDoS et support 24/7.

Un serveur dédié devrait se faire oublier. Quand le vôtre meurt toutes les 30 minutes, soir après soir, c'est que l'hébergeur ou la configuration ne fait pas le travail qu'il devrait faire à votre place.