500 Internal Server Error Çözümü: Nedenleri ve Adım Adım Teşhis

500 Internal Server Error, web sunucusunun isteği işlerken beklenmedik bir sorunla karşılaştığını ama nedenini tarayıcıya açıklayamadığını bildiren genel bir HTTP durum kodudur. Ziyaretçi yalnızca standart bir hata sayfası görür; asıl açıklama sunucudaki hata günlüğüne yazılır. Bu yüzden çözüm tahminle değil, günlükteki o tek satırı bulmakla başlar.

Hatanın kaynağı çoğu zaman sunucu donanımı değil, hesabınızdaki bir dosyadır: bozuk bir .htaccess satırı, ölümcül bir PHP hatası ya da yanlış bir dosya izni. Aşağıdaki kontrol sırası LIONFIN web hosting hesaplarındaki cPanel ve Plesk araçlarına göre hazırlandı; mantığı her Linux hostingde aynıdır.

500 Internal Server Error nedir, diğer 5xx hatalarından farkı ne?

500 kodu, sunucunun “bir şeyler ters gitti, daha uygun bir kod da yok” demesidir; hata istemcide değil, sunucu tarafındaki yapılandırmada ya da uygulamadadır. Tarayıcı değiştirmek veya önbelleği temizlemek bu yüzden sonucu değiştirmez. Aynı ailedeki kodlar ise farklı yerlere işaret eder:

Hatanın tüm sayfalarda mı, yalnızca yönetici panelinde mi, yoksa belirli bir işlemde (form gönderme, görsel yükleme) mi çıktığını not edin; bu ayrım teşhisi belirgin biçimde kısaltır. Kaynak limitleriyle ilişkili olabilen 503 ve 508 kodları için hosting kaynak limitleri rehberine bakın.

500 hatası neden olur?

500 hatası çoğunlukla hesabınızdaki bir yapılandırma ya da kod sorunundan doğar; paylaşımlı hostingde vakaların büyük kısmı şu yedi nedenden birine dayanır:

• .htaccess sözdizimi hatası: Yanlış yazılmış bir yönerge, sunucuda yüklü olmayan bir modüle ait satır ya da PHP-FPM ortamında kullanılan php_value satırı tüm siteyi durdurur.
• Ölümcül PHP hatası (fatal error): Eksik dosya, tanımsız fonksiyon ya da sözdizimi hatası içeren bir eklenti, tema veya özel kod.
• Dosya izinleri ve sahiplik: Betiği hesap kullanıcısıyla çalıştıran suPHP ve suEXEC benzeri yapılandırmalarda gruba ya da herkese yazılabilir dosyalar (777, 775, 666) güvenlik gereği çalıştırılmaz. Başka bir kullanıcıya ait dosyalar da aynı sonucu doğurabilir.
• Bellek sınırı: Betik memory_limit değerini aştığında “Allowed memory size … exhausted” hatasıyla durur.
• Eklenti ya da tema çakışması: Güncelleme sonrası iki eklentinin aynı fonksiyonu ya da sınıfı tanımlaması veya bir eklentinin, bağlı olduğu başka bir eklentinin uyumlu sürümünü bulamaması.
• PHP sürümü uyumsuzluğu: Sürüm yükseltmesinden sonra kaldırılmış fonksiyonlara dayanan eski kod; sık kırılan kalıplar PHP 8 güncelleme rehberi yazısında listelenir.
• Zaman aşımı: max_execution_time süresini aşan içe aktarma, yedekleme ya da rapor betikleri. Web sunucusu ya da proxy kaynaklı zaman aşımı ise çoğunlukla 504 olarak görünür.

Hatanın son yapılan bir değişiklikten hemen sonra başlaması güçlü bir ipucudur: eklenti güncellemesi, PHP sürümü değişikliği ve .htaccess düzenlemesi ilk şüphelilerdir.

500 Internal Server Error nasıl çözülür? Adım adım kontrol sırası

500 hatası, günlükten başlayıp en kolay geri alınabilen nedenden en zoruna doğru ilerleyerek çözülür; her adımdan sonra sayfayı gizli pencerede yeniden deneyin:

1. Hata günlüğünü okuyun. Satır çoğu zaman dosya adını ve satır numarasını verir; günlüğün yeri bir sonraki bölümde anlatılır.
2. .htaccess dosyasını devre dışı bırakın. Adını .htaccess.yedek olarak değiştirin; site açılıyorsa sorun bu dosyadadır, satırları tek tek geri ekleyerek hatalı olanı bulun.
3. İzinleri kontrol edin. Klasörler 755, dosyalar 644 olmalı; 777 izinli öğeleri düzeltin.
4. Uygulama hatasını görünür yapın. WordPress’te WP_DEBUG ile hatayı günlüğe yazdırın, sorunlu eklentiyi klasör adını değiştirerek kapatın.
5. PHP sürümünü değiştirin. Hata bir sürüm değişikliğinin hemen ardından başladıysa önceki sürüme dönüp kodu güncelleyin. Linux hosting paketlerinde PHP sürümünü panelden kendiniz seçersiniz; adımlar cPanel PHP sürümü değiştirme rehberinde.
6. Bellek sınırını yükseltin. Günlükte bellek hatası varsa memory_limit değerini artırın.
7. Son değişikliği geri alın. Hiçbiri sonuç vermezse hatanın başladığı saatten önceki yedeğe dönmeyi değerlendirin.

Dosyaları tarayıcıdan düzenlemek için cPanel dosya yöneticisi yeterlidir; nokta ile başlayan dosyaları görmek için gizli dosya görünümünü açmayı unutmayın.

