500 Internal Server Error Hatası Nedir, Nasıl Düzeltilir?

Siteniz dün akşam çalışıyordu, bu sabah açtığınızda karşınıza bembeyaz bir sayfa ve tek satır yazı çıkıyor: "500 Internal Server Error". Hiçbir ipucu yok, hangi dosyanın, hangi eklentinin ya da hangi ayarın sorun çıkardığına dair tek kelime bile yazmıyor. Bu yazının konusu tam olarak bu belirsizliği ortadan kaldırmak. 500 Internal Server Error hatası, sunucunun "isteğini işlerken bir şeyler ters gitti ama sana ayrıntı veremem" demesidir; ayrıntıyı vermediği yer tarayıcıdır, çünkü hata mesajını dışarıya basmak güvenlik açığıdır. Ayrıntı bir yere yazılır — sunucunun hata kaydına.

İnternette bu hatayı arayınca karşınıza çıkan Türkçe yazıların neredeyse tamamı aynı listeyi tekrar eder: sayfayı yenileyin, tarayıcı önbelleğini temizleyin, eklentileri kapatın, .htaccess dosyasını yeniden adlandırın. Bunlar deneme yanılmadır ve çoğu zaman sorunu çözmez, sadece siteyi bir süre daha kapalı tutar. Bu rehberde önce hata kaydını nasıl okuyacağınızı göstereceğim; çünkü 500 hatasında tek gerçek teşhis o satırdır. Log satırını okuduğunuzda nedenin PHP fatal hatası mı, .htaccess sözdizimi mi, dosya izni mi yoksa kaynak limiti mi olduğunu saniyeler içinde anlarsınız ve doğrudan hedefe gidersiniz.

500 Internal Server Error Ne Demek#

500 Internal Server Error, sunucunun isteği işleyemediğini ama sebebini daha spesifik bir HTTP durum kodu ile ifade edemediğini bildiren genel bir sunucu hatasıdır. HTTP durum kodlarında 4xx ailesi istemci kaynaklı hataları (yanlış adres, yetkisiz erişim), 5xx ailesi ise sunucu kaynaklı hataları temsil eder. 500 bu ailenin "genel" üyesidir; sunucu tam olarak neyin patladığını bilir ama kullanıcıya söylemez.

Bu hatayı 5xx ailesinin diğer üyeleriyle karıştırmamak önemlidir, çünkü teşhis yolları farklıdır:

Ekranda gördüğünüz metin sunucu yazılımına göre değişir: Apache genellikle "Internal Server Error" başlığıyla düz bir sayfa döndürür, Nginx "500 Internal Server Error" yazıp altına sunucu adını yazar, LiteSpeed farklı bir şablon kullanır. Metin farklı olsa da anlam aynıdır ve hepsinde teşhis yolu birdir.

Bir noktayı baştan netleştirelim: 500 hatası sizin bilgisayarınızla, tarayıcınızla ya da internet bağlantınızla ilgili değildir. Tarayıcı önbelleğini temizlemek çok nadiren işe yarar (yalnızca hatalı bir yanıt önbelleğe alınmışsa). Sorun sunucudadır ve çözüm sunucudadır.

Önce Log: Hatanın Gerçek Sebebini Nerede Bulacaksınız#

500 hatasının çözümü hata kaydını okumakla başlar; başka her adım tahmin yürütmektir. Log dosyasının yeri barındırma tipinize göre değişir.

cPanel kullanıyorsanız. Panelde Metrics → Errors ekranı son hata satırlarını gösterir; bu en hızlı yoldur. Daha ayrıntılı kayıt için Dosya Yöneticisi ile /home/kullanici/logs/ klasörüne bakın. Ayrıca PHP hataları çoğu yapılandırmada hatanın oluştuğu dizine error_log adıyla yazılır — yani public_html/wp-content/error_log gibi bir dosya arayın. Panelin hata ekranını nasıl okuyacağınızı cpanel hata kayıtları yazısında ayrıntılı anlattık.

SSH erişiminiz varsa. Kendi sunucunuzdaysanız log yolları dağıtıma göre değişir:

