مهلة HTTP 504 Gateway Timeout مقابل مهلة عميلك

عميلك مستعد للانتظار ستين ثانية. وبعد عشر ثوانٍ يستقبل HTTP 504. ورفع مهلة العميل إلى دقيقتين لا يمنح البوابة خمسين ثانية أخرى للعمل.

يصف 504 بوابةً أو بروكسي لم يتلقَّ ردًا مناسب التوقيت من المنبع أثناء محاولة إتمام الطلب. وقد اتخذت البوابة قرارها بالفعل وأعادت ردًا. وعميلك قادر على قراءة ذلك الرد بنجاح.

أي وسيط أعاده؟

قد يكون البروكسي الأمامي هو المُصدر. وقد تكون بوابة لاحقة يشغّلها الموقع. ومع TLS العادي من الطرف إلى الطرف داخل CONNECT، فإن رد HTTP القادم من داخل ذلك التبادل المحمي مع الوجهة ليس هو نفسه رفض CONNECT نفسه.

سجّل المرحلة وترويسات الرد وصياغة صفحة الخطأ والسجلات المطابقة حيث توفرت. وقد يكون اسم الخادم قرينة، لكن لا ينبغي اعتباره إسنادًا معصومًا من الخطأ. فقد يحتوي المسار على وسطاء أكثر من ذلك الذي ضبطته في عميلك.

ثم افحص سبب عدم اكتمال عملية المنبع تلك. فإمكانية الوصول، والخدمات المثقلة، وجسم الطلب الذي لا يستطيع المنبع معالجته كما هو متوقع، وسلوك التطبيق، كلها قد تكون ذات صلة. والحالة الرقمية وحدها لا تثبت أن تغيير User-Agent أو إضافة خيار مهلة واحد هو الحل الشامل.

قارن الطلب نفسه

حين ينجح أداة أخرى، قارن الطريقة والهدف وترميز الجسم والمصادقة والمسار. فقول "الرابط يُفتح في المتصفح" ليس مقارنة كاملة بإرسال multipart عبر عميل خدمة.

إن كنت تشغّل البوابة المُصدرة، فاضبط ميزانية المنبع لديها بما يوافق الحمل المدعوم والمواعيد النهائية المحيطة. وإن لم تكن تشغّلها، فاحتفظ بنتيجتها كدليل واستخدم مسار الوصول أو الدعم الموثق لدى المشغّل. فالانتظار مدة أطول محليًا لا يمكنه تغيير رد وصل بالفعل.