Hata günlüğü nerede, satırlar nasıl okunur?

Hata günlüğü cPanel’de Metrics → Errors ekranında ve sitenin klasörlerindeki error_log dosyalarında, Plesk’te ise alan adının Logs ekranında bulunur. Errors ekranı web sunucusunun hesabınıza ait son kayıtlarını listeler; PHP hataları ise çoğu yapılandırmada hatayı üreten betiğin klasöründeki error_log dosyasına yazılır, bu yüzden public_html ve wp-admin klasörlerine bakın. PHP-FPM kullanan cPanel hesaplarında aynı kayıtlar ana dizindeki logs klasöründe, alan adınızı içeren .php.error.log uzantılı bir dosyada da olabilir. Plesk’te filtreyi hata kayıtlarına çevirmeniz yeterlidir. Tipik satırlar (tarih alanları kısaltıldı):

[core:alert] [client 203.0.113.10] /home/kullanici/public_html/.htaccess: Invalid command 'RewriteRul', perhaps misspelled or defined by a module not included in the server configuration

PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /home/kullanici/public_html/inc/db.php:12

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/import.php on line 88

İlk satır .htaccess içindeki bir yazım hatasını, ikincisi yeni PHP sürümünde artık bulunmayan bir fonksiyonu, üçüncüsü 128 MB bellek sınırının aşıldığını gösterir. Ölümcül hatalarda satırdaki dosya yolu genellikle suçluyu verir: wp-content/plugins/ sonrasındaki klasör adı sorunlu eklentidir. Bellek hatalarında ise yol yalnızca belleğin tükendiği yeri gösterir; asıl tüketen başka bir bileşen olabilir.

.htaccess ve dosya izinlerinden kaynaklanan 500 nasıl düzeltilir?

.htaccess kaynaklı hatalarda dosyayı sıfırdan yazmak yerine günlükte adı geçen yönergeyi düzeltmek ya da kaldırmak daha güvenlidir. WordPress’te dosyayı yeniden adlandırdıktan sonra Ayarlar → Kalıcı Bağlantılar ekranında Değişiklikleri Kaydet düğmesine basmak standart kuralları yeniden üretir. PHP-FPM kullanan bir hesapta IfModule bloğu dışında kalan php_value ya da php_flag satırını silip aynı ayarı .user.ini dosyasına taşıyın. Bazı paylaşımlı sunucular güvenlik gereği Options +FollowSymLinks satırına izin vermez; yerine Options +SymLinksIfOwnerMatch yazın. Kural örnekleri .htaccess kullanımı rehberindedir.

İzin sorunlarını SSH ya da cPanel Terminal üzerinden topluca bulup düzeltebilirsiniz:

# Gruba ya da herkese yazılabilir öğeleri listeleyin
find ~/public_html \( -perm -g=w -o -perm -o=w \) -ls | head -50

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

İkinci blok tüm klasör ve dosyaları standart izinlere çeker; ardından wp-config.php gibi hassas dosyaları 600 ya da 640, varsa cgi-bin içindeki çalıştırılabilir betikleri yeniden 755 yapın. Dosyaların sahibi başka bir kullanıcıysa sahipliği siz değiştiremezsiniz; destek ekibi düzeltir.

WordPress’te 500 hatası: eklenti, tema ve bellek

WordPress sitelerinde 500 hatasının en yaygın kaynağı bir eklenti ya da temadır ve hata çoğunlukla bir güncellemenin hemen ardından başlar. WordPress’in “kritik hata” sayfası da arka planda 500 kodu döndürür ve yönetici adresine kurtarma modu bağlantısı içeren bir e-posta gönderir; bu e-posta geldiyse sorunlu eklentiyi oradan kapatabilirsiniz. Gelmediyse hatayı ziyaretçiye göstermeden günlüğe yazdırmak için wp-config.php dosyasına ekleyin:

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

Hata wp-content/debug.log dosyasına düşer. Suçluyu bulmak için wp-content/plugins klasörünün adını geçici olarak plugins.kapali yapın; site açılırsa klasöre eski adını verin ve eklentileri yönetici panelinden tek tek etkinleştirerek hatayı yeniden üreteni belirleyin. Tema için aynı yöntemi etkin tema klasöründe uygulayın; varsayılan bir tema yüklüyse WordPress ona geçer. Teşhis bitince WP_DEBUG değerini false yapıp debug.log dosyasını silin. Ekranın tamamen boş kaldığı durumlar için WordPress beyaz ekran hatası, bellek hataları için PHP memory limit artırma rehberine bakın.

Ne zaman destek talebi açmalı, talepte neler olmalı?

Günlükte hiç kayıt yoksa, hata hesabınızdaki tüm sitelerde aynı anda başladıysa ya da yukarıdaki adımlar sonuç vermediyse sorun sunucu yapılandırmasında olabilir; bu noktada müşteri paneli → Destek üzerinden talep açın. Hızlı sonuç için talebe şunları ekleyin:

• Hatanın göründüğü tam adres ve hatanın sürekli mi, aralıklı mı olduğu.
• Hatanın başladığı yaklaşık tarih ve saat.
• Hemen öncesinde yapılan değişiklik: eklenti güncellemesi, PHP sürümü, .htaccess düzenlemesi, taşıma.
• Günlükte gördüğünüz satır, ekran görüntüsü yerine metin olarak.
• Denediğiniz adımlar ve her birinin sonucu.

Bu bilgiler ekibin aynı kontrolleri baştan yapmasını önler. Talep açma adımları destek talebi oluşturma rehberindedir. Şifre ya da kart bilgisi gibi gizli verileri talep metnine yazmayın.