# Ubuntu / Debian – Apache
sudo tail -n 50 /var/log/apache2/error.log

# AlmaLinux / Rocky / CentOS – Apache
sudo tail -n 50 /var/log/httpd/error_log

# PHP-FPM havuz logu
sudo tail -n 50 /var/log/php8.2-fpm.log

# Hatayı canlı yakalamak: bu komutu çalıştırın, sonra sayfayı yenileyin
sudo tail -f /var/log/apache2/error.log

Son komut en değerli olanıdır. tail -f çalışırken tarayıcıdan hatayı veren sayfayı yenilersiniz ve o anda düşen satır tam olarak sizin isteğinize aittir. Yüz binlerce satırlık bir log dosyasında hangi satırın size ait olduğunu tahmin etmek zorunda kalmazsınız.

Hiç log göremiyorsanız. PHP hata kaydı kapalı olabilir. public_html içine geçici olarak bir .user.ini (ya da barındırma buna izin veriyorsa php.ini) dosyası koyup şu satırları ekleyin:

log_errors = On
error_log = /home/kullanici/php-hata.log
display_errors = Off
error_reporting = E_ALL

display_errors değerini canlı sitede kapalı tutun; hataları ziyaretçiye basmak dosya yollarınızı ve veritabanı yapınızı ifşa eder. Ayrıntılı ayarlar için php hata raporlama yazısına bakabilirsiniz.

error_log Satırını Okuma Rehberi#

Log satırını okumak, tahminle çözüm arama döngüsünü tek adımda bitirir. Aşağıdaki tablo, 500 hatasıyla birlikte en sık gördüğüm log satırlarını ve doğrudan işaret ettikleri sebebi eşliyor.

Satırın başındaki zaman damgasına ve sonundaki referer bilgisine de bakın; hangi sayfadan tetiklendiğini gösterir. Şimdi bu sebepleri sırayla ele alalım.

Sebep 1: PHP Fatal Error#

500 hatalarının açık ara en yaygın nedeni PHP tarafındaki ölümcül hatalardır. Log satırı genellikle şuna benzer:

[Mon Aug 11 09:14:22 2026] PHP Fatal error:  Uncaught Error: Call to a member function get_results() on null in /home/site/public_html/wp-content/plugins/ornek-eklenti/inc/rapor.php:88

Bu satır size üç şeyi birden söyler: dosya yolu, satır numarası ve hatanın türü. Sorun ornek-eklenti içindedir; başka hiçbir yere bakmanıza gerek yoktur. FTP ya da Dosya Yöneticisi ile o eklentinin klasörünü ornek-eklenti-kapali olarak yeniden adlandırın; WordPress eklentiyi bulamayınca otomatik olarak devre dışı bırakır ve site açılır.

Bellek hatası ise farklı görünür:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

Buradaki sayı bayt cinsindendir; 134217728 tam olarak 128 MB'dir. Limiti artırmak için wp-config.php içine ilgili satırı eklemek ya da .user.ini ile memory_limit değerini yükseltmek gerekir. Ancak dikkat: 128 MB normal bir WordPress kurulumu için fazlasıyla yeterlidir. Limiti sürekli dolduran bir eklenti varsa asıl sorun limitin düşüklüğü değil, o eklentinin verimsizliğidir. Bu ayrımı allowed memory size exhausted hatası yazısında ayrıntılı ele aldık.

Uzun süren işlemlerde ise Maximum execution time hatası görürsünüz; bu genellikle içe aktarma, yedekleme veya toplu güncelleme işlemlerinde çıkar ve çözümü limiti kalıcı yükseltmek değil, işlemi parçalara bölmektir.

Sebep 2: .htaccess Sözdizimi ve Desteklenmeyen Direktif#

.htaccess dosyasındaki tek bir hatalı satır tüm siteyi 500 hatasına düşürür, çünkü Apache dosyayı okuyamadığında isteği hiç işlemez. Log satırı tam olarak sorunlu satırı verir:

[core:alert] [pid 20411] /home/site/public_html/.htaccess: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration

Bu satır çok net bir şey söylüyor: php_value direktifi bu sunucuda tanımlı değil. Bu direktif Apache mod_php ile çalışır; sunucu PHP-FPM ya da LiteSpeed kullanıyorsa geçersizdir ve PHP ayarlarını .user.ini ile vermeniz gerekir.

Test etmenin en hızlı yolu dosyayı devre dışı bırakmaktır:

mv .htaccess .htaccess.yedek

Site açılıyorsa sebep kesinleşmiştir. Şimdi dosyayı geri alın ve içeriği ikiye bölerek hangi bloğun soruna yol açtığını daraltın. WordPress kullanıyorsanız çekirdek blok şudur ve güvenle bu hâle döndürebilirsiniz:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bir püf noktası: özel direktifleri <IfModule> bloğu içine almak, ilgili modül yoksa satırın sessizce atlanmasını sağlar ve 500 hatasını önler. Yönlendirme kurallarını doğru yazmak için htaccess yönlendirme yazısındaki örneklerden yararlanabilirsiniz; kuralı yayına almadan önce htaccess yönlendirme üretici aracıyla sözdizimini kontrol etmek de iyi bir alışkanlıktır.

Sebep 3: Dosya ve Dizin İzinleri#

İzin kaynaklı 500 hataları özellikle suPHP veya benzeri bir yürütme modeli kullanan paylaşımlı sunucularda görülür ve log satırı çok karakteristiktir:

SoftException in Application.cpp:357: UID of script "/home/site/public_html/index.php" is smaller than min_uid
SoftException in Application.cpp:267: File "/home/site/public_html/wp-config.php" is writeable by group

İkinci satır sık yanlış anlaşılır: sorun dosyanın yazılamaz olması değil, fazla geniş yetkiye sahip olmasıdır. Grup ya da herkes için yazma izni verilmiş bir PHP dosyasını suPHP çalıştırmayı reddeder. Doğru izinler şunlardır:

# Dizinler 755, dosyalar 644
find /home/site/public_html -type d -exec chmod 755 {} \;
find /home/site/public_html -type f -exec chmod 644 {} \;

# Yapılandırma dosyası daha sıkı olabilir
chmod 600 /home/site/public_html/wp-config.php

777 izni asla kullanmayın. Bir eğitim videosunda "izin sorununu 777 ile çöz" tavsiyesini gördüyseniz unutun; hem 500 hatasının kendisine yol açar hem de sunucuya yüklenen bir zararlı dosyanın çalışmasına kapı açar. İzin modelinin mantığını linux dosya izinleri yazısında adım adım anlattık.

Sahiplik de aynı derecede önemlidir. Dosyaları root olarak kopyaladıysanız sahiplikleri düzeltmeniz gerekir:

chown -R site:site /home/site/public_html

Sebep 4: PHP Sürümü ve Eksik Eklenti#

Sürüm uyumsuzluğu, hiçbir şeye dokunmadığınız hâlde çıkan 500 hatalarının en sinsi sebebidir. Barındırma sağlayıcısı PHP sürümünü yükselttiğinde, eski bir tema veya eklenti artık kaldırılmış bir söz dizimini kullanıyorsa site anında çöker. Log satırı şuna benzer:

PHP Parse error: syntax error, unexpected 'new' (T_NEW) in /home/site/public_html/wp-content/themes/eski-tema/functions.php on line 42
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect()

İkinci satır klasiktir: mysql_ fonksiyon ailesi modern PHP sürümlerinde yoktur, kod mysqli_ veya PDO kullanacak şekilde güncellenmelidir.

Eksik eklenti hatası da aynı biçimde görünür — Call to undefined function curl_init(), imagecreatefromjpeg(), mb_strlen() gibi. Bunlar sırasıyla cURL, GD ve mbstring eklentilerinin kurulu olmadığını söyler. cPanel'de Select PHP Version ekranından ilgili eklentiyi işaretleyip kaydetmek yeterlidir; hangi eklentinin ne işe yaradığını cpanel php eklenti seçimi yazısında listeledik.

