Hogyan elemezd az error logokat cPanelen? PHP, Apache és weboldal debug naplók lépésről lépésre

Röviden: hol keresd a hibákat?


Röviden: hol keresd a hibákat?

Ha a weboldalad hibát dob (HTTP 500, fehér képernyő, váratlan hiba), az első lépés mindig az error logok átnézése. Nálunk három fő logforrásod van:

  1. Apache / Nginx hibanapló (error log)
    Teljes loghoz csak rendszergazdáink férnek hozzá.
    Menedzselt tárhely esetén te is látsz belőle kivonatot a cPanelen:
    • Hibák / Errors menü – itt a rendszer kiszűri a saját tárhelyedhez tartozó hibanapló sorokat.
  2. PHP error log
    • Ha be van kapcsolva a PHP-FPM az adott domainre: /home/FELHASZNÁLÓNÉV/logs mappában találod a PHP hibalogokat.
    • Ha nincs PHP-FPM, akkor a log:
      • a php.ini fájlban megadott error_log útvonalon, vagy
      • azon az útvonalon, amit maga a CMS (WordPress, Joomla stb.) beállít magának.
  3. Weboldal / CMS debug log (pl. WordPress debug.log)
    • Ezeket külön kell bekapcsolni, és tipikusan a weboldalad könyvtárában jönnek létre, pl.:
      • WordPress: wp-content/debug.log
      • Joomla: a Joomla konfigurációban megadott log_path mappában.

Ha ezek alapján sem egyértelmű a hiba oka, másold ki a legfrissebb logrészletet és írj nekünk ticketet:
https://ugyfeladmin.tarhely.eu/submitticket.php


Mi az az error log, és miért fontos?

Az error log (hibanapló) a webkiszolgáló és a PHP által írt naplófájl, amelyben hibák, figyelmeztetések és sokszor a „láthatatlan” problémák is megjelennek.

Miért nélkülözhetetlen?

  • Megmutatja, mi történt pontosan, amikor a hiba jelentkezett.
  • Nem csak azt látod, hogy „HTTP 500 Internal Server Error”, hanem azt is, hogy például:
    • elfogyott a memória (Allowed memory size exhausted),
    • lejárt a futási idő (Maximum execution time exceeded),
    • hiányzik egy fájl (No such file or directory),
    • adatbázis hiba van (Access denied for user, Unknown database).
  • Segít eldönteni, hogy:
    • te magad is meg tudod oldani (pl. bővítmény kikapcsolás, memory_limit emelés), vagy
    • inkább ügyfélszolgálatunk segítségére van szükség.


Milyen logtípusokkal találkozol a tárhelyeden?

Apache / Nginx error log (webszerver log)

A háttérben az Apache / Nginx hibanaplóba kerülnek a webszerver hibái.

Nálunk:

  • a teljes Apache / Nginx error loghoz közvetlenül nem férsz hozzá (ez root szintű jogosultság),
  • menedzselt tárhely esetén a cPanelen, a Hibák (Errors) menüpontban láthatod azokat a hibasorokat, amelyek a saját tárhelyedhez tartoznak.

Ez a felület nagyon hasznos minden olyan esetben, amikor:

  • HTTP 500 vagy 503 hibát kapsz,
  • valamilyen Apache modul panaszkodik (pl. mod_rewrite),
  • .htaccess hibák vannak (pl. „RewriteRule: bad flag delimiters”).

PHP error log

A PHP error log kifejezetten a PHP futás közben keletkező hibáit rögzíti.

Nálunk ennek a helye attól függ, hogy a domainen PHP-FPM be van-e kapcsolva.

  • Ha PHP-FPM be van kapcsolva az adott domainre:
    • A státuszt a cPanelen a MultiPHP Manager menüpontban látod.
    • Ilyenkor a PHP hibák a tárhelyeden található /home/FELHASZNÁLÓNÉV/logs mappába kerülnek (több fájl is lehet, domainenként, dátum szerint).
  • Ha PHP-FPM nincs bekapcsolva:
    • a PHP hibaüzenetek elsősorban oda íródnak, amit a php.ini vagy a CMS konfigurációja error_log-nak beállít,
    • vagy ha a CMS más logolási megoldást használ, akkor annak a saját log mappájába.

Ha a logolás technikai beállításában bizonytalan vagy, érdemes fejlesztővel egyeztetned, vagy kérdezz rá nálunk ticketben – itt elsősorban a logok olvasására és értelmezésére koncentrálunk.

Weboldal / keretrendszer (CMS) saját debug logja

