500 Internal Server Error Nedir? Çözümü (nginx, Apache)

HTTP 500 Hatası Nedir?

HTTP 500 hatası (Internal Server Error), isteğiniz işlenirken web sunucusunda bir şeyin bozulduğu ve sunucunun ne olduğunu söylemediği anlamına gelir. En genel sunucu hatasıdır.

HTTP standardı bunu tek cümleyle tanımlar: "The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request" (RFC 9110 §15.6.1); yani sunucu, isteği yerine getirmesini engelleyen beklenmedik bir durumla karşılaştı. 503 hatasının aksine, sorunun geçici olup olmadığı hakkında bir şey söylemez.

Neredeyse her zaman sunucu tarafı kodundaki bir hata, hatalı yapılandırma ya da çökmedir; ziyaretçinin yaptığı bir şey değildir. Düzeltme site sahibinden veya yöneticisinden gelmelidir.

500 Hatası Nasıl Görünür

İfade sunucuya ve uygulamaya göre değişir:

• 500 Internal Server Error — standart durum satırı
• 500 Internal Server Error ve altında "nginx" yazısı — nginx'in kendi hata sayfası
• The server encountered an internal error or misconfiguration and was unable to complete your request. — Apache'nin varsayılan sayfası
• Sitenizde ciddi bir sorun çıktı. — WordPress'in ölümcül hata sayfası, Türkçe sürümdeki hâliyle (İngilizcesi: "There has been a critical error on this website.")
• HTTP Error 500.19 - Internal Server Error — IIS; noktadan sonraki sayı nedeni gösterir (500.19: geçersiz yapılandırma verisi)
• Bu sayfa çalışmıyor · example.com şu anda bu isteği işleme alamıyor. · HTTP ERROR 500 — Chrome, 500 yanıtının kendi sayfası olmadığında
• Request failed with status code 500 — Axios ve bir API'yi çağıran diğer JavaScript kodları
• 500. That's an error. — Google'ın kendi hata sayfası

nginx'te 500 Internal Server Error

nginx çoğu zaman arkasındaki uygulamanın (PHP-FPM, Node.js, Python) döndürdüğü 500'ü yalnızca iletir; PHP-FPM'de PHP'nin kendi hata iletisi nginx günlüğüne düşer. nginx birkaç durumda kendi 500 hatasını da üretir. Hata günlüğünde aranacak satırlar:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Kaynak: nginx'in kendi kodu; çöken veya aşırı yüklenen bir arka uç 500 değil, 502 veya 504 döndürür.)

HTTP 500 Hatasının Yaygın Nedenleri

500 hatası, sunucu tarafındaki onlarca sorundan kaynaklanabilir. En yaygın olanlar:

• Bozuk bir .htaccess dosyası — tek bir geçersiz yönerge veya hatalı bir RewriteRule, Apache'nin o klasör ve altındaki her şey için 500 döndürmesine yol açar.
• PHP ölümcül hataları — sözdizimi hataları, yakalanmamış istisnalar veya tanımsız fonksiyon çağrıları betiği durdurur.
• PHP bellek veya süre limitleri — memory_limit (varsayılan 128M) veya max_execution_time (30 saniye) sınırını aşan betik durdurulur.
• PHP-FPM sunucusunda php_value satırları — yalnızca Apache'nin mod_php'siyle çalışırlar; PHP-FPM altında Apache bunları 500 ile reddeder.
• Yanlış dosya izinleri — PHP, dahil ettiği bir dosyayı okuyamaz ya da bir suPHP/suEXEC sunucusu herkesin yazabildiği dosyaları (777) reddeder. (Web sunucusunun kendisinin okuyamadığı dosya 403 verir.)
• Bir eklenti veya tema — tüm siteyi çökerten yeni ya da güncellenmiş bir WordPress, Joomla veya Drupal uzantısı.
• Veritabanı bağlantı hataları — yanlış kimlik bilgileri, durmuş bir veritabanı sunucusu ya da çok fazla bağlantı.
• Bozulmuş çekirdek dosyalar — başarısız bir güncellemeden veya yarıda kalan bir yüklemeden sonra.
• Dolu bir disk — sunucu günlükleri, oturumları veya geçici dosyaları yazamaz.
• nginx'in kendi tetikleyicileri — bir yeniden yazma döngüsü, okunamayan bir parola dosyası ya da başarısız bir geçici dosya yazımı (çoğu zaman dolu disk); yukarıdaki nginx bölümüne bakın.

