Terraria continue de battre des records de fréquentation près de quinze ans après sa sortie, porté par la mise à jour 1.4.5 « Bigger and Boulder » sortie le 27 janvier 2026. Contrairement au mode « héberger et jouer » intégré au client, un serveur Terraria dédié tourne en continu sur une machine séparée, sans dépendre de la connexion ou de la présence d’un joueur hôte. C’est la seule option viable pour une communauté qui veut un monde persistant accessible 24 heures sur 24, avec des sauvegardes fiables et une administration centralisée via TShock. Ce guide détaille, en 12 étapes vérifiées, l’installation complète d’un serveur Terraria dédié sous Linux : téléchargement via SteamCMD, configuration du fichier serverconfig.txt, ouverture des ports, sécurisation et automatisation du démarrage. Toutes les données techniques ci-dessous ont été vérifiées fin juillet 2026 directement auprès des sources officielles (wiki Terraria, dépôt GitHub de TShock, API Steam).

Pourquoi installer un serveur Terraria dédié ?

Le mode multijoueur le plus simple de Terraria consiste à lancer une partie en solo puis à basculer sur « Héberger et jouer » (Host & Play) directement depuis le client. Cette solution fonctionne pour une session ponctuelle entre deux ou trois amis, mais elle a une limite structurelle : dès que le joueur hôte quitte la partie ou éteint son PC, le monde devient inaccessible pour tout le monde. Aucune sauvegarde automatique programmée, aucune gestion fine des droits, et l’ordinateur de l’hôte doit rester allumé en permanence.

Un serveur dédié résout ces trois problèmes à la fois. Le monde reste disponible même si aucun joueur n’est connecté, la machine peut tourner sur un boîtier dédié, un NAS ou une petite instance cloud plutôt que sur le PC de jeu de quelqu’un, et l’ajout de TShock permet de créer des comptes administrateur, de bannir un joueur toxique ou de restaurer une sauvegarde en quelques secondes. Pour une communauté Discord, un serveur de jeu entre collègues ou un projet de construction collaboratif de longue durée, c’est la seule approche qui tienne dans la durée. C’est aussi la configuration qui rapproche le plus Terraria d’un jeu de type survie persistante, à la manière de ce qu’on retrouve avec un serveur Project Zomboid dédié ou un serveur Enshrouded.

Enfin, un serveur dédié permet d’exposer volontairement une machine sur Internet – ce qui implique une responsabilité de sécurisation que le mode « Héberger et jouer », resté local, n’a pas. C’est un point que ce guide traite comme une étape à part entière, pas comme une note en bas de page.

Ce choix se justifie particulièrement pour les projets de construction de longue haleine, très courants dans la communauté Terraria : reproductions de villes, mégastructures en fil de fer redstone-like, ou parcours PvP construits sur plusieurs semaines par plusieurs contributeurs à des horaires différents. Sur un monde hébergé en local par un joueur, chaque session de construction dépend de la disponibilité de cette seule personne. Sur un serveur dédié, n’importe quel contributeur peut se connecter à toute heure, ajouter sa contribution, puis se déconnecter sans jamais interrompre l’accès des autres – un fonctionnement bien plus proche de la manière dont tournent des jeux orientés serveur permanent comme Minecraft ou Valheim.

Prérequis : versions et matériel nécessaires

