Come risolvere l'errore "Servizio proxy Nginx arrestato" di Zimbra

Quando Zimbra segnala "Servizio proxy Nginx arrestato", il processo proxy è inattivo o il suo controllo di stato non riesce a confermare che sia in esecuzione. Riavviarlo può ripristinare l'accesso se l'arresto era temporaneo, ma lo stesso messaggio può ripresentarsi se NGINX non riesce a caricare la configurazione generata, ad associare una porta necessaria, a leggere un certificato o a raggiungere un server upstream valido. Il risultato utile non è solo uno stato verde: il proxy dovrebbe rimanere in esecuzione, la webmail di Zimbra dovrebbe caricarsi tramite l'URL pubblico previsto e i log del proxy non dovrebbero più mostrare l'errore di avvio.

Questa guida si applica alle implementazioni di Zimbra che utilizzano il servizio Zimbra Proxy incluso. I comandi esatti e i dettagli di configurazione possono variare a seconda della versione di Zimbra e della topologia. In un'installazione multi-server, eseguire dei controlli sul nodo proxy e non abilitare il proxy su un nodo mailbox o MTA solo perché un altro server segnala che si è arrestato. La Guida al proxy di Zimbra e il riferimento alla CLI del proxy descrivono il servizio e i relativi file di diagnostica. Alcune pagine di risoluzione dei problemi del Tech Center sono contrassegnate come "in fase di sviluppo", quindi utilizzarle insieme alla documentazione per la versione installata.

1. Conferma che il proxy deve essere eseguito su questo server

Connettiti al server Zimbra che ospita il proxy e passa all'account Zimbra. Verifica sia l'elenco generale dei servizi che lo stato specifico del proxy:

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

Cercare proxynei servizi abilitati e un processo NGINX in esecuzione nell'output di stato. Documenti Zimbra zmproxyctlcon azioni start, stop, restart, reload, e status. Se questo host è un nodo solo mailbox o solo MTA, è possibile che il proxy sia arrestato. Confermare il ruolo del server nella distribuzione prima di provare ad accenderlo.

Se il proxy dovrebbe essere attivo e il suo stato è "arrestato", è necessario acquisire lo stato corrente prima di apportare qualsiasi modifica. Questo aiuta a distinguere un riavvio non riuscito da un servizio che non è mai stato abilitato sul nodo.

2. Leggere il registro degli errori di NGINX prima di riavviare

La guida alla risoluzione dei problemi del proxy di Zimbra identifica /opt/zimbra/log/nginx.loge /opt/zimbra/log/nginx.access.logcome log del proxy chiave. Controlla le voci di errore recenti e se il file di configurazione principale esiste:

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

Il testo dell'errore di solito indica il controllo successivo. Un valore mancante nginx.confsuggerisce che la configurazione generata necessita di un'analisi. Un "porta non valida" in una listendirettiva indica un problema con la porta o con le impostazioni di associazione. Un errore relativo alla chiave privata o al certificato indica un problema con il protocollo SSL. Un errore di associazione indica che un altro processo potrebbe già essere proprietario dell'indirizzo e della porta.

Non eliminare i file di configurazione di NGINX né modificare i file generati per far scomparire l'errore. Zimbra crea la sua configurazione NGINX a partire da modelli e valori memorizzati nella sua directory di configurazione e in LDAP. La guida alla configurazione del proxy e ai modelli del fornitore spiega questo modello di generazione. Le modifiche manuali ai file generati potrebbero essere ripristinate durante un successivo riavvio o aggiornamento della configurazione.

3. Prova a riavviare il proxy supportato e verifica il risultato

Se i log non indicano un errore di configurazione o di certificato persistente, riavviare il servizio tramite il controller di Zimbra come utente Zimbra:

zmproxyctl restart
zmproxyctl status

Quindi, controlla nuovamente l'elenco completo dei servizi:

zmcontrol status

Un risultato positivo si verifica quando il proxy segnala di essere in esecuzione e rimane in esecuzione dopo il completamento del comando. La documentazione del proxy di Zimbra descrive zmproxyctl restartl'operazione di servizio che avvia anche la generazione della configurazione. Evitare di utilizzare un proxy a livello di sistema systemctl restart nginxcome sostituto: Zimbra gestisce autonomamente la configurazione e il servizio del proxy. Se il riavvio non riesce, tornare all'errore più recente in nginx.log; i riavvii ripetuti senza leggere l'errore di solito non risolvono la causa.

4. Associare l'errore a una riparazione mirata

Se il file di configurazione è mancante o la generazione non riesce

La nota di risoluzione dei problemi di Zimbra relativa a un indirizzo mancante /opt/zimbra/conf/nginx.confdescrive i casi in cui la generazione della configurazione proxy non riesce perché un attributo upstream contiene un server inesistente o un server che non è un server di posta. Verificare innanzitutto i valori pertinenti a livello di server e globali:

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

Confronta ogni nome host con l'inventario dei server attivi e con la configurazione di routing prevista. Correggi le voci obsolete o non valide solo dopo aver confermato quale server deve ricevere quel traffico. Non copiare un nome host di esempio da una pagina del fornitore in produzione. La nota ufficiale di risoluzione dei problemi "Nginx non si avvia" mostra un comando di generazione della configurazione per lo specifico modello di errore di configurazione mancante/generatore:

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

Utilizzare questa opzione solo se l'errore osservato corrisponde a tale schema e dopo aver esaminato i valori pertinenti. Se il generatore continua a generare un'eccezione o il file risulta mancante, interrompere l'esecuzione e analizzare l'intera traccia dello stack e gli attributi del server, anziché rieseguirlo ripetutamente.