Sürüm değiştirmeden önce mevcut sürümü doğrulayın:

php -v
php -m | grep -E 'curl|gd|mbstring|mysqli'

Sürüm düşürmek geçici bir çare olabilir ama kalıcı çözüm değildir; desteği biten bir PHP sürümünde kalmak güvenlik güncellemesi almamak anlamına gelir.

Sebep 5: Kaynak Limitleri ve 508 ile Karışması#

Paylaşımlı barındırmada hesabınız CPU, bellek veya eşzamanlı işlem limitine takıldığında da 500 hatası alabilirsiniz. Log satırında Resource temporarily unavailable, LVE, cgroup gibi ifadeler geçiyorsa sebep budur. Bazı sunucular bu durumda 500 yerine daha açıklayıcı olan 508 resource limit is reached hatası kodunu döndürür.

Kaynak limitine takılmanın en yaygın sebepleri şunlardır: bir bot taraması sitenizi eşzamanlı yüzlerce istekle döver, ağır bir rapor sorgusu veritabanını kilitler, yedekleme eklentisi tüm siteyi tek seferde arşivlemeye çalışır, ya da başlangıç için doğru olan bir paketten çıkmışsınızdır ve trafiğiniz paketin sınırlarını aşmıştır. cPanel'de Resource Usage ekranı hangi limite ne sıklıkta takıldığınızı grafikle gösterir; oradaki "faults" sütununda sıfırdan farklı bir sayı varsa sorunu doğrulamış olursunuz.

Bu durumda yapılacak sıralama şudur: önce ağır işlemleri gece saatlerine alın veya parçalara bölün, sonra önbellekleme kurun, sonra bot trafiğini sınırlayın. Bunların hiçbiri yetmiyorsa artık paket yükseltmenin ya da izole kaynaklı bir sunucuya geçmenin zamanı gelmiştir.

WordPress'te 500 Hatası: WP_DEBUG ile Kaynağı Bulma#

WordPress kullanıyorsanız ve sunucu logunu göremiyorsanız, WordPress'in kendi hata kaydını açabilirsiniz. wp-config.php dosyasında /* That's all, stop editing! */ satırının üstüne şunları ekleyin:

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

Bu ayarlarla hatalar ziyaretçiye gösterilmez, wp-content/debug.log dosyasına yazılır. Sayfayı bir kez yenileyip o dosyayı açın; sorunlu eklentinin adı ve satır numarası orada olacaktır. İşiniz bittiğinde WP_DEBUG değerini false yapmayı unutmayın — açık bırakılan bir debug logu zamanla gigabaytlara ulaşır ve disk kotanızı doldurur.

Panele hiç giremiyorsanız eklentileri toplu devre dışı bırakmanın en hızlı yolu FTP ile wp-content/plugins klasörünü plugins-kapali olarak yeniden adlandırmaktır. Site açılırsa sebep eklentilerdedir; klasörün adını geri alıp eklentileri tek tek yeniden adlandırarak suçluyu bulursunuz. Aynı yöntem tema için de geçerlidir: wp-content/themes içinde aktif temanın adını değiştirin, WordPress varsayılan temaya döner. Beyaz ekranla birlikte gelen varyasyonları wordpress beyaz ekran hatası yazısında topladık.

Hatayı Bir Daha Yaşamamak İçin#

500 hatasını çözmek kadar önemli olan, aynı hatanın yayında tekrarlanmasını engellemektir. Yıllardır gördüğüm en etkili dört alışkanlık şunlar:

1. Güncellemeleri önce test ortamında yapın. Eklenti ve PHP sürümü güncellemelerini canlı sitede denemek, 500 hatalarının en yaygın tetikleyicisidir. Bir kopya ortam kurmak yarım saatlik iştir ve kesinti maliyetinden çok daha ucuzdur.
2. Otomatik yedek alın ve geri dönüşü test edin. Yedeğin varlığı değil, geri yüklenebilirliği önemlidir. Hiç denenmemiş bir yedek yedek sayılmaz.
3. Hata kaydını düzenli kontrol edin. 500 hatası genellikle bir anda oluşmaz; günlerdir logda biriken uyarıların ardından gelir. Haftada bir loga bakmak, hatayı ziyaretçilerden önce görmenizi sağlar.
4. İzleme kurun. Site kapandığında bunu ilk öğrenen kişi siz olmalısınız. Basit bir kesinti izleme aracı, hatayı ziyaretçi şikâyetiyle öğrenmenin önüne geçer.

