HTTP 404 ve 500 Hatası Arasındaki Fark Nedir? Teşhis Rehberi

HTTP 404 ve 500 hatası arasındaki fark, sorunun hangi tarafta başladığıyla ilgilidir. 404, istenen kaynağın sunucuda bulunamadığını gösterir. 500 ise sunucunun isteği işlerken beklenmeyen bir hata yaşadığını gösterir.

İlkinde adrese, yönteme ya da kaynağın varlığına bakarsın. İkincisinde ise çoğunlukla sunucu tarafındaki kodun ve kayıtların incelenmesi gerekir.

404 ve 500 aynı şey değil: durum kodu neyi söyler?

Durum kodu, sunucunun bir isteğe verdiği yanıtın sonucunu istemciye bildiren üç basamaklı bir sayıdır. İlk basamak yanıtın sınıfını belirler. HTTP standardını tanımlayan RFC 9110'a göre 4xx sınıfı, istemcinin hata yapmış göründüğü durumlar içindir. 5xx sınıfı ise sunucunun hata yaptığını fark ettiği ya da isteği yerine getiremediği durumlar içindir.

Buradaki "göründüğü" ifadesi önemlidir. Bir 4xx yanıtı her zaman kullanıcının hatası demek değildir. Geliştiricinin yanlış yazdığı bir adres ya da eksik tanımlanmış bir rota da 404 üretebilir.

Tablo bir başlangıç noktasıdır. Aynı kod farklı sistemlerde farklı nedenlerle dönebilir, bu yüzden tek başına kesin teşhis sayılmaz.

404 Not Found: aranan kaynak bulunamadığında ne olur?

404, sunucuya ulaşıldığını ama hedef kaynak için geçerli bir temsil bulunamadığını gösterir. Sık görülen nedenler şunlardır:

• Adresin yanlış yazılması
• Sunucuda tanımlı olmayan bir rota istenmesi
• Yanlış yol parçası, örneğin /api/users yerine /api/user
• Kaynağın silinmesi ya da taşınması
• Eksik ya da bozuk yönlendirme
• Özel karakterlerin yanlış kodlanması

Boşluk ve Türkçe karakter içeren yol parçaları son maddeye iyi bir örnektir. Bu karakterlerin adreste nasıl göründüğünü URL kodlama ve çözme aracıyla deneyebilirsin. Kodlanmış hâl ile sunucunun beklediği hâl uyuşmuyorsa istek 404 ile dönebilir.

Aşağıdaki iki hatalı adres ve doğru adres yan yana durunca fark görünür. Yanıt kodları, /api/users/{id} rotası tanımlı olan ve 42 numaralı kaydı bulunan bir uygulama varsayılarak yazılmıştır:

GET /api/user/42     -> 404 (rota tanımlı değil)
GET /api/users/9999  -> 404 (rota doğru, bu numaralı kayıt yok)
GET /api/users/42    -> 200 (rota ve kayıt mevcut)

İki hatalı istek aynı kodu döndürür ama nedenleri farklıdır. Bu yüzden yanıt gövdesine de bakmak gerekir. Bir 404 yanıtı gövdesinde şuna benzer bir JSON taşıyabilir:

{
  "status": 404,
  "message": "Kaynak bulunamadı",
  "path": "/api/user/42"
}

Bu şema standart değildir; alan adları uygulamadan uygulamaya değişir. Yine de ortak bir fikir taşır: yanıt, hangi yolun istendiğini söyler. Bu noktada şu soruyu sor: Bu adres, bu yöntemle, bu sunucuda tanımlı mı?

İki sınır durumu da bilmek gerekir. RFC 9110'a göre sunucu, bir kaynağın var olduğunu açıklamak istemediğinde de 404 döndürebilir. Yani 404 her zaman "gerçekten yok" anlamına gelmez. Ayrıca kod, durumun geçici mi kalıcı mı olduğunu kendi başına söylemez. Sunucu bir kaynağın kalıcı olarak kalktığını biliyorsa standart bunun için 410 Gone kodunu tercih eder.

500 Internal Server Error: sunucu isteği işlerken takıldığında

500, sunucunun isteği yerine getirmesini engelleyen beklenmeyen bir durumla karşılaştığını bildirir. RFC 9110 bu kodu tam olarak böyle tanımlar. İstek geçerli olsa bile oluşabilir. Bazen de beklenmedik bir istek verisi sunucu kodundaki bir hatayı tetikler. Yine de kod tek başına kesin teşhis sayılmaz, yalnızca bakılacak yeri daraltır.