Se il registro segnala una porta non valida o un errore di associazione

Innanzitutto, identifica quale listener configurato non funziona. Verifica i valori della porta del servizio Zimbra e del proxy per questo nodo, quindi controlla se un altro processo è già in ascolto sull'indirizzo interessato. Ad esempio, se il messaggio menziona la porta 443, verifica se il listener HTTPS pubblico è gestito da Zimbra NGINX o da un server web o un agente di bilanciamento del carico separato. Non terminare un processo sconosciuto né assegnare una nuova porta finché non hai capito come i client raggiungono il servizio.

Un errore di questo tipo invalid port ...:0non è un motivo per indovinare il numero di porta. Potrebbe indicare un'impostazione proxy incoerente o una configurazione generata errata. Confronta il valore con la topologia prevista, rivedi le modifiche recenti e correggi l'impostazione di origine tramite gli strumenti supportati da Zimbra. Quindi riavvia zmproxyctle verifica che il listener generato sia valido.

Se l'avvio fallisce durante il caricamento di un certificato o di una chiave privata

Leggete l'intero messaggio di errore SSL e identificate il percorso del certificato in esso indicato. Verificate che il certificato e la chiave privata siano associati, siano leggibili dall'account di servizio previsto e non siano scaduti. La documentazione di Zimbra sulla risoluzione dei problemi del proxy include un caso in cui il proxy non riesce a caricare il materiale della chiave. Seguite la procedura di distribuzione del certificato per la vostra versione di Zimbra, anziché sostituire i file in modo estemporaneo. Un riavvio corretto dovrebbe risolvere l'errore di avvio SSL e il browser dovrebbe visualizzare il certificato previsto per il nome host della webmail pubblica.

Se NGINX si avvia ma gli utenti visualizzano errori del gateway

Il funzionamento del proxy non garantisce l'integrità dei backend delle caselle di posta. Per l'errore "Nessun percorso verso l'host", Zimbra consiglia di verificare la risoluzione DNS dal nodo proxy e la raggiungibilità a livello di porta del backend di destinazione. Per le risposte 502 o 503, verificare il servizio di posta, l'host e la porta a monte; la guida al proxy indica che un processo di posta non disponibile può causare errori 503. Utilizzare il backend e la porta esatti per la propria versione e topologia e controllare i log del server di posta prima di modificare i timeout del proxy o le soglie di errore.

5. Verificare il ripristino sia dal server che dal browser

Dopo una riparazione mirata, verificare quanto segue:

• zmproxyctl statussegnala che il proxy è in esecuzione.
• zmcontrol statusmostra i servizi previsti per questo nodo.
• Le ultime righe /opt/zimbra/log/nginx.lognon ripetono lo stesso errore di avvio.
• Il listener previsto è presente e appartiene al servizio in questione. Su Linux, un amministratore può ispezionare i listener con ss -ltnp; i permessi e i dettagli dell'output variano a seconda della distribuzione.
• Un browser può raggiungere il normale hostname di webmail di Zimbra tramite HTTPS, effettuare l'accesso e caricare una casella di posta. Se anche i client IMAP o POP utilizzano questo proxy, testare separatamente tali protocolli.

Questi controlli definiscono un ripristino efficace: il servizio è attivo, il suo listener esiste, il percorso del browser funziona e l'errore non si è ripresentato immediatamente. Se lo stato del servizio è verde ma la webmail continua a non funzionare, è necessario concentrarsi su DNS, TLS, regole del firewall, routing del bilanciatore di carico o integrità del backend della casella di posta. Se il problema si ripresenta, è importante conservare le nuove righe di log e l'output del generatore di configurazione; questi dati sono più utili di un altro riavvio alla cieca.

Utilizzare la registrazione di debug solo per un'indagine breve e controllata.

Se i log normali non spiegano un errore persistente, Zimbra documenta un aumento temporaneo del livello di log del proxy NGINX. La registrazione di debug può esporre informazioni sensibili, inclusi i token di autenticazione, quindi è consigliabile evitare di abilitarla su un sistema di produzione a meno che non sia necessario. Se il supporto tecnico ne richiede l'utilizzo, è necessario limitare l'accesso ai log, raccogliere solo le informazioni necessarie, quindi ripristinare l'impostazione al valore precedente e gestire i log di debug in conformità con le proprie policy di sicurezza. Consultare le istruzioni di Zimbra sulla registrazione di debug di NGINX per il comando appropriato alla versione del sistema.

Se la generazione della configurazione continua a fallire, il certificato proxy non può essere convalidato, l'errore riguarda un listener sconosciuto o il ruolo del nodo non è chiaro, contatta l'amministratore di Zimbra o il supporto del fornitore. Il controller del servizio può riavviare una configurazione funzionante; tuttavia, non è in grado di determinare autonomamente il corretto instradamento della posta, riparare un certificato non valido o risolvere un percorso di rete interrotto.

Riferimenti ufficiali

• Guida al proxy Zimbra: log e risoluzione dei problemi di backend
• Manuale del proxy Zimbra: comandi CLI del proxy
• Centro assistenza tecnica Zimbra: NGINX non si avvia
• Centro assistenza Zimbra: procedura per un servizio proxy che non si avvia
• Manuale del proxy Zimbra: configurazione e modelli generati

Fonti esaminate il 6 ottobre 2026. Le pagine del Centro assistenza tecnica di Zimbra qui citate includono esempi meno recenti e alcune sono contrassegnate come "in fase di sviluppo"; si consiglia di verificare i comandi con la versione di Zimbra installata sul server prima di modificare la configurazione di produzione.