Inhalt dieses Guides
FiveM Server nicht in der Liste oder Direct Connect schlägt fehl: Prozess, info.json, Port 30120, Firewall, NAT, sv_master1 und CGNAT systematisch prüfen.
Server-Arbeitsmodus
Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.
Wo hängt dein Server gerade?
Netzwerkdiagnose bringt nichts, solange der Server lokal nicht sauber startet oder lauscht.
Wenn localhost/LAN funktioniert, liegt der nächste Prüfbereich bei Host-Firewall, Router, öffentlicher Adresse und NAT.
Bei Lag, Abstürzen oder Update-Problemen sind Logs, Ressourcen, Mods und ein sauberer Rollbackpfad wichtiger als weitere Portregeln.
Wenn ein FiveM-Server nicht in der Serverliste auftaucht, ist die wichtigste Frage zuerst: Funktioniert Direct Connect? Cfx nennt fehlerhaftes Portforwarding und Firewallprobleme als häufige Ursachen. Die Serverliste sollte deshalb nicht der erste Diagnosepunkt sein.
1. Prozess und lokale Metadaten prüfen
Kontrolliere in txAdmin oder der Konsole, ob FXServer tatsächlich läuft. Öffne anschließend lokal http://127.0.0.1:30120/info.json beziehungsweise deinen konfigurierten Port. Wenn bereits das scheitert, ist Router/NAT noch nicht relevant.
2. Direct Connect testen
Öffne im FiveM-Client mit F8 die Konsole und verwende connect IP:Port. Teste zunächst aus dem LAN und danach von einem externen Anschluss. Ein externer Mobilfunk-Hotspot eignet sich besser als ein zweiter Client im selben LAN, weil Hairpin-NAT Ergebnisse verfälschen kann.
3. TCP und UDP 30120 prüfen
Das offizielle Beispiel bindet beide Protokolle. Erlaube sie in der Host-Firewall und leite sie bei Heimhosting auf die richtige interne Server-IP weiter. Ein TCP-Web-Portchecker allein sagt wenig über UDP-Verkehr aus.
4. sv_master1 kontrollieren
Cfx weist darauf hin, dass ein aktiviertes sv_master1 "" den Server als privat markieren kann. In der Standardkonfiguration ist die Zeile auskommentiert. Entferne keine Kommentarzeichen blind aus alten Beispielen.
5. CGNAT und Provider prüfen
Wenn die WAN-IP des Routers nicht deiner öffentlich sichtbaren IPv4 entspricht, kann CGNAT klassisches Portforwarding verhindern. Dann helfen lokale Routerregeln nicht. Mehr dazu unter CGNAT erkennen.
6. Proxy und Listing erst danach untersuchen
Bei Reverse Proxy, sv_listingHostOverride oder speziellen Endpoints entstehen zusätzliche Fehlerpfade. Stelle zuerst direkte Erreichbarkeit her und baue den Proxy danach wieder ein.
7. Nach Updates Resources prüfen
Wenn Netzwerk funktioniert, der Join aber während des Ladens scheitert, untersuche Resource-Logs, Dependencies und Datenbankverbindung. Netzwerkfehler und Scriptfehler sehen aus Client-Sicht oft ähnlich aus.
Siehe auch FiveM Ports und Logs systematisch auswerten.
Fehlerklasse anhand des Join-Zeitpunkts eingrenzen
Ein sofortiges „connection refused“ deutet eher auf Endpoint, Firewall oder Prozess hin. Erreicht der Client den Server, lädt aber anschließend Ressourcen endlos oder bricht später ab, verschiebt sich der Fokus auf HTTP-Download, Resource-Fehler, Datenbank, Voice oder Framework. Diese Trennung verhindert, dass du stundenlang Portweiterleitungen änderst, obwohl die Verbindung längst hergestellt wird.
Speichere für reproduzierbare Fälle Client-F8-Ausgabe und Serverlog mit derselben Uhrzeit. So lassen sich korrespondierende Fehlermeldungen wesentlich schneller finden.