Avant de commencer, voici l’ensemble des éléments à réunir. Chaque version citée a été vérifiée directement via l’API Steam, le dépôt GitHub officiel ou le wiki Terraria – aucune n’est une estimation.

  • Un exemplaire légitime de Terraria sur Steam (App ID 105600), ou un compte Steam anonyme suffisant pour SteamCMD – le jeu n’a pas besoin d’être possédé pour télécharger uniquement les fichiers serveur.
  • Une machine Linux (Debian, Ubuntu ou équivalent) avec un accès shell – un VPS, un NAS Synology/QNAP ou un boîtier domestique conviennent tous.
  • SteamCMD, l’outil en ligne de commande officiel de Valve pour télécharger des contenus Steam sans interface graphique.
  • TShock v6.1.0 (« TShock 6.1 for Terraria 1.4.5.6 »), publié le 11 mars 2026, si vous voulez une couche d’administration – fortement recommandé, voir la section suivante.
  • Au minimum 512 Mo de RAM disponibles pour un petit monde à quelques joueurs ; comptez 1 à 2 Go pour un monde plus grand avec une dizaine de joueurs simultanés (voir le tableau de configuration matérielle plus bas).
  • Un accès administrateur à votre routeur/box pour la redirection de port, et à un pare-feu logiciel (ufw, iptables) sur la machine elle-même.
  • Terraria est actuellement en version 1.4.5.6 côté PC (mise à jour « Bigger and Boulder », sortie le 27 janvier 2026, stabilisée le 9 mars 2026) – vérifiez que votre client correspond à cette version avant de vous connecter, un décalage de version empêche la connexion.
  • Une bande passante montante correcte si le serveur reste chez vous plutôt que sur un VPS : le trafic Terraria par joueur reste léger (quelques dizaines de Ko/s en régime normal), mais une ligne asymétrique avec un upload très limité peut se faire sentir au-delà d’une dizaine de connexions simultanées.

Si vous prévoyez d’utiliser des mods via tModLoader plutôt qu’un serveur vanilla ou TShock, notez dès maintenant que tModLoader reste sur la branche 1.4.4 : aucune version stable compatible 1.4.5 n’était disponible à la date de rédaction de cet article (juillet 2026). Ce point est développé dans la section suivante.

Vanilla, TShock ou tModLoader : quelle version choisir ?

Terraria propose en réalité trois chemins distincts pour héberger un serveur, et le choix conditionne toutes les étapes suivantes de ce guide. Voici comment trancher selon votre usage.

Serveur vanilla (officiel, sans mod)

Le serveur vanilla est le binaire officiel fourni par Re-Logic (TerrariaServer.exe sous Windows, TerrariaServer.bin.x86_64 sous Linux). Il ne propose aucune gestion d’administration au-delà d’un mot de passe global et d’un fichier de configuration texte : pas de comptes individuels, pas de bannissement à distance, pas de journal de connexions détaillé. C’est suffisant pour un petit groupe de confiance qui ne cherche pas à modérer activement le serveur. Le serveur vanilla 1.4.5 fonctionne dès aujourd’hui sans réserve : si votre groupe joue en configuration non modifiée, il est directement à jour.

TShock (recommandé pour la plupart des serveurs communautaires)

TShock s’installe par-dessus les fichiers serveur vanilla et ajoute une couche complète de modération : comptes utilisateurs avec mots de passe individuels, groupes de permissions, personnages côté serveur (Server Side Characters, qui empêchent la triche par modification de fichier de sauvegarde local), commandes de bannissement, de kick et de mute, et un système de plugins en C#. La version courante, TShock 6.1.0, cible spécifiquement Terraria 1.4.5.6 et a corrigé une faille de sécurité liée à la modification d’UUID après connexion – une bonne raison à elle seule de migrer depuis une version 6.0.x. TShock est un projet open source sous licence GPL-3.0, avec plus de 2 850 étoiles sur son dépôt GitHub officiel, ce qui en fait de loin la couche d’administration la plus utilisée pour Terraria. C’est l’option retenue pour la suite de ce tutoriel.

tModLoader (pour les serveurs avec mods)

tModLoader est une application Steam gratuite et distincte qui permet de charger des mods communautaires côté serveur comme côté client. Il impose une contrainte stricte : chaque joueur qui se connecte doit avoir installé exactement le même chargeur de mods et la même liste de mods que le serveur, sans quoi la connexion échoue. Point important pour ce choix en 2026 : tModLoader reste sur la branche 1.4.4 et n’a, à la date de rédaction, aucune version stable compatible avec 1.4.5 – une version modée est donc mécaniquement en retard d’une mise à jour majeure par rapport au vanilla et à TShock. Si l’accès aux derniers contenus 1.4.5 (crossover Dead Cells, refonte de l’interface d’artisanat) est prioritaire pour votre groupe, un serveur vanilla ou TShock est actuellement le seul choix cohérent.

Étape 1 : Vérifier la configuration système et préparer un compte Steam

