txAdmin, che cos'è esattamente?
txAdmin è incluso di serie in FXServer dal 2020: non c'è niente da comprare né da installare a parte. Al primo lancio di FXServer, txAdmin parte automaticamente ed espone un'interfaccia web (per impostazione predefinita sulla porta 40120). È lo strumento standard della comunità FiveM, open source e mantenuto dalla squadra Cfx.re.
- Console in diretta: log del server in tempo reale, comandi, cronologia
- Recipe: distribuzione automatica di una base completa (QBCore, ESX Legacy, vanilla)
- Pianificatore: riavvii programmati con annunci in gioco
- Gestione giocatori: ban, avvertimenti, whitelist, note, cronologia per identificativo
- Monitoraggio: rilevamento dei crash con riavvio automatico
Prerequisiti
- Un VPS con almeno 4 GB di RAM — 8 GB consigliati per una base QBCore/ESX con dei giocatori. Su Linux, Debian e Ubuntu sono le distribuzioni meglio documentate: vedi le nostre pagine VPS Debian e VPS Ubuntu. Su Windows serve un VPS Windows con accesso RDP.
- Una chiave di licenza gratuita creata su portal.cfx.re (obbligatoria per qualunque server FiveM), da indicare in
server.cfg tramite sv_licenseKey
- Le porte 30120 in TCP e in UDP (gioco) e 40120 in TCP (pannello txAdmin) aperte nel firewall
- Una base MariaDB o MySQL se distribuisci un framework roleplay: sia QBCore sia ESX vi archiviano i personaggi, l'inventario e l'economia
Installazione su un VPS Linux
Scarica l'ultima build di FXServer da runtime.fivem.net, decomprimila in una cartella (es. ~/fxserver), poi lancia ./run.sh. txAdmin parte automaticamente e mostra nel terminale un codice PIN a 4 cifre valido qualche minuto. Apri http://IP-DEL-VPS:40120 nel tuo navigatore, inserisci il PIN, poi collega il tuo account Cfx.re: sarà lui a fare da identificativo amministratore. Perché il server sopravviva a una disconnessione SSH, lancialo in tmux, screen o tramite un servizio systemd — la sezione seguente dà l'unità completa.
Far girare FXServer come servizio systemd
Un server lanciato a mano in un terminale muore con la tua sessione SSH, e non riparte se il VPS si riavvia. Un servizio systemd risolve entrambe le cose. Crea /etc/systemd/system/fxserver.service con il contenuto qui sotto, sostituendo l'utente e i percorsi con i tuoi:
[Unit] — Description=FXServer FiveM poi After=network.target mariadb.service: il server non parte prima che la rete e la base siano pronte[Service] — User=fivem, WorkingDirectory=/home/fivem/fxserver, ExecStart=/home/fivem/fxserver/run.sh, Restart=always, RestartSec=10[Install] — WantedBy=multi-user.target- Poi
systemctl daemon-reload, systemctl enable --now fxserver, e journalctl -u fxserver -f per leggere i log dell'avvio — è lì che compare il PIN al primo lancio
Fai girare il server con un account dedicato
Non lanciare FXServer come root. Crea un utente di sistema dedicato (adduser --system --group fivem), mettici la cartella del server e dagli la proprietà della cartella txData. Una risorsa di terzi mal scritta — e nell'ecosistema roleplay ne circolano molte — avrà allora accesso soltanto ai file del gioco, non al resto della macchina. Su un VPS dove ospiti anche un sito o una base, questa separazione è il minimo.
Installare txAdmin su un VPS Windows
FXServer esiste anche in build Windows, e molte comunità roleplay ci restano perché i loro strumenti di sviluppo girano lì. Il principio è identico: scarica l'archivio server.zip da runtime.fivem.net, decomprimila e lancia FXServer.exe. txAdmin parte, mostra il PIN nella finestra della console, e il pannello risponde su http://IP-DEL-VPS:40120. Qualche differenza da conoscere:
- Il firewall di Windows blocca per impostazione predefinita: crea due regole di traffico in entrata, una per la porta 30120 in TCP e UDP, una per la porta 40120 in TCP (Windows Defender Firewall con funzionalità avanzate, oppure
New-NetFirewallRule in PowerShell)
- La finestra della console si chiude con la sessione RDP: perché il server giri in permanenza, registra
FXServer.exe come servizio di Windows (NSSM e WinSW sono i due strumenti usati dalla comunità) oppure passa da un'operazione pianificata attivata « all'avvio del computer »
- Prevedi più memoria che su Linux: il sistema stesso ne consuma di più. Sui nostri VPS Windows il taglio di ingresso è da 8 GB, che lascia il margine necessario a una base QBCore o ESX
- La licenza Microsoft non è fornita: è una spesa da prevedere a parte, al contrario di un VPS Linux
Distribuire una base con le recipe
Al primo accesso, la procedura guidata di txAdmin propone di distribuire una recipe: una base di server completa installata automaticamente (framework, base di dati, risorse di partenza). Scegli QBCore o ESX Legacy per un server roleplay, oppure una base vanilla per partire da zero. La recipe configura anche la connessione MySQL/MariaDB — su un VPS installa prima MariaDB e crea una base dedicata.
Le porte da aprire, e perché
Soltanto tre porte, ma un errore classico consiste nell'aprire la 30120 solo in TCP. FiveM usa lo stesso numero di porta in TCP e in UDP: il TCP serve alla scoperta e all'elenco dei server, l'UDP al traffico di gioco. Un server che compare nell'elenco ma sul quale nessuno riesce a connettersi, è quasi sempre l'UDP dimenticato.
- 30120/tcp e 30120/udp: il gioco. Aperte a tutti. Su Debian o Ubuntu:
ufw allow 30120 apre i due protocolli in un colpo
- 40120/tcp: il pannello txAdmin. Da limitare al tuo indirizzo IP, vedi più sotto
- 3306/tcp (MariaDB): da non aprire verso l'esterno. La base gira sulla stessa macchina di FXServer, la si raggiunge in
127.0.0.1. Una porta MySQL esposta su Internet è uno dei modi più rapidi di perdere una base di personaggi
- La porta del gioco si può cambiare (
endpoint_add_tcp e endpoint_add_udp in server.cfg): utile per far girare due server, uno di produzione e uno di prova, sulla stessa macchina
Quante risorse secondo il numero di giocatori
Il motore RAGE è molto dipendente da un solo core: la frequenza del processore conta più del numero di vCore. Un VPS con 8 core lenti terrà meno giocatori di un VPS con 4 core rapidi. Sul lato memoria, sono le risorse di terzi a decidere — un server roleplay completo carica facilmente un centinaio di script.
- Base vanilla, una manciata di giocatori: 4 GB di RAM bastano, è il minimo per lanciare FXServer
- QBCore o ESX, da 20 a 40 giocatori: 8 GB. La cinquantina di script di un server roleplay agli inizi consuma da 2 a 4 GB da sola, MariaDB ne chiede circa 1 in più
- Server consolidato, 64 slot e oltre, script personalizzati: 16 GB, e uno stoccaggio SSD — gli scambi con la base sono continui durante le sessioni
- Disco: conta il peso delle tue risorse più la base, e lascia posto per i backup. I server roleplay crescono col tempo, mai il contrario
La console txAdmin nell'uso quotidiano
La scheda Live Console mostra i log del server in tempo reale e accetta tutti i comandi FXServer (refresh, ensure la-mia-risorsa, restart es_extended…). Le azioni delicate sono registrate per account amministratore: ogni kick, ban o riavvio è tracciato, comodo quando più moderatori gestiscono il server.
- Scheduler: programma 1 o 2 riavvii al giorno con annunci automatici — la memoria di un server FiveM si frammenta con il tempo
- Backup: salva regolarmente la tua cartella di dati e la base MySQL (txAdmin non salva il database al posto tuo)
- Permessi: crea un account amministratore per moderatore con diritti limitati, invece di condividere l'account principale
Aggiornare FXServer e txAdmin
txAdmin non ha un aggiornamento proprio: è incorporato nell'artifact di FXServer, quindi aggiornare il server aggiorna il pannello. La manovra è semplice ma va fatta nell'ordine, altrimenti si perde una configurazione.
- Prendi uno snapshot del VPS dall'area clienti, o almeno una copia della cartella del server e un export della base
- Ferma il server in modo pulito (
systemctl stop fxserver, o il pulsante Stop di txAdmin)
- Sostituisci soltanto i file dell'artifact — non toccare né
txData/, né la tua cartella resources/, né server.cfg: quelli sono i tuoi dati, non quelli del server
- Riavvia, poi verifica nella console che tutte le risorse si carichino. Una risorsa incompatibile con la nuova build si vede immediatamente nei log
- Conserva l'artifact precedente per qualche giorno: tornare indietro consiste allora nel rimettere la vecchia cartella
Salvare quello che conta davvero
Un'osservazione torna spesso nelle richieste di assistenza: « txAdmin fa i backup, no? » Li fa, ma non di quello che credi. La base di dati non viene salvata da txAdmin. Ed è lei a contenere i personaggi, i veicoli, i conti in banca e gli inventari — tutto quello che la tua comunità ha costruito e che nessuno perdonerà di perdere.
- La base: un
mysqldump quotidiano in un'attività cron, inviato altrove e non sul VPS stesso
- La cartella
txData/: contiene admins.json, la configurazione del pannello e la cronologia delle sanzioni
- La tua cartella
resources/ e server.cfg: soprattutto se hai modificato degli script acquistati, quelle modifiche non esistono in nessun altro posto
- Gli snapshot del VPS coprono la macchina intera e si ripristinano con un clic dall'area clienti. Completano gli export della base, non li sostituiscono: uno snapshot ripristina anche l'errore che volevi annullare
Mettere in sicurezza l'accesso al pannello
Un pannello di amministrazione esposto su un IP pubblico è un bersaglio evidente. Bastano tre misure:
- Limitare la porta 40120 al tuo IP:
ufw allow from IL_TUO_IP to any port 40120 poi ufw deny 40120 — solo i tuoi co-amministratori accedono al pannello, la porta del gioco (30120) resta aperta a tutti
- Non disattivare mai l'autenticazione, nemmeno « giusto per provare »: la modalità senza parola d'ordine di txAdmin è riservata allo sviluppo locale, mai su un VPS pubblico
- Reverse proxy HTTPS in produzione (facoltativo): Nginx o Caddy in prima linea con un sottodominio e un certificato Let's Encrypt, invece di esporre
ip:40120 in chiaro — attenzione a trasmettere bene le intestazioni WebSocket (Upgrade/Connection), la console in diretta ne dipende
- Un account amministratore per persona, con il minimo dei diritti: txAdmin registra le azioni per account, cosa che non serve a nulla se tutti condividono lo stesso identificativo
Problemi comuni e soluzioni
- Pagina 40120 irraggiungibile: la porta è chiusa — aprila nel firewall (
ufw allow 40120/tcp) o verifica che txAdmin sia davvero in ascolto (log all'avvio)
- Il server compare nell'elenco ma nessuno riesce a connettersi: la porta 30120 è aperta solo in TCP. Aprila anche in UDP
- PIN scaduto: rilancia FXServer, un nuovo PIN compare nel terminale
- Accesso amministratore perso: ferma il server e cancella il file
txData/admins.json — txAdmin rilancia la procedura guidata di primo avvio
- « Invalid license key »: la chiave Cfx.re è legata a un indirizzo IP. Se hai cambiato server, rigenerala su portal.cfx.re e sostituisci la riga
sv_licenseKey di server.cfg
- La console in diretta resta vuota dietro un reverse proxy: le intestazioni WebSocket non vengono trasmesse. Aggiungi
Upgrade e Connection alla configurazione di Nginx
- Il server si riavvia in continuazione: leggi i log appena prima del crash. Nove volte su dieci è una risorsa di terzi aggiunta il giorno prima — togliila da
server.cfg e riavvia per confermare
- Server che arranca: sorveglia la scheda di monitoraggio; se la RAM satura con la tua base e i tuoi giocatori, passa a un piano VPS superiore. Il cambio di offerta si fa dall'area clienti, senza reinstallazione
- Attacchi ripetuti durante le sessioni: i server roleplay frequentati vengono presi di mira regolarmente. Un filtraggio a livello di rete è il solo rimedio; vedi la nostra guida Capire l'Anti-DDoS