A legtöbb népszerű rendszernek (WordPress, Joomla, Laravel, stb.) van saját debug logja.

  • Ezeket jellemzően külön kell bekapcsolni,
  • és általában a weboldal könyvtárán belül jönnek létre.

Példák:

  • WordPress: wp-content/debug.log
  • Joomla: a konfigurációban (configuration.php / admin felület) megadott log_path mappában lévő fájlok
  • Más keretrendszerek: pl. Laravel: storage/logs/laravel.log

Ezekben a logokban gyakran részletesebb stack trace is van (melyik függvény mit hívott, milyen sorrendben), ami fejlesztésnél vagy összetettebb hibáknál nagyon hasznos.


Hol találod meg a logokat cPanelen?

Apache / Nginx hibanapló – Hibák (Errors) menü

  1. Lépj be a cPanel felületre.
  2. Keresd meg a Metrics / Mutató blokkot.
  3. Kattints a Hibák vagy Errors menüpontra.

Itt látni fogod a legutóbbi hibasorokat, például:

  • HTTP 500 hibákhoz tartozó részletes üzeneteket,
  • .htaccess hibákat,
  • egyes PHP hibákat, ha a webszerver is naplózza őket.

Fontos:
Ez a nézet egy szűrt kivonat, ami csak a te tárhelyedhez tartozó bejegyzéseket mutatja, a teljes szerver-szintű loghoz csak rendszergazdáink férnek hozzá.

PHP error log – ha be van kapcsolva a PHP-FPM

  1. Ellenőrizd a MultiPHP Manager menüpontban, hogy a domainnél be van-e kapcsolva a PHP-FPM.
  2. Nyisd meg a File Manager / Fájlkezelő menüt.
  3. Navigálj a következő könyvtárba:
    • /home/FELHASZNÁLÓNÉV/logs

Itt általában olyan fájlokat találsz, amelyek nevében benne van:

  • a domain neve,
  • és/vagy a php szó,
  • valamint dátum/idő jelölés.

A legfrissebb módosítási idővel rendelkező fájlt érdemes megnyitni.

PHP error log – ha nincs PHP-FPM

Ha a domainen nincs PHP-FPM:

  • a PHP hibaüzenetek elsősorban oda íródnak, amit a php.ini vagy a CMS konfigurációja error_log-nak beállít,
  • vagy ha a CMS más logolási megoldást használ, akkor annak a saját log mappájába.

Ha nem találod a logot, sokszor a CMS dokumentációja jelzi, hova ír, vagy kérdezhetsz rá nálunk ticketben, és ellenőrizzük a beállításokat.


WordPress debug log (debug.log) bekapcsolása

A WordPress saját, részletes hibalogot tud írni a wp-content/debug.log fájlba.

1. lépés: wp-config.php szerkesztése

  1. Nyisd meg a File Manager / Fájlkezelő menüt cPanelen.
  2. Navigálj a WordPress telepítési könyvtárába (pl. public_html).
  3. Keresd meg a wp-config.php fájlt.
  4. Kattints rá jobb gombbal → Edit / Szerkesztés.

A következő sorokat add hozzá (vagy módosítsd, ha már léteznek):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Általában a /* That's all, stop editing! Happy publishing. */ sor előtt szokás elhelyezni őket.

2. lépés: debug.log megkeresése

  1. Lépj a wp-content mappába.
  2. Keresd a debug.log fájlt.

Ebben fogod látni:

  • a PHP hibákat, amelyeket a WordPress érzékel,
  • a plugin / sablon hibákat,
  • részletes stack trace-eket.

Fontos:
Ha végeztél a hibakereséssel, kapcsold ki a debug módot (állítsd a WP_DEBUG-ot false-ra), mert:

  • a log gyorsan nőhet,
  • érzékeny információk is bekerülhetnek.


Joomla és egyéb alkalmazások logjai

Joomla debug és log mappa

Joomla esetén több helyen is találhatsz logot:

  1. Globális konfiguráció → Rendszer
    • Itt kapcsolható a Debug mód.
  2. Konfiguráció → Szerver / System részben találod a Log path beállítást.
    • Ez mutatja, melyik könyvtárba írja a Joomla a logokat (pl. logs vagy administrator/logs).

A logfájlokban tipikusan:

  • bővítmény / modul hibák,
  • adatbázis hibák,
  • PHP figyelmeztetések jelennek meg.

