Zur Anleitung

Dokumentation 9.6.24

Fehlerbehebung

Server, Version, Zeitpunkt und genaue Fehlermeldung notieren. Geheimnisse aus Logs entfernen.

Keine Bridge-Daten#

Prüfen, ob die Verbindung auf der Karte Tosun Connect abgeschaltet ist, ob set tosun_db_bridge_manual "1" ohne tosun_db_bridge_enabled "1" gesetzt ist und ob der alte Spiegel (ts.panelMirror.enabled) aktiv ist; danach oxmysql, Framework/Schema und Verbindungsstatus prüfen. Ein tosun-ac-Paket vor 9.6.14 braucht bis zur Installation des neuen Pakets weiterhin set tosun_db_bridge_enabled "1" in server.cfg. Die Bridge liefert begrenzte Seiten unterstützter Daten, keine vollständige Datenbankkopie.

Garantierter Schutz?#

Nein. Serverprüfungen und eingeschränkte Tokens reduzieren bestimmte Risiken. Ressourcen aktualisieren, Fehlalarme prüfen, Admin-Konten schützen und offengelegte Schlüssel erneuern. Verschlüsselung macht Client-Code nicht unlesbar.

Den ersten Fehler eingrenzen#

Unterscheiden Sie Anmeldung, Zahlung, Download, Resource-Start, Panel-Verbindung, Brücke und Website. Den ersten fehlgeschlagenen Schritt, erwarteten Ausgang und letzten funktionierenden Zeitpunkt notieren.

Version, Änderungen und betroffenes Konto festhalten. Konsolen- und Panel-Zeiten vergleichen. Jeweils eine Änderung testen statt ständig neu zu starten. Unklare Zahlungen oder Geldänderungen vor erneutem Versuch anhand von Rechnung beziehungsweise Kontostand prüfen.

Download und Start prüfen#

Downloads prüfen Dienstberechtigung, Zugriff auf den Server und Serververwaltungsrechte. Nur Links aus Ihrem eigenen Downloadbereich verwenden.

  1. Richtiges Konto und Server auswählen; Rechte- und Abrechnungshinweis lesen.
  2. tosun-ac nicht umbenennen; Paket vollständig entpacken und alte/neue Dateien nicht vermischen.
  3. Abhängigkeiten und Startreihenfolge prüfen; ersten Konsolenfehler beheben, ohne Lizenz in Clientdateien zu kopieren.
  4. Bei Bedarf Version, Server-ID und bereinigten Fehler an Support senden, Paket nicht öffentlich hochladen.

Wartende Dienste und Support#

Eine Website kann noch eingereiht sein; keinen Duplikateintrag erstellen. Aktivierung und HTTPS getrennt prüfen. Eigene Domains brauchen Routing und Besitz-TXT. Die Brücke ist standardmäßig aktiv (keine zusätzliche server.cfg-Zeile) und braucht Panelrechte, oxmysql und ein unterstütztes Schema. Sie antwortet nicht, wenn die Verbindung auf der Tosun-Connect-Karte abgeschaltet wurde, im manuellen Modus (tosun_db_bridge_manual) set tosun_db_bridge_enabled "1" fehlt oder der alte Vollspiegel aktiv ist (ts.panelMirror.enabled = true in configs/anticheat_config.lua); im letzten Fall bleibt die Brücke aus, damit der Spiegel weiterläuft. Pakete vor 9.6.14 brauchen bis zur Installation des neuen Pakets weiterhin set tosun_db_bridge_enabled "1".

Die Brücke ist kein vollständiger SQL-Browser; eine leere oder nicht unterstützte Antwort beweist keine leere Datenbank. Nach zehn Minuten 2FA-Setup neu starten und neuen QR/Schlüssel nutzen. Bei Codefehler Telefonzeit und Authenticator-Konto prüfen.

Support benötigt Ressourcen-ID, Version/Framework, Schritte, Erwartung, Fehler, Zeit mit Zeitzone und letzte Änderungen. Lizenz, Token, QR, Backup-Codes, Bankcodes und unnötige Spielerdaten entfernen.

Ein Browserproblem ohne Beweisverlust eingrenzen#