Commencez par confirmer que la machine cible dispose d’au moins 1 Go de RAM libre (2 Go recommandés si vous visez plus de 10 joueurs simultanés), d’un processeur récent à 2 GHz ou plus, et d’un accès shell en SSH si c’est un serveur distant. Vérifiez aussi qu’aucun autre service n’utilise déjà le port 7777 en TCP ou en UDP :

sudo ss -tulnp | grep 7777

Si la commande ne renvoie rien, le port est libre. Vous n’avez besoin d’un compte Steam payant que si vous voulez héberger le serveur depuis une copie du jeu déjà installée (par exemple sous Windows, via l’assistant intégré). Pour un déploiement Linux via SteamCMD, une connexion anonyme suffit pour télécharger les fichiers serveur – Terraria est l’un des jeux dont les fichiers dédiés serveur sont librement distribués via ce mécanisme, sans qu’il soit nécessaire de posséder le jeu sur ce compte.

Étape 2 : Installer SteamCMD

SteamCMD est l’outil en ligne de commande de Valve qui permet de télécharger n’importe quel contenu Steam, y compris des fichiers de serveur dédié, sans passer par le client graphique. Sous Debian/Ubuntu, activez d’abord les dépôts 32 bits (SteamCMD reste un binaire 32 bits même pour télécharger des jeux 64 bits) :

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd lib32gcc-s1 lib32stdc++6

Créez ensuite un utilisateur système dédié – ne faites jamais tourner un serveur de jeu exposé sur Internet sous le compte root, c’est l’une des erreurs les plus fréquentes et les plus évitables de ce type d’installation :

sudo useradd -m -s /bin/bash terraria
sudo su - terraria

Toutes les commandes des étapes suivantes s’exécutent depuis ce compte utilisateur non privilégié, pas depuis root.

Étape 3 : Télécharger les fichiers du serveur Terraria via SteamCMD

Lancez SteamCMD et téléchargez l’App ID 105600, qui correspond à Terraria – le même identifiant sert à la fois pour le jeu et pour les fichiers serveur dédié :

steamcmd +force_install_dir /home/terraria/server \
  +login anonymous \
  +app_update 105600 validate \
  +quit

Le téléchargement place trois builds côte à côte dans le dossier : un sous-dossier Windows, un sous-dossier Mac et un sous-dossier Linux. C’est ce dernier qui contient le binaire dont vous avez besoin, TerrariaServer.bin.x86_64. Rendez-le exécutable :

chmod +x /home/terraria/server/Linux/TerrariaServer.bin.x86_64

À ce stade, vous avez un serveur vanilla fonctionnel. Si votre groupe n’a pas besoin de comptes administrateur ni de modération avancée, vous pouvez passer directement à l’étape 5 (configuration). Pour la grande majorité des serveurs communautaires, l’étape suivante – l’ajout de TShock – vaut cependant largement les cinq minutes supplémentaires qu’elle demande.

Étape 4 : Installer TShock par-dessus les fichiers vanilla

Téléchargez l’archive Linux x64 de TShock 6.1.0 depuis la page officielle des releases GitHub. Le nom exact de l’asset suit le format TShock-6.1.0-for-Terraria-1.4.5.6-linux-x64-Release.zip :

cd /home/terraria
wget https://github.com/Pryaxis/TShock/releases/download/v6.1.0/TShock-6.1.0-for-Terraria-1.4.5.6-linux-x64-Release.zip
unzip TShock-6.1.0-for-Terraria-1.4.5.6-linux-x64-Release.zip -d tshock
chmod +x tshock/TShockLauncher

TShock 6.1.0 est bâti sur .NET 9 et distribué en publication autonome (self-contained) – inutile d’installer le runtime .NET séparément, l’archive Linux x64 pèse environ 34 Mo et embarque tout le nécessaire. TShock ne remplace pas les fichiers vanilla : il les encapsule et ajoute sa propre couche de gestion par-dessus, via le lanceur TShockLauncher. C’est cette étape qui débloque les comptes individuels, les groupes de permissions et les Server Side Characters évoqués plus haut.

Étape 5 : Configurer le fichier serverconfig.txt

