Tudástár / Weboldal hibák
Weboldal hibák és tipikus problémák
Ha hibát jelez az oldala, fehér képernyő fogadja a látogatókat, vagy eltűntek a levelek — itt megtalálja a leggyakoribb okok pontos magyarázatát és azt, mit lehet tenni.
Tudástár / Weboldal hibák
Ha hibát jelez az oldala, fehér képernyő fogadja a látogatókat, vagy eltűntek a levelek — itt megtalálja a leggyakoribb okok pontos magyarázatát és azt, mit lehet tenni.
Ha a weboldal nem tölt be, az ok általában az alábbiak valamelyike: a tárhelyszerver leállt vagy nem válaszol, a DNS beállítás hibás vagy még propagálódik, a domain lejárt és nem lett megújítva, vagy egy friss frissítés inkompatibilis kóddal tette tönkre a rendszert.
Első lépésként érdemes ellenőrizni, hogy mások számára is elérhetetlen-e az oldal (pl. downforeveryoneorjustme.com segítségével), mert ha csak önnél nem tölt be, az lehet helyi cache- vagy DNS-probléma is. Ha mindenki számára elérhetetlen, a szerveren vagy a domainbeállításokban kell keresni az okot.
Rendszeres monitoring segítségével az ilyen leállások jellemzően perceken belül észlelhetők és elháríthatók, mielőtt érdemi forgalomkiesést okoznának.
Az 500-as hiba azt jelenti, hogy a szerver egy belső hibába ütközött, és nem tudta teljesíteni a kérést — de a pontos okot nem közli a látogatóval. Ez szándékos: biztonsági okokból a hibaüzenet nem tartalmaz érzékeny rendszerinformációkat.
A leggyakoribb okok: egy frissítés inkompatibilis kódot hozott,
egy bővítmény PHP-hibát dob, a szerveren elfogyott a memória,
vagy a .htaccess fájlba
hibás direktíva került.
Laravel alapú alkalmazásoknál előfordulhat még hibás
.env konfiguráció
vagy hiányzó storage
írási jogosultság is.
A pontos okot a szerver logjai tartalmazzák — ezek elemzésével a hiba általában gyorsan azonosítható és javítható. Ha nincs hozzáférése a logokhoz, a tárhelyszolgáltatótól kérheti.
A fehér (üres) képernyő klasszikusan PHP-hibát jelez — a szerver megpróbálta feldolgozni az oldalt, de valahol PHP szintaxis- vagy futásidejű hibába ütközött, és hibajelzés nélkül adta fel. WordPress-en ez a jelenség korábban „White Screen of Death" (WSOD) névvel volt ismert.
Leggyakoribb okok: rosszul kódolt vagy inkompatibilis bővítmény telepítése után, PHP verzióváltást követően, vagy ha a memória limit túllépése miatt a PHP kivétel nélkül leáll. Modern keretrendszereknél (Laravel) a debug mód bekapcsolt állapota részletes hibaüzenetet ad — de éles környezetben ezt ki kell kapcsolni.
Gyors visszaállításhoz mindig érdemes frissítés vagy változtatás előtt biztonsági mentést készíteni — így perceken belül visszaállítható az utolsó működő állapot.
Ha az oldal teljesen „eltűnt", azaz sem hibát nem dob, sem nem tölt be, az okok általában az alábbiak: a domain lejárt és a regisztrátor leállította a névfeloldást, a tárhelyszolgáltató felfüggesztette a fiókot (fizetési elmaradás vagy szabálysértés miatt), a fájlok törlődtek — esetleg szerverhiba vagy biztonsági incidens következtében.
Ilyenkor az első lépés a domain státuszának és a tárhely fiók állapotának ellenőrzése. Ha biztonsági incidens gyanúja merül fel, a szerver logjai árulkodnak arról, ki és mikor fért hozzá a rendszerhez.
Ebben a helyzetben a rendszeres biztonsági mentés az egyetlen megbízható visszaút — mentés nélkül az adat visszaállítása nem garantált, esetenként lehetetlen.
Az email kézbesítési problémák mögött jellemzően DNS rekord hibák állnak. Ha az MX rekord nincs beállítva vagy rossz szerverre mutat, a levelek egyszerűen nem jutnak el a postafiókhoz. Ha az SPF rekord hiányzik vagy túl megengedő, a fogadó szerver spamként kezeli a levelet. Ha a DKIM aláírás nem stimmel, a levél hitelességét nem lehet igazolni — és szintén spam mappába kerül.
A különösen veszélyes ebben az, hogy a feladó oldalán minden rendben tűnik: a levél „elment", nem kapott hibaüzenetet — miközben az ügyfél soha nem kapta meg. Ez üzleti szempontból komoly kockázat, különösen árajánlatok, szerződések vagy visszaigazolások esetén.
Részletes útmutató: Email és DNS beállítások
A hirtelen megnövekedett spam általában azt jelzi, hogy az email-cím felkerült egy spam-listára, vagy a weboldal valamelyik nyitott kapcsolati vagy regisztrációs űrlapján bot-forgalom indult. Ha az email-cím nyilvánosan olvasható formában szerepel a weboldalon, azt a crawlerek automatikusan begyűjtik.
Megoldások: CAPTCHA (pl. reCAPTCHA vagy hCaptcha) beépítése az űrlapokra, az email-cím JavaScript-alapú rejtése vagy egy kapcsolati form mögé bújtatása, szerver szintű spam szűrés beállítása. Ha a helyzet már súlyos, érdemes az email-cím lecserélésével kezdeni és a régit csak irányítóként megtartani.
Frissítés utáni hibákat leggyakrabban verzióütközés okoz: az egyik bővítmény vagy modul nem kompatibilis az újonnan telepített verziókkal. PHP verzióváltásnál szintén előfordulhat, hogy a régi kód nem futtatható az új motoron — különösen elavult szintaxis esetén.
Ha volt mentés a frissítés előtt, a visszaállítás gyorsan elvégezhető, és utána kontrollált körülmények között lehet újra elvégezni a frissítést. Ha nem volt mentés, a szerverlognaplók segíthetnek azonosítani a konkrét hibát, majd célzottan javítani.
A legjobb megelőzés: staging (teszt) környezet, ahol a frissítések élesítés előtt tesztelhetők. Ez elkerülhetővé teszi, hogy az ügyfelek lássák a hibát.
Hirtelen lassulás esetén az okok általában: a szerveren megnövekedett terhelés (pl. más oldal bot-forgalmat kap és „megvisz" mindenkit a shared hostingon), egy új bővítmény vagy szkript drága adatbázis-lekérdezéseket indít, vagy DDoS-szerű forgalom érkezik az oldalra.
Érdemes megnézni a szerver erőforrás-kihasználtságát (CPU, memória), ellenőrizni az adatbázis lassú lekérdezéseit, és megvizsgálni, hogy pontosan mikor kezdődött a lassulás — ez általában megmutatja a kiváltó okot.
Részletes útmutató: Mitől lassú a weboldal?
Gyors hibaelhárítás, karbantartás és folyamatos felügyelet.
Ajánlatkérés