Egyéb keretrendszerek (Laravel, Symfony, saját fejlesztés)

  • Laravel: storage/logs/laravel.log
  • Symfony: var/log mappa
  • Saját fejlesztésnél: a fejlesztő által megadott log mappa (erről a fejlesztőtől tudsz pontos információt kérni).


Hogyan olvass és értelmezz egy logsort?

Vegyünk egy tipikus PHP hibát:

[2025-11-25 12:34:56] PHP Fatal error:  Uncaught Error: Call to undefined function my_missing_function() in /home/felhasznalo/public_html/wp-content/themes/sajat-tema/functions.php:123

Mit jelentenek az elemek?

  • [2025-11-25 12:34:56] – időpont, mikor történt a hiba
  • PHP Fatal error – hibaszint (súlyos, a script futása leáll)
  • Uncaught Error: Call to undefined function ... – hibaüzenet
  • …functions.php:123 – melyik fájlban, hányadik sorban történt a hiba

Általános tipp:

  • mindig a legfrissebb sorokat nézd (log végén),
  • keresd a Fatal error, Parse error, Warning, Notice kifejezéseket,
  • figyeld a fájlt és sorszámot, ez segít beazonosítani a hibás kódot vagy bővítményt.


Tipikus hibák és mit tehetsz ellenük?

1. memory_limit hiba

Példa:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate ...)

Mit jelent?
A PHP elérte a beállított memória-limitet (pl. 128M).

Mit tehetsz?

  • Emeld a memory_limit értékét (pl. 256M vagy 512M – a csomagod keretein belül).
  • Ha így is kifut, nézd át, melyik bővítmény / folyamat használ sok memóriát (log alapján sokszor látszik).
  • Ha a szükséges érték irreálisan magas lenne, vagy nem egyértelmű az ok, írj nekünk ticketet, és csatold a logrészletet.


2. max_execution_time hiba

Példa:

PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /home/...

Mit jelent?
A script futási ideje meghaladta a max_execution_time limitet (pl. 30 másodperc).

Mit tehetsz?

  • Növeld a futási idő limitet (ésszerű kereteken belül, pl. 60–120).
  • Ha nagy importot / migrációt futtatsz, ez természetes is lehet.
  • Ha egy sima oldalbetöltésnél lép fel, valószínűleg egy bővítmény / lassú SQL lekérdezés okozza – ilyenkor érdemes optimalizálni, vagy fejlesztővel / ügyfélszolgálatunkkal egyeztetni.


3. include/require hibák (hiányzó fájl)

Példa:

PHP Warning:  include(/home/.../valami.php): failed to open stream: No such file or directory in /home/.../index.php on line 45

Mit jelent?
A script próbál betölteni egy fájlt, ami nem létezik vagy nem érhető el.

Mit tehetsz?

  • Ellenőrizd, hogy a hivatkozott fájl tényleg ott van-e.
  • Ha bővítmény / sablon frissítés után jött elő, lehet, hogy a frissítés megszakadt, töltsd fel újra.
  • Bizonytalan esetben másold ki a logrészletet és írj nekünk ticketet.


4. Jogosultsági hibák – „Permission denied”

Példa:

PHP Warning:  file_put_contents(...): failed to open stream: Permission denied in /home/...

Mit jelent?
A PHP nem tud írni/olvasni egy fájlt vagy mappát a jogosultságok miatt.

Mit tehetsz?

  • Fájlkezelőben ellenőrizd a jogosultságokat:
    • fájloknál jellemzően 0644,
    • könyvtáraknál 0755 javasolt.
  • Ha sok fájl / mappa érintett, vagy nem vagy biztos abban, mit lehet átírni, kérj segítséget ügyfélszolgálatunktól.


5. Adatbázis hibák

Példák:

PHP Warning:  mysqli_connect(): (HY000/1045): Access denied for user 'dbuser'@'localhost' (using password: YES)

PDOException: SQLSTATE[HY000] [1049] Unknown database 'adatbazisnev'

Mit jelent?

  • Rossz adatbázis felhasználónév / jelszó,
  • nem létezik az adatbázis,
  • a felhasználónak nincs jogosultsága az adatbázisra.

Mit tehetsz?

  • Ellenőrizd a weboldalad konfigurációs fájlját (WordPress: wp-config.php, Joomla: configuration.php stb.).
  • Nézd meg, hogy a cPanel → MySQL Databases menüben:
    • létezik-e az adatbázis,
    • hozzá van-e rendelve a megfelelő user,
    • helyes-e a jelszó.
  • Ha nem egyértelmű, küldd el nekünk a releváns logrészletet (jelszó nélkül).


