Az egyik legelterjedtebb webkiszolgáló-kombináció manapság az Nginx webkiszolgáló szoftver megvalósítását tartalmazza az Ubuntu Server kiadásban. Ez a rendszer rendkívül hatékony és könnyen naprakész, mivel mindkét csomag továbbra is rendszeres frissítéseket kap. A rendszergazdák általában az apt csomagkezelőn keresztül telepítik a frissítéseket, mert az Ubuntu Server alapértelmezés szerint nem rendelkezik grafikus felülettel.
Az Ubuntu Server frissítései néha szokatlan hibákat generálhatnak, és ez a grafikus felhasználói felület hiánya megnehezítheti a kezdők számára a hibaelhárítást. Néhány egyszerű parancs elegendő lehet a 404 Nginx hibák kijavításához az Ubuntu frissítése után.
1. módszer: A hiányzó Nginx hibaoldalak javítása
Ha egy webhely AWS-en, magánkiszolgálón vagy bármely más kiszolgálókonfiguráción van egy LEMP-veremben, akkor véletlenszerűen csökkenhet az Ubuntu Server frissítése után. Megpróbálja elérni a webhelyet egy böngészőből, esetleg egy másik gépen. Ha feltételezzük, hogy 404-es hibát ad vissza, menjen az Ubuntu Server CLI-re, és futtassa a tail -f parancsot 
az összes legfrissebb hiba megtekintéséhez.
Ha a napló olyan hibát tartalmaz, mint:
Rendszerében hiányzó hibaoldal van. Lehet, hogy ebben a sorban 40x.html-t is lát, bár ez viszonylag ritka, ha webhelye nem működik, és cserébe 404 hibát kap. Használja az ls parancsot 
hogy van-e ott valami. Ha nem, akkor létre kell hoznia az oldal HTML-kódját 50X-es hibák esetén.
Ne feledje, hogy az alapértelmezettet használja 
A könyvtárstruktúra gyakran jelent problémát a csomagkezelőkkel, amelyek felülírják az ott tároltakat. Megváltoztathatja a docroot sort az Nginx konfigurációjában az ilyen jellegű problémák megelőzése érdekében, ha engedélyezheti egyéni könyvtárstruktúra létrehozását.
2. módszer: A PHP megtalálása a megfelelő aljzaton
Találhat olyan hibát is, amely ilyesmit olvas a 
Ez azt jelenti, hogy fut a PHP7.0, de nem ott fut, ahol lennie kellene. A verziószám a PHP beállításától függően eltérő lehet. Az alapértelmezett telepítés kezdete: 
vagy 
, de ha van ilyen hibája, akkor valószínűleg nem ez a helyzet.
Futtassa a parancsokat 
majd keresse meg a -name ’php * fpm.sock’ elemet, hogy ellenőrizze, fut-e valahol egy aljzat a rendszerén.
Feltételezve, hogy pozitív kimenetet kapott, akkor frissítenie kell az Nginx konfigurációját, hogy a megfelelő helyet mutassa 
a foglalatnak működnie kell. Természetesen a / directoryPath helyére a helyes útvonal kerül. A php / php7.0-fpm.sock sornak frissítenie kell a konfigurációt, ha socket fájlt használ.
A régebbi, socket fájlokat nem használó TCP foglalatok felhasználói a sudo netstat -tulpn | futtatásával ellenőrizhetik, hogy egy PHP aljzat éppen a 9000-es portot hallgatja-e. grep 9000 a parancssorból. Ebben az esetben nyissa meg a fastcgi_pass fájlt a nano, vi vagy más szövegszerkesztőben, és cserélje ki az unix:… sort, és ehelyett a 127.0.0.1:9000 parancsot használja a socket frissítésére.
Ha egyik sem működik, akkor ellenőrizze, hogy a php7.0-fpm vagy bármelyik használt verziószám fut-e a sudo systemctl restart paranccsal, majd ismételje meg a fenti folyamatot.
Ne feledje, hogy a legtöbb esetben a meghallgatási bejegyzés 
és az érték 
azonosnak kell lennie. Lehet, hogy megpróbálja 
újabb konfigurációkhoz, vagy 127.0.0.1:9000 a régi stílusúakhoz.
