चैट पेज लोड होता है पर लाइव कनेक्शन विफल रहता है: कहाँ देखें

चैट पेज लोड करने से पहले नेटवर्क पैनल खोलें, फिर वह अनुरोध खोजें जो संदेश ले जाता है, न कि वह जो खोल बनाता है। दस्तावेज़, स्क्रिप्ट, साइन-इन विनिमय और चैट ट्रांसपोर्ट सभी अलग-अलग होस्ट पर जा सकते हैं। VPN ने चैट तोड़ दी होने की ज़्यादातर रिपोर्टें वास्तव में उन चार अनुरोधों में से किसी एक की विफलता बताती हैं। उन्हें क्रम में देखें और उत्तर आमतौर पर पहले दो मिनट में दिख जाता है।

वह अनुरोध खोजें जो संदेश ले जाता है

पेज शांत होने पर प्रकार से फ़िल्टर करें: WebSocket अपनी अलग प्रविष्टि के रूप में दिखता है, इवेंट स्ट्रीम बढ़ते उत्तर के साथ खुली रहती है, और लंबा पोल नियमित अंतराल पर दोहराता है। जो अपडेट ले जाता है उसका स्कीम, होस्ट, पोर्ट और स्थिति दर्ज करें। ध्यान दें कि यह साइन-इन से पहले या बाद में शुरू हुआ, क्योंकि प्रमाणीकरण से पहले खुला ट्रांसपोर्ट आमतौर पर बाद में खुले से अलग डिज़ाइन होता है। अपग्रेड अनुरोध या स्वीकृत सामग्री प्रकार के लिए अनुरोध हेडर पढ़ें, क्योंकि वे उस ट्रांसपोर्ट की पहचान करते हैं जिसे तैनात पेज ने वास्तव में चुना।

पुरानी फ़ोरम पोस्टें ऐसे ट्रांसपोर्ट बताती हैं जिन्हें उत्पादों ने वर्षों पहले छोड़ दिया, इसलिए लेख के बजाय ब्राउज़र द्वारा दर्ज किए गए पर भरोसा करें। अगर प्रविष्टि पूरी तरह गायब है, तो क्लाइंट कोड ने शायद कभी कनेक्शन की कोशिश ही नहीं की, जो पहले की स्क्रिप्ट या कॉन्फ़िगरेशन विफलता की ओर संकेत करता है। जो पेज लोड होता है वह केवल यह सिद्ध करता है कि दस्तावेज़ पहुँचा, और यही अंतर तय करता है कि आप नेटवर्क को डीबग कर रहे हैं या नहीं।

सेटअप, डिलीवरी और जीवनकाल अलग-अलग तरह से विफल होते हैं

WebSocket HTTP अपग्रेड से खुलता है जिसका उत्तर 101 स्थिति से दिया जाता है, और उसके बाद सब कुछ पेज लाने के बजाय फ़्रेम किए गए संदेश है, दो चरण जिन्हें RFC 6455 स्पष्ट रूप से अलग रखता है। इवेंट स्ट्रीम स्ट्रीमिंग सामग्री प्रकार से उत्तर देती है और उत्तर का मुख्य भाग खुला रखती है। दोनों खुलने में विफल हो सकते हैं, खुलकर कुछ भी नहीं पहुँचा सकते, या खुलकर पहुँचाने के बाद चुपचाप मर सकते हैं।

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

प्रोफ़ाइल को छूने से पहले पहली सार्थक विफलता पकड़ें, क्योंकि तीन समय अलग-अलग परतों की ओर संकेत करते हैं। अगर हैंडशेक कभी पूरा नहीं होता, तो उसी होस्ट पर सादे HTTPS अनुरोध से तुलना करें कि वहाँ कुछ पहुँचता है या नहीं। अगर वह पूरा होता है और संदेश नहीं आते, तो फ़्रेम या स्ट्रीम बॉडी देखें जब कोई दूसरे खाते से परीक्षण संदेश भेजता है। अगर काम करता है और फिर रुक जाता है, तो सटीक समय और क्लोज़ कोड लिखें, क्योंकि यही जोड़ी बताती है कि किस पक्ष ने हार मानी।

