cPanel Hata Kayıtları ile Site Sorunlarını Bulma

Siteniz bir anda beyaz ekran veya "500 Internal Server Error" verdiğinde ilk tepki genellikle paniktir. Eklentiyi mi silsem, temayı mı değiştirsem, hostinge mi yazsam diye düşünürken aslında sorunun ne olduğunu size net biçimde söyleyen bir kaynak zaten hesabınızın içinde durur: hata kayıtları. Sunucu, bir isteği tamamlayamadığında bunu sessizce yutmaz; ne olduğunu, hangi dosyada ve hangi satırda takıldığını bir log dosyasına yazar. cPanel de bu kayıtların en tazesini tarayıcıdan okumanız için "Errors" (Hata Kayıtları) adında bir ekran sunar.

Bu rehberde cPanel'in Errors ekranındaki son Apache hatalarını nasıl okuyacağınızı, bir log satırındaki dosya yolu ile satır numarasını nasıl yorumlayacağınızı ve bu bilgiyle 500 hatası, izin sorunları ve PHP fatal error gibi en sık karşılaşılan üç problemi adım adım nasıl teşhis edeceğinizi anlatacağım. Amaç rastgele deneme yanılma değil; kıdemli bir sistem yöneticisinin yaptığı gibi önce logu okuyup, sorunun kök nedenini isabetle bulup ardından tek ve doğru müdahaleyi yapmaktır. Bu ekrana bir kez alıştığınızda, çoğu "site çöktü" krizini destek talebi açmadan kendiniz çözersiniz.

Errors Ekranı Ne Gösterir#

cPanel ana sayfasında "Metrics" (Ölçümler) grubunun altında yer alan Errors aracı, sunucunun Apache/LiteSpeed hata logundan hesabınıza ait son yaklaşık 300 satırı ters kronolojik sırayla (en yenisi en üstte) önünüze getirir. Yani ekranı açtığınız anda gördüğünüz ilk satırlar, birkaç saniye önce oluşan hatalardır. Bu ekranın en büyük avantajı, SSH ile sunucuya bağlanıp uzun log dosyalarını tail etmeden, tamamen panelden anlık hataları görmenizdir. Özellikle paylaşımlı hosting kullanıcıları için sorun teşhisinin en hızlı başlangıç noktası burasıdır.

Ekranın gösterdiği kayıtlar yalnızca "gerçek hatalar" değildir; eksik bir favicon, bulunamayan bir görsel (404), yanlış yapılandırılmış bir yönlendirme kuralı ve PHP'nin ürettiği her warning/notice de buraya düşebilir. Bu yüzden ilk bakışta uzun ve korkutucu görünen liste, aslında çoğunlukla önemsiz gürültüyle asıl kritik hatanın karışımıdır. İşin ustalığı, bu karışımın içinden sitenizi gerçekten çökerten satırı ayıklamaktır; birazdan bunun pratik yöntemine geleceğiz.

Şunu baştan bilmek gerekir: Errors ekranı yalnızca son 300 satırı tutar. Trafiği yoğun bir sitede bu 300 satır birkaç dakikada dolup taşabilir, dolayısıyla dünkü bir hatayı burada bulamayabilirsiniz. Böyle durumlarda ham log dosyalarına inmek gerekir; bu yerlere ilerideki bölümde değineceğiz. cPanel'in genel araç ekosistemine yabancıysanız, önce cPanel nedir yazımızla panelin mantığını oturtmanız bu rehberi çok daha anlaşılır kılar.

Bir Log Satırını Parçalara Ayırmak#

Bir hata satırını doğru okuyabilmek, teşhisin yarısıdır. Errors ekranındaki tipik bir Apache satırı şuna benzer:

[Wed Jul 09 14:32:07.114820 2026] [proxy_fcgi:error] [pid 21894] [client 85.34.12.7:52344] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_current_user() in /home/kullanici/public_html/wp-content/themes/tema/functions.php:212'

Görünüşte karmaşık olsa da bu satır aslında düzenli parçalardan oluşur ve her parça size ayrı bir ipucu verir. Parçaları soldan sağa şöyle okuyun:

