HTTP 504 Gateway Timeout বনাম আপনার ক্লায়েন্টের টাইমআউট

আপনার ক্লায়েন্ট ষাট সেকেন্ড অপেক্ষা করতে রাজি। দশ সেকেন্ড পরে এটি HTTP 504 পায়। ক্লায়েন্টের টাইমআউট দুই মিনিটে বাড়ালে গেটওয়ে আরও পঞ্চাশ সেকেন্ড কাজ করার সুযোগ পায় না।

504 এমন গেটওয়ে বা প্রক্সি বোঝায় যা অনুরোধটি সম্পূর্ণ করার চেষ্টা করার সময় সময়মতো আপস্ট্রিম উত্তর পায়নি। গেটওয়ে ইতিমধ্যেই তার সিদ্ধান্ত নিয়ে উত্তর ফিরিয়ে দিয়েছে। আপনার ক্লায়েন্ট সেই উত্তর সফলভাবে পড়তে পারে।

কোন মধ্যবর্তী এটি ফেরত দিল?

ফরওয়ার্ড প্রক্সিই প্রেরক হতে পারে। ওয়েবসাইটের পরিচালিত পরবর্তী গেটওয়েও হতে পারে। CONNECT-এর ভেতরে সাধারণ এন্ড-টু-এন্ড TLS-এর সঙ্গে, সেই সুরক্ষিত গন্তব্য বিনিময়ের ভেতর থেকে আসা HTTP উত্তর CONNECT নিজেই প্রত্যাখ্যান হওয়ার সমান নয়।

পর্যায়, উত্তর হেডার, ত্রুটি পৃষ্ঠার ভাষা এবং উপলব্ধ হলে মিলে যাওয়া লগ সংরক্ষণ করুন। সার্ভার লেবেল সূত্র হতে পারে, কিন্তু একে অব্যর্থ আরোপণ হিসেবে গণ্য করা উচিত নয়। পথে আপনার ক্লায়েন্টে কনফিগার করা একটির চেয়ে বেশি মধ্যবর্তী থাকতে পারে।

তারপর পরীক্ষা করুন সেই আপস্ট্রিম কাজটি কেন সম্পূর্ণ হয়নি। নাগাল, অতিরিক্ত বোঝাই সেবা, আপস্ট্রিম প্রত্যাশিতভাবে প্রক্রিয়া করতে না পারা অনুরোধ বডি, এবং অ্যাপ্লিকেশন আচরণ — সবই গুরুত্বপূর্ণ হতে পারে। কেবল সংখ্যাগত স্ট্যাটাস প্রমাণ করে না যে User-Agent বদলানো বা একটি টাইমআউট অপশন যোগ করাই সর্বজনীন সমাধান।

একই অনুরোধ তুলনা করুন

অন্য একটি টুল কাজ করলে পদ্ধতি, লক্ষ্য, বডি এনকোডিং, প্রমাণীকরণ ও পথ তুলনা করুন। "URL ব্রাউজারে খোলে" — এটি সেবা ক্লায়েন্টের মাধ্যমে multipart জমার পূর্ণ তুলনা নয়।

আপনি যদি প্রেরক গেটওয়ে পরিচালনা করেন, তার আপস্ট্রিম বাজেট সমর্থিত কাজের ভার ও আশপাশের সময়সীমার সঙ্গে মেলান। না করলে, তার ফলাফল প্রমাণ হিসেবে রাখুন এবং পরিচালকের নথিভুক্ত প্রবেশ বা সহায়তা পথ ব্যবহার করুন। স্থানীয়ভাবে বেশি সময় অপেক্ষা করলে ইতিমধ্যে আসা উত্তর বদলাবে না।