So beheben Sie den Zimbra-Fehler „Nginx-Proxy-Dienst wurde gestoppt“.

Wenn Zimbra „Nginx Proxy Service Stopped“ meldet, ist der Proxy-Prozess entweder ausgefallen oder seine Statusprüfung kann seinen Betrieb nicht bestätigen. Ein Neustart kann den Zugriff wiederherstellen, wenn der Ausfall nur vorübergehend war. Dieselbe Meldung kann jedoch auch erscheinen, wenn NGINX seine generierte Konfiguration nicht laden, einen erforderlichen Port nicht binden, ein Zertifikat nicht lesen oder keinen gültigen Upstream-Server erreichen kann. Das gewünschte Ergebnis ist mehr als nur ein grüner Status: Der Proxy sollte weiterhin laufen, Zimbra Webmail sollte über die vorgesehene öffentliche URL erreichbar sein und die Proxy-Protokolle sollten keinen Startfehler mehr anzeigen.

Diese Anleitung gilt für Zimbra-Bereitstellungen, die den integrierten Zimbra-Proxy-Dienst nutzen. Die genauen Befehle und Konfigurationsdetails können je nach Zimbra-Version und -Topologie variieren. Führen Sie bei Installationen mit mehreren Servern Prüfungen auf dem Proxy-Knoten durch und aktivieren Sie den Proxy nicht auf einem Mailbox- oder MTA-Knoten, nur weil ein anderer Server meldet, dass er beendet wurde. Die Zimbra- Proxy-Anleitung und die Proxy-CLI-Referenz beschreiben den Dienst und seine Diagnosedateien. Einige Seiten zur Fehlerbehebung im Tech Center sind als „in Bearbeitung“ gekennzeichnet. Verwenden Sie diese daher zusammen mit der Dokumentation für Ihre installierte Version.

1. Bestätigen Sie, dass der Proxy auf diesem Server ausgeführt werden soll.

Stellen Sie eine Verbindung zum Zimbra-Server her, der den Proxy hostet, und wechseln Sie zum Zimbra-Konto. Überprüfen Sie sowohl die allgemeine Dienstliste als auch den Proxy-spezifischen Status:

su - zimbra
zmcontrol status
zmproxyctl status
zmprov gs `zmhostname` zimbraServiceEnabled

Suchen Sie proxyin den aktivierten Diensten nach einem laufenden NGINX-Prozess in der Statusausgabe. Zimbra dokumentiert zmproxyctldie entsprechenden Aktionen. Wenn startes sich bei diesem Host um einen reinen Mailbox- oder MTA - Knoten stophandelt , ist ein gestoppter Proxy zu erwarten. Prüfen Sie die Rolle des Servers in Ihrer Bereitstellung, bevor Sie versuchen, ihn zu aktivieren.restartreloadstatus

Wenn der Proxy aktiv sein sollte, der Status aber „Beendet“ lautet, erfassen Sie den aktuellen Zustand, bevor Sie Änderungen vornehmen. Dies hilft, einen fehlgeschlagenen Neustart von einem Dienst zu unterscheiden, der auf dem Knoten nie aktiviert wurde.

2. Lesen Sie das NGINX-Fehlerprotokoll vor dem Neustart.

Zimbras Leitfaden zur Proxy-Fehlerbehebung nennt /opt/zimbra/log/nginx.logund /opt/zimbra/log/nginx.access.logals wichtige Proxy-Protokolle. Überprüfen Sie die letzten Fehlermeldungen und ob die Hauptkonfigurationsdatei vorhanden ist:

tail -n 100 /opt/zimbra/log/nginx.log
tail -n 50 /opt/zimbra/log/nginx.access.log
ls -l /opt/zimbra/conf/nginx.conf