6. Session hiba – session_start(): Failed to read session data / session.save_path

Példa:

PHP Warning:  session_start(): Failed to read session data: files (path: /var/cpanel/php/sessions/ea-phpXX) in /home/...

Mit jelent?
A PHP nem tudja használni a session tárolót (pl. nem írható a session.save_path, vagy sérült session fájlok vannak).

Mit tehetsz?

  • Ha saját session útvonalat használsz, ellenőrizd, hogy a mappa létezik-e és írható-e.
  • Ha rendszer alapértelmezett útvonalat látsz (pl. /var/cpanel/php/sessions/...), és folyamatosan ilyen hiba jelenik meg, másold ki a logrészletet és jelezd nekünk ticketben – ezt rendszerszinten tudjuk ellenőrizni.


7. Header hiba – „Cannot modify header information”

Példa:

PHP Warning:  Cannot modify header information - headers already sent by (output started at /home/.../file.php:10) in /home/.../file.php on line 50

Mit jelent?
A PHP már küldött kimenetet a böngészőnek (pl. szóköz, BOM, echo), és ezután próbál HTTP fejléceket küldeni (pl. header(), setcookie()).

Mit tehetsz?

  • A hibaüzenetben megadott „output started at” fájl / sorszám környékén keresd a felesleges kiírást:
    • üres sor a <?php előtt,
    • HTML / echo,
    • BOM (rejtett karakter a fájl elején).
  • Ha a hiba plugin / sablon fájlban van, érdemes fejlesztővel egyeztetni vagy a bővítményt másikra cserélni.


8. cURL / külső API hibák

Példák:

cURL error 28: Connection timed out after 5000 milliseconds
cURL error 60: SSL certificate problem: certificate has expired

Mit jelent?

  • A weboldal cURL-lel próbál csatlakozni egy külső szolgáltatáshoz (API, fizetési rendszer, külső kép/forrás), de:
    • nem válaszol időben,
    • tanúsítványhiba van,
    • tűzfal / hálózati probléma akadályozza.

Mit tehetsz?

  • Ellenőrizd, hogy a hivatkozott külső szolgáltatás elérhető-e böngészőből.
  • Ha saját fejlesztésű integrációról van szó, a fejlesztővel nézessétek át a timeout értékeket, hívott URL-t, tanúsítványt.
  • Ha biztos vagy benne, hogy a külső szolgáltatás rendben van, de cURL hibát kapsz, csatold a logrészletet a tickethez, mi oldalunkról is megvizsgáljuk.


9. mod_security / WAF által blokkolt kérések

Példák (Apache / Errors kivonatban):

ModSecurity: Access denied with code 406 (phase 2). Pattern match "(?i:(select\s+.+from))" at ARGS:search.

Mit jelent?
A webszerver WAF / mod_security szabályrendszere gyanúsnak ítélte a kérést (SQL injection gyanú, XSS, stb.), és blokkolta.

Mit tehetsz?

  • Ha egyértelműen valós látogatói / admin műveletet blokkol (pl. admin keresőmező), másold ki a teljes hibasort,
  • írd meg ticketben, milyen URL-t, mit csinálva kaptál hibát (pl. keresés admin felületen),
  • mi a szabályazonosító alapján célzottan tudjuk vizsgálni, szükséges-e finomhangolás.


10. Deprecated / Notice hibák – régi kód, jövőbeni problémák

Példák:

PHP Deprecated:  Function create_function() is deprecated in /home/...
PHP Notice:  Undefined index: my_key in /home/...

Mit jelent?

  • Deprecated: olyan függvényt vagy szintaxist használ a kód, ami újabb PHP verziókban már elavult, később el fog tűnni.
  • Notice: nem kritikus, de jelzi, hogy valami nincs teljesen rendben (pl. nem létező tömbkulcs, változó).

Mit tehetsz?

  • Ezek általában nem állítják meg a weboldalt, de hosszú távon problémát okozhatnak (PHP verzió váltásnál).
  • Ha modern PHP verzióra váltasz, és sok Deprecated hibát látsz, fejlesztői oldalról érdemes a kódot frissíteni.
  • Ha a log tele van Notice üzenetekkel, az ugyan nem kritikus, de takarja a valódi hibákat – fejlesztővel érdemes átnézetni.


Mikor és mit küldj el nekünk a logokból?

