Como corrigir o erro "Serviço de proxy Nginx interrompido" do Zimbra

Quando o Zimbra reporta “Serviço de Proxy Nginx Parado”, o processo do proxy está inativo ou a verificação de status não consegue confirmar que ele está em execução. Reiniciá-lo pode restaurar o acesso quando a parada foi temporária, mas a mesma mensagem pode retornar se o NGINX não conseguir carregar a configuração gerada, vincular uma porta necessária, ler um certificado ou alcançar um servidor upstream válido. O resultado útil não é apenas um status verde: o proxy deve permanecer em execução, o webmail do Zimbra deve carregar através da URL pública correta e os logs do proxy não devem mais mostrar a falha de inicialização.

Este guia se aplica a implementações do Zimbra que utilizam o serviço Zimbra Proxy integrado. Os comandos exatos e os detalhes de configuração podem variar de acordo com a versão e a topologia do Zimbra. Em uma instalação com vários servidores, execute verificações no nó proxy e não habilite o proxy em um nó de caixa de correio ou MTA simplesmente porque outro servidor relatou que ele foi interrompido. O Guia do Proxy do Zimbra e a referência da CLI do proxy descrevem o serviço e seus arquivos de diagnóstico. Algumas páginas de solução de problemas do Tech Center estão marcadas como em desenvolvimento; portanto, use-as juntamente com a documentação da sua versão instalada.

1. Confirme se o proxy deve ser executado neste servidor.

Conecte-se ao servidor Zimbra que hospeda o proxy e acesse a conta Zimbra. Verifique tanto a lista geral de serviços quanto o status específico do proxy:

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

Procure por proxyserviços habilitados e por um processo NGINX em execução na saída de status. Documentos Zimbra com ações zmproxyctl. Se este host for um nó somente de caixa de correio ou somente de MTA, um proxy parado pode ser esperado. Confirme a função do servidor em sua implantação antes de tentar ativá-lo.startstoprestartreloadstatus

Se o proxy deveria estar ativo e o status for "parado", capture o estado atual antes de alterar qualquer coisa. Isso ajuda a distinguir uma reinicialização com falha de um serviço que nunca foi habilitado no nó.

2. Leia o log de erros do NGINX antes de reiniciar.

O guia de solução de problemas de proxy do Zimbra identifica `proxy.log` /opt/zimbra/log/nginx.loge /opt/zimbra/log/nginx.access.log`proxy.log` como logs de proxy importantes. Verifique as entradas de erro recentes e se o arquivo de configuração principal existe:

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

O texto de erro geralmente aponta para a próxima verificação. A ausência de um valor nginx.confsugere que a configuração gerada precisa ser investigada. Uma "porta inválida" em uma listendiretiva indica um problema com a porta ou configuração de vinculação. Um erro de chave privada ou certificado indica um problema com o SSL. Uma falha de vinculação indica que outro processo já pode estar utilizando o endereço e a porta.

Não exclua os arquivos de configuração do NGINX nem edite os arquivos gerados para que o erro desapareça. O Zimbra cria sua configuração do NGINX a partir de modelos e valores armazenados em seu diretório de configuração e LDAP. O guia de configuração e modelos de proxy do fornecedor explica esse modelo de geração. As edições manuais nos arquivos gerados podem ser revertidas em uma reinicialização ou atualização de configuração posterior.

3. Tente reiniciar o proxy conforme as instruções e verifique o resultado.

Se os registros não indicarem um erro persistente de configuração ou certificado, reinicie o serviço através do controlador do Zimbra como o usuário Zimbra:

zmproxyctl restart
zmproxyctl status

Em seguida, verifique novamente a lista completa de serviços:

zmcontrol status

Um resultado bem-sucedido é que o proxy reporte estar em execução e permaneça em execução após a conclusão do comando. A documentação do proxy do Zimbra descreve zmproxyctl restartessa operação como o serviço que também invoca a geração de configuração. Evite usar um proxy de sistema systemctl restart nginxcomo substituto: o Zimbra gerencia sua própria configuração e serviço de proxy. Se a reinicialização falhar, retorne ao erro mais recente em `/etc nginx.log/zimbra/proxy.conf`; reinicializações repetidas sem ler o erro geralmente não corrigem a causa.

4. Associe o erro a um reparo específico.

Se o arquivo de configuração estiver ausente ou a geração falhar

A nota de resolução de problemas do Zimbra para um erro /opt/zimbra/conf/nginx.confde configuração de proxy descreve casos em que a geração da configuração de proxy falha porque um atributo upstream contém um servidor inexistente ou um servidor que não é um servidor de caixa de correio. Inspecione primeiro os valores relevantes no nível do servidor e os valores globais:

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

Compare cada nome de host com o inventário de servidores ativos e com o seu projeto de roteamento. Corrija entradas desatualizadas ou inválidas somente após confirmar qual servidor deve receber o tráfego. Não copie um nome de host de exemplo da página de um fornecedor para um ambiente de produção. A nota oficial de solução de problemas "Nginx não inicia" mostra um comando de gerador de configuração para o padrão específico missing-config / generator-error:

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

Use esta opção somente quando a falha observada corresponder a esse padrão e após revisar os valores relevantes. Se o gerador ainda lançar uma exceção ou o arquivo continuar ausente, pare e investigue o rastreamento de pilha completo e os atributos do servidor, em vez de executá-lo repetidamente.