Der Fehlertext weist üblicherweise auf die nächste Prüfung hin. Fehlt ein Eintrag, nginx.confmuss die generierte Konfiguration überprüft werden. Ein ungültiger Port in einer listenDirektive deutet auf ein Problem mit der Port- oder Bindungseinstellung hin. Ein Fehler mit dem privaten Schlüssel oder Zertifikat weist auf ein Problem mit SSL hin. Ein Bindungsfehler bedeutet, dass ein anderer Prozess möglicherweise bereits die Adresse und den Port verwendet.

Löschen Sie keine NGINX-Konfigurationsdateien und bearbeiten Sie keine generierten Dateien, um den Fehler zu beheben. Zimbra erstellt seine NGINX-Konfiguration anhand von Vorlagen und Werten, die im Konfigurationsverzeichnis und im LDAP gespeichert sind. Die Proxy-Konfigurations- und Vorlagenanleitung des Herstellers erläutert dieses Generierungsmodell. Manuelle Änderungen an generierten Dateien können bei einem späteren Neustart oder einer Konfigurationsaktualisierung überschrieben werden.

3. Versuchen Sie einen Neustart des unterstützten Proxys und überprüfen Sie das Ergebnis.

Falls die Protokolle keinen anhaltenden Konfigurations- oder Zertifikatsfehler anzeigen, starten Sie den Dienst über den Zimbra-Controller als Zimbra-Benutzer neu:

zmproxyctl restart
zmproxyctl status

Überprüfen Sie dann erneut die vollständige Serviceliste:

zmcontrol status

Ein erfolgreiches Ergebnis liegt vor, wenn der Proxy meldet, dass er ausgeführt wird und nach Abschluss des Befehls weiterhin aktiv bleibt. Die Zimbra-Proxy-Dokumentation beschreibt dies zmproxyctl restartals Dienstoperation, die auch die Konfigurationsgenerierung aufruft. Vermeiden Sie die Verwendung eines systemweiten Proxys systemctl restart nginxals Ersatz: Zimbra verwaltet seine eigene Proxy-Konfiguration und seinen eigenen Dienst. Falls der Neustart fehlschlägt, kehren Sie zum letzten Fehler in der Fehlerbehandlung zurück nginx.log; wiederholte Neustarts ohne Berücksichtigung des Fehlers beheben die Ursache in der Regel nicht.

4. Ordnen Sie den Fehler einer gezielten Reparatur zu.

Wenn die Konfigurationsdatei fehlt oder die Generierung fehlschlägt

Zimbras Hinweis zur Fehlerbehebung bei fehlenden Einträgen /opt/zimbra/conf/nginx.confbeschreibt Fälle, in denen die Generierung der Proxy-Konfiguration fehlschlägt, weil ein Upstream-Attribut einen nicht existierenden Server oder einen Server enthält, der kein Mailbox-Server ist. Überprüfen Sie zunächst die relevanten Werte auf Serverebene und die globalen Werte:

zmprov -l gs `zmhostname` zimbraReverseProxyAvailableLookupTargets
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamEwsServers
zmprov -l gs `zmhostname` zimbraReverseProxyUpstreamLoginServers
zmprov -l gcf zimbraReverseProxyAvailableLookupTargets
zmprov -l gcf zimbraReverseProxyUpstreamEwsServers
zmprov -l gcf zimbraReverseProxyUpstreamLoginServers

Vergleichen Sie jeden Hostnamen mit der Live-Serverliste und Ihrem geplanten Routing-Design. Korrigieren Sie veraltete oder ungültige Einträge erst, nachdem Sie bestätigt haben, welcher Server den Datenverkehr empfangen soll. Kopieren Sie keinen Beispiel-Hostnamen von einer Anbieterseite in die Produktionsumgebung. Die offizielle Fehlerbehebungsanleitung „Nginx startet nicht“ enthält einen Befehl zur Konfigurationsgenerierung für das spezifische Fehlermuster „fehlende Konfiguration“ / „Generatorfehler“.

