3CX Troubleshooting — Logs, Diagnose, Fehlerlösung

Die meisten 3CX-Probleme lassen sich mit einer systematischen Vorgehensweise eingrenzen: Log Viewer öffnen, betroffene Komponente identifizieren, gezielt testen. Dieser Guide führt durch die Diagnose-Werkzeuge und die häufigsten Fehlerbilder.

Wofür ist das und wann brauche ich das?

Relevant, sobald etwas nicht wie erwartet funktioniert — von „Admin-Portal nicht erreichbar" bis „Anrufe ohne Ton". Die Reihenfolge unten hilft, das Problem einer der drei häufigsten Ursachengruppen zuzuordnen: Netzwerk/Firewall, SIP-Trunk-Konfiguration oder Client/Endgerät.

Logs finden und lesen

Der schnellste Weg führt über den 3CX Log Viewer direkt in der Admin Console — er zeigt SIP-Signalisierung, Anrufverlauf und Systemereignisse gefiltert und durchsuchbar an, ohne dass Sie sich auf der Kommandozeile durch Rohdaten wühlen müssen. Für die reine Anrufhistorie (wer hat wann mit wem telefoniert, Status, Dauer) eignet sich zusätzlich Berichte → Anrufprotokoll — oft der schnellere Einstieg, um ein gemeldetes Problem überhaupt erst zeitlich einzugrenzen. Auf Linux-Installationen liegen die zugrunde liegenden Log-Dateien zusätzlich unterhalb von /var/lib/3cxpbx/Logs auf dem Server, falls eine tiefere Analyse nötig ist.

Systematisch vorgehen

1. Komponente eingrenzen: Betrifft es das Admin-Portal, einen SIP-Trunk, ein einzelnes Endgerät oder alle Anrufe gleichzeitig?
2. Log Viewer öffnen und den Zeitraum des Vorfalls filtern
3. SIP-Trace für den betroffenen Anruf/die Registrierung ansehen — zeigt, ob Pakete den Server überhaupt erreichen
4. Netzwerk isoliert testen (siehe Diagnose-Befehle unten), um Firewall-/Routing-Probleme von Konfigurationsfehlern zu unterscheiden

Häufige Fehler und Lösungen

Admin-Portal nicht erreichbar

• Richtigen Port geprüft? Standard ab V20-Neuinstallation ist 443, bei Upgrades von v18 teils weiterhin 5001 — Wert in Erweitert → Netzwerk nachsehen.
• Läuft der Dienst? systemctl status 3cxpbx
• Firewall-Regel für den Admin-Port vorhanden?
• Eigene IP evtl. durch die eingebaute Anti-Hacking-Funktion temporär gesperrt (mehrere Fehlversuche)?

SIP-Trunk registriert sich nicht

• Zugangsdaten (Benutzername, Passwort, Hauptrufnummer) exakt wie vom Provider vorgegeben eingetragen?
• Ports 5060/UDP und 5060–5061/TCP in der Firewall offen — siehe Sicherheits-Guide für die vollständige Portliste?
• Erwartet der Provider eine statische öffentliche IP? Bei dynamischer IP (häufig bei Standard-DSL-Anschlüssen) kann die Registrierung fehlschlagen oder instabil sein.
• Provider-spezifische Anleitungen: Deutsche Telekom, sipgate, Swisscom

Anrufe ohne Ton (One-Way- oder No-Way-Audio)

• Fast immer ein RTP-Portproblem: Bereich 9000–10999/UDP muss vollständig durchgereicht werden, nicht nur ein Ausschnitt.
• Bei Standorten hinter doppeltem NAT (Router + zusätzliche Firewall) beide Ebenen prüfen.
• Bandbreite und Jitter testen — bei überlasteten Leitungen bricht die Sprachqualität zuerst ab, bevor die Signalisierung ausfällt.

Schlechte Sprachqualität (Robotereffekt, Aussetzer)

• QoS/DSCP für Sprachpakete am Router aktiviert?
• Ausreichend Bandbreite pro gleichzeitigem Gespräch eingeplant (grober Richtwert: ca. 100 kbit/s pro Gespräch bei G.711, weniger bei komprimierten Codecs)?
• Jitter und Paketverlust mit einem Netzwerktest-Tool des Providers oder mtr gegen den SIP-Server prüfen.

Endgerät (IP-Telefon) provisioniert nicht

• MAC-Adresse korrekt in der Extension hinterlegt?
• PnP im lokalen Netz möglich, oder ist das Telefon im Homeoffice — dann RPS (Remote Phone Service) nötig? Details: Endgeräte-Guide
• Firmware des Telefons stark veraltet? Ältere Firmware-Stände unterstützen aktuelle Provisioning-Templates teils nicht vollständig.

Diagnose-Befehle (Server-Ebene)

# DNS-Auflösung des eigenen Servers/Trunk-Providers prüfen
dig ihr-3cx-server.example.com

# SIP-Port-Erreichbarkeit grob testen
nc -vz -u siptrunk.provider.example 5060

# Allgemeine Netzwerk-Erreichbarkeit
ping -c 4 8.8.8.8

# Laufender 3CX-Dienst
systemctl status 3cxpbx

Wann professionelle Unterstützung sinnvoll ist

Bei wiederkehrenden Problemen, die sich mit den obigen Schritten nicht eingrenzen lassen — insbesondere bei komplexen Multi-Site-Setups, VPN-Strecken oder mehreren SIP-Trunks gleichzeitig — lohnt sich eine gezielte Fernanalyse, statt stundenlang im Log Viewer zu suchen.

Diagnose-Checkliste vor dem Support-Ticket

Bevor Sie ein Ticket beim 3CX-Support oder Ihrem Partner eröffnen, hilft diese Checkliste, die relevanten Informationen direkt griffbereit zu haben:

1. Betroffene Komponente eindeutig benannt (Admin-Portal, konkreter Trunk, konkrete Extension, alle Anrufe)?
2. Zeitpunkt und Häufigkeit des Problems notiert (einmalig, seit wann durchgehend, nur zu bestimmten Zeiten)?
3. Relevanter Log-Ausschnitt aus dem Log Viewer exportiert?
4. Änderungen kurz vor dem Auftreten des Problems dokumentiert (Update, Firewall-Änderung, neuer Trunk)?
5. Betroffenheit eingegrenzt: ein Nutzer, eine Gruppe, oder alle?

Häufig gestellte Fragen

Wo finde ich die 3CX-Logs?

Am einfachsten über den 3CX Log Viewer in der Admin Console. Auf Linux-Installationen liegen die Rohdaten zusätzlich unterhalb von /var/lib/3cxpbx/Logs auf dem Server.

Warum registriert sich mein SIP-Trunk nicht?

Häufigste Ursachen: falsche Zugangsdaten, blockierte Ports 5060/UDP oder 5060–5061/TCP in der Firewall, oder eine dynamische statt statischer öffentlicher IP-Adresse, die der Provider für die Registrierung erwartet.

Warum ist bei Anrufen kein Ton zu hören (One-Way-Audio)?

Meist ein zu eng gefasster oder komplett fehlender RTP-Portbereich (9000–10999/UDP) in der Firewall bzw. NAT-Konfiguration. Der SIP-Kanal baut auf, die Audiopakete finden aber keinen Weg zurück.

Weiterführend

• Sicherheit & Firewall-Ports
• SIP-Trunk-Übersicht
• Backup & Restore