Cómo solucionar el error "Nginx Proxy Service Stopped" de Zimbra

Cuando Zimbra informa "Servicio de proxy Nginx detenido", el proceso del proxy está inactivo o su comprobación de estado no puede confirmar que se esté ejecutando. Reiniciarlo puede restablecer el acceso si la interrupción fue temporal, pero el mismo mensaje puede aparecer si NGINX no puede cargar su configuración generada, vincular un puerto necesario, leer un certificado o conectarse a un servidor ascendente válido. El resultado útil no es solo un estado verde: el proxy debería permanecer en ejecución, el correo web de Zimbra debería cargarse a través de la URL pública prevista y los registros del proxy ya no deberían mostrar el fallo de inicio.

Esta guía se aplica a las implementaciones de Zimbra que utilizan el servicio Zimbra Proxy incluido. Los comandos exactos y los detalles de configuración pueden variar según la versión y la topología de Zimbra. En una instalación con varios servidores, realice comprobaciones en el nodo proxy y no habilite el proxy en un nodo de buzón o MTA solo porque otro servidor informe que se ha detenido. La Guía de proxy de Zimbra y la referencia de la CLI de proxy describen el servicio y sus archivos de diagnóstico. Algunas páginas de solución de problemas del Centro de soporte técnico están marcadas como en desarrollo, por lo que se recomienda utilizarlas junto con la documentación de la versión instalada.

1. Confirma que el proxy debe ejecutarse en este servidor.

Conéctese al servidor Zimbra que aloja el proxy y cambie a la cuenta Zimbra. Verifique tanto la lista general de servicios como el estado específico del proxy:

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

Busque proxyen los servicios habilitados y un proceso NGINX en ejecución en la salida de estado. Zimbra documenta zmproxyctlcon acciones start, stop, restart, reload, y status. Si este host es un nodo solo de buzón o solo MTA, es posible que se espere un proxy detenido. Confirme el rol del servidor en su implementación antes de intentar encenderlo.

Si el proxy debería estar activo y su estado es detenido, capture el estado actual antes de realizar cualquier cambio. Esto ayuda a distinguir un reinicio fallido de un servicio que nunca se habilitó en el nodo.

2. Lea el registro de errores de NGINX antes de reiniciar.

La guía de solución de problemas de proxy de Zimbra identifica /opt/zimbra/log/nginx.logy /opt/zimbra/log/nginx.access.logcomo registros de proxy clave. Verifique las entradas de error recientes y si existe el archivo de configuración principal:

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

El texto de error suele indicar la siguiente comprobación. Si falta algún elemento, nginx.confsugiere que la configuración generada requiere investigación. Un "puerto no válido" en una listendirectiva apunta a un problema con el puerto o la configuración de enlace. Un error de clave privada o certificado apunta a problemas con SSL. Un fallo de enlace indica que otro proceso podría estar utilizando la dirección y el puerto.

No elimine los archivos de configuración de NGINX ni edite los archivos generados para solucionar el error. Zimbra crea su configuración de NGINX a partir de plantillas y valores almacenados en su directorio de configuración y en LDAP. La guía de configuración y plantillas del proxy del proveedor explica este modelo de generación. Las modificaciones manuales a los archivos generados podrían revertirse durante un reinicio o una actualización de configuración posterior.

3. Intente reiniciar el proxy compatible y verifique el resultado.

Si los registros no indican un error persistente de configuración o certificado, reinicie el servicio a través del controlador de Zimbra como el usuario Zimbra:

zmproxyctl restart
zmproxyctl status

A continuación, vuelva a consultar la lista completa de servicios:

zmcontrol status

Un resultado satisfactorio es que el proxy informe que se está ejecutando y permanezca en ejecución después de que el comando finalice. La documentación del proxy de Zimbra describe zmproxyctl restartla operación de servicio como aquella que también invoca la generación de configuración. Evite usar una configuración global del sistema systemctl restart nginxcomo sustituto: Zimbra gestiona su propia configuración y servicio de proxy. Si el reinicio falla, vuelva al error más reciente en nginx.log; los reinicios repetidos sin leer el error generalmente no corrigen la causa.

4. Asociar el error a una reparación específica.

Si falta el archivo de configuración o falla la generación

La nota de solución de problemas de Zimbra para un error /opt/zimbra/conf/nginx.confde configuración de proxy describe casos en los que la generación de la configuración de proxy falla porque un atributo ascendente contiene un servidor inexistente o un servidor que no es un servidor de buzones. Primero, inspeccione los valores globales y a nivel de servidor relevantes:

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 nombre de host con el inventario de servidores en vivo y su diseño de enrutamiento previsto. Corrija las entradas obsoletas o no válidas solo después de confirmar qué servidor debe recibir ese tráfico. No copie un nombre de host de ejemplo de la página de un proveedor en producción. La nota oficial de solución de problemas "Nginx no se inicia" muestra un comando de generador de configuración para el patrón específico de configuración faltante/error del generador:

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

Utilice esta opción únicamente cuando el fallo observado coincida con ese patrón y tras revisar los valores pertinentes. Si el generador sigue generando una excepción o el archivo no se encuentra, deténgase e investigue el seguimiento completo de la pila y los atributos del servidor en lugar de ejecutarlo repetidamente.

Si el registro informa de un puerto no válido o un fallo de enlace

