TCP कनेक्शन यशस्वी झाल्यानंतर प्रॉक्सी CONNECT टाइमआउट
पूर्ण झालेल्या TCP कनेक्शनने टनेल सेटअपही पूर्ण केला असे गृहीत धरण्याऐवजी CONNECT दरम्यान सक्रिय असलेला टाइमआउट शोधा.
क्लायंट प्रॉक्सीशी जोडल्याक्षणी TCP कनेक्शन टाइमआउटने आपले काम पूर्ण केले आहे. पुढील प्रतीक्षा—संपूर्ण CONNECT प्रतिसाद मिळवणे—दुसऱ्या टाइमरद्वारे नियंत्रित असू शकते.
प्रॉक्सी कदाचित अजूनही वरच्या बाजूला जोडत असेल, प्रमाणीकरण संदेशांची देवाणघेवाण करत असेल किंवा दुसऱ्या सेवेची वाट पाहत असेल. वेबसाइटचा नेहमीचा प्रतिसाद अजून सुरू झालेला नाही.
| शेवटची पूर्ण झालेली पायरी | अजून कशाची वाट पाहत आहे? |
|---|---|
| TCP प्रॉक्सीशी जोडले | CONNECT स्वीकारण्यासह प्रॉक्सी हँडशेक |
| CONNECT स्वीकारले | लक्ष्य ते वापरत असल्यास गंतव्याचे TLS |
| गंतव्याची विनंती पाठवली | गंतव्याचा प्रतिसाद |
कनेक्टर तो हँडशेक वाचत व लिहित असताना सक्रिय असलेला टाइमर शोधा. “response timeout” नावाचा गुणधर्म कदाचित मार्ग स्थापित झाल्यानंतरच लागू होईल. HttpClient 5 मध्ये ConnectionConfig आणि त्याचा सॉकेट टाइमआउट, TLS हँडशेक कॉन्फिगरेशन आणि विनंती-स्तरीय प्रतिसाद टाइमआउट यात फरक करा. वास्तविक क्लायंट वापरत असलेल्या मॅनेजरमार्फत संबंधित कनेक्शन कॉन्फिगरेशन लागू करा. जुन्या Apache HttpClient पिढ्या वेगळे API वापरतात, त्यामुळे जुना स्निपेट या जबाबदाऱ्यांचा विश्वासार्ह नकाशा नाही.
अंतिम CONNECT नकार प्रॉक्सीचा प्रतिसाद म्हणून ठेवा. यशस्वी प्रतिसादानंतर TLS थांबणे हा आणखी एक अयशस्वी टप्पा आहे. “TCP जोडले; सेटअप मुदतीपूर्वी संपूर्ण CONNECT प्रतिसाद नाही” हे सामान्य प्रॉक्सी टाइमआउटपेक्षा समस्या अधिक अचूकपणे वर्णन करते.
एक एकूण मुदत या टप्प्यानिहाय मर्यादांसोबत कॉलरची प्रतीक्षा मर्यादित करू शकते. ती संपल्यावर, पुढील प्रयत्न कनेक्शन क्षमता खर्च करण्यापूर्वी क्लायंटला समर्थित जीवनचक्रातून क्रिया रद्द करा किंवा बंद करा.