Un serveur 7 Days to Die dédié tourne encore aujourd’hui pour environ 24 000 joueurs simultanés sur Steam d’après SteamCharts, avec un pic historique proche de 124 à 125 000 joueurs simultanés atteint en juillet 2024, et l’App Fun Pimps vient de livrer coup sur coup deux mises à jour majeures : la V3.0 « Dead Hot Summer » le 29 juin 2026, puis la V3.1 « Henpocalypse » à peine un mois plus tard, le 27 juillet 2026. Entre le crossplay PC/Xbox Series X|S/PS5 désormais natif, un nouveau système d’élevage de poules et un piège de migration des codes sandbox qui piège déjà des administrateurs de serveurs communautaires, monter son propre serveur n’a jamais autant valu la peine, mais jamais non plus autant demandé de rigueur technique. Ce guide détaille, en 13 étapes vérifiées, l’installation complète d’un serveur 7 Days to Die dédié sous Linux et Windows : SteamCMD, fichiers de configuration, ports réseau, permissions, crossplay console, migration vers la V3.1, et surtout la sécurisation d’une installation exposée sur Internet.
Prérequis pour un serveur 7 Days to Die dédié
Avant de commencer, voici ce qu’il faut réunir. Aucun de ces prérequis n’est optionnel : les sauter mène presque systématiquement à un serveur invisible dans la liste ou à une installation qui plante au démarrage.
- Une machine Linux (Debian/Ubuntu recommandé) ou Windows Server/10/11, physique ou VPS, avec un accès administrateur complet
- Au minimum 8 Go de RAM pour un usage confortable à 8 joueurs (détail complet dans la section matérielle plus bas)
- 10 à 15 Go d’espace disque libre sur SSD, 25 Go recommandés avec les mises à jour futures
- Un accès à l’interface d’administration de votre box ou routeur, pour la redirection de ports
- SteamCMD installé (étape 2 de ce guide)
- Des bases en ligne de commande : naviguer dans les dossiers, éditer un fichier texte, lancer un script
- Aucun achat du jeu requis : contrairement à d’autres serveurs dédiés, l’outil serveur de 7 Days to Die s’installe avec un compte Steam anonyme
Pourquoi héberger votre propre serveur 7 Days to Die dédié ?
7 Days to Die propose une option d’hébergement rapide directement depuis le client de jeu, en mode « serveur d’écoute » : un joueur ouvre une partie et les autres la rejoignent. C’est suffisant pour une session ponctuelle entre deux amis, mais cette formule a trois limites concrètes. D’abord la persistance : dès que l’hôte quitte, tout le monde est déconnecté, ce qui est incompatible avec un monde qui doit continuer à tourner entre les sessions de jeu. Ensuite la performance : la machine de l’hôte doit à la fois faire tourner le rendu du jeu et simuler le monde pour tous les autres joueurs, ce qui dégrade nettement le framerate de l’hôte dès que la horde de la nuit sanglante arrive. Enfin le contrôle : un serveur dédié permet de définir des permissions par joueur, d’activer des mods côté serveur, de planifier des sauvegardes automatiques et d’ouvrir le monde au crossplay Xbox/PlayStation, ce qu’un simple serveur d’écoute ne permet pas de gérer proprement.
Un serveur dédié tourne en tâche de fond, sans interface graphique, sur une machine réservée à cet usage (VPS loué ou machine personnelle allumée en continu). Concrètement, cela signifie que le monde continue d’exister même lorsque personne n’est connecté : les cultures poussent, les zombies patrouillent, et la nuit sanglante arrive à l’heure prévue par le cycle configuré, exactement comme le vivrait un joueur qui se déconnecte puis se reconnecte le lendemain. C’est cette continuité, plus que la seule performance, qui distingue fondamentalement un serveur dédié d’une simple session entre amis. C’est ce que ce guide met en place, de bout en bout.
Étape 1 : choisir entre location clé en main et auto-hébergement
Deux chemins mènent à un serveur 7 Days to Die dédié fonctionnel. Le premier consiste à louer une offre clé en main chez un hébergeur spécialisé : panneau de configuration prêt à l’emploi, mises à jour automatiques, support technique, mais moins de contrôle fin sur la machine sous-jacente. Le second consiste à auto-héberger sur un VPS générique ou une machine personnelle : plus de travail de configuration manuelle, mais un contrôle total et souvent un coût par Go de RAM plus avantageux à volumes égaux. Ce guide couvre l’auto-hébergement en détail (étapes 2 à 9), la méthode qui s’applique aussi bien à un VPS loué qu’à du matériel personnel, et revient sur la comparaison de prix à l’étape 12.
Étape 2 : installer SteamCMD
SteamCMD est l’outil en ligne de commande de Valve qui télécharge les fichiers du serveur dédié. Sous Linux (Debian/Ubuntu), installez-le ainsi :
sudo apt update
sudo apt install -y lib32gcc-s1 curl
mkdir -p ~/steamcmd && cd ~/steamcmd
curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" -o steamcmd.tar.gz
tar -xvzf steamcmd.tar.gz
./steamcmd.shSous Windows, téléchargez steamcmd.zip depuis la documentation officielle Valve, extrayez-le dans un dossier dédié (par exemple C:\steamcmd) et lancez steamcmd.exe une première fois pour qu’il se mette à jour tout seul. La page SteamCMD du Valve Developer Community détaille les deux plateformes si un paquet venait à changer d’emplacement.
Étape 3 : télécharger les fichiers du serveur dédié (App ID 294420)
7 Days to Die distingue clairement deux App ID Steam distincts : 251570 pour le jeu client (celui que possèdent les joueurs) et 294420 pour l’outil serveur dédié, gratuit et téléchargeable sans posséder le jeu, via une connexion Steam anonyme. C’est l’erreur la plus fréquente des débutants : confondre les deux identifiants. Dans SteamCMD :
login anonymous
force_install_dir /home/steam/7dtd-server
app_update 294420 validate
quitSous forme de commande unique, la même opération s’écrit :
./steamcmd.sh +@sSteamCmdForcePlatformType linux +force_install_dir /home/steam/7dtd-server +login anonymous +app_update 294420 validate +quitUne installation réussie affiche cette ligne en fin de téléchargement :
Success! App '294420' fully installed.Comptez entre 8 et 12 Go de téléchargement selon la version, donc prévoyez une connexion stable. Le comportement est documenté sur la page dédiée du Valve Developer Community, qui précise notamment la liste des ports à ouvrir abordée à l’étape 8.
Étape 4 : comprendre l’arborescence des fichiers du serveur
Une fois l’installation terminée, le dossier du serveur contient une structure assez lisible :
7dtd-server/
├── 7DaysToDieServer.x86_64 # binaire Linux
├── 7DaysToDieServer.exe # binaire Windows
├── startserver.sh # script de lancement Linux
├── startdedicated.bat # script de lancement Windows
├── serverconfig.xml # configuration principale du serveur
├── serveradmin.xml # comptes admin, whitelist, bannis, permissions
├── Data/
├── Mods/ # dossier des mods, vide = crossplay possible
└── Saves/ # mondes sauvegardésDeux fichiers méritent une attention particulière avant le premier lancement : serverconfig.xml, qui définit toutes les règles du monde, et serveradmin.xml, qui définit qui a le droit de faire quoi. C’est l’objet des deux étapes suivantes.
Étape 5 : configurer serverconfig.xml
serverconfig.xml utilise un format plat, sans imbrication : chaque réglage est une balise <property name="X" value="Y"/> indépendante. Voici un extrait des propriétés essentielles à vérifier avant le premier démarrage :
<property name="ServerName" value="Mon Serveur 7DTD"/>
<property name="ServerPort" value="26900"/>
<property name="ServerVisibility" value="2"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="ServerPassword" value=""/>
<property name="GameWorld" value="Navezgane"/>
<property name="GameDifficulty" value="2"/>
<property name="EACEnabled" value="true"/>
<property name="ServerDisabledNetworkProtocols" value="SteamNetworking"/>Le tableau ci-dessous détaille les propriétés qui posent le plus de questions en pratique :
| Propriété | Valeur par défaut | Rôle |
|---|---|---|
| ServerVisibility | 2 | 2 = public (liste des serveurs), 1 = amis Steam uniquement, 0 = non répertorié |
| ServerMaxPlayerCount | 8 | Doit rester ≤ 8 si le crossplay console est activé (étape 11) |
| GameWorld | Navezgane | Carte fixe ; toute autre valeur + WorldGenSeed/WorldGenSize déclenche une génération aléatoire (RWG) |
| EACEnabled | true | EasyAntiCheat ; doit rester activé pour le crossplay, désactivez-le uniquement pour des mods en DLL |
| ServerDisabledNetworkProtocols | SteamNetworking | Laisse LiteNetLib actif par défaut, protocole utilisé par le crossplay |
| BloodMoonEnemyCount | 8 | Zombies par joueur pendant la nuit sanglante (horde night) |
| MaxSpawnedZombies | 60 | Le commentaire du fichier de référence prévient qu’au-delà de ~80, le framerate du serveur en pâtit |
| MaxSpawnedAnimals | 50 | Plafond du nombre d’animaux simulés simultanément |
| LandClaimSize | 41 | Taille en blocs de la zone protégée autour d’une balise de revendication de terrain |
Pour vérifier des valeurs par défaut ou repartir d’une base propre, le dépôt communautaire GameServerManagers/Game-Server-Configs sur GitHub conserve un exemplaire de référence à jour de serverconfig.xml, utile quand un guide tiers affiche des valeurs qui semblent obsolètes.
Étape 6 : personnaliser les paramètres de gameplay (sandbox)
Au-delà des réglages réseau, serverconfig.xml pilote aussi l’expérience de jeu : GameDifficulty (0 à 5, du plus facile au plus punitif), la fréquence et la durée du cycle jour/nuit, le taux de butin (loot), ou encore l’agressivité des zombies en journée. Depuis la V3.0 « Dead Hot Summer », plus de 150 options de personnalisation sandbox sont disponibles, regroupées en 11 préréglages officiels prêts à l’emploi si la configuration manuelle propriété par propriété semble trop fastidieuse pour démarrer. La V3.1 « Henpocalypse » (détaillée à l’étape 12) ajoute encore 10 options sandbox supplémentaires et réorganise la façon dont la densité et la fréquence de réapparition des ennemis et des animaux sont réglées, désormais séparées entre jour et nuit d’un côté, et ennemis et animaux de l’autre.
Le choix entre la carte fixe Navezgane et une carte générée aléatoirement (Random World Generation, RWG) se fait via la propriété GameWorld : laissez-la sur Navezgane pour une carte identique à chaque partie, ou renseignez un autre nom avec WorldGenSeed et une WorldGenSize comprise entre 2048 et 16384 pour une carte unique générée à la volée. Notez que le crossplay impose une limite de 8192 sur la taille de génération, détaillée à l’étape 11.
Étape 7 : configurer serveradmin.xml et les niveaux de permission
serveradmin.xml gère les comptes administrateurs, la liste blanche et les bannissements, sur une échelle de permission allant de 0 à 1000 :
| Niveau | Portée |
|---|---|
| 0 | Super administrateur : toutes les commandes, y compris celles non listées explicitement (une commande non répertoriée est verrouillée au niveau 0 par défaut, donc sécurisée par défaut) |
| 1 à 999 | Niveaux personnalisés que vous définissez vous-même selon vos besoins de modération |
| 1000 | Niveau par défaut de tout joueur non listé, c’est-à-dire aucun droit particulier |
Pour ajouter un administrateur, éditez serveradmin.xml :
<adminuser platformid="STEAM_ID_64" permission_level="0">
<name>VotrePseudo</name>
</adminuser>Trouver son SteamID64
Le fichier attend un SteamID64, un identifiant numérique à 17 chiffres propre à chaque compte Steam, à ne pas confondre avec le pseudo affiché en jeu. Le site steamid.io convertit n’importe quelle URL de profil Steam en SteamID64 en un clic ; c’est la méthode la plus fiable pour ne pas se tromper de joueur lors de la promotion d’un administrateur.
Étape 8 : ouvrir les ports et configurer le pare-feu
7 Days to Die utilise un ensemble précis de ports, à ne pas confondre entre eux :
| Port | Protocole | Usage | Exposition recommandée |
|---|---|---|---|
| 26900 | TCP + UDP | Connexion principale au jeu | Publique (obligatoire) |
| 26901–26903 | UDP | Données de jeu complémentaires | Publique (obligatoire) |
| 8080 | TCP | Panneau de contrôle web (optionnel) | Localhost/VPN uniquement |
| 8081 | TCP | Administration à distance par telnet (optionnel) | Localhost/VPN uniquement |
Sur un pare-feu Linux avec ufw, seule la plage de jeu doit être ouverte publiquement :
sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw enable
sudo ufw statusSur une box ou un routeur domestique, la même opération s’appelle la redirection de ports (port forwarding) : dans l’interface d’administration du routeur, redirigez le port TCP 26900 et la plage UDP 26900-26903 vers l’adresse IP locale de la machine serveur. C’est l’étape la plus souvent oubliée, et la cause numéro un d’un serveur invisible dans la liste malgré une configuration par ailleurs correcte.
Étape 9 : démarrer le serveur (Linux et Windows)
Sous Linux :
cd /home/steam/7dtd-server
./startserver.sh -configfile=serverconfig.xmlSous Windows, double-cliquez sur startdedicated.bat, ou lancez directement l’exécutable avec ses paramètres :
7DaysToDieServer.exe -quit -batchmode -nographics -configfile=serverconfig.xml -dedicatedUn démarrage sain affiche progressivement ce type de journal, jusqu’à la ligne confirmant que le monde est prêt :
Loading permissions file
GameServer waiting for players
Started thread SteamGameServer.Update
GMSG: Game name changed to 'Mon Serveur 7DTD'
GMSG: Loading world 'Navezgane'
Time: 00.00m 00.63s | GMSG: Server saved worldÉtape 10 : se connecter à votre serveur
Deux méthodes de connexion existent côté client. La première, directe par IP, est la plus fiable : dans le menu Rejoindre une partie du jeu, saisissez l’adresse IP publique du serveur suivie du port (par exemple 203.0.113.10:26900). La seconde passe par la liste des serveurs intégrée au jeu, qui recense automatiquement tout serveur dont ServerVisibility vaut 2 ; elle est plus pratique mais dépend d’une redirection de ports correcte pour apparaître, et met parfois quelques minutes à se rafraîchir après le démarrage.
Étape 11 : activer le crossplay Xbox Series X|S et PS5
Depuis la V3.0 « Dead Hot Summer », les consoles de salon actuelles reçoivent les mises à jour de 7 Days to Die le même jour que le PC, crossplay inclus dès le premier jour. Cinq conditions doivent être réunies simultanément pour qu’un serveur PC dédié accepte des joueurs Xbox Series X|S et PS5 :
- Consoles de génération actuelle uniquement : PS4 et Xbox One ne sont pas compatibles
- Dossier
Mods/vide : un serveur moddé, même légèrement, exclut le crossplay EACEnabledsurtrue: EasyAntiCheat doit rester actifServerVisibilitysur 2 (serveur public)ServerMaxPlayerCount≤ 8 etWorldGenSize≤ 8192 si la carte est générée aléatoirement
Certains guides communautaires (WinterNode, wiki.7d2d.net) mentionnent également une propriété ServerAllowCrossplay dédiée dans serverconfig.xml ; le nom est cohérent avec les autres propriétés du fichier mais n’apparaît pas dans le fichier de référence GitHub cité plus haut, à traiter donc comme une information communautaire à vérifier au cas par cas plutôt qu’une confirmation officielle de Valve ou de The Fun Pimps.
Étape 12 : migrer vers la V3.1 « Henpocalypse »
La V3.1.0 « Henpocalypse » est passée stable le 27 juillet 2026, simultanément sur PC, Xbox et PlayStation, un mois quasiment jour pour jour après la V3.0. Elle ajoute un système d’élevage de poules, un nouveau poste d’artisanat dédié (le poulailler, Chicken Coop), quatre recettes de cuisine inédites utilisant les produits de cet élevage, et dix nouvelles options sandbox. Les sauvegardes existantes migrent sans corruption depuis la V3.0, un bug historique d’exception de fin de flux (EndofStreamException) ayant été corrigé au passage.
Un point mérite une vigilance particulière pour tout administrateur de serveur déjà en production : un ancien code sandbox (SandboxCode) créé sous la V3.0 continue de se charger sans générer d’erreur sous la V3.1, mais peut appliquer des réglages différents de ceux prévus à l’origine. La mise à jour a en effet réorganisé les curseurs de densité et de fréquence de réapparition des ennemis et animaux, désormais séparés entre jour/nuit et ennemis/animaux, en réutilisant les emplacements libérés par trois anciennes options supprimées. Concrètement : si votre serveur utilise un code sandbox personnalisé, vérifiez chaque valeur une par une après la mise à jour plutôt que de faire confiance à l’absence de message d’erreur au démarrage. La V3.1 introduit aussi la possibilité de scanner, copier et partager un code sandbox via QR code depuis un téléphone, pratique pour resynchroniser plusieurs serveurs sur la même configuration.
Étape 13 : sécuriser et entretenir le serveur sur la durée
Un serveur dédié reste exposé sur Internet 24h/24, ce qui en fait une cible potentielle au même titre que n’importe quel service réseau. Trois réflexes limitent l’essentiel du risque. D’abord, ne jamais exposer publiquement les ports 8080 (panneau web) et 8081 (telnet) : par conception, un mot de passe telnet laissé vide restreint déjà l’accès au localhost, mais le plus sûr reste de ne joindre ces interfaces que via un tunnel VPN ou un SSH local, jamais directement depuis Internet. Ensuite, définissez des mots de passe robustes pour TelnetPassword et ControlPanelPassword dès l’installation, plutôt que de les laisser vides « en attendant ». Enfin, gardez le serveur à jour : chaque version stable corrige des failles et des bugs de stabilité, dont l’historique de l’EndofStreamException mentionné plus haut est un bon exemple concret.
Automatiser les sauvegardes
Une sauvegarde régulière, indépendante des sauvegardes internes du jeu, protège contre une corruption de fichier ou une fausse manipulation. Une tâche cron quotidienne suffit :
crontab -e
# Sauvegarde chaque jour à 4h du matin
0 4 * * * tar -czf /home/steam/backups/7dtd-$(date +\%Y\%m\%d).tar.gz /home/steam/7dtd-server/Saves/Combien coûte un serveur 7 Days to Die dédié en France ?
Les prix relevés chez deux hébergeurs actifs sur le marché français, Fly-Serv et HelloServ, donnent une bonne fourchette de référence pour 2026 :
| Hébergeur | Offre | RAM | vCores | Stockage | Prix mensuel |
|---|---|---|---|---|---|
| Fly-Serv | Tier 1 | 4 Go | 2 | 20 Go NVMe | 3,99 € |
| Fly-Serv | Tier 2 | 8 Go | 2 | 30 Go NVMe | 5,99 € |
| Fly-Serv | Tier 3 | 16 Go | 4 | 50 Go NVMe | 9,99 € |
| HelloServ | 7DTD-LITE | 8 Go | 2 | 40 Go SSD | 7,99 € |
| HelloServ | 7DTD-START | 12 Go | 3 | 60 Go SSD | 14,99 € |
| HelloServ | 7DTD-PLUS | 16 Go | 4 | 80 Go SSD | 19,99 € |
| HelloServ | 7DTD-PERF | 24 Go | 6 | 100 Go SSD | 28,99 € |
Les deux hébergeurs annoncent un nombre de joueurs illimité sur chaque palier, la vraie limite venant de la RAM et du CPU disponibles plutôt que d’un plafond contractuel. Le prix grimpe essentiellement avec la RAM allouée et le nombre de vCores, deux ressources directement liées à la taille de la carte et au nombre de joueurs simultanés, détaillés dans la section matérielle ci-dessous.
Louer une offre clé en main ou auto-héberger sur un VPS ?
Une offre clé en main comme celles du tableau ci-dessus convient à qui veut un serveur fonctionnel en quelques minutes, sans gérer de pare-feu ni de mises à jour manuelles : le panneau de contrôle de l’hébergeur s’en charge. L’auto-hébergement sur un VPS générique (OVH, Hetzner ou équivalent) demande de suivre les étapes 2 à 9 de ce guide manuellement, mais laisse un contrôle total sur la machine : utile si le même serveur doit aussi héberger d’autres services, ou si des mods nécessitant un accès disque étendu sont prévus.
Configuration matérielle recommandée
The Fun Pimps ne publie pas de configuration matérielle officielle pour l’hébergement dédié ; les repères ci-dessous reflètent un consensus communautaire éprouvé plutôt qu’une spécification éditeur :
| Joueurs | RAM | CPU | Stockage |
|---|---|---|---|
| 1 à 4 (vanilla) | 4 à 6 Go | Bi-cœur 3,0 GHz+ | 10 à 15 Go SSD |
| 8 (référence par défaut) | 8 Go | Bi-cœur 3,0 GHz+ | 15 Go SSD |
| 8+ ou moddé | 12 à 16 Go+ | Quad-cœur 3,2-3,5 GHz+ | 25 Go+ SSD |
Le point souvent sous-estimé : 7 Days to Die reste majoritairement mono-thread côté serveur. Le calcul de chemin des zombies (pathfinding), le chargement des chunks et la simulation de la horde de la nuit sanglante s’appuient lourdement sur un seul cœur. La fréquence d’horloge par cœur compte donc davantage que le nombre total de cœurs disponibles : un processeur quad-cœur à fréquence modeste sera souvent moins performant qu’un bi-cœur cadencé plus haut pour ce jeu spécifiquement.
Mettre à jour le serveur en toute sécurité
Au-delà du cas précis de la migration vers la V3.1 détaillé à l’étape 12, The Fun Pimps a livré deux versions stables majeures en un mois quasiment jour pour jour (29 juin puis 27 juillet 2026). Un administrateur de serveur doit donc partir du principe que ce rythme va se répéter, et traiter chaque mise à jour, petite ou grande, avec la même procédure plutôt qu’à l’improviste.
La séquence qui limite le risque de corruption ou de mauvaise surprise se déroule toujours dans le même ordre : prévenir les joueurs connectés via say en telnet, arrêter proprement le service (sudo systemctl stop 7dtd si vous suivez la configuration systemd de la section astuces avancées), lancer une sauvegarde manuelle du dossier Saves/ même si la tâche cron quotidienne existe déjà, puis relancer la même commande app_update que celle utilisée à l’étape 3, cette fois sans nécessairement l’option validate pour une mise à jour mineure, mais en la conservant pour tout changement de version majeure (3.0 → 3.1, par exemple). Une fois le téléchargement terminé, comparez la version affichée dans le journal de démarrage du serveur avec celle annoncée côté client avant de rouvrir l’accès : un décalage de version est la cause la plus fréquente d’un serveur qui refuse la connexion à des joueurs pourtant à jour.
Pour une communauté de plusieurs dizaines de joueurs, il est également raisonnable de tester une mise à jour majeure sur une copie du monde de production, dans un dossier Saves/ distinct, avant de l’appliquer au monde réel : une heure de test suffit généralement à repérer un mod devenu incompatible ou un ancien code sandbox qui se comporte différemment, plutôt que de le découvrir en pleine nuit sanglante devant des joueurs mécontents.
Erreurs fréquentes à éviter
- Confondre les App ID 294420 et 251570 : le premier est l’outil serveur (gratuit, login anonyme), le second le jeu client. Utiliser le mauvais ID dans SteamCMD fait échouer l’installation ou télécharge le mauvais produit.
- Oublier la redirection de ports sur le routeur : un pare-feu logiciel correctement configuré ne suffit pas si le routeur domestique ne redirige pas aussi le trafic vers la machine serveur.
- Désactiver EasyAntiCheat pour installer un mod, puis s’étonner que le crossplay ne fonctionne plus : les deux sont directement liés, ce n’est pas un bug.
- Appliquer un ancien code sandbox V3.0 sans le revérifier après la migration V3.1 : il se charge sans erreur mais peut modifier silencieusement le réglage de densité des ennemis, voir l’étape 12.
- Régler MaxSpawnedZombies trop haut : au-delà d’environ 80, le framerate du serveur se dégrade nettement pendant la nuit sanglante, d’après le commentaire du fichier de configuration de référence lui-même.
- Laisser TelnetPassword ou ControlPanelPassword vides tout en ouvrant ces ports publiquement : à ne jamais faire, voir l’étape 13.
- Ne pas sauvegarder avant une mise à jour majeure : la migration V3.0 → V3.1 est documentée comme sûre, mais l’historique du jeu (bug EndofStreamException) justifie une sauvegarde systématique par précaution avant toute mise à jour.
Dépannage : résoudre les problèmes courants
Le message « Success! » n’apparaît jamais après app_update.
Vérifiez l’espace disque disponible (15 Go minimum) et relancez la commande ; un téléchargement interrompu reprend généralement là où il s’est arrêté.
Le serveur démarre mais n’apparaît pas dans la liste des serveurs en jeu.
Vérifiez dans l’ordre : ServerVisibility=2, la redirection de ports sur le routeur, puis le pare-feu logiciel (ufw/iptables) sur la machine elle-même.
Les joueurs rejoignent par IP directe mais le serveur reste invisible dans la liste publique.
C’est le symptôme classique d’un problème de NAT loopback ou d’une redirection de ports mal configurée : la connexion directe passe par le réseau local, la liste publique dépend elle du trafic entrant depuis l’extérieur.
Les joueurs Xbox ou PS5 ne parviennent pas à rejoindre.
Repassez en revue les cinq conditions du crossplay à l’étape 11 : dossier Mods vide, EACEnabled=true, ServerVisibility=2, 8 joueurs maximum, WorldGenSize ≤ 8192.
Le serveur rame fortement pendant la nuit sanglante (horde night).
Réduisez MaxSpawnedZombies en dessous de 60-70 et vérifiez que le CPU alloué a une fréquence par cœur élevée, le goulot d’étranglement étant presque toujours mono-thread sur ce jeu.
La connexion telnet est refusée.
Confirmez que TelnetEnabled=true, que TelnetPort correspond bien à 8081 dans votre commande de connexion, et que rien ne bloque le port en local (le port ne doit toutefois jamais être ouvert publiquement, voir l’étape 13).
Les réglages sandbox se comportent différemment après la mise à jour V3.1.
Un ancien SandboxCode V3.0 en est presque toujours la cause : régénérez-le ou vérifiez chaque valeur individuellement plutôt que de réappliquer l’ancien code tel quel.
Le monde ne se charge plus après une mise à jour.
Restaurez la dernière sauvegarde automatisée (voir l’étape 13) et vérifiez la version exacte du serveur par rapport à celle du client : les deux doivent toujours correspondre.
Le panneau de contrôle web reste inaccessible à distance.
C’est le comportement voulu par sécurité : n’ouvrez ce port que via un tunnel VPN ou SSH, jamais directement sur Internet.
Astuces avancées pour aller plus loin
Une fois le serveur stable, quelques réglages supplémentaires améliorent nettement l’expérience d’administration au quotidien.
Redémarrage automatique avec systemd (Linux). Un service systemd relance le serveur automatiquement en cas de crash ou de redémarrage de la machine :
[Unit]
Description=Serveur 7 Days to Die
After=network.target
[Service]
User=steam
WorkingDirectory=/home/steam/7dtd-server
ExecStart=/home/steam/7dtd-server/startserver.sh -configfile=serverconfig.xml
Restart=on-failure
[Install]
WantedBy=multi-user.targetEnregistrez ce fichier sous /etc/systemd/system/7dtd.service, puis activez-le avec sudo systemctl enable --now 7dtd.
Administration à distance par telnet. Une fois connecté via un tunnel VPN ou SSH local, telnet permet d’envoyer des commandes serveur sans redémarrer :
telnet 127.0.0.1 8081
# Une fois authentifié avec TelnetPassword :
listplayers
say "Redémarrage dans 5 minutes"
saveworldMods populaires. Deux extensions communautaires dominent la scène 7 Days to Die : Darkness Falls, une refonte complète orientée progression et exploration, et Undead Legacy, centrée sur un artisanat et une économie approfondis. Les deux s’installent en copiant leur dossier dans Mods/ puis en redémarrant le serveur ; rappelez-vous toutefois qu’un serveur moddé perd automatiquement l’accès au crossplay console (étape 11).
Votre projet complet : récapitulatif fonctionnel
À l’issue des 13 étapes, l’installation complète tient dans une poignée de fichiers et un unique service actif : les binaires serveur installés sous l’App ID 294420 via SteamCMD, un serverconfig.xml avec un port de jeu ouvert (26900 + 26901-26903 UDP) et le web/telnet restreints au local, un serveradmin.xml listant vos administrateurs par SteamID64, un service systemd (ou son équivalent NSSM sous Windows) qui relance le serveur automatiquement, et une tâche cron de sauvegarde quotidienne. C’est cette combinaison, et non un seul fichier de configuration isolé, qui constitue un serveur 7 Days to Die dédié réellement prêt pour la production : accessible aux joueurs PC comme, si les conditions de l’étape 11 sont réunies, aux joueurs Xbox Series X|S et PS5, à jour sur la V3.1 « Henpocalypse », et protégé contre l’exposition accidentelle de ses interfaces d’administration.
Foire aux questions
Faut-il posséder 7 Days to Die pour héberger un serveur dédié ?
Non. L’outil serveur (App ID 294420) se télécharge gratuitement via une connexion Steam anonyme, indépendamment de la possession du jeu client (App ID 251570).
Quels ports dois-je ouvrir pour un serveur 7 Days to Die dédié ?
Le port 26900 en TCP et UDP, ainsi que la plage UDP 26901-26903, doivent être ouverts publiquement. Les ports 8080 (panneau web) et 8081 (telnet) restent optionnels et ne doivent jamais être exposés directement sur Internet.
Peut-on jouer entre PC, Xbox Series X|S et PS5 sur le même serveur ?
Oui, depuis la V3.0 « Dead Hot Summer », à condition que le serveur reste non moddé, qu’EasyAntiCheat soit activé, qu’il soit public et limité à 8 joueurs maximum.
Combien de RAM faut-il pour un serveur 7 Days to Die à 8 joueurs ?
8 Go constituent la référence communautaire pour un usage confortable non moddé ; comptez 12 à 16 Go ou plus avec des mods ou davantage de joueurs.
Combien coûte un serveur 7 Days to Die dédié en France ?
Les offres clé en main démarrent autour de 4 à 8 € par mois pour un petit groupe, et montent vers 20 à 35 € par mois pour une configuration plus généreuse en RAM et en vCores, d’après les grilles tarifaires actuelles de Fly-Serv et HelloServ.
Comment savoir si mon serveur tourne en V3.0 ou en V3.1 ?
La version s’affiche dans le journal de démarrage du serveur et dans le menu principal du jeu côté client ; en cas de doute, comparez avec la date de sortie de chaque version (29 juin 2026 pour la V3.0, 27 juillet 2026 pour la V3.1).
Un ancien code sandbox de la V3.0 va-t-il casser mon serveur après la mise à jour V3.1 ?
Il continuera de se charger sans erreur, mais peut appliquer des réglages de densité d’ennemis différents de ceux prévus à l’origine ; revérifiez chaque valeur individuellement après la migration.
Un serveur dédié est-il plus sûr qu’un serveur hébergé depuis son propre PC ?
Un serveur dédié isole le jeu sur une machine séparée et permet de restreindre précisément les ports exposés ; un serveur d’écoute lancé depuis un PC personnel expose souvent ce même PC à des ports ouverts sans configuration de pare-feu aussi fine.
Peut-on héberger plusieurs mondes sur le même serveur 7 Days to Die ?
Oui, techniquement, en dupliquant l’installation dans un dossier distinct avec son propre ServerPort et sa propre instance de processus ; chaque monde consomme alors sa propre part de RAM et de CPU, ce qui n’est vraiment confortable que sur les paliers matériels les plus généreux du tableau tarifaire ci-dessus.
Contenus liés
- Toute l’actualité Jeux Vidéo sur shattered.io
- Serveur Terraria dédié : 12 étapes, 30 min
- Serveur Project Zomboid dédié : 12 étapes, 30 min
- Serveur Satisfactory dédié : 12 étapes, 30 min
- Serveur Enshrouded dédié : 12 étapes, 30 min
- Serveur Rust dédié : 12 étapes, 30 min
- Serveur Palworld dédié : 12 étapes, 30 min
