Comment résoudre l'erreur « Service proxy Nginx arrêté » de Zimbra ?

Lorsque Zimbra signale « Service proxy Nginx arrêté », cela signifie que le processus proxy est hors service ou que sa vérification d'état ne permet pas de confirmer son fonctionnement. Un redémarrage peut rétablir l'accès si l'arrêt était temporaire, mais ce même message peut s'afficher si Nginx ne parvient pas à charger sa configuration, à lier un port requis, à lire un certificat ou à contacter un serveur en amont valide. L'important n'est pas seulement que le proxy reste opérationnel, que la messagerie web Zimbra soit accessible via l'URL publique prévue et que les journaux du proxy ne signalent plus l'échec de démarrage.

Ce guide s'applique aux déploiements Zimbra utilisant le service Zimbra Proxy intégré. Les commandes exactes et les détails de configuration peuvent varier selon la version de Zimbra et la topologie. Sur une installation multi-serveurs, effectuez des vérifications sur le nœud proxy et ne réactivez pas le proxy sur un nœud de messagerie ou MTA simplement parce qu'un autre serveur signale son arrêt. Le guide du proxy Zimbra et la documentation de référence de l'interface de ligne de commande du proxy décrivent le service et ses fichiers de diagnostic. Certaines pages de dépannage du Centre technique sont en cours d'élaboration ; consultez-les en complément de la documentation relative à votre version installée.

1. Vérifiez que le proxy est bien censé fonctionner sur ce serveur.

Connectez-vous au serveur Zimbra qui héberge le proxy et accédez à votre compte Zimbra. Vérifiez la liste générale des services ainsi que l'état spécifique du proxy :

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

Recherchez proxyles services activés et un processus NGINX en cours d'exécution dans la sortie d'état. Zimbra documente ces actions zmproxyctlpar des indicateurs tels que « démarrage », start« exécution » et « exécution ». Si cet hôte est un nœud dédié à la messagerie ou à l'authentification multipoint (MTA), un proxy arrêté est probable. Vérifiez le rôle du serveur dans votre déploiement avant de tenter de le démarrer.stoprestartreloadstatus

Si le proxy devrait être actif et que son état est « arrêté », enregistrez l'état actuel avant toute modification. Cela permet de distinguer un redémarrage ayant échoué d'un service qui n'a jamais été activé sur le nœud.

2. Consultez le journal des erreurs NGINX avant de redémarrer.

Le guide de dépannage des proxys de Zimbra identifie /opt/zimbra/log/nginx.logles /opt/zimbra/log/nginx.access.logjournaux de proxys clés. Vérifiez les entrées d'erreur récentes et l'existence du fichier de configuration 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

Le message d'erreur indique généralement la prochaine vérification. Une valeur manquante nginx.confsuggère que la configuration générée nécessite une analyse. Un « port invalide » dans une listendirective signale un problème de port ou de configuration de liaison. Une erreur de clé privée ou de certificat signale un problème lié au protocole SSL. Un échec de liaison indique qu'un autre processus utilise peut-être déjà l'adresse et le port.

Ne supprimez pas les fichiers de configuration NGINX et ne modifiez pas les fichiers générés pour tenter de faire disparaître l'erreur. Zimbra construit sa configuration NGINX à partir de modèles et de valeurs stockés dans son répertoire de configuration et son annuaire LDAP. Le guide de configuration et de modèles du fournisseur explique ce modèle de génération. Les modifications manuelles apportées aux fichiers générés peuvent être écrasées lors d'un redémarrage ou d'une mise à jour de la configuration.

3. Essayez de redémarrer le proxy pris en charge et vérifiez le résultat.

Si les journaux n'indiquent pas d'erreur de configuration ou de certificat persistante, redémarrez le service via le contrôleur Zimbra en tant qu'utilisateur Zimbra :

zmproxyctl restart
zmproxyctl status

Vérifiez ensuite à nouveau la liste complète des services :

zmcontrol status

En cas de succès, le proxy est signalé comme étant en cours d'exécution et le reste après la fin de la commande. La documentation du proxy Zimbra décrit zmproxyctl restartcette opération comme une opération de service qui déclenche également la génération de la configuration. Évitez d'utiliser une solution systèmesystemctl restart nginx : Zimbra gère sa propre configuration et son propre service de proxy. Si le redémarrage échoue, consultez la dernière erreur enregistréenginx.log ; des redémarrages répétés sans lecture de l'erreur ne permettent généralement pas de résoudre le problème.

4. Associer l'erreur à une réparation ciblée

Si le fichier de configuration est manquant ou si la génération échoue

La note de dépannage de Zimbra concernant l'absence d'un attribut /opt/zimbra/conf/nginx.confdécrit les cas où la génération de la configuration du proxy échoue car un attribut en amont contient un serveur inexistant ou un serveur qui n'est pas un serveur de messagerie. Commencez par examiner les valeurs pertinentes au niveau du serveur et au niveau global.

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

Comparez chaque nom d'hôte avec l'inventaire des serveurs en production et votre architecture de routage. Ne corrigez les entrées obsolètes ou invalides qu'après avoir confirmé quel serveur doit recevoir ce trafic. Ne copiez pas un nom d'hôte d'exemple provenant d'une page fournisseur en production. La note de dépannage officielle « Nginx ne démarre pas » présente une commande de génération de configuration pour le modèle spécifique d'erreur de configuration manquante/générateur :

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

N'utilisez cette méthode que si l'erreur observée correspond à ce schéma et après avoir examiné les valeurs pertinentes. Si le générateur génère toujours une exception ou si le fichier reste manquant, arrêtez-vous et analysez la trace de pile complète et les attributs du serveur plutôt que de le relancer sans cesse.

Si le journal signale un port invalide ou un échec de liaison