कोड 1006 का अर्थ है कि सॉकेट क्लोज़ फ़्रेम के बिना बंद हुआ, ब्राउज़र के अंदर से बीच का उपकरण या निष्क्रिय टाइमआउट ऐसा ही दिखता है। VPN हार्टबीट यह सिद्ध नहीं करती कि भीतरी एप्लिकेशन सत्र अभी भी जीवित है।

लाइव होस्ट एक अलग गंतव्य है

चैट बैकएंड अक्सर अपने ही होस्टनाम पर रहते हैं, कभी अलग पोर्ट पर या अलग प्रमाणपत्र के पीछे। उस गंतव्य को अपना रिज़ॉल्यूशन, मार्ग और प्रॉक्सी व्यवहार चाहिए, और स्प्लिट टनलिंग पेज को शामिल कर सॉकेट को बाहर छोड़ सकती है। क्लाइंट मशीन से लाइव होस्टनाम हल करें और पुष्टि करें कि वह उस नेटवर्क में अपेक्षित पता लौटाता है। विशेष रूप से उसी होस्टनाम के लिए प्रमाणपत्र शृंखला जाँचें, क्योंकि साइट को कवर करने वाला वाइल्डकार्ड हमेशा सॉकेट एंडपॉइंट को कवर नहीं करता।

अगर मार्ग में प्रॉक्सी है, तो पुष्टि करें कि वह अपग्रेड या लंबे समय तक चलने वाले उत्तर को अनुमति देती है, उसे बफ़र नहीं करती। HTML को फिर से लिखने वाली कॉर्पोरेट प्रॉक्सियाँ अक्सर WebSocket अपग्रेड को बुरी तरह संभालती हैं, जिससे ऐसा पेज बनता है जो दिखता है पर चैट कभी जुड़ती नहीं। इसलिए एक ही उत्पाद के दो अनुरोध एक ही होस्ट के दो अनुरोध नहीं हैं।

गंतव्यों की सूची ठीक करें, सुरक्षा जाँच नहीं

गंतव्यों की सूची ठीक करना रूटिंग परिवर्तन है और यह मार्ग के मालिक का काम है। प्रमाणपत्र सत्यापन ढीला करना या Origin हेडर हटाना सुरक्षा परिवर्तन है और यह नीति के मालिक का काम है, जो शायद ही टिकट डीबग करने वाला व्यक्ति होता है। कनेक्शन दिखाने का सबसे तेज़ तरीका आमतौर पर घटना को संभव बनाने का सबसे तेज़ तरीका है।

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

सौंपने के लिए पर्याप्त रिकॉर्ड करें

उपयोगी दस्तावेज़ छोटा है: पेज URL, लाइव एंडपॉइंट, हैंडशेक परिणाम, पहली विफलता का समय, और क्या फिर से कनेक्ट करने का प्रयास हुआ। VPN प्रोफ़ाइल का नाम और वह नेटवर्क जोड़ें जिस पर आप थे, और कोई भी पाठक छह प्रश्न पूछे बिना परीक्षण दोहरा सकेगा। कुकीज़, प्राधिकरण हेडर और संदेश निकायों को छिपाएँ, और पूर्ण संग्रह निर्यात के बजाय टाइमिंग स्तंभ का स्क्रीनशॉट पसंद करें। फ़्रेम और नेटवर्क संग्रह में निजी संदेश और सत्र टोकन हो सकते हैं, इसलिए कुछ भी संलग्न करने से पहले जाँचें।

अगर विफलता चुपचाप बंद होना है, तो क्लोज़ कोड और उससे पहले का निष्क्रिय अंतराल शामिल करें, क्योंकि यही जोड़ी आमतौर पर टाइमआउट के मालिक की पहचान करती है। स्वयं टाइमआउट मान का अनुमान लगाने के बजाय रिकॉर्ड एप्लिकेशन या गेटवे मालिक को दें। समर्थित कीपअलाइव व्यवहार के बारे में उनका उत्तर ही टिकट बंद करता है।