403, 404, 500, 502, 503, 504 Sunucu Hataları ve Çözümleri

Sitenizin yerinde beyaz bir sayfa ve üç haneli bir sayı gördüğünüzde, o sayı aslında size ilk ipucunu verir. Hata kodları rastgele değildir: 4 ile başlayanlar isteğin kendisinde, 5 ile başlayanlar sunucu tarafında bir sorun olduğunu söyler. Bu ayrım tek başına aramanızı yarı yarıya daraltır.

Aşağıda en sık karşılaşılan altı kodu, tipik sebepleriyle ve düzeltme adımlarıyla ele alıyorum. Sonda da hepsinin ortak teşhis aracını, yani hata günlüğünü nasıl okuyacağınızı bulacaksınız.

Hata kodlarına hızlı bakış

403 Forbidden: dosya var ama kapı kapalı

Sunucu dosyayı buluyor, size vermeyi reddediyor. Üç yaygın nedeni var.

• Yanlış izinler. Klasörler 755, dosyalar 644 olmalıdır. Bir klasör 700’e düşmüşse web sunucusu içine giremez.
• index dosyası yok. Klasörde index.php ya da index.html yoksa ve dizin listeleme kapalıysa 403 alırsınız. Doğru davranış budur; listeleme açmak yerine bir index dosyası koyun.
• .htaccess engeli. Güvenlik eklentileri ya da sağlayıcı kuralları belirli IP’leri veya wp-admin dizinini kilitlemiş olabilir. Bir de sunucudaki ModSecurity kuralları vardır: uzun bir form gönderdiğinizde tetiklenip 403 döndürür. Bu durumda sağlayıcıdan ilgili kural kimliğinin (id) günlükten bakılmasını isteyin.

404 Not Found: adres var, hedef yok

Tek bir sayfada 404 alıyorsanız muhtemelen bağlantı yanlıştır ya da içerik silinmiştir. Ama ana sayfa açılıp diğer tüm sayfalar 404 veriyorsa tablo başkadır: bu neredeyse her zaman yeniden yazma kurallarının bozulmasıdır.

WordPress’te çözüm basittir: Ayarlar > Kalıcı Bağlantılar sayfasını açıp hiçbir şeyi değiştirmeden Kaydet’e basmak, .htaccess dosyasını yeniden yazdırır. Dosya yazılamıyorsa izin 644 mü diye bakın. Site taşındıysa ve sunucu Nginx ise .htaccess hiç okunmaz; kuralların sunucu yapılandırmasında tanımlı olması gerekir.

Eski adresleri kalıcı olarak taşıdıysanız 404 bırakmayın, 301 yönlendirmesi yapın. Arama motorları için de ziyaretçi için de fark eder.

500 Internal Server Error: en yaygın ve en belirsiz

500, sunucunun "isteği işlerken bir şey patladı ama detayı size söylemeyeceğim" demesidir. Detay her zaman günlüktedir. Sırayla şunlara bakın:

1. .htaccess. Dosyayı .htaccess_eski diye yeniden adlandırın ve siteyi yenileyin. Site açılıyorsa suçlu bulundu; içindeki son eklenen bloğu kaldırın. Yanlış yazılmış tek bir yönerge tüm siteyi 500’e düşürür.
2. PHP bellek limiti. Günlükte Allowed memory size of 134217728 bytes exhausted benzeri bir satır varsa limit yetmiyordur. cPanel’de MultiPHP INI Editor ile memory_limit değerini 256M’ye çıkarın. Tekrarlıyorsa asıl sorun sızıntı yapan bir eklentidir.
3. Bozuk eklenti ya da tema. WordPress’te panele giremiyorsanız FTP ile wp-content/plugins klasörünü plugins_kapali yapın. Site açılırsa eklentileri tek tek geri alarak suçluyu bulun.
4. Sözdizimi hatası. functions.php‘ye elle kod eklediyseniz eksik bir parantez yeter. Günlükteki PHP Parse error satırı size dosya adını ve satır numarasını verir.