Que vous tourniez en vanilla ou sous TShock, le comportement du serveur est piloté par un fichier texte, serverconfig.txt, dont les clés sont identiques dans les deux cas – TShock lit et respecte ce même fichier. Le wiki officiel de Terraria tient à jour la liste complète de ces paramètres ; celle ci-dessous reprend les clés les plus utiles en pratique. Créez le fichier à la racine du dossier serveur :

port=7777
maxplayers=16
password=votremotdepasse
motd=Bienvenue sur le serveur !
worldname=MonMonde
autocreate=2
difficulty=1
upnp=0
secure=1
language=fr-FR

Le tableau suivant détaille chaque clé disponible, sa plage de valeurs et son rôle exact :

ParamètreValeurs possiblesDescription
port1–65535Port d’écoute du serveur ; 7777 est la valeur par défaut, en TCP et UDP simultanément.
maxplayers1–255Nombre maximal de connexions simultanées. Le modèle généré automatiquement affiche encore 8 par défaut, alors que le client lui-même est passé de 8 à 16 comme valeur par défaut depuis la mise à jour 1.4.0.1 – pensez à l’augmenter explicitement.
passwordtexte libreMot de passe de connexion ; laissez vide pour un serveur public sans protection par mot de passe.
motdtexte libreMessage du jour affiché à la connexion.
worldnametexte libreNom du monde généré si aucun fichier .wld existant n’est fourni.
worldchemin completChemin absolu vers un fichier .wld déjà existant, à charger au lieu d’en générer un nouveau.
autocreate1, 2 ou 3Taille du monde (petit/moyen/grand) généré à la création. Ignoré si le paramètre world pointe vers un fichier existant.
difficulty0–30=normal, 1=expert, 2=maître, 3=voyage.
upnp0 ou 1Active la redirection de port automatique via UPnP si le routeur le supporte.
secure0 ou 1Active des vérifications anticheat basiques côté serveur.
languagecode langue (ex. fr-FR)Langue des messages du serveur.

Le serveur accepte aussi ces mêmes réglages en ligne de commande via des drapeaux équivalents (-config, -port, -players, -password, -world, -autocreate, -secure, -steam, -seed), utile pour surcharger ponctuellement une valeur sans modifier le fichier.

Étape 6 : Générer ou importer un monde

Deux options s’offrent à vous. Si serverconfig.txt définit autocreate mais qu’aucun fichier world n’est spécifié, le serveur générera un nouveau monde au premier lancement, avec une taille correspondant à la valeur choisie (1=petit, quelques Mo ; 2=moyen, quelques dizaines de Mo ; 3=grand, 40 Mo ou plus une fois exploré et construit). Si vous avez déjà un monde existant – par exemple exporté depuis une partie solo – copiez le fichier .wld dans le dossier serveur et référencez son chemin complet via le paramètre world :

world=/home/terraria/server/Linux/Worlds/MonMonde.wld

Attention à l’ordre de priorité : le paramètre autocreate n’a strictement aucun effet si le fichier désigné par world existe déjà sur le disque – dans ce cas, le serveur charge simplement le monde existant tel quel, quelle que soit la valeur d’autocreate. C’est une confusion fréquente à l’origine de mondes générés par erreur alors qu’on pensait charger une sauvegarde.

Le choix de la taille mérite réflexion avant de lancer la génération : un petit monde se termine plus vite en exploration complète (utile pour une session courte entre quelques amis ou un run orienté vitesse), tandis qu’un grand monde offre davantage de biomes, de structures souterraines et de place pour des constructions ambitieuses, au prix d’un fichier de sauvegarde plus lourd et d’un temps de génération initial plus long. Pour un serveur communautaire destiné à durer plusieurs mois, la taille « grande » reste le choix le plus courant malgré son coût en stockage.

Étape 7 : Ouvrir le port 7777 sur le routeur et le pare-feu

Terraria communique sur le port 7777, en TCP et en UDP simultanément – c’est le piège le plus courant de cette étape : de nombreux guides ne mentionnent que le TCP, alors que les deux protocoles doivent être ouverts pour une connexion fiable. Sur la box/le routeur, créez une redirection de port (port forwarding) vers l’adresse IP locale de la machine serveur pour le port 7777 en TCP et en UDP. Sur la machine elle-même, si un pare-feu logiciel est actif :