/opt/zimbra/libexec/zmproxyconfgen -s `zmhostname`
zmproxyctl restart

Verwenden Sie diese Methode nur, wenn der beobachtete Fehler diesem Muster entspricht und nachdem Sie die relevanten Werte überprüft haben. Falls der Generator weiterhin eine Ausnahme auslöst oder die Datei fehlt, brechen Sie den Vorgang ab und untersuchen Sie den vollständigen Stacktrace sowie die Serverattribute, anstatt ihn wiederholt auszuführen.

Wenn das Protokoll einen ungültigen Port oder einen Bindungsfehler meldet

Identifizieren Sie zunächst den konfigurierten Listener, der nicht funktioniert. Überprüfen Sie die Zimbra-Dienst- und Proxy-Portwerte für diesen Knoten und prüfen Sie anschließend, ob bereits ein anderer Prozess auf der betroffenen Adresse lauscht. Wenn die Meldung beispielsweise Port 443 nennt, prüfen Sie, ob der öffentliche HTTPS-Listener von Zimbra NGINX oder einem separaten Webserver bzw. Load-Balancer-Agenten verwaltet wird. Beenden Sie keinen unbekannten Prozess und weisen Sie keinen neuen Port zu, bevor Sie wissen, wie Clients den Dienst erreichen.

Ein Fehler wie dieser invalid port ...:0ist kein Grund, die Portnummer zu erraten. Er kann auf eine inkonsistente Proxy-Einstellung oder eine fehlerhafte generierte Konfiguration hinweisen. Vergleichen Sie den Wert mit der erwarteten Topologie, überprüfen Sie die letzten Änderungen und korrigieren Sie die Quelleinstellung mithilfe der von Zimbra unterstützten Tools. Starten Sie anschließend neu zmproxyctlund vergewissern Sie sich, dass der generierte Listener gültig ist.

Wenn der Startvorgang beim Laden eines Zertifikats oder privaten Schlüssels fehlschlägt

Lesen Sie die vollständige SSL-Fehlermeldung und ermitteln Sie den darin genannten Zertifikatspfad. Stellen Sie sicher, dass Zertifikat und privater Schlüssel zusammengehören, vom vorgesehenen Dienstkonto lesbar sind und nicht abgelaufen sind. Die Dokumentation zur Fehlerbehebung bei Zimbra-Proxys enthält einen Fall, in dem der Proxy das Schlüsselmaterial nicht laden kann. Befolgen Sie die für Ihre Zimbra-Version vorgesehene Zertifikatbereitstellungsprozedur, anstatt Dateien willkürlich zu ersetzen. Ein erfolgreicher Neustart sollte den SSL-Startfehler beheben, und der Browser sollte das erwartete Zertifikat für den öffentlichen Webmail-Hostnamen anzeigen.

Wenn NGINX startet, aber Benutzer Gateway-Fehler sehen

Ein laufender Proxy beweist nicht, dass die Mailbox-Backends fehlerfrei funktionieren. Bei der Fehlermeldung „Keine Route zum Host“ empfiehlt Zimbra, die DNS-Auflösung vom Proxy-Knoten und die Erreichbarkeit des gewünschten Backends auf Portebene zu überprüfen. Bei 502- oder 503-Fehlern überprüfen Sie den Mailbox-Dienst sowie den Upstream-Host und -Port. Im Proxy-Leitfaden wird darauf hingewiesen, dass ein nicht verfügbarer Mailbox-Prozess 503-Fehler verursachen kann. Verwenden Sie das exakte Backend und den Port, die für Ihre Version und Topologie gelten, und überprüfen Sie die Mailbox-Serverprotokolle, bevor Sie Proxy-Timeouts oder Fehlerschwellenwerte ändern.

5. Überprüfen Sie die Wiederherstellung sowohl vom Server als auch von einem Browser aus.

Nach einer gezielten Reparatur überprüfen Sie bitte Folgendes:

• zmproxyctl statusmeldet, dass der Proxy läuft.
• zmcontrol statuszeigt die für diesen Knoten erwarteten Dienste an.
• Die neuesten Zeilen /opt/zimbra/log/nginx.logwiederholen nicht denselben Startfehler.
• Der erwartete Listener ist vorhanden und gehört zum gewünschten Dienst. Unter Linux kann ein Administrator die Listener mit dem Befehl `ls -l` überprüfen ss -ltnp; Berechtigungen und Ausgabedetails variieren je nach Distribution.
• Ein Browser kann den normalen Zimbra-Webmail-Hostnamen über HTTPS erreichen, sich anmelden und ein Postfach laden. Falls IMAP- oder POP-Clients diesen Proxy ebenfalls verwenden, testen Sie diese Protokolle separat.

Diese Prüfungen definieren eine erfolgreiche Wiederherstellung: Der Dienst ist verfügbar, sein Listener existiert, der Browserpfad funktioniert und der Fehler ist nicht sofort wieder aufgetreten. Ist der Dienststatus grün, Webmail aber weiterhin nicht erreichbar, sollten Sie DNS, TLS, Firewall-Regeln, Load-Balancer-Routing oder den Zustand des Mailbox-Backends überprüfen. Falls der Dienst erneut ausfällt, speichern Sie die neuen Protokollzeilen und die Ausgabe des Konfigurationsgenerators; diese sind hilfreicher als ein weiterer Neustart ohne vorherige Prüfung.

Verwenden Sie die Debug-Protokollierung nur für kurze, kontrollierte Untersuchungen.

Wenn normale Protokolle einen anhaltenden Fehler nicht erklären, protokolliert Zimbra eine temporäre Erhöhung des NGINX-Proxy-Protokollierungslevels. Debug-Protokollierung kann sensible Informationen, einschließlich Authentifizierungstoken, offenlegen. Aktivieren Sie sie daher auf einem Produktivsystem nur, wenn es unbedingt erforderlich ist. Falls der Support Sie zur Verwendung auffordert, beschränken Sie den Zugriff auf die Protokolle, erfassen Sie nur die benötigten Daten, setzen Sie die Einstellung anschließend wieder auf den vorherigen Wert zurück und behandeln Sie die Debug-Protokolle gemäß Ihrer Sicherheitsrichtlinie. Die für die jeweilige Version relevanten Befehle finden Sie in der Zimbra- Anleitung zur NGINX-Debug-Protokollierung .

Wenden Sie sich an Ihren Zimbra-Administrator oder den Support Ihres Anbieters, falls die Konfigurationsgenerierung weiterhin fehlschlägt, das Proxy-Zertifikat nicht validiert werden kann, der Fehler auf einen unbekannten Listener hinweist oder die Rolle des Knotens unklar ist. Der Service-Controller kann eine funktionierende Konfiguration neu starten; er kann jedoch nicht selbstständig das korrekte Mail-Routing bestimmen, ein ungültiges Zertifikat reparieren oder einen fehlerhaften Netzwerkpfad beheben.

Offizielle Referenzen

• Zimbra Proxy-Leitfaden: Protokolle und Fehlerbehebung im Backend
• Zimbra Proxy-Handbuch: Proxy-CLI-Befehle
• Zimbra Tech Center: NGINX startet nicht
• Zimbra Tech Center: Schritte zur Behebung eines Proxy-Dienstes, der nicht startet
• Zimbra Proxy-Handbuch: Generierte Konfiguration und Vorlagen

Die Quellen wurden am 6. Oktober 2026 überprüft. Die hier genannten Seiten des Zimbra Tech Centers enthalten ältere Beispiele und einige sind als „in Bearbeitung“ gekennzeichnet; überprüfen Sie die Befehle anhand der auf Ihrem Server installierten Zimbra-Version, bevor Sie die Produktionskonfiguration ändern.