Notieren Sie vor dem Aktualisieren einer falsch geladenen Seite Adresse, ausgewähltes Konto und Meldung. Unterscheiden Sie Darstellungsfehler, abgelehntes Speichern und fehlgeschlagene externe Weiterleitung. Diese Symptome haben unterschiedliche Ursachen. Sofortiges Löschen aller Browsereinstellungen kann hilfreichen Kontext entfernen, ohne zugrunde liegende Rechte oder Dienstzustände zu korrigieren.

Vergleichen Sie bei reinen Anzeigeproblemen dieselbe Seite in einer neuen Browsersitzung und prüfen Sie Erweiterungen, die Skripte oder Navigation blockieren. Bestätigen Sie das richtige Konto nach der Anmeldung. Meldet ein altes Formular eine abgelaufene Sicherheitssitzung, öffnen Sie die Seite über normale Navigation statt wiederholter alter Formularsendungen.

Zahlungsversuche und Wirtschaftsänderungen gehören erst in diesen Vergleich, wenn ihr ursprüngliches Ergebnis bekannt ist. Kopieren Sie keine Sitzungscookies oder Authentifizierungsheader in Supportanfragen. Nennen Sie Browserversion, ursprünglichen Fehler, Zeit und ob die neue Sitzung das Ergebnis verändert hat.

Eine kurze Reproduktion mit klarem Endpunkt erstellen#

Wählen Sie mit einem berechtigten Konto die kleinste Schrittfolge zum gemeldeten Fehler. Beispielsweise Server auswählen, Spielerliste öffnen und Antwort erfassen: Zum Nachweis eines Lesefehlers müssen keine Guthaben geändert werden. Erklären Sie je Schritt das erwartete Ergebnis.

Tritt das Problem nur nach einem bestimmten Ressourcenupdate oder bei einer konkreten Spielaktion auf, nennen Sie diese Bedingung. Vergleichen Sie sie mit dem letzten funktionierenden Zustand und der Version. Stoppen Sie nach dem ersten erfassten Fehler, statt zusätzliche Aufrufe, Neustarts und Änderungen anzuhäufen und die Ursache zu verwischen.

Beschreiben Sie bereits durchgeführte Prüfungen und unveränderte Ergebnisse. Teilen Sie nur Konsolenzeilen im Umfeld des Fehlers und entfernen Sie Geheimnisse sowie sachfremde Spielerdaten. Eine kurze Reproduktion liefert einen prüfbaren Fall und einen klaren Maßstab dafür, ob ein vorgeschlagener Fix wirkte.

Die Korrektur am ursprünglichen Symptom prüfen#

Wiederholen Sie nach einer Korrektur die ursprüngliche Lese- oder Spielsituation unter vergleichbaren Bedingungen. Prüfen Sie unmittelbare Antwort und passende Panel- oder Konsolenaufzeichnung. Ein verschwundenes Banner beweist allein nicht, dass Download, Verbindung, Website-Bereitstellung oder Zahlungsbestätigung erfolgreich abgeschlossen wurden.

Halten Sie frühere und neue Versionen oder Einstellungswerte im Änderungsnachweis fest. Testen Sie bei Spielproblemen die betroffene normale Aktion und eine benachbarte unbetroffene Aktion. Bei Websites prüfen Sie gewünschte Adresse und HTTPS. Bei Abrechnung verwenden Sie das Ergebnis der bestehenden Rechnung statt einer Testbelastung.

Kehrt das Symptom zurück, melden Sie Zeitpunkt und seit der Prüfung veränderte Bedingungen. Stellen Sie eine bekannte funktionierende Konfiguration nur über Ihr vorbereitetes Wiederherstellungsverfahren her. Bewahren Sie den kurzen Fallverlauf auf, damit die nächste Untersuchung auf belegten Beobachtungen statt denselben erfolglosen Vermutungen aufbaut.

Ein Supportticket anhand eines anonymen Beispiels ausfüllen#

