500 Internal Server Error Nedir ve Nasıl Çözülür?

500 hatası tam olarak ne anlama gelir?

HTTP durum kodlarında 5xx sınıfı, sunucunun görünüşte geçerli bir isteği yerine getiremediğini anlatır. 500 bu sınıfın en genel üyesidir. MDN'nin örnek olarak saydığı olası nedenler şunlardır: hatalı sunucu yapılandırması, bellek yetersizliği, yakalanmamış istisnalar (unhandled exceptions), hatalı dosya izinleri ve başka karmaşık etkenler. Diğer kodların ne anlattığını merak ediyorsanız HTTP durum kodları rehberimize bakabilirsiniz.

Benzer görünen kodlarla karıştırmamak önemlidir: 502 ve 504 çoğunlukla bir ara sunucunun (proxy, PHP-FPM, yük dengeleyici) arka taraftan geçerli yanıt alamadığını gösterir; bunları 502 ve 504 gateway hataları yazısında ele aldık. 503 ise geçici bir aşırı yük veya bakım durumudur; ayrıntısı 503 Service Unavailable yazısında.

Ziyaretçiyseniz: kısa kontroller

MDN'nin de belirttiği gibi 500 hataları sunucu sahibi veya yöneticisi tarafından incelenmesi gereken hatalardır; ziyaretçi olarak asıl sorunu siz çözemezsiniz. Yine de geçici bir aksaklığı ayırt etmek için şunları deneyebilirsiniz:

• Sayfayı birkaç saniye sonra yenileyin. Anlık bir yük veya yeniden başlatma sırasında oluşan hata kendiliğinden geçebilir.
• Aynı adresi başka bir tarayıcıda veya gizli pencerede açın. Bozuk bir çerez, oturum açılan sitelerde bazen sunucu tarafında hataya yol açabilir.
• Mobil veri gibi başka bir bağlantıdan deneyin. Hata herkeste oluyorsa sorun kesinlikle sitededir.
• Hata sürüyorsa site sahibine hangi sayfada, hangi saatte ve hangi işlemi yaparken (form gönderme, ödeme vb.) karşılaştığınızı yazın. Bu bilgi günlükte doğru satırı bulmayı kolaylaştırır.

Site sahibiyseniz: önce hata günlüğüne bakın

500 hatasını tahminle çözmeye çalışmak çoğu zaman vakit kaybıdır. Sunucu, hatanın gerçek nedenini neredeyse her zaman bir günlük dosyasına yazar. Hangi dosyaya bakacağınız kullandığınız ortama bağlıdır:

SSH erişiminiz varsa günlüğü canlı izlemek en hızlı yoldur. Apache belgeleri test sırasında tail -f ile günlüğü sürekli izlemeyi önerir. Bir terminalde aşağıdaki komutu çalıştırıp hatalı sayfayı tarayıcıda yenileyin; yeni satır anında görünür. SSH bağlantısı için SSH ile sunucuya bağlanma yazısına bakabilirsiniz.

# Debian/Ubuntu üzerinde Apache
sudo tail -f /var/log/apache2/error.log

# RHEL ailesinde Apache
sudo tail -f /var/log/httpd/error_log

# Nginx
sudo tail -f /var/log/nginx/error.log

Günlük satırı nasıl okunur?

Apache belgelerindeki tipik bir hata satırı şöyledir:

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error

Sırasıyla tarih ve saat, modül ve önem düzeyi (core:error), süreç ve iş parçacığı numarası, istemcinin IP adresi ve son olarak asıl mesaj yer alır. Siz en çok son kısma odaklanın: hangi dosya, hangi satır, hangi yönerge. Yukarıdaki örnek, bir yönlendirme döngüsünün 500'e yol açtığını gösteriyor. Nginx'te benzer bir döngüde günlükte "rewrite or internal redirection cycle" mesajı görülür; Nginx belgelerine göre istek başına 10 iç yönlendirme sınırı aşıldığında 500 döndürülür.

En yaygın nedenler ve çözümleri

1. .htaccess dosyasındaki hatalar

Paylaşımlı hostinglerde 500 hatasının bir numaralı nedeni bozuk veya uyumsuz bir .htaccess dosyasıdır. Apache belgeleri iki durumu ayrıca anlatır: dosyada izin verilmeyen bir yönerge kullanılması (örnek günlük satırı: DirectoryIndex not allowed here) ve yönergenin kendisinde sözdizimi hatası olması (örnek: RewriteCond: bad flag delimiters). Her iki durumda da günlük size tam olarak hangi dosyada ve hangi yönergede sorun olduğunu söyler.

