HTTP 504 Gateway Timeout विरुद्ध तुमच्या क्लायंटचा टाइमआउट

तुमचा क्लायंट साठ सेकंद वाट पाहायला तयार आहे. दहा सेकंदांनंतर त्याला HTTP 504 मिळतो. क्लायंटचा टाइमआउट दोन मिनिटांपर्यंत वाढवल्याने गेटवेला आणखी पन्नास सेकंद काम मिळत नाही.

504 अशा गेटवे किंवा प्रॉक्सीचे वर्णन करते ज्याला विनंती पूर्ण करण्याचा प्रयत्न करताना वेळेवर अपस्ट्रीम प्रतिसाद मिळाला नाही. गेटवेने आधीच निर्णय घेतला आहे आणि प्रतिसाद परत पाठवला आहे. तुमचा क्लायंट तो प्रतिसाद सहज वाचू शकतो.

हा कोणत्या मध्यस्थाने परत पाठवला?

फॉर्वर्ड प्रॉक्सी जारीकर्ता असू शकतो. वेबसाइट चालवते तो नंतरचा गेटवेही असू शकतो. CONNECT मधील नेहमीच्या एंड-टू-एंड TLS सह, त्या संरक्षित गंतव्य देवघेवीतून येणारा HTTP प्रतिसाद CONNECT लाच नाकारण्यासारखा नाही.

टप्पा, प्रतिसाद हेडर, त्रुटी पृष्ठावरील मजकूर आणि उपलब्ध असल्यास जुळणारे लॉग जतन करा. सर्व्हरचे नाव सुगावा असू शकते, पण ते अचूक श्रेय मानू नये. मार्गात तुमच्या क्लायंटमध्ये कॉन्फिगर केलेल्या एकापेक्षा जास्त मध्यस्थ असू शकतात.

मग ती अपस्ट्रीम क्रिया का पूर्ण झाली नाही ते तपासा. पोहोच, अतिभारित सेवा, अपस्ट्रीम अपेक्षेप्रमाणे प्रक्रिया करू शकत नाही असे विनंतीचे मुख्य भाग, आणि अनुप्रयोगाचे वर्तन — सर्व महत्त्वाचे ठरू शकतात. केवळ संख्यात्मक स्थिती हे सिद्ध करत नाही की User-Agent बदलणे किंवा एक टाइमआउट पर्याय जोडणे हा सार्वत्रिक उपाय आहे.

तीच विनंती तुलना करा

दुसरे साधन चालत असेल तर पद्धत, लक्ष्य, मुख्य भागाचे एन्कोडिंग, प्रमाणीकरण आणि मार्ग यांची तुलना करा. "URL ब्राउझरमध्ये उघडते" ही सेवा क्लायंटद्वारे multipart सबमिशनशी पूर्ण तुलना नाही.

तुम्ही जारीकर्ता गेटवे चालवत असाल, तर त्याचे अपस्ट्रीम बजेट समर्थित कामाचा भार आणि आसपासच्या मुदतींशी जुळवा. नसाल, तर त्याचा निकाल पुरावा म्हणून ठेवा आणि ऑपरेटरचा दस्तऐवजीकृत प्रवेश किंवा सहाय्य मार्ग वापरा. स्थानिक पातळीवर जास्त वेळ थांबल्याने आधीच आलेला प्रतिसाद बदलू शकत नाही.