Quand nginx ne démarre pas, la raison est écrite dans systemctl status nginx et journalctl -u nginx. Testez ensuite la configuration avec nginx -t. Les causes habituelles sont une erreur de syntaxe, un port déjà occupé (ss -tlnp), un certificat ou un fichier introuvable, des permissions incorrectes. Pour Apache, la commande équivalente est apachectl configtest.
nginx est strict : une seule directive invalide, un fichier de certificat qui a disparu ou un second service qui occupe le port 80 suffisent à empêcher le démarrage de tout le serveur web, donc de tous les sites hébergés dessus. L’incident survient presque toujours juste après une modification de configuration, un renouvellement de certificat, une mise à jour de paquet ou un redémarrage du serveur.
Les étapes suivent l’ordre le plus économique : lire le message d’erreur, tester la configuration, puis corriger la cause identifiée. Les commandes sont celles de Debian et Ubuntu, avec les équivalents Apache signalés dans chaque étape.
Lire l’état du service
Lancez systemctl status nginx --no-pager -l. Les dernières lignes citent généralement la cause : bind() to 0.0.0.0:80 failed, cannot load certificate, unexpected "}" avec un numéro de ligne. Si le message est tronqué, ouvrez le journal complet avec journalctl -xeu nginx --no-pager | tail -50. Notez le fichier et la ligne mentionnés : ils vous évitent de chercher à l’aveugle. Sur Apache, remplacez nginx par apache2 (Debian, Ubuntu) ou httpd (autres distributions).
Tester la configuration
nginx -t vérifie la syntaxe sans rien modifier et indique le fichier et la ligne fautifs. Il lit aussi les certificats et les fichiers inclus, donc il détecte un ssl_certificate manquant. Pour Apache, apachectl configtest joue le même rôle et répond Syntax OK quand tout va bien. Corrigez l’erreur signalée puis relancez le test jusqu’à obtenir le message de réussite, avant de démarrer le service.
Chercher un port déjà utilisé
Le message Address already in use signifie qu’un autre processus écoute sur le port. Identifiez-le avec ss -tlnp | grep -E ':(80|443)\b' : la dernière colonne donne le nom et le PID du programme. Il peut s’agir d’un Apache oublié après une installation, d’un conteneur Docker qui publie le port 80, ou d’une ancienne instance de nginx restée active. Arrêtez ou reconfigurez le service qui n’a pas à occuper ce port, puis relancez nginx. Un fichier listen en doublon dans deux sites de sites-enabled produit une erreur voisine.
Remettre un certificat manquant ou illisible
Une erreur comme cannot load certificate "/etc/letsencrypt/live/domaine/fullchain.pem" indique que le fichier a disparu, qu’un renouvellement a échoué ou que le chemin a changé. Listez les certificats avec ls -l /etc/letsencrypt/live/ et certbot certificates. Si le dossier d’un domaine supprimé figure encore dans un bloc server, retirez ce bloc ou corrigez le chemin. Pour obtenir un nouveau certificat, voyez le guide sur un certificat SSL expiré ; en attente, vous pouvez commenter temporairement le bloc HTTPS fautif afin de remettre les autres sites en ligne.
Contrôler les permissions et les propriétaires
Un journal d’erreurs qui mentionne Permission denied ou open() "/var/log/nginx/error.log" failed renvoie à des droits ou à un disque. Vérifiez que l’utilisateur du service lit bien la configuration et les certificats avec namei -l /chemin/du/fichier, qui montre les droits de chaque dossier du chemin. Corrigez avec chown et chmod ciblés, par exemple chmod 640 sur une clé privée, jamais chmod 777. Pensez aussi à df -h : un disque plein empêche nginx d’écrire ses journaux, voyez le guide sur le disque plein.
Revenir à la dernière configuration valide
Si vous ne trouvez pas la modification fautive, comparez avec une copie : cp -a /etc/nginx /root/nginx-actuel pour garder l’état courant, puis restaurez la dernière sauvegarde ou le fichier précédent. Si la configuration est versionnée avec git, git diff dans /etc/nginx montre exactement ce qui a changé. Sinon, désactivez le dernier site ajouté en supprimant son lien dans /etc/nginx/sites-enabled/ (le fichier d’origine reste dans sites-available), testez avec nginx -t, puis relancez.
Démarrer, recharger et vérifier
Quand nginx -t annonce que la syntaxe est correcte, lancez systemctl start nginx puis systemctl status nginx. Pour appliquer un changement sans coupure, préférez systemctl reload nginx. Vérifiez depuis l’extérieur avec curl -I https://votre-domaine.fr, puis lisez tail -n 50 /var/log/nginx/error.log pour repérer d’éventuels avertissements. Activez le démarrage automatique avec systemctl enable nginx. Si le site répond ensuite par une erreur, c’est un autre sujet : voyez l’erreur 502.
Questions fréquentes
Comment savoir pourquoi nginx ne démarre pas ?
Lancez systemctl status nginx puis journalctl -u nginx. Le message d’erreur indique presque toujours la cause et le fichier concerné. Complétez avec nginx -t, qui teste la configuration sans démarrer le service et donne le numéro de ligne à corriger.
Que veut dire « bind() to 0.0.0.0:80 failed (98: Address already in use) » ?
Un autre processus écoute déjà sur le port 80, souvent Apache, un conteneur Docker ou une instance nginx restée active. Identifiez-le avec ss -tlnp | grep :80, arrêtez-le ou changez son port, puis redémarrez nginx.
nginx -t affiche « syntax is ok » mais le service ne démarre pas, pourquoi ?
Le test valide la syntaxe, mais le démarrage échoue encore si un port est occupé, si un répertoire n’est pas accessible ou si un module manque. Relisez journalctl -u nginx et contrôlez les ports avec ss -tlnp.
Comment corriger l’erreur de configuration d’Apache qui ne démarre pas ?
Lancez apachectl configtest pour obtenir le fichier et la ligne fautifs, consultez journalctl -u apache2 et vérifiez qu’aucun autre service n’occupe les ports 80 et 443. Corrigez, testez à nouveau, puis systemctl restart apache2.
Puis-je recharger nginx sans interrompre les sites ?
Oui, systemctl reload nginx applique la nouvelle configuration sans couper les connexions en cours, à condition que nginx -t soit valide. Si la configuration est invalide, nginx conserve l’ancienne et signale l’erreur, ce qui limite le risque.
Sources
- Beginner’s Guide — nginx.org
- Contrôle de nginx — nginx.org
- Programme apachectl — Apache HTTP Server
- Liaison d’adresses et de ports — Apache HTTP Server