Apache belgelerinde ilginç bir test yöntemi de var: .htaccess içine anlamsız bir kelime yazıp sayfayı yenilediğinizde 500 hatası oluşmuyorsa sunucuda büyük ihtimalle AllowOverride None etkindir, yani dosya hiç okunmuyordur. Tersinden düşünürsek, dosyadaki tek bir yazım hatası bütün siteyi 500'e düşürebilir.

LiteSpeed Web Server kullanan hostinglerde de .htaccess kuralları genellikle okunur, ancak bazı Apache modüllerine özgü yönergeler farklı davranabilir. Kural yazımıyla ilgili ayrıntılar için .htaccess rehberi ve Apache .htaccess yönlendirme rehberi yazılarımıza bakabilirsiniz.

2. PHP ölümcül hataları

Bir eklenti, tema veya kendi kodunuz çalışırken PHP'nin devam edemeyeceği bir hata oluşursa sunucu 500 döndürebilir. Canlı sitede hata mesajlarını ziyaretçiye göstermek yerine günlüğe yazmak gerekir. PHP kılavuzu display_errors ayarının internete açık sistemlerde asla kullanılmaması gerektiğini, bunun yerine log_errors ile günlüğe yazmanın şiddetle önerildiğini belirtir. error_log ayarlanmamışsa hatalar SAPI'nin günlüğüne, örneğin Apache hata günlüğüne gider.

; Canlı site için önerilen PHP hata ayarları
display_errors = Off
log_errors = On

cPanel'de bu ayarları Software bölümündeki MultiPHP INI Editor'dan değiştirebilirsiniz. cPanel belgelerine göre display_errors varsayılan olarak kapalı, log_errors ise açıktır.

3. Dosya izinleri ve sahiplik (suEXEC)

Birçok paylaşımlı sunucuda PHP, suEXEC benzeri bir yapıyla dosyanın sahibi olan kullanıcı adına çalışır. Apache'nin suEXEC belgesi, programı çalıştırmadan önce yaptığı güvenlik kontrollerini listeler: dizinin ve programın sahibi dışında kimse tarafından yazılabilir olmaması, programın setuid veya setgid olmaması ve hedef kullanıcının dosyanın sahibi olması bunların arasındadır. Koşullardan biri sağlanmazsa suEXEC hatayı günlüğe yazar ve programı çalıştırmaz. cPanel belgelerine göre Errors ekranı da hesabınızla ilgili suexec_log kayıtlarını gösterir.

Bu yüzden "herkes yazabilsin" düşüncesiyle izinleri genişletmek sorunu çözmek yerine genellikle büyütür. WordPress belgeleri suEXEC kullanan sunucular için klasörlerde 755 veya 750, dosyalarda 644 veya 640 önerir ve hiçbir klasöre 777 verilmemesi gerektiğini açıkça yazar. Ayrıntılar için WordPress dosya izinleri ve güvenlik rehberi yazımıza bakın.

# public_html içinde: önce yedek alın, sonra çalıştırın
cd ~/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

4. PHP sürümü uyumsuzluğu

Hosting panelinden PHP sürümünü değiştirdikten hemen sonra 500 hatası başlıyorsa, eski bir eklenti veya tema yeni sürümde kaldırılmış bir fonksiyonu kullanıyor olabilir; tersi de mümkündür, yeni bir eklenti eski PHP'de çalışmayabilir. cPanel'deki MultiPHP Manager ekranında alan adının yanındaki kutuyu işaretleyip PHP Version menüsünden sürüm seçip Apply ile kaydedersiniz. cPanel belgelerine göre inherit seçeneği alan adının sunucu varsayılanını kullanmasını sağlar. Kalıcı çözüm, yazılımı güncel PHP ile uyumlu hale getirmektir. PHP hakkında genel bilgi için PHP nedir yazısına bakabilirsiniz.

5. Bellek ve kaynak sınırları

MDN, bellek yetersizliğini 500 nedenleri arasında sayar. PHP'nin memory_limit sınırını aşan bir betik ölümcül hata verir; bu konuyu Allowed memory size hatası yazısında ayrıntılı anlattık. CloudLinux kullanan paylaşımlı sunucularda hesap başına bellek ve süreç sınırları da vardır. LiteSpeed belgeleri, süreç sayısı sınırına ulaşıldığında kullanıcının 500 veya 503 hatası görebileceğini belirtir. Disk alanının dolması da birçok yazma işlemini başarısız kılar; disk doldu hatası yazısına göz atın.

Nginx kullanıyorsanız