Primero, identifique qué agente de escucha configurado está fallando. Verifique los valores del servicio Zimbra y del puerto proxy para este nodo y, a continuación, compruebe si otro proceso ya está escuchando en la dirección afectada. Por ejemplo, si el mensaje menciona el puerto 443, verifique si el agente de escucha HTTPS público pertenece a Zimbra NGINX o a un servidor web o agente de balanceo de carga independiente. No finalice un proceso desconocido ni asigne un nuevo puerto hasta que comprenda cómo acceden los clientes al servicio.

Un error como este invalid port ...:0no justifica adivinar el número de puerto. Puede indicar una configuración de proxy inconsistente o una configuración generada incorrectamente. Compare el valor con la topología esperada, revise los cambios recientes y corrija la configuración de origen mediante las herramientas compatibles con Zimbra. Luego, reinicie zmproxyctly confirme que el listener generado sea válido.

Si el inicio falla al cargar un certificado o una clave privada.

Lea el error SSL completo e identifique la ruta del certificado que se menciona. Confirme que el certificado y la clave privada pertenecen al mismo conjunto, que la cuenta de servicio esperada puede leerlos y que no han caducado. La documentación de solución de problemas de proxy de Zimbra incluye un caso en el que el proxy no puede cargar el material de clave. Siga el procedimiento de implementación de certificados para su versión de Zimbra en lugar de reemplazar archivos de forma arbitraria. Un reinicio exitoso debería eliminar el error de inicio SSL y el navegador debería mostrar el certificado esperado para el nombre de host del correo web público.

Si NGINX se inicia pero los usuarios ven errores de puerta de enlace

El funcionamiento de un proxy no garantiza que los servidores backend de buzones estén en buen estado. Para el error "No hay ruta al host", Zimbra recomienda verificar la resolución DNS desde el nodo proxy y la accesibilidad a nivel de puerto al servidor backend previsto. Para las respuestas 502 o 503, verifique el servicio de buzón y el host y puerto de origen; la guía del proxy indica que un proceso de buzón no disponible puede provocar errores 503. Utilice el servidor backend y el puerto exactos para su versión y topología, y revise los registros del servidor de buzones antes de modificar los tiempos de espera del proxy o los umbrales de fallo.

5. Verifique la recuperación tanto desde el servidor como desde un navegador.

Tras una reparación específica, confirme lo siguiente:

• zmproxyctl statusinforma que el proxy está en funcionamiento.
• zmcontrol statusMuestra los servicios previstos para este nodo.
• Las últimas líneas /opt/zimbra/log/nginx.logno repiten el mismo fallo de inicio.
• El oyente esperado está presente y pertenece al servicio previsto. En Linux, un administrador puede inspeccionar los oyentes con ss -ltnp; los detalles de permisos y salida varían según la distribución.
• Un navegador puede acceder al nombre de host habitual del correo web de Zimbra mediante HTTPS, iniciar sesión y cargar un buzón de correo. Si los clientes IMAP o POP también utilizan este proxy, pruebe esos protocolos por separado.

Estas comprobaciones definen una recuperación útil: el servicio está activo, su oyente existe, la ruta del navegador funciona y el fallo no se ha repetido inmediatamente. Si el estado del servicio es verde pero el correo web sigue fallando, revise el DNS, TLS, las reglas del firewall, el enrutamiento del balanceador de carga o el estado del servidor de correo. Si vuelve a fallar, conserve las nuevas líneas de registro y la salida del generador de configuración; son más útiles que otro reinicio a ciegas.

Utilice el registro de depuración solo para una investigación breve y controlada.

Si los registros normales no explican un fallo persistente, Zimbra documenta un aumento temporal en el nivel de registro del proxy NGINX. El registro de depuración puede exponer información confidencial, incluidos los tokens de autenticación, por lo que se recomienda evitar su activación en un sistema de producción a menos que sea necesario. Si el soporte técnico le indica que lo utilice, restrinja el acceso a los registros, recopile solo la información necesaria, luego restablezca la configuración a su valor anterior y gestione los registros de depuración de acuerdo con su política de seguridad. Consulte las instrucciones de Zimbra para el registro de depuración de NGINX para obtener el comando adecuado para su versión.

Si la generación de la configuración sigue fallando, no se puede validar el certificado proxy, el error indica la presencia de un oyente desconocido o no está clara la función del nodo, póngase en contacto con su administrador de Zimbra o con el soporte técnico del proveedor. El controlador de servicio puede reiniciar una configuración correcta; sin embargo, no puede determinar por sí solo el enrutamiento de correo adecuado, reparar un certificado no válido ni resolver una ruta de red interrumpida.

Referencias oficiales

• Guía de Zimbra Proxy: registros y solución de problemas del backend
• Manual de Zimbra Proxy: comandos CLI de proxy
• Centro de soporte técnico de Zimbra: NGINX no se inicia.
• Centro de soporte técnico de Zimbra: pasos para un servicio proxy que no se inicia
• Manual de Zimbra Proxy: configuración y plantillas generadas

Fuentes consultadas el 6 de octubre de 2026. Las páginas del Centro Técnico de Zimbra a las que se hace referencia aquí incluyen ejemplos antiguos y algunas están etiquetadas como trabajos en progreso; confirme los comandos con la versión de Zimbra instalada en su servidor antes de modificar la configuración de producción.