Bu parçalar içinde sizi doğrudan çözüme götüren ikisi dosya yolu ve satır numarasıdır. Yukarıdaki örnekte hata wp-content/themes/tema/functions.php dosyasının 212. satırındadır; yani sorun WordPress çekirdeğinde değil, kullandığınız temanın kodundadır. Bu iki bilgi olmadan "sitede bir hata var" dersiniz; bu iki bilgiyle "temanın functions dosyasının 212. satırı tanımsız bir fonksiyon çağırıyor" dersiniz. Aradaki fark, saatlerce süren deneme yanılma ile beş dakikalık hedefli düzeltme arasındaki farktır.

Hata seviyesini de gözden kaçırmayın. error ve crit gerçekten sitenizi bozan, öncelik verilmesi gereken kayıtlardır. warn ve notice çoğu zaman siteyi çökertmez ama uzun vadede sorun habercisidir. Bir kod dosyasını incelerken satır numarasına gitmek için Dosya Yöneticisi'nin (File Manager) kod düzenleyicisini kullanabilir, ilgili satırı görüp düzeltebilirsiniz.

500 Internal Server Error'ı Teşhis Etmek#

500 hatası, ziyaretçiye gösterilen en genel ve en bilgisiz hatadır; sunucu "bir şeyler ters gitti ama detayı sana söylemem" der. Detay her zaman logdadır. Errors ekranını açtığınızda 500 hatasının arkasında genellikle üç sebepten biri yatar: bozuk bir .htaccess kuralı, PHP bellek/işlem limitine takılma ya da izin problemi. Logdaki mesaj hangisi olduğunu size doğrudan söyler.

.htaccess kaynaklı bir 500 hatası, logda tipik olarak şöyle görünür:

[core:alert] [client 85.34.12.7] /home/kullanici/public_html/.htaccess: Invalid command 'RewriteRule', perhaps misspelled or defined by a module not enabled

Bu mesajı gördüğünüzde çözüm nettir: sunucu .htaccess içindeki bir satırı tanımıyor. En hızlı test, .htaccess dosyasını geçici olarak .htaccess_yedek diye yeniden adlandırıp siteyi tekrar denemektir. Site açılıyorsa suçlu kesinleşmiştir; dosyayı temizleyip kuralları tek tek geri ekleyerek hangisinin bozuk olduğunu bulursunuz. WordPress'te bu dosya bozulmuşsa, panelden ayarları yeniden kaydederek sağlıklı bir sürüm ürettirebilirsiniz. .htaccess yönlendirme kurallarını daha derinlemesine öğrenmek için ilgili wiki yazılarımıza da göz atabilirsiniz.

PHP bellek limitine takılan bir 500 hatası ise logda şöyle belli eder kendini:

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/kullanici/public_html/wp-includes/wp-db.php on line 2056

Buradaki Allowed memory size ... exhausted ifadesi, betiğin izin verilen bellekten fazlasını istediğini söyler. Kalıcı çözüm, çoğu zaman belleği körlemesine artırmak değil, belleği tüketen kötü eklenti veya sorguyu bulmaktır; ancak acil olarak nefes aldırmak için php.ini ya da panelin MultiPHP INI Editor bölümünden limiti yükseltebilirsiniz:

memory_limit = 512M
max_execution_time = 120

Eğer 500 hatasının yanında hiçbir açıklama yoksa ve log yalnızca Premature end of script headers gibi kuru bir satır içeriyorsa, sorun neredeyse her zaman dosya izinlerindedir; bir sonraki bölüm tam olarak buna ayrılmış durumda.

İzin ve Sahiplik Hataları#

Paylaşımlı hostingte 500 hatalarının en sinsi kaynağı, yanlış dosya izinleridir. Sunucu, güvenlik gereği bir betiğin ya da klasörün fazla açık (herkese yazılabilir) ya da yanlış sahiplikte olmasına izin vermez; böyle bir durumda betiği çalıştırmayı reddeder ve logda bunu açıkça belirtir:

[core:error] [client 85.34.12.7] Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive is also forbidden due to its similarity to a symlink
[cgi:error] SoftException in Application.cpp: Directory "/home/kullanici/public_html" is writeable by group

İkinci satırdaki writeable by group uyarısı klasiktir: dosya ya da klasör 777 gibi aşırı geniş bir izne sahiptir ve suPHP/CloudLinux bunu güvenlik ihlali sayıp betiği çalıştırmaz. Doğru izinler neredeyse her zaman klasörler için 755, dosyalar için 644 olmalıdır. SSH erişiminiz varsa tüm hesabı tek seferde normalize etmek için:

# Klasörleri 755, dosyaları 644 yap
find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;