Nginx .htaccess dosyalarını okumaz; kurallar sunucu yapılandırmasındadır. Bu yüzden Nginx'te 500 hatasının yaygın nedenleri yapılandırma hataları, yönlendirme döngüleri ve PHP-FPM tarafındaki hatalardır. Nginx belgelerine göre error_log yönergesi debug, info, notice, warn, error, crit, alert ve emerg düzeylerini destekler; düzey verilmezse error kullanılır. Sorun ararken geçici olarak daha ayrıntılı bir düzey açabilirsiniz:

server {
    # Sorun giderme süresince geçici olarak
    error_log /var/log/nginx/site-error.log notice;
}

Yapılandırmayı değiştirdikten sonra Nginx belgelerinin belirttiği gibi nginx -s reload ile yeniden yüklemeniz gerekir; değişiklikler bu komut gönderilmeden ya da sunucu yeniden başlatılmadan uygulanmaz. PHP-FPM havuz ayarları için PHP-FPM yapılandırma, genel ayarlar için Nginx yapılandırma rehberi yazılarına bakabilirsiniz.

WordPress sitelerinde 500 hatası

WordPress belgelerindeki "Common WordPress Errors" sayfası, Internal Server Error için en olası nedenin bozuk bir .htaccess dosyası olduğunu söyler ve şu sırayı önerir:

• FTP veya Dosya Yöneticisi ile .htaccess dosyasını yeniden adlandırın. Site açılırsa yönetim panelinde Ayarlar > Kalıcı Bağlantılar sayfasını kaydederek yeni bir dosya oluşturun. Kurallar için WordPress .htaccess kuralları yazısına bakın.
• Tüm eklentileri devre dışı bırakın. Panele giremiyorsanız wp-content/plugins klasörünü yeniden adlandırmak eklentileri topluca kapatır.
• Varsayılan bir temaya geçin.
• PHP bellek sınırını artırın.
• Son çare olarak wp-admin ve wp-includes klasörlerini temiz bir WordPress paketinden yeniden yükleyin.

Hatanın kaynağını görmek için WordPress'in hata ayıklama günlüğünü açabilirsiniz. WordPress belgelerindeki örneğe göre bu ayarlar hataları ekrana basmadan wp-content/debug.log dosyasına yazar. Önce wp-config.php dosyasının yedeğini alın; ayrıntılı sabitler için wp-config.php sabitleri rehberine bakabilirsiniz.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress yakaladığı bir PHP ölümcül hatasında genellikle düz bir 500 sayfası yerine "There has been a critical error on this website." (Türkçe WordPress'te "Sitenizde ciddi bir sorun çıktı.") mesajını gösterir. WordPress kaynak kodunda bu varsayılan şablonun da HTTP 500 koduyla döndüğü görülür. Bu senaryoyu WordPress kritik hata çözümü yazısında ayrıca ele aldık. Hata veritabanı bağlantısıyla ilgiliyse veritabanı bağlantı hatası yazısına geçin.

Sık Sorulan Sorular

500 Internal Server Error benim bilgisayarımdan mı kaynaklanıyor?

Hayır. 500, sunucunun isteği işlerken sorun yaşadığını belirtir. Tarayıcınızı yenilemek veya başka cihazdan denemek yalnızca geçici bir aksaklığı ayırt etmeye yarar; kalıcı çözüm site sahibindedir.

500 hatası SEO'yu etkiler mi?

Kısa süreli bir hata genellikle sorun yaratmaz, ama süreklileşirse etkiler. Google Search Central belgelerine göre 500, 502 ve 503 hataları Google'ın siteyi taramasını yavaşlatır ve sürekli sunucu hatası döndüren URL'ler zamanla dizinden çıkarılır. Sunucu yeniden 2xx yanıt vermeye başladığında tarama hızı kademeli olarak artar.

Hata günlüğünü göremiyorum, ne yapmalıyım?

cPanel'de Metrics > Errors ekranı görünmüyorsa hosting firmanız bu özelliği kapatmış olabilir. Dosya Yöneticisi'nde gizli dosyaları gösterip error_log dosyalarını arayın; bulamazsanız destek ekibinden ilgili zaman aralığındaki günlük satırlarını isteyin.

Yalnızca tek bir sayfada 500 alıyorum, neden?

Bu genellikle o sayfada çalışan belirli bir kodun, eklentinin veya kısa kodun hata verdiğini gösterir. O sayfayı yenilerken günlüğü canlı izlerseniz hangi dosyanın hata verdiğini doğrudan görürsünüz.

Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: 403 Forbidden hatası · 503 Service Unavailable hatası · WordPress kritik hata · PHP memory limit hatası · 502 ve 504 hataları · .htaccess rehberi