500 Internal Server Error: Nedenleri, Günlükler ve 502'den Farkı

500 size neden bu kadar az şey söyler

RFC 9110, 500'ü sunucunun isteği yerine getirmesini engelleyen beklenmedik bir durum olarak tanımlar. Bu kasıtlı olarak geniştir. Uygulamanın öngörmediği her şey, boş bir referanstan başarısız bir veritabanı bağlantısına, ayrıştıramadığı bir yapılandırma dosyasına kadar, aynı numaranın altında toplanır.

Belirsizlik aynı zamanda bir güvenlik özelliğidir. Bir 500 sayfası, yığın izlerini (stack trace), dosya yollarını, SQL parçalarını veya kütüphane sürümlerini halka asla sızdırmamalıdır, çünkü bunlar tam olarak bir saldırganın istediği ayrıntılardır. Bu yüzden kod yanıtta genel kalır, ve ayrıntı yalnızca sizin okuyabileceğiniz bir günlüğe gider. Bu takas doğrudur, ve diğer her şeyden daha yararlı olan tek bir bilgiyi ortaya çıkarır: günlüklerinizin nerede tutulduğu.

500'ün 502, 503 ve 504 ile karşılaştırması

Dördü de sunucu hatasıdır, ama farklı bileşenler tarafından üretilirler ve farklı sorunlara işaret ederler. Bunu doğru yapmak, hata ayıklama süresinin çoğunu kazandırır.

• 500 uygulamanın kendisinden gelir. Bir şey çalıştı ve bir istisna fırlattı. Uygulama günlüğünde bir yığın izi vardır.
• 502 uygulamanın önündeki, arka uçtan geçersiz bir yanıt veya kapatılmış bir bağlantı alan bir vekil sunucudan gelir. Arka uç genellikle hiçbir şey kaydetmez, çünkü isteği hiç tamamlamamıştır. Bkz. 502 rehberi.
• 503 bir çökme değil, bir rettir. Sunucu aşırı yüklüdür veya bakımdadır ve genellikle bir Retry-After ile kasıtlı olarak işi reddediyordur.
• 504 bir zaman aşımıdır. Arka uça erişilebiliyordu ama vekil sunucunun sınırı içinde yanıt vermedi. İstek genellikle perde arkasında hala çalışıyordur.

Kaba bir kısayol: 500 kodunuzun bozulduğu, 502 arka ucunuzun öldüğü veya kötü davrandığı, 503 sunucunuzun kasıtlı olarak hayır dediği, 504 arka ucunuzun çok yavaş olduğu anlamına gelir. Tüm aile 5xx genel bakışında karşılaştırılır.

Bir 500'e neyin neden olduğu

• Uygulama kodundaki işlenmeyen istisnalar. En büyük tek kategori. Boş bir değer, başarısız bir tür dönüşümü, aralık dışı bir dizi indeksi, kimsenin test etmediği bir yolda sıfıra bölme.
• Veritabanı hataları. Bağlantı havuzu tükenmiş, kimlik bilgileri döndürülmüş, veritabanı yeniden başlatılmış, kilitlenen veya zaman aşımına uğrayan bir sorgu.
• Bir dağıtımdan sonra eksik veya bozuk bağımlılıklar. Kurulmayan bir paket, derlemenin kopyalamadığı bir dosya, hazırlık ortamında var olup üretimde olmayan bir ortam değişkeni.
• Yapılandırma söz dizimi hataları. Apache'de, bir .htaccess dosyasındaki tek bir geçersiz yönerge, o dizin altındaki her istek için 500 üretir.
• Dosya izinleri ve sahiplik. Uygulama bir yapılandırma dosyasını okuyamıyor veya bir önbellek, oturum ya da yükleme dizinine yazamıyor.
• Kaynak sınırları. Bir bellek sınırı, bir yürütme süresi sınırı veya dolu bir disk. Bunlar tipik olarak trafiği izleyen aralıklı 500'ler üretir.
• Kodun geri dönüş planı olmadan çağırdığı üçüncü taraf API hataları; böylece uzak bir kesinti sizin hata sayfanız haline gelir.

Bir 500 nasıl teşhis edilir

1. Kodu ve onu kimin ürettiğini doğrulayın. Markalı bir hata sayfası gerçek durumu gizleyebilir:

   curl -sS -o /dev/null -D - https://example.com/failing-page

   Durum satırını ve herhangi bir Server veya CDN başlığını kontrol edin. Hata bir uç ağ tarafından imzalanmışsa ve kaynak 200 yanıtı veriyorsa, uygulamanızdan gelen bir 500'e hiç bakmıyorsunuzdur.
2. Önce uygulama günlüğünü açın. Yığın izinin bulunduğu yer burasıdır. Çerçeve günlükleri, platform günlük akışı veya konteynerin standart çıktısı, yığınınız hangisini kullanıyorsa, ve zaman damgası ile istek yoluna göre eşleştirin.
3. Ardından web sunucusu hata günlüğü. Apache error_log, nginx error.log, veya IIS için Windows Olay Günlüğü. Uygulama hiçbir şey kaydetmediyse, hata kodunuz çalışmadan önce gerçekleşmiştir; bu da yapılandırmaya veya çalışma zamanına işaret eder.
4. Kasıtlı olarak yeniden üretin. 500'ün tek bir URL'yi, tek bir HTTP yöntemini, tek bir kullanıcıyı mı yoksa her şeyi mi etkilediğini belirleyin. Yalnızca POST'ta bir 500, genellikle form işleme veya bir yazma yolu anlamına gelir. Tek bir kullanıcı için bir 500, genellikle onların verisi anlamına gelir.
5. Herkese açık olmayan bir ortamda ayrıntılı hataları açın. Asla üretimde değil. Tam hata çıktısıyla hazırlık ortamında yeniden üretin; bu genel bir 500'ü belirli bir satır numarasına çevirir.
6. Neyin değiştiğini kontrol edin. Son dağıtım, bir yapılandırma gönderimi, bir sertifika yenilemesi, bir bağımlılık güncellemesi veya bir veritabanı geçişi. Site bir saat önce sorunsuzsa, yanıt neredeyse her zaman son değişikliktedir.
7. Ana bilgisayar kaynaklarını kontrol edin. Disk alanı, bellek ve bağlantı sayıları. Günlüklerle dolan bir disk, koddan tamamen ilgisiz görünen 500'ler üretir.

Yalnızca bir sayfanın döndürdüğü 500'ler

Çoğu 500 tüm siteyi çökertmez. Ana sayfa yüklenmeye devam ederken tek bir rota, tek bir form veya tek bir bölge bozulur; bu yüzden dışarıdan hiçbir şey yanlış görünmez ve hatalar günler sonra kaybedilen kayıtlar olarak ortaya çıkar. Yalnızca ana sayfada değil, önemli olan sayfalarda zamanlanmış bir HTTP kontrolü, döndürülen kodu beklenenle karşılaştırır ve bir rota 500 vermeye başladığı anda uyarır. Uyarılar e-posta, SMS, sesli arama, Slack, Telegram ve daha fazlasıyla gelebilir, bu yüzden gece yarısı bir hata, sabahı beklemek yerine nöbetçi olan kişiye ulaşır. HostTracker 2004'ten beri web sitelerini izliyor.