sudo ufw allow 7777/tcp
sudo ufw allow 7777/udp
sudo ufw status

Si vous préférez gérer le filtrage directement via iptables plutôt que via ufw, la logique d’ouverture de port est la même – consultez notre tutoriel iptables pour sécuriser un serveur Linux pour le détail des règles. Un service comme Fail2ban est également recommandé en complément dès qu’un serveur de jeu est exposé publiquement, pour limiter les tentatives de connexion abusives sur le port SSH de la machine (un vecteur d’attaque totalement indépendant du jeu lui-même, mais qui concerne toute machine exposée sur Internet).

Étape 8 : Lancer le serveur pour la première fois

Pour un serveur vanilla, lancez directement le binaire Linux en pointant vers votre fichier de configuration :

cd /home/terraria/server/Linux
./TerrariaServer.bin.x86_64 -config /home/terraria/serverconfig.txt

Pour un serveur TShock, utilisez plutôt le lanceur dédié, qui démarre TerrariaServer en arrière-plan puis charge la couche TShock par-dessus :

cd /home/terraria/tshock
./TShockLauncher -config /home/terraria/serverconfig.txt

Au premier démarrage, si aucun monde n’existe encore, la génération peut prendre de quelques secondes à plusieurs minutes selon la taille choisie. Une fois que la console affiche Server started (ou l’équivalent TShock), le serveur écoute activement sur le port configuré et accepte les connexions entrantes.

Étape 9 : Se connecter au serveur depuis le client Terraria

Depuis le client Terraria (obligatoirement en version 1.4.5.6 pour correspondre au serveur), sélectionnez « Multijoueur » puis « Rejoindre via IP ». Renseignez l’adresse IP publique du serveur (ou son IP locale si vous testez depuis le même réseau) suivie du port si différent de 7777 :

<IP_PUBLIQUE_DU_SERVEUR>:7777

Un décalage de version entre client et serveur est la cause la plus fréquente d’échec de connexion à ce stade – si le client affiche un rejet immédiat, vérifiez en priorité que les deux sont bien alignés sur 1.4.5.6 avant de creuser du côté réseau. Concernant le crossplay avec les versions mobile et console : la « Phase 1 », qui permet à des clients mobiles de rejoindre un serveur hébergé sur PC, est active depuis la mise à jour de février 2026. Le crossplay côté console reste en revanche toujours en cours de finalisation à la date de rédaction – ne présumez pas qu’une connexion depuis PlayStation ou Xbox fonctionnera de la même manière tant que Re-Logic ne l’a pas confirmé explicitement.

Étape 10 : Configurer les comptes administrateur et les permissions TShock

Une fois connecté au serveur en jeu, ouvrez la console de chat et créez votre premier compte superadmin directement depuis la console serveur (pas depuis le chat en jeu, pour des raisons de sécurité) :

user add MonPseudo motdepassefort superadmin

Connectez-vous ensuite en jeu avec /login MonPseudo motdepassefort. TShock organise les permissions par groupes (par défaut : guest, default, admin, superadmin), chacun avec un ensemble de commandes autorisées – vous pouvez créer des groupes intermédiaires pour des modérateurs de confiance sans leur donner un accès superadmin complet. Les commandes de modération courantes incluent /kick, /ban, /mute et /tempban. Les Server Side Characters (activés par défaut sous TShock) stockent l’inventaire et les statistiques de chaque joueur côté serveur plutôt que dans un fichier local modifiable – c’est la protection anticheat la plus efficace disponible pour ce jeu, et une raison de plus de préférer TShock à un serveur vanilla pour tout serveur ouvert à des inconnus.

Étape 11 : Sécuriser le serveur (sauvegardes, mises à jour, anti-DDoS)

Ni le serveur vanilla ni TShock n’intègrent de protection anti-DDoS native – c’est une responsabilité qui relève de la couche réseau/hébergement, pas d’un réglage dans serverconfig.txt. Si votre serveur tourne sur un VPS, vérifiez si votre hébergeur propose une protection réseau incluse ; à défaut, limiter l’exposition du port SSH (changement de port par défaut, clés SSH plutôt que mot de passe, Fail2ban) reste la mesure la plus simple à mettre en œuvre soi-même.

