L'une des combinaisons de serveurs Web les plus courantes aujourd'hui comprend l'implémentation du logiciel de serveur Web Nginx fonctionnant sur l'édition Ubuntu Server. Ce système est extrêmement efficace et facile à mettre à jour, car les deux packages continuent de recevoir des mises à jour régulières. Les administrateurs système installent généralement les mises à jour via le gestionnaire de packages apt, car Ubuntu Server n'a pas d'interface graphique par défaut.
Les mises à niveau d'Ubuntu Server peuvent parfois générer des erreurs inhabituelles, et ce manque d'interface utilisateur graphique peut rendre difficile pour les débutants de les résoudre. Quelques commandes simples pourraient suffire pour corriger les erreurs 404 Nginx après une mise à niveau d'Ubuntu.
Méthode 1: Correction des pages d'erreur Nginx manquantes
Si un site est hébergé sur AWS, un serveur privé ou toute autre configuration de serveur dans une pile LEMP, il peut tomber de manière aléatoire après une mise à niveau du serveur Ubuntu. Essayez d'accéder au site à partir d'un navigateur Web, peut-être sur une autre machine. En supposant qu'il renvoie une erreur 404, dirigez-vous vers l'interface de ligne de commande du serveur Ubuntu et exécutez la commande tail -f 
pour afficher toutes les erreurs les plus récentes.
Si le journal contient une erreur telle que:
Votre système souffre d'une page d'erreur manquante. Vous pouvez également voir 40x.html dans cette ligne, bien que ce soit relativement rare si votre site est en panne et que vous obtenez 404 erreurs en échange. Utilisez la commande ls 
pour voir s'il y a quelque chose là-bas. Sinon, vous devrez créer le code HTML d'une page pour les erreurs 50X.
Gardez à l'esprit que l'utilisation de la valeur par défaut 
La structure des répertoires est souvent un problème avec les gestionnaires de paquets, qui peuvent écraser tout ce qui y est stocké. Vous pouvez modifier la ligne docroot dans la configuration Nginx pour éviter ce genre de problème si vous êtes autorisé à créer une structure de répertoire personnalisée.
Méthode 2: Faire en sorte que PHP trouve le bon socket
Vous pouvez également trouver une erreur qui lit quelque chose comme ceci dans le 
Cela signifie que PHP7.0 est en cours d’exécution, mais qu’il n’exécute pas là où il devrait être. Le numéro de version peut être différent selon la configuration de PHP. Les installations par défaut seront exécutées à partir de 
ou 
, mais si vous rencontrez cette erreur, ce n'est probablement pas le cas.
Exécutez les commandes 
puis recherchez -name ‘php * fpm.sock’ pour voir s’il y a un socket en cours d’exécution quelque part sur votre système.
En supposant que vous ayez reçu une sortie positive, vous devez mettre à jour votre configuration Nginx pour afficher le bon endroit dans 
le socket doit fonctionner. Naturellement, / directoryPath serait remplacé par le chemin correct. La ligne php / php7.0-fpm.sock devrait mettre à jour la configuration si vous utilisez un fichier socket.
Les utilisateurs des anciennes sockets TCP qui n'utilisent pas de fichiers de socket peuvent vérifier si un socket PHP écoute actuellement le port 9000 en exécutant sudo netstat -tulpn | grep 9000 hors de la ligne de commande. Si tel est le cas, ouvrez votre fastcgi_pass dans nano, vi ou un autre éditeur de texte et changez la ligne unix:… pour utiliser à la place 127.0.0.1:9000 pour mettre à jour le socket.
Si rien de tout cela ne fonctionne, assurez-vous que php7.0-fpm ou quel que soit le numéro de version que vous utilisez est en cours d'exécution avec la commande sudo systemctl restart php7.0-fpm, puis répétez le processus ci-dessus.
Gardez à l'esprit que dans la plupart des cas, l'entrée d'écoute 
et la valeur de 
doivent être les mêmes. Vous pourriez essayer 
pour les configurations plus récentes, ou 127.0.0.1:9000 pour les anciennes.