Ziyaretçiler İçin 500 Hatasını Düzeltme

Başkasının web sitesinde 500 hatası görüyorsanız, sorun sunucu tarafındadır; sizde değil. Ancak vazgeçmeden önce deneyebileceğiniz birkaç şey var.

• Bir dakika sonra sayfayı bir kez yenileyin (F5 veya Mac'te Cmd+R). Birçok 500 hatası yalnızca bir dağıtım ya da yeniden başlatma süresince sürer.
• Herkes için kapalı mı diye bakın — Site Çöktü mü Kontrolü sayfayı 11 yerden açar, HTTP Başlık Kontrolü ise sunucumuzun aldığı tam durum kodunu gösterir.
• Sitenin çerezlerini silin ya da gizli pencere deneyin. Bozuk bir oturum çerezi, bazı uygulamaların her sayfada yalnızca sizin için hata vermesine yol açabilir.
• Daha sonra tekrar deneyin — düzeltme sunucu tarafındadır, bu yüzden site sahibine zaman tanıyın.
• Site sahibine haber verin; sorun saatlerce sürerse sayfa adresini ve olduğu saati belirtin.

Çözüm 1: Sunucu Hata Günlüklerini Kontrol Edin

Hata günlükleri, 500 hataları için en önemli hata ayıklama aracıdır. Size tam olarak neyin yanlış gittiğini, dosya yolunu, satır numarasını ve hata mesajını söyler. Başka bir şey denemeden önce her zaman günlükleri kontrol edin.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Çözüm 2: .htaccess Dosyasını Test Edin ve Onarın

Bozuk bir .htaccess dosyası Apache'de 500 hatalarının klasik nedenidir: tek bir yazım hatası, sunucunun desteklemediği bir yönerge veya hatalı bir RewriteRule klasörü çalışmaz hâle getirir. Apache'nin hata günlüğü .htaccess dosyasını ve hatalı yönergeyi gösterir; örneğin Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

En hızlı test, dosyanın adını geçici olarak değiştirmektir. Adı değiştirdikten sonra site açılıyorsa sorun .htaccess dosyasıydı.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Çözüm 3: Dosya İzinlerini Düzeltin

İzinler, PHP dahil ettiği bir dosyayı okuyamadığında ya da herkesin yazabildiği dosyaları reddeden suPHP/suEXEC sunucularında 500 hatasına yol açar. Olağan ayarlar dosyalar için 644 ve klasörler için 755'tir. Asla 777 kullanmayın: güvenlik riskidir ve suEXEC/suPHP sunucularında tek başına 500 hatasına neden olur.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Çözüm 4: PHP Bellek ve Çalıştırma Limitlerini Artırın

PHP, bellek sınırını veya en uzun çalışma süresini aşan betikleri durdurur ve ziyaretçi 500 hatası alır. Varsayılan değerler, yani 128M bellek ve 30 saniye, ağır sayfalar için çoğu zaman düşüktür.

Bunları sunucunuzun okuduğu yerde yükseltin. PHP-FPM için FPM'in php.ini dosyasını (örneğin /etc/php/8.3/fpm/php.ini) düzenleyin ve php-fpm'i yeniden yükleyin; .user.ini değişikliklerinin uygulanması 5 dakikayı bulabilir.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Çözüm 5: Eklentileri ve Temayı Devre Dışı Bırakın (CMS)

WordPress, Joomla veya başka bir CMS kullanıyorsanız, hatalı bir eklenti veya tema 500 hatalarının en yaygın nedenlerinden biridir. En hızlı test, tüm eklentileri bir seferde devre dışı bırakıp ardından tek tek yeniden etkinleştirmektir.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Çözüm 6: Veritabanı Bağlantısını Kontrol Edin ve Onarın

Uygulama veritabanına bağlanamadığında 500 hatası oluşabilir. Bu, kimlik bilgileri yanlış olduğunda, veritabanı sunucusu çalışmadığında veya tablolar bozulduğunda gerçekleşir.

Önce yapılandırma dosyanızdaki (WordPress için wp-config.php, Laravel için .env) veritabanı kimlik bilgilerinizi doğrulayın. Ardından bağlantıyı test edin ve gerekirse bozuk tabloları onarın.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Çözüm 7: PHP Sürüm Uyumluluğunu Kontrol Edin

Eski bir PHP sürümü için yazılmış kod, daha yeni bir sürümde (ya da tersinde) ölümcül hatalara takılabilir. PHP yükseltmesinden sonra genellikle kaldırılan fonksiyonlar ve değişen davranışlar suçludur; kullanımdan kaldırılmış (deprecated) fonksiyonlar yalnızca bildirim üretir.

Sitenizin gerçekte hangi PHP sürümünü çalıştırdığını kontrol edin. Komut satırındaki php -v, sitenizin kullandığından farklı bir PHP gösterebilir; bu yüzden hosting panelinize veya geçici bir phpinfo() sayfasına da bakın:

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Çözüm 8: Disk Alanını Kontrol Edin

Bir sunucunun disk alanı (veya inode'ları) tükendiğinde günlükleri, geçici dosyaları ya da oturum verilerini yazamaz ve istekler 500 hatasıyla başarısız olmaya başlar.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500, 502, 503 ve 504 Arasındaki Fark Nedir?

Temel fark: 500 = sunucu içeride bozuldu. 502 = proxy arka uçtan anlamsız bir yanıt aldı. 503 = sunucu ayakta ama meşgul. 504 = proxy beklemeyi bıraktı. Sunucunuzun döndürdüğü tam durum kodunu DNS Robot HTTP Başlık Kontrolü ile kontrol edebilirsiniz.

Hata bunun yerine bir 502 ise uygulama sağlam olabilir; sorun proxy ile uygulama arasındadır. 502 Bad Gateway rehberimiz bu durumu ele alır.

500 Hataları SEO'yu Nasıl Etkiler

Google'ın kendi belgeleri ne olduğunu anlatır (Google tarayıcı belgeleri):

• Tarama yavaşlar. 5xx hatalarında Google, siteyi tarama hızını hata döndüren URL sayısıyla orantılı olarak düşürür.
• Dizine eklenmiş sayfalar başta kalır. Zaten dizinde olan URL'ler bir süre korunur, ancak kalıcı olarak sunucu hatası döndüren URL'ler kaldırılır.
• Toparlanma kademelidir. Sunucu yeniden 2xx ile yanıt vermeye başlayınca Google taramayı yavaş yavaş artırır.
• Bir iki günlük planlı kesinti için 503 kullanın, Retry-After başlığıyla birlikte (Google); böylece kesinti geçici olarak okunur (503 rehberi).

500 Hatalarını Nasıl Önlersiniz

Önlem almak, hata ayıklamaktan her zaman daha iyidir. Web sitenizdeki 500 hatası riskini en aza indirmek için şu en iyi uygulamaları takip edin.

• Uptime izleme kurun — Sitenizi her 1-5 dakikada kontrol etmek için UptimeRobot veya Pingdom gibi araçlar kullanın. 500 hatası oluştuğunda anında uyarı alın.
• Değişiklikleri her zaman hazırlık ortamında test edin — Doğrudan üretim ortamına dağıtım yapmayın. Eklenti güncellemelerini, PHP yükseltmelerini ve yapılandırma değişikliklerini önce hazırlık ortamında test edin.
• Sürüm kontrolü (Git) kullanın — Her değişikliği kaydedin, böylece kötü bir dağıtımı tek bir komutla anında geri alabilirsiniz.
• Doğru hata yönetimi uygulayın — Veritabanı sorgularını ve API çağrılarını try-catch bloklarına sarın. Her hata için sunucu tarafında tam yığın izlemelerini kaydedin.
• Disk alanı ve sunucu kaynaklarını izleyin — Disk kullanımı %80'in üstünde, yüksek CPU ve bellek baskısı için uyarılar ayarlayın.
• Yazılımı güncel tutun — Güncellenmemiş CMS sürümleri, eklentiler ve sunucu yazılımı çökmelere neden olan bilinen hatalar içerir.
• Otomatik yedekleme yapın — Geri yükleme prosedürünüzü düzenli olarak test edin. Hiç test etmediğiniz bir yedek, yedek değildir.
• PHP limitlerini uygun şekilde ayarlayın — memory_limit ve max_execution_time'ı varsayılan değerler yerine gerçek iş yüküne göre yapılandırın.
• CI/CD hatları kullanın — Dağıtımdan önce testi otomatikleştirin. Testler başarısız olursa, dağıtım devam etmemelidir.