Sık görülen nedenler şunlardır:

• Yakalanmamış (işlenmemiş) bir istisna
• Yanlış ya da eksik yapılandırma
• Veritabanına ya da başka bir servise bağlanamama
• Kodun beklemediği bir boş değerle karşılaşması

Log ile nedeni bulmak

1. Hatanın oluştuğu zamana göre uygulama günlüğünü (log) bul.
2. Yığın izinin (stack trace) ilk satırlarını oku: hata türü ve mesajı en üstte, kodun hangi satırında patladığı hemen altında yer alır.
3. Aynı isteği tekrar gönder ve yeni log satırını isteğinle eşleştir.

Yığın izini ya da iç ayrıntıları yanıt gövdesinde kullanıcıya göstermek güvenlik riski taşır, çünkü dosya yolları ve sistem bilgileri saldırgana ipucu verebilir. Ayrıntı log'da kalmalı, istemciye genel bir mesaj ile izlenebilir bir kimlik gitmelidir:

{
  "hata": "Beklenmeyen bir sunucu hatası oluştu",
  "istek_id": "a1b2c3"
}

Bu istek_id değerini log içinde aratarak ilgili kaydı doğrudan bulabilirsin.

Hangi soruyu sormalıyım? Sunucu bu isteği işlerken tam olarak hangi satırda neden başarısız oldu?

Tarayıcıda Network sekmesinde durum kodu nasıl okunur?

Sekme ve alan adları tarayıcıya ve sürüme göre biraz değişebilir, ama temel akış aynıdır:

1. Sayfada F12'ye bas ya da sağ tıklayıp "İncele"yi seç.
2. Network (Ağ) sekmesini aç.
3. Sayfayı yeniden yükle ki istekler listelensin.
4. Durum sütununda 4xx ya da 5xx görünen satıra tıkla.

Ayrıntı panelinde şu alanlara bak: Status (durum kodu), Request URL (istek adresi), Request Method (yöntem) ve Response ya da Preview sekmesindeki yanıt gövdesi. Adresteki küçük bir yazım hatası 404'ün, gövdedeki mesaj ise 500'ün nedenine dair ilk ipucu olabilir.

Aynısını kodla görmek

Tarayıcı konsolunda şu fonksiyonu deneyebilirsin:

async function kontrolEt(adres) {
  const res = await fetch(adres);
  const metin = await res.text();
  console.log(res.status, res.ok, metin);
}

kontrolEt("/api/urunler/999");

Adres bulunamıyorsa ve sunucu yukarıdaki gibi bir gövde döndürüyorsa konsolda şuna benzer bir satır görürsün:

404 false {"hata":"Kaynak bulunamadı"}

Sunucu tarafında hata varsa çıktı şöyle olabilir:

500 false {"hata":"Beklenmeyen bir sunucu hatası oluştu","istek_id":"a1b2c3"}

Dikkat edilecek nokta şu: fetch, 404 ve 500 gibi HTTP hata yanıtlarında hata fırlatmaz. Söz (promise) yalnızca ağ düzeyindeki bir sorunda reddedilir. HTTP hata kodlarını yakalamak için res.ok değerini kendin kontrol etmelisin. Bu değer 200-299 aralığındaki durum kodlarında true, diğerlerinde false olur.

Sıralı teşhis listesi: istemciden yanıt gövdesine altı adım

Bir hata kodu gördüğünde isteğin izlediği yolu istemciden başlayıp yanıt gövdesine kadar sırayla kontrol edebilirsin. Her adımda 404 ile 500'ü ayıran tek bir soru sor.