SSH erişiminiz yoksa aynı işlemi cPanel Dosya Yöneticisi'nden bir klasöre sağ tıklayıp "Change Permissions" (İzinleri Değiştir) diyerek yapabilirsiniz. Dosya izinlerinin mantığını temelden kavramak, bu tür hataları en baştan önler; izin numaralarının ne anlama geldiğini merak ediyorsanız Linux dosya izinleri konusundaki wiki yazımız bu konuyu ayrıntısıyla açıklıyor.

Sahiplik (ownership) sorunları da benzer belirti verir. Genellikle bir dosyayı root olarak ya da farklı bir kullanıcıyla yüklediğinizde ortaya çıkar; log Permission denied der ama izinler doğru görünür. Bu durumda dosyanın sahibi hesabınızın kullanıcı adı değildir. Paylaşımlı hostingte sahipliği çoğu zaman kendiniz düzeltemezsiniz; böyle bir satır gördüğünüzde bu, destek ekibine iletmeniz gereken nadir durumlardan biridir. Sunucunuzu kendiniz yönetiyorsanız chown ile sahipliği hesabınıza geri verirsiniz.

PHP Fatal Error ve Uyarılarını Okumak#

WordPress, Laravel veya herhangi bir PHP uygulaması çalıştırıyorsanız, Errors ekranında en sık göreceğiniz kayıt türü PHP hatalarıdır. Bunların ciddiyeti bir hiyerarşiye göre değişir ve hangisiyle uğraştığınızı bilmek önceliklendirme açısından kritiktir:

En yıkıcı olan Fatal error ile başlayalım. Bu satır her zaman sorunun tam adresini verir:

PHP Fatal error:  Uncaught Error: Call to undefined function get_field()
in /home/kullanici/public_html/wp-content/themes/tema/single.php:48

Buradaki Call to undefined function get_field() mesajı, kodun var olmayan bir fonksiyonu çağırdığını söyler; get_field genellikle ACF eklentisinden gelir. Yani muhtemelen bir eklenti devre dışı kalmış ya da silinmiş, ama tema hâlâ onun fonksiyonunu çağırıyordur. Çözüm, ilgili eklentiyi yeniden etkinleştirmek veya temadaki çağrıyı bir koşula almaktır. Parse error ise daha basittir; genellikle FTP ile yaptığınız yarım bir düzenlemeden ya da kopyala-yapıştır sırasında bozulan bir karakterden kaynaklanır ve satır numarası sizi doğrudan hatalı yere götürür.

Eksik dosya kaynaklı Warning satırları da çok yaygındır ve genellikle şu kalıptadır:

PHP Warning:  require_once(/home/kullanici/public_html/wp-config.php):
Failed to open stream: No such file or directory in ... on line 21

Bu mesaj birebir "beklediğim dosyayı bulamadım" demektir; ya dosya gerçekten silinmiştir, ya yolu yanlış yazılmıştır, ya da bir taşıma sonrası yol değişmiştir. Site taşıma işlemlerinden sonra bu tür "dosya bulunamadı" hataları sık görülür; temiz bir taşıma yaptığınızdan emin olmak için site taşıma hizmetimiz bu tür yol/izin sorunlarını en baştan engeller. WordPress'e özgü hata çözümlerinin tam bir listesi için WordPress hata çözümü rehberimiz adım adım senaryolar sunar.

Errors Ekranı Dışındaki Log Yerleri#

cPanel'in Errors aracı hızlı bir başlangıç noktasıdır ama tek log kaynağı değildir. Ekranın tuttuğu 300 satır yetmediğinde ya da hata oraya hiç düşmediğinde bakmanız gereken başka yerler vardır. Bunları bilmek, sizi "logda bir şey yok, demek ki sorun yok" yanılgısından kurtarır.

En değerlisi, çoğu PHP uygulamasının kendi çalışma dizinine yazdığı error_log dosyasıdır. Örneğin bir WordPress sitesinde public_html/error_log ya da hataya sebep olan eklentinin klasöründe bir error_log dosyası oluşur ve buraya cPanel ekranından çok daha fazla kayıt birikir. Dosya Yöneticisi'nden ya da SSH ile bu dosyayı doğrudan okuyabilirsiniz:

# Sitenizin kendi PHP hata logunun son 50 satırı
tail -n 50 ~/public_html/error_log