Commencez par identifier le processus d'écoute défaillant. Vérifiez les valeurs des ports de service et de proxy Zimbra pour ce nœud, puis assurez-vous qu'aucun autre processus n'écoute déjà sur l'adresse concernée. Par exemple, si le message mentionne le port 443, vérifiez si le processus d'écoute HTTPS public est géré par Zimbra NGINX, un autre serveur web ou un agent d'équilibrage de charge. Ne terminez pas un processus inconnu et n'attribuez pas de nouveau port tant que vous n'avez pas compris comment les clients accèdent au service.

Une erreur de ce type invalid port ...:0ne justifie pas de deviner un numéro de port. Elle peut indiquer une configuration de proxy incohérente ou une configuration générée incorrecte. Comparez la valeur avec la topologie attendue, vérifiez les modifications récentes et corrigez la configuration source à l'aide des outils fournis par Zimbra. Redémarrez ensuite le service zmproxyctlet assurez-vous que l'écouteur généré est valide.

Si le démarrage échoue lors du chargement d'un certificat ou d'une clé privée

Lisez attentivement l'erreur SSL complète et identifiez le chemin d'accès au certificat. Vérifiez que le certificat et la clé privée sont bien liés, accessibles au compte de service concerné et valides. La documentation de dépannage du proxy Zimbra inclut une procédure pour le cas où le proxy ne parvient pas à charger les éléments de clé. Suivez la procédure de déploiement des certificats pour votre version de Zimbra plutôt que de remplacer les fichiers au hasard. Un redémarrage devrait résoudre l'erreur de démarrage SSL et votre navigateur devrait afficher le certificat attendu pour le nom d'hôte public de la messagerie web.

Si NGINX démarre mais que les utilisateurs rencontrent des erreurs de passerelle

Un proxy actif ne garantit pas le bon fonctionnement des serveurs de messagerie. En cas d'erreur « Aucun chemin d'accès à l'hôte », Zimbra recommande de vérifier la résolution DNS depuis le nœud proxy et l'accessibilité du port vers le serveur de messagerie. Pour les réponses 502 ou 503, vérifiez le service de messagerie ainsi que l'hôte et le port en amont ; le guide du proxy indique qu'un processus de messagerie indisponible peut provoquer des erreurs 503. Utilisez le serveur de messagerie et le port exacts pour votre version et votre topologie, et consultez les journaux du serveur de messagerie avant de modifier les délais d'expiration ou les seuils d'échec du proxy.

5. Vérifiez la récupération à la fois depuis le serveur et depuis un navigateur.

Après une réparation ciblée, veuillez confirmer les points suivants :

• zmproxyctl statussignale que le proxy est en cours d'exécution.
• zmcontrol statusaffiche les services attendus pour ce nœud.
• Les dernières lignes de code /opt/zimbra/log/nginx.logne reproduisent pas le même échec de démarrage.
• Le processus d'écoute attendu est présent et appartient au service concerné. Sous Linux, un administrateur peut inspecter les processus d'écoutess -ltnp ; les permissions et les détails de la sortie varient selon la distribution.
• Un navigateur peut accéder au nom d'hôte habituel de la messagerie web Zimbra via HTTPS, s'y connecter et charger une boîte aux lettres. Si des clients IMAP ou POP utilisent également ce proxy, testez ces protocoles séparément.

Ces vérifications définissent une reprise efficace : le service est opérationnel, son écouteur est actif, le chemin d'accès du navigateur est fonctionnel et l'erreur ne s'est pas reproduite immédiatement. Si le service est opérationnel mais que la messagerie web reste inaccessible, vérifiez le DNS, le TLS, les règles du pare-feu, le routage de l'équilibreur de charge ou l'état du serveur de messagerie. En cas de nouvelle panne, conservez les nouvelles lignes de journal et la sortie du générateur de configuration ; ces informations seront plus utiles qu'un redémarrage à l'aveugle.

N'utilisez la journalisation de débogage que pour une enquête courte et contrôlée.

Si les journaux normaux n'expliquent pas une panne persistante, Zimbra documente une augmentation temporaire du niveau de journalisation du proxy NGINX. La journalisation de débogage peut exposer des informations sensibles, notamment les jetons d'authentification ; il est donc déconseillé de l'activer sur un système de production, sauf en cas de nécessité. Si le support vous recommande de l'utiliser, limitez l'accès aux journaux, ne collectez que les informations nécessaires, puis rétablissez la valeur précédente du paramètre et gérez les journaux de débogage conformément à votre politique de sécurité. Consultez les instructions de journalisation de débogage NGINX de Zimbra pour connaître la commande appropriée à votre version.

Si la génération de la configuration échoue systématiquement, si le certificat du proxy ne peut être validé, si l'erreur concerne un écouteur inconnu ou si le rôle du nœud est incertain, veuillez contacter votre administrateur Zimbra ou le support technique du fournisseur. Le contrôleur de service peut redémarrer une configuration fonctionnelle ; en revanche, il ne peut pas déterminer le routage du courrier électronique, réparer un certificat invalide ni résoudre automatiquement une panne réseau.

Références officielles

• Guide du proxy Zimbra : journaux et dépannage du serveur
• Manuel du proxy Zimbra : commandes CLI du proxy
• Centre technique Zimbra : NGINX ne démarre pas
• Centre d'assistance technique Zimbra : étapes pour un service proxy qui ne démarre pas
• Manuel du proxy Zimbra : configuration et modèles générés

Sources consultées le 6 octobre 2026. Les pages du Zimbra Tech Center mentionnées ici contiennent des exemples plus anciens et certaines sont étiquetées comme étant en cours de développement ; vérifiez les commandes par rapport à la version de Zimbra installée sur votre serveur avant de modifier la configuration de production.