Se o registro indicar uma porta inválida ou falha na vinculação,

Primeiro, identifique qual listener configurado está apresentando falhas. Verifique os valores de porta do serviço Zimbra e do proxy para esse nó e, em seguida, inspecione se outro processo já está escutando no endereço afetado. Por exemplo, se a mensagem mencionar a porta 443, verifique se o listener HTTPS público pertence ao Zimbra NGINX ou a um servidor web separado ou a um agente de balanceamento de carga. Não encerre um processo desconhecido nem atribua uma nova porta até entender como os clientes acessam o serviço.

Um erro como esse invalid port ...:0não é motivo para tentar adivinhar o número da porta. Ele pode indicar uma configuração de proxy inconsistente ou uma configuração gerada incorretamente. Compare o valor com a topologia esperada, revise as alterações recentes e corrija a configuração de origem usando as ferramentas suportadas pelo Zimbra. Em seguida, reinicie o serviço zmproxyctle confirme se o listener gerado é válido.

Se a inicialização falhar durante o carregamento de um certificado ou chave privada

Leia a mensagem de erro SSL completa e identifique o caminho do certificado mencionado nela. Confirme se o certificado e a chave privada pertencem ao mesmo conjunto, se podem ser lidos pela conta de serviço esperada e se não expiraram. A documentação de solução de problemas de proxy do Zimbra inclui um caso em que o proxy não consegue carregar o material da chave. Siga o procedimento de implantação de certificado para a sua versão do Zimbra, em vez de substituir arquivos aleatoriamente. Uma reinicialização bem-sucedida deve resolver o erro de inicialização SSL e o navegador deverá exibir o certificado esperado para o nome de host do webmail público.

Se o NGINX iniciar, mas os usuários virem erros de gateway

Um proxy em execução não comprova que os servidores de e-mail estejam íntegros. Para o erro "Sem rota para o host", o Zimbra recomenda verificar a resolução de DNS a partir do nó do proxy e a acessibilidade em nível de porta ao servidor de e-mail pretendido. Para respostas 502 ou 503, verifique o serviço de e-mail e o host e porta upstream; o guia do proxy observa que um processo de e-mail indisponível pode causar erros 503. Use o servidor de e-mail e a porta exatos para sua versão e topologia e verifique os logs do servidor de e-mail antes de alterar os tempos limite ou os limites de falha do proxy.

5. Verifique a recuperação tanto do servidor quanto do navegador.

Após o reparo direcionado, confirme todos os seguintes itens:

• zmproxyctl statusinforma que o proxy está em execução.
• zmcontrol statusMostra os serviços esperados para este nó.
• As últimas linhas de código /opt/zimbra/log/nginx.lognão repetem a mesma falha de inicialização.
• O listener esperado está presente e pertence ao serviço pretendido. No Linux, um administrador pode inspecionar os listeners com o comando ss -ltnp`sudo`; as permissões e os detalhes de saída variam conforme a distribuição.
• Um navegador pode acessar o hostname normal do webmail Zimbra via HTTPS, fazer login e carregar uma caixa de correio. Se clientes IMAP ou POP também utilizarem esse proxy, teste esses protocolos separadamente.

Essas verificações definem uma recuperação útil: o serviço está ativo, seu ouvinte existe, o caminho do navegador funciona e a falha não retornou imediatamente. Se o status do serviço estiver verde, mas o webmail ainda falhar, concentre-se no DNS, TLS, regras de firewall, roteamento do balanceador de carga ou integridade do backend da caixa de correio. Se parar novamente, preserve as novas linhas de log e a saída do gerador de configuração; elas são mais úteis do que outra reinicialização às cegas.

Utilize o registro de depuração apenas para uma investigação breve e controlada.

Se os logs normais não explicarem uma falha persistente, o Zimbra documenta um aumento temporário no nível de log do proxy NGINX. O registro de depuração pode expor informações confidenciais, incluindo tokens de autenticação, portanto, evite habilitá-lo em um sistema de produção, a menos que seja necessário. Se o suporte técnico orientar você a usá-lo, restrinja o acesso aos logs, colete apenas o necessário e, em seguida, retorne a configuração ao seu valor anterior e gerencie os logs de depuração de acordo com sua política de segurança. Consulte as instruções de registro de depuração do NGINX do Zimbra para obter o comando apropriado para a sua versão.

Se a geração de configuração continuar falhando, o certificado do proxy não puder ser validado, o erro envolver um listener desconhecido ou a função do nó não estiver clara, entre em contato com o administrador do Zimbra ou com o suporte do fornecedor. O controlador de serviço pode reiniciar uma configuração íntegra; no entanto, ele não consegue determinar o roteamento de e-mail correto, reparar um certificado inválido ou resolver um caminho de rede corrompido por conta própria.

Referências oficiais

• Guia do Zimbra Proxy: logs e solução de problemas de backend
• Manual do Zimbra Proxy: comandos CLI do proxy
• Centro Técnico Zimbra: NGINX não inicia
• Centro Técnico Zimbra: etapas para um serviço proxy que não inicia
• Manual do Zimbra Proxy: configuração e modelos gerados

Fontes consultadas em 6 de outubro de 2026. As páginas do Zimbra Tech Center aqui referenciadas incluem exemplos antigos e algumas estão marcadas como trabalhos em andamento; confirme os comandos com a versão do Zimbra instalada em seu servidor antes de alterar a configuração de produção.