# Belirli bir kelimeyi anlık izlemek (Ctrl+C ile çıkın)
tail -f ~/public_html/error_log | grep -i "fatal"

Ham Apache erişim ve hata loglarına ulaşmak için cPanel'in "Metrics" grubundaki Raw Access (Ham Erişim Kayıtları) aracını kullanabilirsiniz; bu, tarih bazlı geçmişe dönük analiz için idealdir. WordPress tarafında ise kod düzeyinde ayrıntı görmek isterseniz wp-config.php dosyasına hata ayıklama modunu açtırabilirsiniz:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // wp-content/debug.log dosyasına yazar
define( 'WP_DEBUG_DISPLAY', false ); // hataları ziyaretçiye gösterme

Bu ayar açıkken tüm WordPress hataları wp-content/debug.log içine yazılır ve ziyaretçilere gösterilmez. Sorununuzu bulduktan sonra bu satırları false yapmayı ya da tamamen kaldırmayı unutmayın; canlı sitede açık kalan debug modu güvenlik ve performans açısından risklidir. Kendi sunucunuzu yönetiyorsanız, log dosyalarının yapılandırılması ve düzenli temizliği gibi işleri profesyonel biçimde ele almak için sunucu yönetimi hizmetimiz bu yükü sizden alır.

Adım Adım Teşhis Akışı#

Şimdi tüm parçaları tek bir tekrarlanabilir akışta birleştirelim. Bir hata yönetimi krizinde panikleyip rastgele dosya silmek yerine, kıdemli bir yöneticinin izlediği şu sırayı takip edin; çoğu sorun bu altı adımın içinde çözülür.

Önce ne zaman ve neyin bozulduğunu netleştirin. Site tamamen mi kapalı yoksa belirli bir sayfa mı hata veriyor? Sorun bir eklenti güncellemesi, tema değişikliği ya da yeni bir kod yüklemesinden hemen sonra mı başladı? Bu bilgi, logdaki hangi zaman damgasına odaklanacağınızı belirler. Ardından Errors ekranını açın ve en üstteki, yani en yeni error/Fatal error satırını bulun; warn ve notice gürültüsünü şimdilik atlayın.

Bulduğunuz satırda dosya yolu ile satır numarasını okuyun. Sorun bir eklenti klasöründe mi, tema dosyasında mı, yoksa uygulama çekirdeğinde mi? Bu, müdahale edeceğiniz yeri daraltır. Sonra hata mesajını sınıflandırın: bellek mi tükendi, dosya mı bulunamadı, izin mi reddedildi, fonksiyon mu tanımsız? Her sınıfın çözümü bu rehberde ayrı bölümlerde. Beşinci adımda tek bir değişiklik yapıp test edin; aynı anda beş şeyi birden değiştirirseniz, düzelse bile hangisinin işe yaradığını asla bilemezsiniz. Son olarak, sorun paylaşımlı hostingte sizin erişiminizin dışındaysa (sahiplik, sunucu modülü, kaynak limiti), logdaki tam satırı kopyalayıp destek talebine ekleyin; hazır teşhisle gelen bir talep, dakikalar içinde çözülür.

# Hızlı teşhis için pratik komut dizisi (SSH)
tail -n 100 ~/public_html/error_log | grep -iE "fatal|error"   # kritik hataları süz
find ~/public_html -type f -perm 0777                          # tehlikeli açık izinli dosyalar
ls -la ~/public_html/.htaccess                                 # htaccess var mı, izni ne

Bu akışı birkaç kez uyguladıktan sonra hata kayıtları sizin için korkutucu bir duvar olmaktan çıkar ve sitenizin size ne söylediğini anlatan bir konuşma diline dönüşür. İşte o noktada gerçek anlamda sitenizin kontrolü sizdedir.

Sıkça Sorulan Sorular#

cPanel Errors ekranı boş görünüyor, bu ne demek?#

Boş bir Errors ekranı çoğu zaman iyi haberdir; son 300 kayıt içinde hesabınıza ait ciddi bir hata oluşmadığı anlamına gelir. Ancak yanıltıcı olabilir çünkü bu ekran yalnızca son satırları tutar ve trafiği yüksek bir sitede eski hatalar hızla dışarı taşabilir. Aradığınız hatayı bulamıyorsanız, sitenizin kendi error_log dosyasına ya da Raw Access loglarına bakın; oralarda çok daha uzun bir geçmiş birikir.