Programmez également une sauvegarde automatique du dossier monde avant toute mise à jour ou redémarrage planifié :

0 */6 * * * cp /home/terraria/server/Linux/Worlds/MonMonde.wld \
  /home/terraria/backups/MonMonde-$(date +\%Y\%m\%d-\%H\%M).wld

Cette ligne de crontab sauvegarde le monde toutes les six heures dans un dossier séparé. Pour les mises à jour du jeu lui-même, relancez simplement la commande app_update 105600 validate de l’étape 3 – toujours après avoir arrêté proprement le serveur et sauvegardé le monde, jamais à chaud.

Étape 12 : Automatiser le démarrage avec systemd

Pour que le serveur redémarre automatiquement après un reboot de la machine ou un crash, créez un service systemd plutôt que de dépendre d’une session screen ou tmux laissée ouverte manuellement :

sudo tee /etc/systemd/system/terraria.service > /dev/null <<'EOF'
[Unit]
Description=Serveur Terraria dedie (TShock)
After=network.target

[Service]
Type=simple
User=terraria
WorkingDirectory=/home/terraria/tshock
ExecStart=/home/terraria/tshock/TShockLauncher -config /home/terraria/serverconfig.txt
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now terraria.service

Vérifiez ensuite l’état du service et consultez ses journaux en cas de souci :

sudo systemctl status terraria.service
journalctl -u terraria.service -f

Avec Restart=on-failure, le serveur redémarre automatiquement s’il plante, sans intervention manuelle. C’est la configuration recommandée pour tout serveur destiné à rester en ligne durablement, à la différence d’un lancement ponctuel dans un terminal qui s’arrête dès la fermeture de la session SSH.

Auto-hébergement ou hébergeur payant : combien coûte un serveur Terraria ?

L’auto-hébergement décrit dans les 12 étapes ci-dessus ne coûte rien au-delà du matériel déjà possédé (PC allumé en permanence, NAS ou VPS déjà loué pour d’autres usages) et de l’électricité consommée. C’est l’option la plus économique, au prix d’un peu de maintenance manuelle. Pour qui préfère une solution clé en main sans administration système, plusieurs hébergeurs spécialisés proposent Terraria comme jeu pré-configuré. Le tableau suivant reprend les tarifs publiés par G-Portal, un hébergeur européen actif sur Terraria avec des serveurs en Europe centrale :

SolutionPrixJoueurs maxRemarque
Auto-hébergement (ce guide)Gratuit (hors matériel/électricité)Jusqu’à 255 (limite du jeu)Contrôle total, maintenance manuelle
G-Portal – 30 jours13,70 €10Serveur en Europe centrale
G-Portal – 90 jours36,99 €10Offre la plus choisie selon l’hébergeur
G-Portal – 180 jours69,87 €10Tarif dégressif à l’engagement plus long

Le nombre de slots plus élevé et l’absence totale de coût récurrent font de l’auto-hébergement l’option la plus rentable dès lors qu’une machine reste de toute façon allumée pour d’autres usages. Un hébergeur payant reste pertinent si vous ne disposez d’aucune machine à laisser tourner en continu, ou si vous préférez ne pas gérer vous-même les mises à jour et la sécurisation réseau détaillées aux étapes 7 et 11.

Une troisième voie, intermédiaire, consiste à auto-héberger sur du matériel à très faible consommation plutôt que sur un PC de bureau laissé allumé en permanence : un Raspberry Pi 4 ou 5 avec 4 Go de RAM ou plus suffit largement pour un monde de petite à moyenne taille avec quelques joueurs, pour une consommation électrique de l’ordre de quelques watts au repos. La procédure d’installation SteamCMD décrite dans ce guide fonctionne à l’identique sur l’architecture ARM64 de ces cartes, à condition d’utiliser une distribution Linux 64 bits.

