HTTP 504 Gateway Timeout र तपाईंको क्लाइन्टको टाइमआउट

तपाईंको क्लाइन्ट साठी सेकेन्ड पर्खन तयार छ। दस सेकेन्डपछि यसले HTTP 504 प्राप्त गर्छ। क्लाइन्टको टाइमआउट दुई मिनेट बनाउँदा गेटवेले थप पचास सेकेन्ड काम पाउँदैन।

504 ले अनुरोध पूरा गर्न खोज्दा अपस्ट्रिमबाट समयमै प्रतिक्रिया नपाएको गेटवे वा प्रोक्सीलाई जनाउँछ। गेटवेले पहिले नै आफ्नो निर्णय लिइसकेको छ र प्रतिक्रिया फर्काइसकेको छ। तपाईंको क्लाइन्टले त्यो प्रतिक्रिया राम्ररी पढ्न सक्छ।

कुन मध्यस्थले यो फर्कायो?

अगाडिको प्रोक्सी नै जारीकर्ता हुन सक्छ। वेबसाइटले सञ्चालन गर्ने पछिको गेटवे पनि हुन सक्छ। CONNECT भित्रको सामान्य इन्ड-टु-इन्ड TLS सँग, त्यो सुरक्षित गन्तव्य आदानप्रदानबाट आउने HTTP प्रतिक्रिया आफै CONNECT अस्वीकार गर्नुसँग बराबर हुँदैन।

चरण, प्रतिक्रिया हेडर, त्रुटि पृष्ठको शब्द र उपलब्ध भएमा मिल्ने लगहरू सुरक्षित राख्नुहोस्। सर्भरको नाम सङ्केत हुन सक्छ, तर यसलाई अचुक श्रेय मान्नु हुँदैन। मार्गमा तपाईंको क्लाइन्टमा कन्फिगर गरिएको भन्दा धेरै मध्यस्थ हुन सक्छन्।

त्यसपछि त्यो अपस्ट्रिम कार्य किन पूरा भएन भनी जाँच्नुहोस्। पहुँच, अत्यधिक भार भएका सेवा, अपस्ट्रिमले अपेक्षाअनुसार प्रशोधन गर्न नसक्ने अनुरोध निकाय, र अनुप्रयोगको व्यवहार सबै महत्त्वपूर्ण हुन सक्छन्। केवल सङ्ख्यात्मक स्थितिले User-Agent बदल्नु वा एउटा टाइमआउट विकल्प थप्नु सार्वभौमिक उपाय हो भनी प्रमाणित गर्दैन।

उही अनुरोध तुलना गर्नुहोस्

अर्को उपकरण चल्न सक्यो भने विधि, लक्ष्य, निकाय इन्कोडिङ, प्रमाणीकरण र मार्ग तुलना गर्नुहोस्। "URL ब्राउजरमा खुल्छ" भन्ने सेवा क्लाइन्टमार्फत multipart पेस गर्नुसँग पूर्ण तुलना होइन।

यदि तपाईं जारीकर्ता गेटवे सञ्चालन गर्नुहुन्छ भने, यसको अपस्ट्रिम बजेट समर्थित कार्यभार र वरपरका समयसीमासँग मिलाउनुहोस्। नगर्नुभए, यसको नतिजा प्रमाणका रूपमा राख्नुहोस् र सञ्चालकको कागजात भएको पहुँच वा सहयोग मार्ग प्रयोग गर्नुहोस्। स्थानीय रूपमा लामो समय पर्खंदा पहिले नै आइसकेको प्रतिक्रिया बदलिँदैन।