Çoğu satıcı 500 hatasını gördüğünde ilk olarak hosting firmasını arar ve "sunucunuzda sorun var" der. Karşı taraf logları kontrol eder, sunucunun ayakta olduğunu söyler, iş orada tıkanır. Oysa 500 hatası sunucunun çöktüğü anlamına gelmez. Tam tersine, sunucu gayet iyi çalışıyordur; sadece uygulaman ona anlamadığı bir şey söylemiş, o da tarayıcıya nazikçe "içeride bir sorun oldu" diye dönmüştür.
Yani 500, bir hata değildir; susturulmuş bir hata mesajıdır. Gerçek cümle bir yerde yazılıdır, sadece sana gösterilmez. Bu yazıda bir dijital ürün satış yazılımı üzerinde 500 hatasının hangi sırayla aranacağını, en sık beş sebebi ve özellikle ödeme dönüşünde ortaya çıkan 500'lerin neden diğerlerinden çok daha tehlikeli olduğunu anlatıyorum. Bir e-pin scripti işletiyorsan bu tabloyu bir kez öğrenmen, ilerideki onlarca gece yarısı panik anını ortadan kaldırır.
500 hatası bir arıza değil, susturulmuş bir cümledir
Canlı sistemlerde hata mesajlarının ekrana basılmaması doğru bir güvenlik tercihidir; aksi halde ziyaretçi veri tabanı kullanıcı adını, dosya yollarını, hatta sorgu içeriğini görebilir. Ama bu tercih, hatanın kaybolduğu anlamına gelmez. Mesaj log dosyasına yazılır. Senin işin o dosyayı bulmaktır, tahmin yürütmek değil.
Buradaki en büyük zaman kaybı, kodda rastgele değişiklik yapıp sayfayı yenilemektir. Bu yöntem bazen tesadüfen işe yarar ve tam da bu yüzden tehlikelidir: sorunu kapatmış ama sebebini öğrenmemiş olursun, iki hafta sonra aynı hata başka bir yerden çıkar. Doğru refleks tek cümledir: önce logu oku, sonra dokun.
Log nerede? Üç ayrı yerde bakmadan konuşma
Birinci yer sunucunun hata logudur; paylaşımlı hosting kullanıyorsan panelde "Hata Günlükleri" başlığı altındadır, kendi sunucunda ise web sunucusunun log dizinindedir. İkinci yer PHP'nin kendi hata logudur ve çoğu zaman sitenin kök dizininde ayrı bir dosya olarak durur. Üçüncü yer ise uygulamanın kendi logudur; iyi yazılmış her e-pin satış yazılımı kendi hata kaydını ayrıca tutar.
Üçünü birlikte okumak gerekir çünkü her biri farklı bir katmandan konuşur. Sunucu logu isteğin geldiğini ve sonlandığını söyler; PHP logu hangi dosyanın kaçıncı satırında patladığını söyler; uygulama logu ise o anda hangi kullanıcının hangi siparişi işlemeye çalıştığını söyler. Üçünü yan yana koyduğunda teşhis çoğu zaman kendiliğinden ortaya çıkar. Zaman damgalarını eşleştirmeyi unutma; sunucu saati ile uygulama saat dilimi farklıysa yanlış satırı okursun.
| Belirti | Muhtemel sebep | İlk bakılacak yer | Tipik çözüm |
|---|---|---|---|
| Tüm site 500 veriyor | .htaccess veya yapılandırma hatası | Sunucu hata logu | Son değişikliği geri al |
| Sadece bir sayfa 500 | Kod hatası, eksik sınıf | PHP hata logu | İlgili satırı düzelt |
| Yoğun saatte 500 | Bellek veya süre limiti | PHP logu, kaynak grafiği | Limit artır, sorguyu optimize et |
| Güncelleme sonrası 500 | PHP sürüm uyumsuzluğu | Uygulama logu | Uyumlu sürüme dön |
| Ödeme dönüşünde 500 | Bildirim işleme hatası | Uygulama + sağlayıcı logu | Bildirimi yeniden işlet |
| Rastgele, tekrarlanmayan 500 | Veri tabanı bağlantı limiti | Veri tabanı logu | Bağlantı havuzunu düzenle |
En sık beş sebep ve hangi saatte ortaya çıkarlar
Birincisi bellek limitidir ve genellikle rapor ekranlarında, toplu kod yüklemede veya yedek alırken çıkar. İkincisi çalışma süresi aşımıdır; toplu teslimat ve toplu e-posta gönderiminde görülür. Üçüncüsü PHP sürüm uyumsuzluğudur ve hosting firması sunucuyu güncellediğinde, senin hiçbir şey yapmadığın bir gecede ortaya çıkar. Bu sonuncusu satıcıları en çok şaşırtan sebeptir.
Dördüncüsü dosya izinleridir; taşıma veya yedekten dönüş sonrası izinler bozulur ve uygulama yazamadığı bir dizine yazmaya çalışınca patlar. Beşincisi ise .htaccess dosyasıdır. Tek bir hatalı satır, tüm siteyi anında 500'e düşürür. Bu yüzden canlı sistemde .htaccess'e dokunmadan önce mutlaka yedeğini almalısın; dokunduktan sonra ilk iş ana sayfayı kontrol etmektir.
Dijital ürün satış sistemlerinde 500 hatası kaynak dağılımı
- Kod, eklenti ve sürüm uyumsuzluğu 50%
- Kaynak limitleri (bellek, süre) 25%
- Yapılandırma ve dosya izinleri 15%
- Veri tabanı ve dış servis 10%
Ödeme dönüşünde 500 görmek: paran mı gitti, sipariş mi kayboldu?
Bütün 500'ler eşit değildir. Ürün sayfasında çıkan 500 can sıkıcıdır; ödeme sağlayıcısının bildirimini işlerken çıkan 500 ise doğrudan paradır. Müşteri ödemesini yapmış, sağlayıcı sana "bu ödeme başarılı" demiş, senin uygulaman o bildirimi işlerken patlamıştır. Sonuç: para tahsil edilmiş, sipariş oluşmamış, kod teslim edilmemiştir. Müşteri haklı olarak öfkelidir.
Bu riski ortadan kaldıran tek yapı, bildirim işlemenin yeniden denenebilir olmasıdır. Gelen bildirim önce ham haliyle kaydedilir, sonra işlenir. İşleme başarısız olursa kayıt "bekliyor" durumunda kalır ve zamanlanmış bir görev belirli aralıklarla yeniden dener. Böylece geçici bir hata kalıcı bir kayba dönüşmez. Ayrıca aynı bildirim iki kez gelirse ikinci kez kod düşmemelidir; tekillik kontrolü şarttır. Bu yapının nasıl kurgulandığını özellikler bölümünde inceleyebilirsin.
Log dosyasında hatayı ararken saat dilimi farkını hesaba kat. Sunucu UTC, uygulaman yerel saat kullanıyorsa üç saatlik bir kayma seni tamamen yanlış satıra götürür ve saatlerce var olmayan bir hatayı ararsın.
Opcache, deploy ve "bende çalışıyordu" tuzağı
Dosyayı düzelttin, sunucuya yükledin, sayfayı yeniledin ve hata hâlâ duruyor. Bu noktada çoğu kişi düzeltmenin yanlış olduğunu düşünüp geri alır; oysa düzeltme doğrudur, sadece sunucu eski kodu bellekten servis etmektedir. Bayt kodu önbelleği, dosya değişse bile eski sürümü belirli bir süre kullanmaya devam edebilir. Önbelleği temizlemeden yapılan her test yanıltıcıdır.
Aynı tuzak içerik dağıtım ağı katmanında da vardır. Ara katman hata sayfasını önbelleğe almışsa, sen düzeltsen bile ziyaretçi hâlâ 500 görür. Doğru sıra şudur: dosyayı yükle, bayt kodu önbelleğini temizle, dağıtım ağı önbelleğini temizle, sonra gizli pencerede test et. Bu dört adımı alışkanlık haline getirmek, yaşadığın hata ayıklama süresini gözle görülür biçimde kısaltır.
500'ü kalıcı olarak nasıl erken yakalarsın?
Asıl hedef hatayı çözmek değil, hatayı müşteriden önce öğrenmektir. Bunun için üç basit mekanizma yeterlidir. Birincisi, uygulama seviyesinde kritik hataların anlık bildirim olarak sana ulaşması; ikincisi ödeme ve teslimat uç noktalarının dakikalık kontrol edilmesi; üçüncüsü ise hata sayısında ani artış olduğunda uyarı verilmesi. Bunlar pahalı araçlar gerektirmez, doğru kurgulanmış bir zamanlanmış görevle çözülür.
Buna bir de değişiklik günlüğü ekle. Her dosya yüklemesinin, her ayar değişikliğinin tarihi kayıtlı olsun. Bir hata çıktığında ilk soru daima "son ne değişti" olmalıdır ve bu sorunun cevabı hafızanda değil bir kayıtta bulunmalıdır. Hangi sürümde hangi izleme özelliklerinin geldiğini fiyat tablosundan karşılaştırabilir, kurulum desteğine buradan ulaşabilirsin.
| Adım | Ne yaparsın | Süre |
|---|---|---|
| 1. Kapsamı belirle | Tüm site mi, tek sayfa mı 500 veriyor? | 1 dk |
| 2. Son değişikliği hatırla | Güncelleme, dosya yükleme, ayar değişimi | 1 dk |
| 3. Üç logu oku | Sunucu, PHP ve uygulama loglarını eşleştir | 3 dk |
| 4. Hata satırını doğrula | Dosya ve satır numarasını koda karşılık getir | 2 dk |
| 5. Önbellekleri temizle | Bayt kodu ve dağıtım ağı önbelleği | 1 dk |
| 6. Ödeme kuyruğunu kontrol et | İşlenmemiş bildirim kaldı mı? | 2 dk |
| 7. Bekleyen siparişleri kapat | Yeniden işletip teslimatı tamamla | 5 dk |
| 8. İzlemeyi kur | Bir dahakine müşteriden önce haberin olsun | Tek seferlik |
Hatayı müşteriden önce öğrenen bir sistem kur
Pinova; ayrıntılı uygulama logu, yeniden denenebilir ödeme bildirimi kuyruğu ve kritik hata uyarılarıyla gelir. 500 hatası bile olsa sipariş kaybolmaz, kuyrukta bekler ve tamamlanır.
500 hatası verirken hata detayını ekranda göstersem olmaz mı?
Geçici olarak ve yalnızca kendi IP adresine özel açman en doğrusudur. Herkese açık şekilde detaylı hata göstermek dosya yollarını ve veri tabanı bilgilerini sızdırır; teşhis bittiğinde mutlaka kapatılmalıdır.
Hosting firması "sunucuda sorun yok" diyorsa ne yapmalıyım?
Büyük ihtimalle haklıdırlar. Onlardan sunucu hata logunun ilgili zaman aralığındaki satırlarını istemek, tartışmayı bitiren en hızlı adımdır. Log satırı elinde olduğunda konu artık tahmin değil veri üzerinden yürür.
Ödeme sırasında 500 aldım, müşterinin parası ne olacak?
Para sağlayıcıda başarılı görünüyorsa işlem tamamlanmıştır. Yapman gereken, sağlayıcı panelinden işlemi doğrulayıp bildirimi yeniden işletmek veya siparişi elle tamamlamaktır. Yeniden denenebilir kuyruk yapısı varsa bu zaten kendiliğinden olur.
Aynı 500 hatası tekrar tekrar çıkıyorsa sebep ne olabilir?
Genellikle kaynak limiti veya dış servis bağlantısıdır. Belirli saatlerde tekrarlıyorsa zamanlanmış bir görevle çakışıyordur; belirli bir işlemde tekrarlıyorsa o işlemin sorgusu ya da bellek tüketimi limiti aşıyordur.
500 hatası korkutucu görünür ama aslında disiplinli bir okuma işidir: kapsamı belirle, son değişikliği hatırla, logu oku, önbelleği temizle, kuyruğu kontrol et. Bu beş adımı uyguladığında çoğu vaka beş dakikada kapanır. Hata yönetimi, log ayrıntısı ve ödeme kuyruğunun hazır kurulu halde nasıl çalıştığını görmek istersen canlı demo üzerinden sistemi açıp kendi senaryonu deneyebilir, arka plandaki kayıtları doğrudan inceleyebilirsin.