Erreurs courantes à éviter

  • N’ouvrir que le port TCP : Terraria a besoin du TCP et de l’UDP sur 7777 simultanément ; oublier l’UDP produit des connexions instables ou des rejets aléatoires selon les clients.
  • Laisser maxplayers à sa valeur par défaut : le fichier de configuration généré automatiquement affiche encore 8, alors que la plupart des serveurs communautaires visent 16 ou plus – vérifiez toujours cette ligne avant le premier lancement public.
  • Faire tourner le serveur sous le compte root : aucune fonctionnalité du jeu ne le nécessite ; un compte système dédié limite les dégâts en cas de faille future.
  • Confondre autocreate et chargement d’un monde existant : autocreate n’a aucun effet si le fichier désigné par world existe déjà – le serveur charge alors ce fichier tel quel, quelle que soit la valeur d’autocreate.
  • Redémarrer ou mettre à jour sans sauvegarde préalable : un monde corrompu pendant une mise à jour n’est récupérable que si une sauvegarde récente existe ; automatisez-la comme montré à l’étape 11 plutôt que de compter sur une sauvegarde manuelle occasionnelle.
  • Mélanger client mobile/console et serveur PC en supposant un crossplay total : seule la Phase 1 (mobile rejoignant un hôte PC) est confirmée active ; le crossplay console est encore en finalisation.
  • Ignorer le décalage de version après une mise à jour Terraria : un serveur resté sur une version antérieure à 1.4.5.6 rejettera silencieusement les clients à jour ; mettez toujours à jour serveur et TShock ensemble.

Dépannage : problèmes fréquents et solutions

« Connection timed out » lors de la connexion depuis l’extérieur du réseau local.
Vérifiez d’abord que le port 7777 est bien redirigé en TCP ET en UDP sur le routeur, puis testez l’ouverture depuis l’extérieur avec un outil de scan de port en ligne ; si le test échoue malgré une redirection correcte, vérifiez que votre FAI ne bloque pas activement le port ou n’impose pas un CGNAT qui empêche toute redirection entrante.

Le serveur démarre mais aucun client ne peut se connecter, même en local.
Confirmez que le processus écoute bien sur toutes les interfaces avec ss -tulnp | grep 7777 ; si rien n’apparaît, le serveur a probablement crashé silencieusement au démarrage – consultez les journaux via journalctl -u terraria.service si vous utilisez systemd.

Un plugin TShock ne se charge plus après une mise à jour.
Les plugins compilés pour TShock 6.0.x ne sont pas garantis compatibles avec 6.1.0 sans recompilation contre la nouvelle API ; consultez le dépôt du plugin concerné pour une version mise à jour avant de rouvrir un ticket au mauvais endroit.

Le monde semble corrompu ou refuse de charger après un crash.
Restaurez la dernière sauvegarde automatique créée à l’étape 11 ; Terraria conserve aussi généralement une copie .bak du fichier monde précédent dans le même dossier, à renommer en .wld en dernier recours si aucune sauvegarde crontab n’existe.

Consommation mémoire qui augmente progressivement sur plusieurs jours.
Un monde de grande taille avec une activité intense (fermes automatisées, événements déclenchés en boucle) peut faire grimper l’usage RAM ; programmez un redémarrage hebdomadaire planifié via systemd/cron plutôt que de laisser un unique processus tourner indéfiniment sans interruption.

Chute de performance ou lag important pendant un combat de boss.
Les événements à forte densité de projectiles (boss, invasions) sont connus pour solliciter fortement le CPU serveur ; réduire le nombre de joueurs simultanés ou augmenter les ressources CPU allouées à la machine atténue généralement le problème.

Un client mobile ne parvient pas à rejoindre un serveur PC malgré la Phase 1 du crossplay.
Vérifiez que le client mobile est également à jour vers la version correspondant à 1.4.5.6 ; un décalage de version bloque la connexion crossplay exactement comme entre deux clients PC.

Erreur de permission refusée au lancement du binaire Linux.
Le fichier téléchargé via SteamCMD n’est pas exécutable par défaut ; relancez chmod +x TerrariaServer.bin.x86_64 (ou TShockLauncher selon le cas) avant de retenter le lancement.

Le mot de passe superadmin TShock ne fonctionne plus après une réinstallation.
Les comptes TShock sont stockés dans une base SQLite propre au dossier d’installation, pas dans serverconfig.txt ; si vous avez réinstallé TShock dans un nouveau dossier, recréez le compte via user add depuis la console serveur plutôt que de chercher un mot de passe qui n’a pas été migré.