Öffnen Sie im Supportbereich des Panels ein neues Ticket; Ihr Konto benötigt support.create. Füllen Sie Betreff, Kategorie, Priorität und Nachricht wie im erfundenen Beispiel aus. Für das Problem beim Lesen der Spielerliste wurden technical und normal gewählt. Richten Sie die Priorität nach der tatsächlichen Auswirkung: Ein Fehler auf einer Leseseite ist kein Ausfall des gesamten Servers. Sichtbare Bezeichnungen können sich mit der Oberflächensprache ändern; die Werte in Klammern entsprechen den aktuellen Formularoptionen. Eine Supportanfrage benötigt weder Lizenz noch Passwort oder Datenbankzugriff.

Servername und Referenz des Beispiels sind keine Kundendatensätze. Benennen Sie den betroffenen Server in Ihrem autorisierten privaten Ticket eindeutig und anonymisieren Sie den Text angemessen, bevor Sie ihn öffentlich teilen. Die Nachricht enthält Schritte und einen Haltepunkt: Kein Kontostand wurde geändert und kein neuer Auftrag angelegt. Das Formular prüft mindestens fünf Zeichen beim Betreff und zehn bei der Nachricht; eine kurze aussagekräftige Erklärung erfüllt das bereits. Ergänzen Sie spätere Beobachtungen im selben Ticket. Übermitteln Sie nur bereinigte relevante Zeilen statt der gesamten Konsole, SQL-Dumps oder Cookies. Die gewählte Priorität garantiert keine Antwortzeit.

Betreff: Anfrage der Spielerliste wird nicht abgeschlossen
Kategorie: Technisch (technical)
Priorität: Normal (normal)
Nachricht:
Server: TEST-SERVER — für dieses Beispiel anonymisiert
Version / Framework: 9.6.3 / QBCore — Beispielwerte
Zeitpunkt: 2026-09-26 14:03 UTC
Schritte: Server ausgewählt; Spielerliste einmal geöffnet.
Erwartet: Erfolgreich abgeschlossene erste Spielerseite.
Beobachtet: pending, danach Netzwerk-Zeitüberschreitung.
Referenz: TEST-REQUEST — keine echte Anfrage-ID
Geprüft: Resource gestartet; erforderliches Leserecht vorhanden.
Haltepunkt: Kein neuer Auftrag und keine Kontostandsänderung.
Geheimnisse, Cookies, _csrf und Spielerkennungen entfernt.

Nächsten Schritt und Haltepunkt aus dem Symptom ableiten#

Diese Entscheidungsfolge hilft, den ersten fehlerhaften Schritt zu finden; sie ist weder eine automatische Reparatur noch eine Wiederholungsregel für jeden Fehler. Öffnet sich die Spielerliste nicht, prüfen Sie zunächst HTTP: 401 verweist auf die Sitzung, 419 auf den Sicherheitswert des Formulars, 403 auf Konto- oder Dienstberechtigungen und 429 auf Kapazität beziehungsweise Warten. Ist nur ein Eintrag leer, prüfen Sie Charakter und unterstütztes Schema. Ähnliche Symptome können verschiedene Ursachen haben: Eine abgeschlossene leere Seite und eine abgelehnte Anfrage sind unterschiedliche Ereignisse. Bewahren Sie zuerst die vorhandenen Belege.

Bei einem ausstehenden Wirtschaftsschreibvorgang oder einer Zahlung mit unklarem Ausgang wählen Sie den Haltepfad: Prüfen Sie vorhandene Anfrage, Rechnung und aktuellen Zustand, bevor Sie einen weiteren Vorgang starten. Startet eine Resource nicht, führen Installation und erster Konsolenfehler weiter; wird eine normale Bewegung beanstandet, prüfen Sie die betreffende Integration und die kurze Erlaubnisdauer. Schalten Sie nicht sämtliche Schutzfunktionen als Zwischenlösung ab. Ist eine Website aktiv, aber HTTPS scheitert, prüfen Sie Domain und Zertifikat getrennt. Eine geänderte lokale Uhr oder Anzeige bedeutet keinen abgeschlossenen Servervorgang. Nennen Sie dem Support die Beobachtung, die den Pfad bestimmt hat; werten Sie ein unbekanntes Ergebnis nicht als Erfolg.