HTTP 504 Gateway Timeout در برابر مهلت زمانی کلاینت شما
درخواست فرسوده‌شدهٔ بالادست در دروازه را از مهلتی که در کلاینت پروکسی خودتان تنظیم شده است جدا کنید.
کلاینت شما حاضر است شصت ثانیه صبر کند. ده ثانیه بعد HTTP 504 دریافت می‌کند. افزایش مهلت کلاینت به دو دقیقه، پنجاه ثانیهٔ دیگر برای کار به دروازه نمی‌دهد.
504 توصیف می‌کند دروازه یا پروکسی‌ای را که هنگام تلاش برای کامل‌کردن درخواست، پاسخ به‌موقع بالادست دریافت نکرد. دروازه پیشاپیش تصمیم خود را گرفته و پاسخی برگردانده است. کلاینت شما می‌تواند آن پاسخ را بی‌مشکل بخواند.
کدام واسطه آن را برگرداند؟
پروکسی پیش‌رو می‌تواند صادرکننده باشد. همچنین دروازهٔ بعدی که وب‌سایت اداره می‌کند. با TLS معمول سرتاسری درون CONNECT، پاسخ HTTP از درون آن تبادل محافظت‌شده با مقصد همان رد شدن خود CONNECT نیست.
مرحله، سرایندهای پاسخ، عبارت صفحهٔ خطا و گزارش‌های متناظر را در صورت وجود نگه دارید. برچسب سرور می‌تواند سرنخ باشد، اما نباید آن را انتساب خطاناپذیر دانست. مسیر ممکن است بیش از یک واسطهٔ پیکربندی‌شده در کلاینت شما داشته باشد.
سپس بررسی کنید چرا آن عملیات بالادست کامل نشد. دسترس‌پذیری، سرویس‌های بارگذاشته، بدنهٔ درخواستی که بالادست نمی‌تواند مطابق انتظار پردازش کند، و رفتار برنامه همگی می‌توانند مهم باشند. وضعیت عددی به‌تنهایی ثابت نمی‌کند که تغییر User-Agent یا افزودن یک گزینهٔ مهلت، راه‌حل همگانی است.
همان درخواست را مقایسه کنید
وقتی ابزار دیگری کار می‌کند، روش، هدف، کدگذاری بدنه، احراز هویت و مسیر را مقایسه کنید. «نشانی در مرورگر باز می‌شود» مقایسهٔ کاملی با ارسال multipart از طریق کلاینت سرویس نیست.
اگر دروازهٔ صادرکننده را اداره می‌کنید، بودجهٔ بالادست آن را با بار کاری پشتیبانی‌شده و مهلت‌های پیرامون هم‌تراز کنید. اگر نه، نتیجهٔ آن را به‌عنوان شواهد نگه دارید و از مسیر دسترسی یا پشتیبانی مستندشدهٔ اپراتور استفاده کنید. انتظار بیشتر به‌صورت محلی نمی‌تواند پاسخی را که رسیده است تغییر دهد.