How to Fix Zimbra’s “Nginx Proxy Service Stopped” Error

When Zimbra reports “Nginx Proxy Service Stopped,” the proxy process is down or its status check cannot confirm it is running. Restarting it can restore access when the stop was temporary, but the same message can return if NGINX cannot load its generated configuration, bind a required port, read a certificate, or reach a valid upstream server. The useful result is not just a green status: the proxy should stay running, Zimbra webmail should load through the intended public URL, and proxy logs should no longer show the startup failure.

This guide applies to Zimbra deployments that use the bundled Zimbra Proxy service. Exact commands and configuration details can vary by Zimbra version and topology. On a multi-server installation, run checks on the proxy node and do not enable the proxy on a mailbox or MTA node simply because another server reports it stopped. Zimbra’s Proxy Guide and proxy CLI reference describe the service and its diagnostic files. Some Tech Center troubleshooting pages are marked as works in progress, so use them alongside documentation for your installed release.

1. Confirm the proxy is supposed to run on this server

Connect to the Zimbra server that hosts the proxy and switch to the Zimbra account. Check both the overall service list and the proxy-specific status:

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

Look for proxy in the enabled services and for a running NGINX process in the status output. Zimbra documents zmproxyctl with start, stop, restart, reload, and status actions. If this host is a mailbox-only or MTA-only node, a stopped proxy may be expected. Confirm the server’s role in your deployment before trying to turn it on.

If the proxy should be active and the status is stopped, capture the current state before changing anything. This helps distinguish a failed restart from a service that was never enabled on the node.

2. Read the NGINX error log before restarting

Zimbra’s proxy troubleshooting guide identifies /opt/zimbra/log/nginx.log and /opt/zimbra/log/nginx.access.log as key proxy logs. Check recent error entries and whether the main configuration file exists:

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

The error text usually points toward the next check. A missing nginx.conf suggests the generated configuration needs investigation. An “invalid port” in a listen directive points toward a port or bind setting. A private-key or certificate error points toward SSL material. A bind failure indicates that another process may already own the address and port.

Nu ștergeți fișierele de configurare NGINX și nu editați fișierele generate pentru a face eroarea să dispară. Zimbra își construiește configurația NGINX din șabloane și valori stocate în directorul său de configurare și LDAP. Ghidul furnizorului pentru configurarea și șabloane proxy explică acest model de generare. Modificările manuale ale fișierelor generate pot fi înlocuite în timpul unei reporniri ulterioare sau al unei actualizări de configurație.

3. Încercați repornirea proxy-ului acceptat și verificați rezultatul.

Dacă jurnalele nu indică o eroare persistentă de configurare sau de certificat, reporniți serviciul prin intermediul controlerului Zimbra ca utilizator Zimbra:

zmproxyctl restart
zmproxyctl status

Apoi verificați din nou lista completă de servicii:

zmcontrol status

Un rezultat pozitiv este că proxy-ul raportează că rulează și rămâne în funcțiune după finalizarea comenzii. Documentația proxy-ului Zimbra descrie zmproxyctl restartoperațiunea de serviciu care invocă și generarea configurației. Evitați utilizarea unui proxy la nivel de sistem systemctl restart nginxca înlocuitor: Zimbra își gestionează propria configurație și serviciu proxy. Dacă repornirea eșuează, reveniți la cea mai recentă eroare din nginx.log; repornirile repetate fără citirea erorii nu corectează de obicei cauza.

4. Asociați eroarea cu o reparație specifică

Dacă fișierul de configurare lipsește sau generarea eșuează

Nota de depanare Zimbra pentru un atribut lipsă /opt/zimbra/conf/nginx.confdescrie cazurile în care generarea configurației proxy eșuează deoarece un atribut din amonte conține un server inexistent sau un server care nu este un server de cutii poștale. Inspectați mai întâi valorile relevante la nivel de server și globale:

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

Comparați fiecare nume de gazdă cu inventarul serverului live și cu designul de rutare dorit. Corectați intrările învechite sau nevalide numai după ce confirmați care server ar trebui să primească acel trafic. Nu copiați un nume de gazdă exemplu de pe pagina unui furnizor în producție. Nota oficială de depanare „Nginx nu reușește să pornească” arată o comandă configuration-generator pentru modelul specific missing-config / generator-error:

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

Folosiți această funcție numai atunci când eroarea observată corespunde acelui model și după ce ați analizat valorile relevante. Dacă generatorul încă generează o excepție sau fișierul lipsește, opriți-l și investigați urmărirea completă a stivei și atributele serverului, în loc să îl rulați din nou.

Dacă jurnalul raportează un port nevalid sau o eroare de legare

Mai întâi identificați care listener configurat eșuează. Verificați valorile serviciului Zimbra și ale portului proxy pentru acest nod, apoi inspectați dacă un alt proces ascultă deja la adresa afectată. De exemplu, dacă mesajul numește portul 443, verificați dacă listenerul HTTPS public este deținut de Zimbra NGINX sau de un server web separat sau de un agent de echilibrare a încărcării. Nu terminați un proces necunoscut și nu atribuiți un port nou până nu înțelegeți cum ajung clienții la serviciu.