502, 503 ve 504: sunucunun nefesi kesildiğinde

Bu üçü genelde kaynak ile ilgilidir ve birbirine karışır.

502 Bad Gateway, web sunucusunun PHP işleyicisinden geçerli bir cevap alamamasıdır. PHP-FPM süreci çöktüyse ya da yeniden başlatıldıysa görülür. Genelde kendiliğinden düzelir; sık tekrarlıyorsa bellek yetersizliği ya da sürekli çöken bir betik vardır.

503 Service Unavailable, paylaşımlı hostingde en sık "hesap kaynak limitini aştı" anlamına gelir. CloudLinux kullanan sunucularda cPanel ana sayfasındaki kaynak kullanımı grafiğinde Entry Processes ya da CPU sütununun tavana vurduğunu görürsünüz. WordPress’te ayrıca yarım kalmış bir güncelleme .maintenance dosyasını kök dizinde bırakır; o dosyayı silmek siteyi anında geri getirir.

504 Gateway Timeout, işlemin izin verilen sürede bitmemesidir. Klasik tetikleyicileri: 20 bin satırlık bir ürün içe aktarımı, kargo firmasının yavaş API’si, optimize edilmemiş bir arama sorgusu. Çözüm max_execution_time‘ı büyütmek değil, işi parçalamaktır; toplu işlemleri 500’er kayıtlık partiler halinde çalıştırın. Yükün kaynağını bulmak için site yavaşlığının nedenlerini incelemek işe yarar.

error_log dosyasını okumak

Tahmin yürütmeyi bırakıp günlüğe bakmak, teşhis süresini dakikalara indirir. Günlük genelde iki yerdedir:

• Hatanın oluştuğu dizindeki error_log dosyası (cPanel Dosya Yöneticisi’nde gizli dosyaları göstermeyi açın).
• cPanel’de Ölçümler > Hatalar ekranı; son 300 satırı gösterir.

Satırlar şu biçimdedir: tarih, hata düzeyi, mesaj, dosya yolu ve satır numarası. Önce en alttaki yani en yeni satıra bakın, sonra hatanın ilk göründüğü zamana çıkın. WordPress’te daha ayrıntılı kayıt için wp-config.php içine define('WP_DEBUG', true); ve define('WP_DEBUG_LOG', true); ekleyip define('WP_DEBUG_DISPLAY', false); ile hataların ziyaretçiye görünmesini engelleyin. Kayıtlar wp-content/debug.log dosyasına düşer. İşiniz bitince bu satırları kaldırın; hata mesajları saldırgana dosya yollarınızı gösterir.

Günlükteki mesajı çözemiyorsanız, ham satırı olduğu gibi sağlayıcınıza iletin. "Site açılmıyor" demekle "PHP Fatal error: Allowed memory size exhausted in /home/kullanici/public_html/wp-includes/functions.php on line 402 alıyorum" demek arasında saatlerce fark vardır. Kalıcı çözüm için paketinizin kaynak sınırlarının siteye yetip yetmediğini de gözden geçirin; hosting paketi seçerken CPU ve bellek limitleri fiyattan daha belirleyicidir.

Özetle

• 4xx isteğe, 5xx sunucuya işaret eder; bu ayrım aramayı hemen daraltır.
• 403’te izinleri ve .htaccess’i, 404’te kalıcı bağlantı ayarını ilk sırada kontrol edin.
• 500 hatasında önce .htaccess’i devre dışı bırakın, sonra eklentileri kapatın, sonra bellek limitine bakın.
• 503 paylaşımlı hostingde çoğunlukla kaynak limiti; 504 ise uzun süren işlem demektir.
• Her durumda error_log dosyasındaki gerçek satır, tahminlerden daha hızlı sonuç verir.