Kısa cevap: 504, ağ geçidinin üst servisten zamanında yanıt alamadığını gösterir. Ekranda hata görmek, arka plandaki sipariş veya işin kesin durduğu anlamına gelmez.
Tekrar denemenin yan etkisini anlayın
Dosya içe aktarımı, rapor hazırlama veya ödeme isteğinde zaman aşımı olduysa işlemi hemen tekrar göndermeyin. Uygulamanın iş geçmişini ve beklenen kaydı kontrol edin. İlk istek arka planda tamamlandıysa tekrar denemek mükerrer kayıt oluşturabilir. Uygulamanın görev kimliği ve tekrar deneme davranışı burada önemlidir.
Gerçek para veya stok etkisi olan işlemde işletmenin sorumlusuna haber verin. Hata fotoğrafı yanında işlem zamanı ve güvenli iş kimliğini not edin; kart bilgisi veya müşteri verisi eklemeyin. Tarayıcıdaki hata sayfasını, işin gerçek sonucundan ayrı bir gözlem olarak tutun.
Yanıt süresini katmanlara ayırın
504 tanımı, proxy veya gateway’in beklediği yanıtın zamanında gelmemesine dayanır. Uygulama, veritabanı veya dış servis gecikmesi araştırılabilir; kod tek başına hangi katmanın geciktiğini söylemez. Ağ geçidindeki süreyle uygulamanın kendi çalışma süresi aynı ayar olmayabilir.
Hangi URL’nin hangi koşulda geciktiğini belirleyin. Küçük bir rapor çalışırken büyük rapor hata veriyorsa dosya kapsamını ve uygulama işleyişini geliştiriciyle inceleyin. Üretimde giderek daha büyük dosyalar göndererek kontrolsüz yük testi yapmayın. Kaynak kullanımını hatayla aynı zaman aralığında değerlendirin.
Süre artırmayı tek çözüm saymayın
Zaman aşımı değerini büyütmek bazen akışı değiştirebilir, fakat yavaş sorguyu veya kilitlenen dış servisi düzeltmez. Ayrıca daha uzun açık kalan isteklerin kapasite etkisi olabilir. Hangi katmanın sınırına takılındığını bilmeden rastgele limitleri yükseltmeyin.
Uzun işlerin kuyruk veya arka plan görevine taşınması uygulama tasarım kararıdır. Her yazılıma tek bir cron komutu ekleyerek uygulanamaz. Geliştirici; ilerleme kaydı, tekrar deneme, başarısız iş ve kullanıcıya sonuç bildirme yöntemini birlikte tasarlamalıdır. Hosting kapsamı ve çalışma yöntemi de doğrulanmalıdır.
Düzeltmeyi sonuç ve süreyle kaydedin
Kontrollü testte başlangıç ve bitiş zamanını, üretilen dosyayı veya iş kaydını doğrulayın. Yalnız HTTP 200 almak, raporun bütün satırlarının işlendiğini kanıtlamaz. Beklenen çıktı kapsamını ve tek işlem oluştuğunu kontrol edin. Hassas veriyi test amacıyla gereksiz yere çoğaltmayın.
Desteğe iletilen zaman çizelgesi istemci, proxy ve uygulama kayıtlarını bağlamalıdır. Bir dış serviste gecikme varsa onun güvenli istek kimliğini ekleyin. Yeni denemeyi ne zaman ve nasıl yapacağınız tanımlı olsun; işin bittiğini anlamadan aynı işlemi tekrar tekrar başlatmayın.
Resmî belgeler ve ilgili rehberler
MDN: HTTP 504 anlamı. Cloudflare: 504 tanısı.
arka plan görevi kontrolü, uzun işin tarayıcı yanıtından bağımsız yürütülmesi planlanıyorsa görev yolu ve gerçek sonuç kontrolünü açıklar. mükerrer işlem ayrımı, ilk isteğin tamamlanıp tamamlanmadığı bilinmeden yeniden gönderilmesinin neden riskli olduğunu farklı bir örnekle gösterir. aynı zamandaki kaynak kayıtları, 504 görülen aralıktaki yük ve servis belirtilerini aynı zaman çizelgesinde karşılaştırmak için kullanılabilir. kapasite ihtiyacını değerlendirme, timeout değerini artırmakla kapasite ihtiyacını çözmenin aynı şey olmadığını değerlendirmeye yardımcı olur.
Bu konunun diğer kontrolleri
- 502 Bad Gateway Hatası: Web Sunucusu ile Uygulama Arasını İnceleyin
- Cloudflare 502 ve 504 Hatasında Sorun Nerede? Origin ile Edge’i Ayırın
Sıkça Sorulan Sorular
504 olunca işlem iptal olmuş mudur?
Bunu varsaymayın. Ağ geçidi yanıt beklemeyi bırakmış olsa bile arka plandaki işin sonucunu uygulama kaydından kontrol etmek gerekir.
Timeout değerini artırmak yeterli mi?
Önce geciken katmanı ve işin gereksinimini belirleyin. Süre artışı uygulama kusurunu veya kapasite sorununu otomatik düzeltmez.
Raporu tekrar yükleyeyim mi?
Önce ilk işin kimliğini ve sonucunu doğrulayın. Tekrar yükleme çift kayıt veya stok değişikliği yaratabiliyorsa uygulamanın güvenli yeniden deneme yolunu kullanın.