Serveur 7 Days to Die privé : mot de passe, whitelist et visibilité
Un serveur 7 Days to Die public attire vite des inconnus… et parfois des griefers qui rasent une base construite pendant des semaines. Le jeu propose trois outils pour garder la main : le mot de passe, la visibilité dans la liste des serveurs et la whitelist. On peut les combiner.
🔒 Serveur entre vous
Votre serveur 7DTD privé, 24/7
Notre hébergeur 7 Days to Die dès 8,90 €/mois : mot de passe et whitelist en quelques clics, Anti-DDoS 5 Tbps, Ryzen 9 5950X et support FR 24/7.
Quelle protection choisir ?
| Besoin | Outil | Niveau de protection |
|---|---|---|
| Serveur entre amis, simple | Mot de passe | Moyen : le mot de passe peut circuler |
| Ne pas apparaître dans la liste publique | Visibilité | Faible seul : l’IP reste joignable |
| Contrôle nominatif des joueurs | Whitelist | Fort : seuls les joueurs listés entrent |
| Serveur communautaire semi-ouvert | Mot de passe + règles à l’entrée + bans | Selon modération |
Méthode 1 — Le mot de passe
Dans serverconfig.xml :
<property name="ServerPassword" value="MotDePasseSolide"/>
Chaque joueur devra saisir ce mot de passe en rejoignant. Laissez la valeur vide ("") pour un serveur ouvert.
Changez le mot de passe si un joueur quitte le groupe en mauvais termes, et communiquez-le en message privé plutôt que sur un Discord public.
Méthode 2 — La visibilité dans la liste des serveurs
<property name="ServerVisibility" value="0"/>
| Valeur | Effet (d’après le commentaire officiel du fichier) |
|---|---|
2 | Public : listé dans le navigateur de serveurs |
1 | Visible par les amis seulement |
0 | Non listé |
Deux subtilités :
- Le fichier officiel précise qu’on n’est jamais ami avec un serveur dédié : avec la valeur
1, le serveur n’apparaît qu’une fois qu’un premier joueur s’est connecté manuellement par IP. - Un serveur non listé reste joignable par IP (
IP:26900) : ce n’est pas une protection en soi. Combinez-le avec un mot de passe ou une whitelist.
Crossplay : les joueurs PS5 / Xbox passent par le navigateur de serveurs. Un serveur crossplay doit rester public (
2) : protégez-le plutôt avec un mot de passe ou une whitelist. Voir crossplay sur un serveur 7DTD.
Méthode 3 — La whitelist (la plus sûre)
La whitelist se trouve dans serveradmin.xml. Le fichier officiel le dit en commentaire : dès qu’une entrée existe dans la whitelist, le mode « whitelist only » s’active, et plus personne ne peut entrer s’il n’est pas dans la whitelist ou dans les admins.
Ajouter des joueurs dans le fichier
Serveur arrêté, ajoutez vos joueurs dans la section <whitelist> :
<whitelist>
<user platform="Steam" userid="76561198012345678" name="Alice" />
<user platform="Steam" userid="76561198087654321" name="Bob" />
</whitelist>
Les joueurs console ou Epic s’ajoutent avec leur plateforme (EOS, XBL, PSN) et leur identifiant. Pour trouver les identifiants, voir devenir admin sur un serveur 7DTD.
Ou depuis la console
whitelist add <nom / identifiant>
whitelist remove <nom / identifiant>
whitelist list
Pratique : un joueur connecté peut être ajouté par son nom. Tapez help whitelist pour la syntaxe exacte de votre version.
N’oubliez pas les admins : ils peuvent toujours entrer, mais pensez à ajouter vos modérateurs non-admins à la whitelist avant de l’activer.
Désactiver la whitelist
Videz la section <whitelist> (ou retirez tous les joueurs avec whitelist remove) : le serveur redevient ouvert.
Bannir un joueur
Pour un serveur semi-public, le ban reste l’outil principal :
ban add <nom / entity id / identifiant> <durée> <unité> [raison]
ban remove <identifiant>
ban list
Exemple : ban add Griefer42 30 days "destruction de base". Les bans sont enregistrés dans la section <blacklist> de serveradmin.xml, avec date de fin et raison. Plus de commandes dans la liste des commandes admin 7DTD.
Bonus — Faire accepter les règles à l’entrée
serverconfig.xml propose une propriété peu connue :
<property name="ServerLoginConfirmationText" value="Pas de raid des bases alliées. Discord : discord.gg/xxxx"/>
Si elle est renseignée, chaque joueur voit ce message en rejoignant et doit le confirmer pour continuer. Idéal pour afficher les règles d’un serveur communautaire.
FAQ
Le mot de passe suffit-il pour un serveur entre amis ?
Oui pour un petit groupe de confiance. Dès que le groupe s’élargit ou que le mot de passe circule, passez à la whitelist.
J’ai activé la whitelist et plus personne ne peut entrer
C’est le comportement voulu : seuls les joueurs listés et les admins entrent. Ajoutez vos joueurs avec whitelist add ou dans serveradmin.xml.
Un serveur non listé est-il invisible ?
Il n’apparaît pas dans la liste, mais reste joignable par son IP. Ajoutez un mot de passe.
Peut-on avoir une whitelist sur un serveur crossplay ?
Rien dans la documentation officielle ne l’interdit : ajoutez les joueurs console avec leur plateforme et leur identifiant (visibles via listplayerids quand ils se connectent).
Conclusion
Pour un groupe d’amis : mot de passe. Pour une communauté sérieuse : whitelist + admins + message de règles. Et dans tous les cas, gardez des sauvegardes régulières : c’est la seule vraie protection contre un grief qui passerait entre les mailles.
Pour aller plus loin
- Meilleur hébergeur 7 Days to Die 2026
- Devenir admin sur un serveur 7DTD
- Commandes admin 7 Days to Die
- Créer un serveur 7 Days to Die entre amis
Sources : commentaires du
serverconfig.xmlofficiel (ServerPassword,ServerVisibility,ServerLoginConfirmationText— copie LinuxGSM), commentaires duserveradmin.xmlofficiel (mode whitelist only — reproduits sur wiki.7d2d.net), format V1 serveradmin.xml (r-pufky), wiki officiel — Command Console.