Ticket írása előtt érdemes összegyűjtened:

  1. Melyik domain / aldomain érintett?
  2. Mikor jelentkezett a hiba (dátum, idő, hozzávetőlegesen)?
  3. Logrészlet a hiba idejéről:
    • Apache / Nginx kivonat a cPanel → Hibák (Errors) menüből,
    • PHP error logból 10–20 friss sor,
    • WordPress / Joomla debug.log vonatkozó része.

Ezt másold be a ticketbe:
https://ugyfeladmin.tarhely.eu/submitticket.php
Minél pontosabb logokat küldesz, annál gyorsabban és célzottabban tudunk segíteni.


Biztonság és teljesítmény – mire figyelj logolás közben?

  • Ne hagyd feleslegesen bekapcsolva a debug módot (WordPress, Joomla, egyéb keretrendszerek):
    • logfájlok gyorsan nőnek,
    • érzékeny technikai információk (fájlstruktúra, path-ok, esetleg részleges adatok) kerülhetnek bele.
  • Időnként ellenőrizd a logfájlok méretét, ha túl nagyok lettek:
    • töltsd le őket saját gépre archiválásra,
    • majd töröld a tárhelyről, hogy ne foglaljanak feleslegesen helyet.
  • Logfájlokat ne tarts webből közvetlenül elérhető könyvtárban, vagy legalább biztosítsd, hogy ne legyenek böngészőn át letölthetők.


GYIK – Error logokkal kapcsolatos gyakori kérdések


1. Üres az error log. Akkor nincs hiba?

Nem feltétlenül.

Előfordulhat, hogy:

  • a hiba nem PHP hiba, hanem például DNS / hálózati gond,
  • a logolás nincs megfelelően bekapcsolva,
  • másik logfájlt használ a rendszer.

Ilyenkor érdemes ellenőrizni a cPanel Hibák menüt, a PHP-FPM logs mappát és a CMS saját logját.


2. Nem jön létre a WordPress debug.log fájl. Mit rontottam el?

Ellenőrizd:

  • hogy a wp-config.php-ben biztosan a megfelelő helyen és pontosan vannak-e a define sorok,
  • hogy a wp-content mappának vannak-e írási jogosultságai,
  • hogy van-e valamilyen cache / opcache, ami nem frissítette még a kódot.

Ha ezek rendben vannak, provokálj ki egy kisebb hibát (pl. ideiglenesen elírsz egy fájlnevet), és nézd meg, bekerül-e a logba.


3. Mekkora lehet a logfájl maximális mérete?

Konkrét felső korlát nincs, de gyakorlati okból érdemes figyelni rá:

  • több száz MB-os vagy több GB-os log már feleslegesen terheli a tárhelyet,
  • lassabb lehet a megnyitása, szerkesztése.

Ha nagyon nagyra nőtt, töltsd le, majd töröld vagy rotáld (új, üres logfájl jön létre a következő hiba esetén).


4. Kinyithatom a logfájlokat közvetlenül böngészőből?

Nem ajánlott.

  • Biztonsági okból jobb, ha a logfájlok nem elérhetők közvetlenül HTTP-n keresztül.
  • Használd a cPanel Fájlkezelőjét vagy FTP-t / SFTP-t a letöltésükhöz.


5. Hibát látok, de nem értem, mi a teendő – mit tegyek?

Semmi gond, ez teljesen normális.

Másold ki a hiba pontosan látható részét (időpont, üzenet, fájl/sor), és írj nekünk ticketet:

https://ugyfeladmin.tarhely.eu/submitticket.php

Mi a log alapján meg tudjuk mondani, hogy:

  • tárhely / szerver beállítási kérdésről van szó, vagy
  • inkább weboldal / fejlesztés oldalról kell javítani a hibát.
  • error log, nginx error log, joomla log, apache error log, cpanel hibák menü, php error log, http 500 hiba, log elemzés, debug, 2025, wordpress debug log
  • 0 Utilisateurs l'ont trouvée utile
Cette réponse était-elle pertinente?

Articles connexes

503 Service Unavailable Error: mi a megoldás?

Megoldás: A cPanel tárhely admin felület "Jogjavítás" menüpontja alatt kattintson a "Jogjavítás"...

Error log alapján HTTP 500 hibák megoldása – fejlesztői gyorstalpaló

Ha HTTP 500 hibát kapsz, a böngészőben látott „Internal Server Error” üzenet önmagában semmit nem...

403 Forbidden hibaüzenet: mit jelent, és hogyan javíthatod a tárhelyen?

A 403 Forbidden azt jelenti, hogy a szerver elérhető, de nem engedi a kért oldal/fájl...