1. İstemci: İstek doğru yöntemle (GET, POST gibi) ve doğru taraftan mı gönderiliyor? Ayırt edici soru: İstek sunucuya ulaşıp bir yanıt aldı mı? Bazı sunucular yöntem yanlışsa 404 döndürebilir, bu yüzden yöntemi de kontrol et.
2. URL: Yol, sorgu parametreleri ve özel karakterlerin kodlaması doğru mu? Ayırt edici soru: Adreste yazım hatası ya da bozuk kodlama var mı? Bu durum 404'te sık görülür, 500'de nadirdir.
3. Yönlendirme: 301 kaynağın kalıcı olarak başka adrese taşındığını, 302 ise geçici olarak başka adreste bulunduğunu bildirir. Ayırt edici soru: Yönlendirme zinciri nereye gidiyor ve son hedef gerçekten var mı? Zincirin sonunda 404 çıkıyorsa asıl sorun hedef adrestedir.
4. Sunucu rotası: İstenen yol ve yöntem için tanımlı bir işleyici var mı? Ayırt edici soru: Rota hiç tanımlı değil mi, yoksa tanımlı olup çalışırken mi çöküyor? Rota yoksa genellikle 404, rota varken işleyici çöküyorsa genellikle 500 beklenir.
5. Uygulama günlüğü: Hatanın oluştuğu saniyede bir istisna, veri tabanı bağlantı hatası ya da zaman aşımı kaydı var mı? Ayırt edici soru: Günlükte bu isteğe ait bir hata izi görünüyor mu? 500'de en belirleyici adım budur. İstek günlükte hiç yoksa takıldığı yer bir ağ geçidi ya da vekil sunucu gibi başka bir katman olabilir.
6. Yanıt gövdesi: Hata mesajı ve varsa istek kimliği ne diyor? Ayırt edici soru: Mesaj "bulunamadı" mı diyor, yoksa içeride bir şeyin ters gittiğini mi? İstek kimliğini günlükte aratırsan doğrudan ilgili kayda ulaşabilirsin.

Hata kodu tek başına kesin teşhis değildir. Yalnızca aramayı daraltan bir ipucudur ve kanıtı ancak bu adımlardan elde edersin.

Bir kodu diğerine dönüştürmek neden yanıltıcı?

Bulunamayan bir kaynak için 500 dönersen, sunucu hatası izleyen sistemler yanlış alarm üretir ve ekip var olmayan bir arızayı aramaya başlar. Sunucu çöktüğünde 404 ya da 200 dönersen gerçek arıza sessizce gizlenir. İstemci de buna göre yanlış karar verir: geçici bir 5xx hatasında yeniden denemek mantıklı olabilirken kalıcı bir 404'te aynı isteği tekrarlamak boşuna yük bindirir. Arama motorları ve önbellekler de kodu yorumlayarak davranır, yanlış kod onları yanlış yönlendirir.

Her şeyi 200 ile dönüp hatayı gövdeye yazmak da sorunludur. Durum kodunu okuyan araçlar, önbellekler ve istemci kütüphaneleri başarılı bir yanıt görür ve gövdeyi çözmeden hatayı fark edemez. Bu etkiler genel ilke olarak geçerlidir; kesin davranış istemciye ve altyapıya göre değişebilir.

Doğru yaklaşım üç adımdan oluşur: kodu olayın gerçek niteliğine göre seç, gövdede ayrıntı ve izlenebilirlik (örneğin istek kimliği) sağla, hata teşhisini yalnızca koda bırakma. İstemci-sunucu mantığını ne kadar kavradığını görmek istersen ücretsiz bilgi testleri ile seviyeni ölçebilirsin.

Sık Sorulan Sorular

500 hatasını ziyaretçi olarak düzeltebilir miyim?

Genellikle hayır, çünkü sorun çoğunlukla sunucu tarafındadır. Sayfayı yenileyebilir, biraz sonra tekrar deneyebilir ve girdiğin bilgileri kontrol edebilirsin. Hata kalıcıysa site sahibine bildirmek en doğrusudur.

404 ile 403 arasındaki fark nedir?

404 kaynağın bulunamadığını gösterir. 403 ise sunucunun isteği anladığını ama erişime izin vermediğini belirtir. Bazı sistemler bir kaynağın varlığını gizlemek için yetkisiz isteklere 403 yerine bilerek 404 döndürebilir.

Aynı adres bazen 404 bazen 500 dönüyorsa neden olabilir?

Birkaç neden olabilir: yük dengeleyicinin arkasında farklı sürümlerde çalışan sunucular, tutarsız bir dağıtım, önbellekteki eski yanıtlar ya da isteğe göre değişen veriler ve bağımlılık hataları. Bu durumda her yanıtın istek kimliğini ve zamanını not edip günlüklerle eşleştirmek işe yarar.

502 ve 503 gibi diğer 5xx kodları 500 ile aynı anlama mı gelir?

Hepsi sunucu tarafı hata sınıfındadır ama anlamları farklıdır. 500 genel bir iç hatadır. 502, bir ağ geçidi ya da vekilin üst sunucudan geçersiz yanıt aldığını, 503 ise sunucunun isteği geçici olarak karşılayamadığını (bakım ya da aşırı yük gibi) gösterir.

Durum kodları tek başına cevap vermez ama doğru soruyu sormanı sağlar. 404'te kaynağı ve yolu, 500'de işleyiciyi ve günlüğü incelemek seni çoğu zaman daha hızlı çözüme götürür.