Logda gördüğüm satır numarasına nasıl giderim?#

Hata mesajındaki :212 gibi bir satır numarası, belirtilen dosyadaki tam konumu gösterir. cPanel Dosya Yöneticisi'nde o dosyayı bulup üstüne sağ tıklayın ve "Edit" ya da "Code Edit" seçeneğiyle açın; kod düzenleyici satır numaralarını solda gösterdiği için ilgili satıra kolayca kayabilirsiniz. SSH erişiminiz varsa sed -n '210,215p' dosya.php komutuyla o satırın çevresindeki birkaç satırı doğrudan görüntüleyebilirsiniz.

500 hatası aldım ama Errors ekranında hiçbir açıklama yok, ne yapmalıyım?#

Bu genellikle hatanın Apache seviyesinde değil, PHP işleminin daha erken bir aşamasında oluştuğu anlamına gelir. İlk olarak .htaccess dosyasını geçici olarak yeniden adlandırıp siteyi deneyin; açılıyorsa sorun oradadır. Açılmıyorsa dosya izinlerini kontrol edin ve WordPress kullanıyorsanız wp-config.php içinden WP_DEBUG_LOG modunu açarak wp-content/debug.log dosyasında daha ayrıntılı bir kayıt üretin.

Hata kayıtlarını temizlemek sorunu çözer mi?#

Hayır, log dosyasını silmek yalnızca kayıtları temizler, sorunun kendisini ortadan kaldırmaz; hata devam ediyorsa bir sonraki istekte yeniden yazılır. Log temizliği sadece disk alanı için, o da dosya çok büyüdüğünde anlamlıdır. Asıl yapılması gereken, logu okuyup kök nedeni bulmak ve o nedeni düzeltmektir; hata çözülünce yeni satır zaten yazılmaz.

PHP Warning satırlarını görmezden gelebilir miyim?#

Çoğu Warning ve Notice satırı siteyi çökertmez, bu yüzden acil bir kriz anında önceliğiniz Fatal error satırları olmalıdır. Ancak uyarıları tamamen görmezden gelmek de doğru değildir; "eksik dosya" ya da "geçersiz argüman" gibi bir uyarı, bugün siteyi bozmasa da yarın ciddi bir hataya dönüşebilecek bir sorunun erken habercisidir. Zamanınız olduğunda bu uyarıların da kaynağını düzeltmek, sitenizi uzun vadede sağlıklı tutar.

Kendi sunucumda log dosyaları nerede tutulur?#

Kendi VPS ya da sunucunuzu yönetiyorsanız, sistem geneli Apache hataları genellikle /var/log/apache2/error.log (Debian/Ubuntu) veya /var/log/httpd/error_log (CentOS/AlmaLinux) altındadır. LiteSpeed kullanıyorsanız /usr/local/lsws/logs/error.log dosyasına bakın. Her sanal alan adının kendine ait bir log dosyası da olabilir; bunların yollarını web sunucusunun yapılandırma dosyasındaki ErrorLog satırından öğrenebilirsiniz.

Kapanış#

Hata kayıtları, sitenizin size doğrudan konuştuğu yerdir; onu okumayı öğrendiğinizde çoğu "site çöktü" krizi, panikle geçen bir öğleden değil, birkaç dakikalık odaklı bir teşhise dönüşür. Yapmanız gereken tek şey, önce logu açmak, en yeni kritik satırı bulmak, dosya yolu ile satır numarasını okumak ve tek bir doğru müdahaleyi yapmaktır. Bu alışkanlık, sizi hem daha yetkin bir site sahibi yapar hem de gereksiz destek talebi trafiğinden kurtarır.

Clou.TR olarak biz bu işi kolaylaştırmak için buradayız. Hızlı NVMe altyapısı, güncel PHP sürümleri ve anlaşılır bir cPanel deneyimi sunan hosting paketlerimiz ile hata kayıtlarınıza tek tıkla ulaşırsınız; WordPress'e özel optimize edilmiş bir ortam istiyorsanız WordPress hosting çözümümüz, kaynak ve güvenlik ayarlarını sizin için önceden yapılandırır. Sunucu tarafındaki log yönetimi, izin düzeltmeleri ve performans işlerini uzmanlara bırakmak isterseniz sunucu yönetimi hizmetimiz her zaman yanınızda. Sorununuz ne olursa olsun, çözümün ilk adımı hep aynıdır: logu açın ve dinleyin.