Le lag d'un serveur Rust vient rarement d'une seule chose. C'est presque toujours le server.fps qui passe sous les 30, et à partir de là tout se propage : déplacements en élastique, portes qui refusent de se fermer, raids qui ressemblent à un diaporama, et le redoutable freeze général toutes les cinq minutes au moment de la sauvegarde de la map. En tant qu'hébergeur exploitant des dizaines d'instances Rust sur Pterodactyl, nous voyons les cinq mêmes causes expliquer environ 90 % des tickets "mon serveur Rust lag". Ce guide détaille ce qui casse réellement sur votre machine, ce qu'il faut taper pour le confirmer, et les valeurs exactes qui corrigent chaque cause.
Symptômes : à quoi ressemble vraiment le lag serveur
Avant de changer quoi que ce soit, vérifiez qu'il s'agit bien de lag serveur et non de lag client. Le plus rapide est d'ouvrir la console de votre serveur (onglet console de Pterodactyl, ou RCON) et de taper :
server.fps
C'est la cadence de simulation de votre serveur dédié, pas vos FPS client. Les valeurs à viser :
- 200+ sur un serveur vanilla avec moins de 50 joueurs : en bonne santé
- 120 à 200 sur un serveur moddé avec 50 à 100 joueurs : acceptable
- 60 à 120 en moddé avec des plugins lourds : les joueurs commencent à sentir la lourdeur
- Sous 30 : c'est ce que les joueurs appellent "le lag". Les portes traînent, les blocs de construction scintillent, les tirs ne sont pas enregistrés, les véhicules saccadent
Si server.fps tient à 200+ et que les joueurs signalent quand même du lag, le problème est côté client (leur GPU, leur réseau, ou de la perte de paquets entre eux et le datacenter) et rien de ce que vous changerez sur le serveur n'y fera. S'il est sous 60, en particulier pendant les combats ou près des grosses bases, la suite de cet article vous concerne.
Cause 1 (la plus fréquente) : les pics de garbage collection des plugins
C'est de loin la première cause des tickets "mon serveur allait bien hier et maintenant il lag toutes les 30 secondes". Les plugins Oxide/uMod accumulent des allocations d'objets, le runtime .NET met en pause le thread de simulation principal pour faire le ménage, et vous obtenez un freeze visible de 0,5 à 1,5 seconde pour tous les joueurs du serveur.
Le correctif se fait en deux temps. D'abord, lancez une collecte manuelle depuis la console :
gc.collect
Si le lag disparaît immédiatement après cette commande, le GC des plugins est votre goulot d'étranglement. Le correctif durable consiste soit à alléger la charge de plugins, soit à planifier des collectes préventives.
Les plugins réputés lourds (à auditer en priorité si vous avez du lag) :
- CopyPaste lorsqu'il colle de gros blueprints aux heures de pointe
- BetterChat avec des plugins de journalisation de chat empilés par-dessus
- Backpacks configuré en 48 slots ou plus avec beaucoup de joueurs
- ZoneManager avec de nombreuses zones qui se chevauchent
- NTeleportation quand beaucoup de joueurs se téléportent en même temps
- Tout ce qui interroge chaque tick (CombatLog, plugins de decay). Regardez la source du plugin pour y trouver OnEntityTick ou des hooks similaires.
Ouvrez votre console Pterodactyl et lancez oxide.plugins (ou carbon.plugins si vous êtes sur Carbon) pour voir ce qui est réellement chargé. Au-delà de 50 plugins, vous avez un problème de plugins, quels qu'ils soient.
Cause 2 : le pic de sauvegarde des 5 minutes
Par défaut, Rust sauvegarde l'état du serveur toutes les 300 secondes. Sur un serveur peuplé, cette sauvegarde est synchrone et met toute la simulation en pause pendant 2 à 8 secondes selon le nombre d'entités et la vitesse du disque. Pour les joueurs, cela donne : je marche, freeze, je me téléporte.
Ouvrez la configuration de votre serveur et cherchez :
server.saveinterval 300
Pour un wipe déjà bien peuplé (au-delà du troisième jour avec 50 joueurs ou plus), passez à :
server.saveinterval 600
Sur de très grandes maps ou en fin de wipe, 900 reste raisonnable. Le compromis : en cas de crash du serveur, vous perdez jusqu'à autant de secondes de progression. Sur du matériel bien hébergé, le risque de crash est proche de zéro, donc 600 à 900 convient. Chez DoomHosting, nous réglons les nouveaux serveurs Rust sur 600 pour exactement cette raison.
Vous pouvez confirmer que le pic de sauvegarde est bien la cause de votre lag en surveillant la console du serveur au moment précis du freeze. Si vous voyez [Server] Saving complete juste après le freeze, c'était bien le coupable.
Cause 3 : l'accumulation d'entités au fil du wipe
Rust fait apparaître et suit chaque porte, chaque coffre, chaque code lock, chaque fourneau, chaque objet lâché au sol. Au cinquième jour d'un wipe, un serveur 100 slots avec 30 bases actives a souvent dépassé les 300 000 entités. Chaque entité coûte du temps de simulation à chaque tick.
Vérifiez votre nombre d'entités :
server.entitiesPerPlayer
print(BaseNetworkable.serverEntities.Count)
Les fourchettes saines :
- Jour 1 : moins de 50 000 entités
- Jour 3 : 100 000 à 150 000
- Jour 5 et au-delà : 200 000 à 300 000 est normal, c'est à partir de 400 000 que le lag de fin de wipe apparaît
Il n'existe pas de correctif propre en cours de wipe, à part activer un decay plus agressif (démolition plus rapide des bases sans TC) et le nettoyage des objets au sol :
decay.scale 1.5
decay.upkeep true
Le vrai correctif, c'est le wipe. Si votre serveur meurt systématiquement autour du jour 7 à 10, raccourcissez votre calendrier de wipe. La plupart des serveurs moddés qui marchent wipent chaque semaine ou toutes les deux semaines, précisément à cause de cette courbe.
Cause 4 : server.tickrate, fps.limit et les réglages accusés à tort
Un mythe tenace veut que baisser server.tickrate corrige le lag. C'est faux. server.tickrate agit côté client et contrôle la fréquence à laquelle les clients envoient leurs mises à jour de position au serveur. Le baisser réduit le trafic réseau mais ne libère pas de CPU sur votre serveur dédié.
De la même façon, fps.limit sur le serveur ne vous donne pas plus de FPS. Il plafonne la borne haute pour éviter de gâcher des cycles CPU. 256 est la valeur par défaut raisonnable. Descendre plus bas peut au contraire provoquer du lag, parce que le serveur garde moins de marge pour absorber les pics.
Ce qui compte vraiment :
server.maxplayersréglé au-delà de ce que votre matériel peut tenir. Un 100 slots vanilla demande au moins 4 cœurs dédiés à 4,5 GHz et plus ; un 100 slots moddé demande 6 cœurs et 16 Go de RAM au minimum.- Tourner sur du CPU partagé chez un hébergeur bon marché. Rust déteste les cœurs partagés : les performances monothread font tout.
- Un processus serveur qui n'est pas épinglé sur un cœur rapide.
Si vous êtes chez un hébergeur en Ryzen 9 ou i9 et que votre serveur reste sous 60 de server.fps avec moins de 50 joueurs, le goulot d'étranglement est logiciel (plugins, entités, sauvegarde), pas matériel.
Cause 5 : le lag d'après mise à jour
Presque chaque gros patch Facepunch introduit une régression de performances temporaire quelque part, généralement dans un nouveau type d'entité ou un système refondu. Le schéma en 2026 :
- Le patch sort le jeudi avec force wipe
- Les joueurs signalent des saccades pendant 3 à 4 jours
- Les auteurs de mods publient leurs mises à jour de compatibilité pendant le week-end
- Le mardi ou le mercredi suivant, tout se stabilise
Si votre lag a commencé juste après une mise à jour Facepunch et que vous n'avez pas touché aux plugins, la cause est presque certainement un plugin obsolète qui n'a pas été mis à jour pour la nouvelle API. Vérifiez les pages Oxide/uMod de chacun de vos plugins et retirez ou désactivez tout ce qui n'a pas été mis à jour depuis le patch. Le journal d'erreurs (server.log) désigne généralement le coupable avec des stack traces NullReferenceException.
Checklist de diagnostic (à coller dans votre console)
Quand un joueur signale du lag, lancez ceci dans l'ordre dans votre console Pterodactyl :
server.fps
print(BaseNetworkable.serverEntities.Count)
oxide.plugins
gc.collect
server.fps
Comparez la première valeur de server.fps à celle obtenue après gc.collect. Si elle a bondi de 20 points ou plus, le garbage collection des plugins est votre goulot d'étranglement et vous devez faire le tri. Si elle n'a pas bougé, votre goulot vient des entités (cause 3) ou du matériel (cause 4).
Ce que nous réglons par défaut sur nos serveurs Rust
À titre de repère, voici ce que contient chaque installation Rust neuve chez DoomHosting :
server.saveinterval 600fps.limit 256decay.scale 1.0(configurable serveur par serveur)- Des limites de ressources Pterodactyl calibrées pour que le processus Rust garde toujours de la marge CPU dédiée
- Un processus serveur qui tourne sur du matériel Ryzen 9 avec un boost monothread au-delà de 5,0 GHz. Rust est limité par le monothread, donc une fréquence élevée bat toujours un plus grand nombre de cœurs.
- Des sauvegardes automatiques chaque nuit, pour pouvoir monter le saveinterval sans crainte
Nous livrons aussi uniquement les plugins que vous installez, sans surcouche préchargée. La plupart des tickets de lag que nous voyons après une migration depuis un concurrent viennent de plugins laissés par l'hébergeur précédent.
Toujours du lag ?
Reprenez les causes dans l'ordre : GC des plugins (test gc.collect), puis intervalle de sauvegarde, puis entités, puis matériel. L'ordre compte, car chaque cause est environ 5 fois plus coûteuse à corriger que la précédente. Si vous avez traité les quatre et que server.fps reste sous 60 avec moins de 50 joueurs, il vous faut presque à coup sûr un meilleur matériel ou un wipe.
Hébergez votre serveur Rust chez DoomHosting
Si vous en avez assez de déboguer votre tickrate chez un hébergeur à CPU partagé, nos serveurs Rust tournent sur des cœurs Ryzen 9 dédiés avec les réglages ci-dessus déjà en place. Lancez un serveur Rust chez DoomHosting, fixez votre calendrier de wipe et laissez-nous le reste. Installation instantanée, FTP complet pour vos plugins Oxide, et une équipe de support 24/7 qui joue vraiment au jeu.