Bir de log dosyalarının kendisi büyür; logrotate yapılandırması olmayan bir sunucuda error_log dosyası diski doldurabilir ve o zaman bambaşka hatalarla uğraşırsınız.

Sıkça Sorulan Sorular#

500 Internal Server Error sitemi mi yoksa bilgisayarımı mı ilgilendirir#

Hata tamamen sunucu tarafındadır ve sizin bilgisayarınızla ilgisi yoktur. Tarayıcı sadece sunucunun gönderdiği durum kodunu gösterir; önbellek temizlemek, farklı tarayıcı denemek veya modemi yeniden başlatmak sonucu değiştirmez. Sayfayı başka bir cihazdan ve mobil veriden açtığınızda da aynı hatayı görüyorsanız bu doğrulanmış olur. Çözüm barındırma hesabınızın hata kaydında aranmalıdır.

Hata kaydını cPanel'de nerede bulurum#

cPanel ana ekranındaki Metrics bölümünde yer alan Errors sayfası en son hata satırlarını gösterir ve ilk bakılacak yer burasıdır. Daha ayrıntılı kayıt için Dosya Yöneticisi ile logs klasörüne, PHP hataları içinse hatanın oluştuğu dizindeki error_log dosyasına bakmanız gerekir. Gizli dosyaların görünmesi için Dosya Yöneticisi ayarlarından "Show Hidden Files" seçeneğini açmayı unutmayın. Log hiç oluşmuyorsa PHP tarafında hata kaydı kapalı demektir ve log_errors ayarını açmanız gerekir.

.htaccess dosyasını silmek zararlı olur mu#

Dosyayı silmek yerine yeniden adlandırmak her zaman daha güvenlidir, çünkü içindeki yönlendirme ve güvenlik kuralları kaybolmaz. .htaccess dosyasını .htaccess.yedek yapıp siteyi test edin; açılıyorsa sebep bu dosyadadır ve içeriği parça parça geri ekleyerek sorunlu satırı bulabilirsiniz. WordPress kullanıyorsanız dosya yoksa Ayarlar bölümündeki kalıcı bağlantı ayarlarını yeniden kaydettiğinizde temel blok otomatik yeniden oluşur. Dosyayı tamamen silerseniz özel yönlendirmeleriniz ve erişim kısıtlamalarınız da gider.

500 hatası ile 502 ve 503 arasındaki fark nedir#

500 sunucunun isteği işlerken karşılaştığı genel bir hatadır ve neredeyse her zaman uygulama katmanındaki bir sorunu işaret eder. 502 ise bir ters vekil sunucunun arkasındaki servisten geçersiz yanıt aldığını, yani PHP-FPM gibi bir bileşenin çökmüş ya da ulaşılamaz olduğunu gösterir. 503 servisin geçici olarak kullanılamadığını söyler ve genellikle bakım modu ya da kaynak doygunluğu anlamına gelir. Üçünün de log dosyaları farklı yerlerde olabilir, bu yüzden önce kodu doğru okumak gerekir.

Sitem sadece belirli sayfalarda 500 veriyor, neden#

Hatanın tüm siteyi değil belirli sayfaları etkilemesi, sebebin genel bir yapılandırma değil o sayfaya özgü bir kod veya sorgu olduğunu gösterir. En yaygın senaryolar şunlardır: sadece o sayfada çalışan bir eklenti ölümcül hata veriyordur, o sayfanın veritabanı sorgusu bellek limitini dolduruyordur ya da o adrese özel bir yönlendirme kuralı hatalıdır. Hata kaydındaki referer ve dosya yolu bilgisi hangi bileşenin sorumlu olduğunu doğrudan söyler. Yönetim paneli çalışıyor ama ön yüz çalışmıyorsa şüpheyi önce tema dosyalarına yöneltin.