Le service systemd refuse de démarrer avec une erreur « status=203/EXEC ».
Cette erreur signale presque toujours un chemin incorrect dans la directive ExecStart ou un binaire non exécutable ; vérifiez le chemin absolu vers TShockLauncher ou TerrariaServer.bin.x86_64 et confirmez les droits d’exécution avec ls -l avant de relancer systemctl daemon-reload.

Astuces avancées pour aller plus loin

Une fois le serveur stable, plusieurs options permettent d’aller au-delà d’une installation basique. Le système de plugins de TShock, écrit en C# et chargé dynamiquement au démarrage, ouvre l’accès à des fonctionnalités communautaires comme des systèmes d’économie, des mini-jeux PvP ou une intégration Discord pour relayer le chat en jeu vers un salon dédié – la liste des plugins maintenus se trouve directement sur le dépôt GitHub du projet et ses discussions communautaires.

Pour les groupes qui gèrent plusieurs mondes en parallèle (un monde principal en expert, un monde de départ en normal, un monde d’événement temporaire), il est possible de faire tourner plusieurs instances du service systemd décrit à l’étape 12 en dupliquant le fichier unit sous un nom différent, avec un fichier serverconfig.txt et un port distincts pour chacune – pensez alors à ouvrir un port supplémentaire par instance sur le routeur.

Enfin, pour un monitoring plus poussé que les journaux systemd bruts, un script cron complémentaire qui vérifie périodiquement que le port 7777 répond (via une simple vérification de connexion) et envoie une alerte si ce n’est pas le cas permet de détecter un crash plus rapidement qu’en attendant un signalement des joueurs.

Foire aux questions

Combien coûte un serveur Terraria dédié ?
En auto-hébergement sur du matériel déjà possédé, le coût se limite à l’électricité consommée. Chez un hébergeur spécialisé comme G-Portal, comptez à partir de 13,70 € pour 30 jours avec 10 emplacements joueurs.

Quel est le port par défaut du serveur ?
Le port 7777, à ouvrir simultanément en TCP et en UDP sur le routeur et sur tout pare-feu logiciel actif.

TShock est-il obligatoire pour héberger ce serveur ?
Non, un serveur vanilla fonctionne seul. TShock reste toutefois fortement recommandé dès que le serveur accueille plus qu’un petit groupe de confiance, pour la gestion des comptes, la modération et la protection anticheat via les Server Side Characters.

Le crossplay fonctionne-t-il entre PC, mobile et consoles sur un serveur dédié ?
Partiellement. La Phase 1, qui permet à des clients mobiles de rejoindre un serveur hébergé sur PC, est active depuis février 2026. Le crossplay côté console reste en cours de finalisation à la date de rédaction de cet article.

Combien de RAM faut-il prévoir ?
Environ 512 Mo suffisent pour un petit monde avec quelques joueurs ; comptez 1 à 2 Go ou plus pour un monde de grande taille avec une dizaine de joueurs simultanés.

Peut-on héberger ce serveur sur un NAS Synology ou QNAP ?
Oui, tant que le NAS dispose d’un accès shell (SSH) et de suffisamment de RAM libre ; la procédure SteamCMD décrite dans ce guide fonctionne de façon identique sur un NAS Linux et sur un VPS classique.

Comment le mettre à jour vers la dernière version ?
Arrêtez proprement le service, sauvegardez le dossier du monde, puis relancez la commande SteamCMD app_update 105600 validate de l’étape 3 avant de redémarrer le service systemd.

Un serveur dédié fonctionne-t-il avec des mods via tModLoader ?
Oui, mais tModLoader reste sur la branche 1.4.4 à la date de rédaction, sans version stable compatible 1.4.5. Un serveur modé est donc actuellement en retard d’une mise à jour majeure par rapport à un serveur vanilla ou TShock.

Peut-on limiter l’accès à une liste fermée de joueurs ?
Oui : sous TShock, il suffit de créer un compte pour chaque joueur autorisé via user add et de désactiver les connexions anonymes non enregistrées dans les permissions du groupe par défaut, ce qui transforme de fait le serveur en liste blanche.

Contenus liés