“Connection reset by peer” ले टुटेको यातायात जडान जनाउँछ। यसले ISP, प्रोक्सी अपरेटर वा वेबसाइटलाई कारणका रूपमा पहिचान गर्दैन।

रिसेटको समयकहाँ अनुसन्धान गर्ने
TCP जोडिएलगत्तैप्रोटोकलको नमिल्दो वा सुरुको आदानप्रदान अस्वीकार गर्ने सेवा
CONNECT सफल भएपछिस्थापित सुरुङ मार्ग
प्रतिक्रियाको क्रममामाथिल्लो बन्द हुनु, मध्यस्थको आयु नीति र स्थानान्तरण मार्ग

त्यसपछि प्रोक्सी र गन्तव्य स्थिर राखेर एउटा सान्दर्भिक सर्त बदल्नुहोस्। जहाँ समर्थित छ त्यहाँ ठीकसँग कन्फिगर गरिएको इन्क्रिप्टेड क्लाइन्ट-देखि-प्रोक्सी जडान, वा अर्को स्वीकृत नेटवर्कबाट त्यही क्लाइन्ट तुलना गर्नुहोस्। अपरेटरले आफ्नो लगमा यो प्रयास सम्बन्धित गर्न सक्छ कि भनी सोध्नुहोस्।

फरक नतिजाले अनुसन्धान साँघुरो बनाउँछ तर एउटा कारण प्रमाणित गर्दैन। सुरुङबाट ट्राफिक पठाउँदा समय, भार, नीति र मध्यस्थ उपकरणहरू एकैसाथ बदलिन सक्छन्। यसको सफलताले मात्र मूल मार्गमा जानाजान अवरोध स्थापित गर्न सक्दैन।

जहाँ अधिकृत प्याकेट अवलोकन उपलब्ध छ, तिनलाई अनुप्रयोग र प्रोक्सी लगसँग तुलना गर्नुहोस्। अपेक्षित प्याकेट स्रोत ठेगानाले पनि रिसेट किन पठाइयो वा कुन प्रणालीले नीति लागू गर्‍यो भन्ने व्याख्या गर्दैन।

सङ्ख्यात्मक त्रुटि, टाइमस्ट्याम्प, अन्तिम बिन्दु र अन्तिम पूरा भएको चरण सुरक्षित राख्नुहोस्। प्रमाणपत्र वा TLS सेटिङ बदल्नु अघि त्यो प्रमाण प्रयोग गर्नुहोस्; छोटो रिसेट सन्देशले आफैंमा ती दुईमध्ये कुनै पनि बदल्न कुनै कारण दिँदैन।

सम्बन्धित लेखहरू