O eroare precum „ invalid port ...:0nu este un motiv pentru a ghici un număr de port”. Aceasta poate indica o setare proxy inconsistentă sau o configurație generată inconsistentă. Comparați valoarea cu topologia așteptată, examinați modificările recente și corectați setarea sursă prin intermediul instrumentelor acceptate de Zimbra. Apoi reporniți cu zmproxyctlși confirmați că listener-ul generat este valid.

Dacă pornirea eșuează în timpul încărcării unui certificat sau a unei chei private

Citiți eroarea SSL completă și identificați calea certificatului menționată în aceasta. Confirmați că certificatul și cheia privată aparțin împreună, sunt lizibile de contul de serviciu așteptat și nu au expirat. Documentația de depanare a proxy-ului Zimbra include un caz în care proxy-ul nu poate încărca materialul cheii. Urmați procedura de implementare a certificatului pentru versiunea dvs. de Zimbra, în loc să înlocuiți fișierele ad-hoc. O repornire reușită ar trebui să elimine eroarea de pornire SSL, iar un browser ar trebui să prezinte certificatul așteptat pentru numele de gazdă public al webmail-ului.

Dacă NGINX pornește, dar utilizatorii văd erori de gateway

Un proxy care rulează nu dovedește că backend-urile cutiei poștale sunt sănătoase. Pentru „Fără rută către gazdă”, Zimbra recomandă verificarea rezoluției DNS de la nodul proxy și a accesibilității la nivel de port către backend-ul dorit. Pentru răspunsurile 502 sau 503, verificați serviciul cutiei poștale și gazda și portul din amonte; ghidul proxy menționează că un proces de cutie poștală indisponibil poate cauza erori 503. Utilizați backend-ul și portul exact pentru versiunea și topologia dvs. și verificați jurnalele serverului de cutii poștale înainte de a modifica timeout-urile proxy sau pragurile de eroare.

5. Verificați recuperarea atât de pe server, cât și de pe un browser

După o reparație specifică, confirmați toate următoarele:

• zmproxyctl statusraportează rularea proxy-ului.
• zmcontrol statusafișează serviciile așteptate pentru acest nod.
• Ultimele linii din /opt/zimbra/log/nginx.lognu repetă aceeași eroare de pornire.
• Listener-ul așteptat este prezent și este deținut de serviciul dorit. Pe Linux, un administrator poate inspecta listener-ele cu ss -ltnp; permisiunea și detaliile de ieșire variază în funcție de distribuție.
• Un browser poate accesa numele de gazdă webmail Zimbra normal prin HTTPS, se poate conecta și încărca o cutie poștală. Dacă și clienții IMAP sau POP utilizează acest proxy, testați aceste protocoale separat.

Aceste verificări definesc o recuperare utilă: serviciul este activ, listenerul său există, calea browserului funcționează și eroarea nu a revenit imediat. Dacă starea serviciului este verde, dar webmail-ul încă eșuează, îndreptați atenția către DNS, TLS, regulile firewall, rutarea load balancer sau starea backend-ului cutiei poștale. Dacă se oprește din nou, păstrați noile linii de jurnal și ieșirea generatorului de configurare; acestea sunt mai utile decât o altă repornire oarbă.

Folosește jurnalizarea de depanare doar pentru o investigație scurtă și controlată

Dacă jurnalele normale nu explică o eroare persistentă, Zimbra documentează o creștere temporară a nivelului jurnalului proxy NGINX. Înregistrarea în jurnal a depanării poate expune informații sensibile, inclusiv token-uri de autentificare, așadar evitați activarea acesteia pe un sistem de producție decât dacă este necesar. Dacă asistența vă indică să o utilizați, restricționați accesul la jurnale, colectați doar ceea ce este necesar, apoi reveniți la valoarea anterioară a setării și gestionați jurnalele de depanare conform politicii dvs. de securitate. Consultați instrucțiunile de înregistrare în jurnal a depanării NGINX ale Zimbra pentru comanda corespunzătoare versiunii.

Escalați problema către administratorul Zimbra sau către serviciul de asistență al furnizorului dacă generarea configurației continuă să eșueze, certificatul proxy nu poate fi validat, eroarea implică un listener necunoscut sau rolul nodului este neclar. Controlerul de servicii poate reporni o configurație sănătoasă; nu poate determina rutarea corectă a e-mailurilor, nu poate repara un certificat nevalid sau nu poate rezolva singur o cale de rețea defectă.

Referințe oficiale

• Ghid Zimbra Proxy: jurnalele și depanarea backend-ului
• Manualul Zimbra Proxy: comenzi CLI proxy
• Centrul Tehnic Zimbra: NGINX nu pornește
• Centrul tehnic Zimbra: pași pentru un serviciu proxy care nu pornește
• Manualul Zimbra Proxy: configurație și șabloane generate

Surse revizuite la 6 octombrie 2026. Paginile Centrului Tehnic Zimbra la care se face referire aici includ exemple mai vechi, iar unele sunt etichetate ca lucrări în curs; confirmați comenzile pentru versiunea Zimbra instalată pe server înainte de a modifica configurația de producție.