PHP memory_limit değerini artırmak kalıcı çözüm müdür#

Genellikle değildir, çünkü bellek limitini dolduran neredeyse her zaman verimsiz çalışan bir kod parçasıdır. Standart bir kurumsal site ya da blog, makul bir bellek limitiyle rahatlıkla çalışır; limiti sürekli artırmak zorunda kalıyorsanız asıl sorun hangi eklentinin ne kadar bellek tükettiğidir. Geçici olarak limiti yükseltip siteyi ayağa kaldırmak doğru bir ilk adımdır, ancak ardından hata kaydından o işlemi bulup optimize etmek gerekir. Aksi hâlde birkaç hafta sonra aynı hatayı daha yüksek bir limitte tekrar görürsünüz.

Hiçbir şey değiştirmediğim hâlde neden 500 hatası aldım#

Bu durumun en yaygın üç sebebi vardır: barındırma tarafında PHP sürümünün yükseltilmesi, otomatik güncellenen bir eklentinin yeni sürümünün uyumsuz çıkması ve hesabın kaynak limitine takılması. Üçü de sizin bir işlem yapmanızı gerektirmez, bu yüzden "hiçbir şeye dokunmadım" hissi doğrudur. Hata kaydındaki zaman damgasını sağlayıcının bakım bildirimleriyle ve eklenti güncelleme geçmişinizle karşılaştırmak sebebi çoğunlukla dakikalar içinde ortaya çıkarır. Trafiğin ani yükseldiği saatlerde ortaya çıkan hatalarda ise ilk bakılacak yer kaynak kullanım grafiğidir.

Hata kaydında hiçbir satır yoksa ne yapmalıyım#

Log dosyasının boş olması, hata kaydının kapalı olduğu ya da yanlış dosyaya baktığınız anlamına gelir. Önce PHP tarafında log_errors ayarının açık ve error_log yolunun yazılabilir bir dizini gösterdiğinden emin olun. Ardından tail -f ile logu canlı izleyip sayfayı yenileyin; satır o an düşmüyorsa istek PHP'ye hiç ulaşmıyor demektir ve sorun web sunucusu katmanındadır, yani .htaccess ya da sanal sunucu yapılandırmasındadır. Bu durumda Apache veya Nginx'in kendi hata dosyasına bakmanız gerekir.

Kapanış#

500 Internal Server Error korkutucu görünse de aslında en kolay teşhis edilen hatalardan biridir; tek şartı doğru yere bakmaktır. Tarayıcı size hiçbir şey söylemez, ama sunucunun hata kaydı sorunun dosya yolunu ve satır numarasını verir. tail -f ile logu açıp sayfayı yenilemek, saatlerce süren deneme yanılmanın yerini alan tek adımdır. Log satırını okuduktan sonra bu yazıdaki eşleştirme tablosu sizi doğrudan doğru bölüme götürür: PHP fatal hatası, .htaccess sözdizimi, dosya izni, eksik eklenti ya da kaynak limiti. Beş sebep dışında bir şey neredeyse hiç çıkmaz.

Sorunun kaynağı kaynak yetersizliğine dayanıyorsa ya da hata kaydını okuyup düzeltmeyi kendiniz üstlenmek istemiyorsanız birkaç yol var. Trafiğinizin büyüdüğü ve paylaşımlı kaynakların yetmediği bir noktadaysanız hosting paketleri arasından daha geniş kaynaklı bir plana geçmek ya da izole kaynak veren VDS sunucu tarafına taşınmak kalıcı çözümdür. WordPress kaynaklı tekrarlayan hatalarda güncelleme, yedek ve hata takibini düzenli olarak üstlenen WordPress bakım hizmeti bu döngüyü tamamen ortadan kaldırır; sunucu tarafındaki log, izin ve PHP yapılandırması işlerini devretmek isterseniz sunucu yönetimi hizmeti bu işi sizin adınıza yürütür.