चॅट पेज लोड होते पण थेट कनेक्शन अयशस्वी होते: कुठे पाहावे
पेज आणि चॅट वाहतूक या वेगवेगळ्या विनंत्या आहेत. WebSocket, इव्हेंट स्ट्रीम किंवा लाँग पोल तपासा, नंतर सेटअप, वितरण आणि आयुष्य वेगळे करा.
चॅट पेज लोड करण्यापूर्वी नेटवर्क पॅनेल उघडा, नंतर पेजची चौकट रेखाटणारी विनंती नाही तर संदेश वाहून नेणारी विनंती शोधा. दस्तऐवज, स्क्रिप्ट, साइन-इन देवघेव आणि चॅट वाहतूक हे सर्व वेगवेगळ्या होस्टकडे जाऊ शकतात. VPN ने चॅट खराब झाला अशा बहुतेक तक्रारी प्रत्यक्षात या चारपैकी एक विनंती अयशस्वी झाल्याचे वर्णन करतात. त्या क्रमाने पाहा आणि उत्तर सहसा पहिल्या दोन मिनिटांत दिसते.
संदेश वाहून नेणारी विनंती शोधा
पेज स्थिर झाल्यावर प्रकारानुसार फिल्टर करा: WebSocket स्वतंत्र नोंद म्हणून दिसते, इव्हेंट स्ट्रीम वाढत्या प्रतिसादासह उघडी राहते आणि लाँग पोल नियमित अंतराने पुनरावृत्ती होते. अद्ययावत माहिती वाहून नेणाऱ्या नोंदीसाठी योजना, होस्ट, पोर्ट आणि स्थिती नोंदवा. ती साइन-इनपूर्वी की नंतर सुरू झाली हे लक्षात ठेवा, कारण प्रमाणीकरणापूर्वी उघडलेली वाहतूक सहसा त्यानंतर उघडलेल्यापेक्षा वेगळी रचना असते. अपग्रेड विनंती किंवा स्वीकारलेल्या सामग्री प्रकारासाठी विनंती हेडर वाचा, कारण ते तैनात केलेल्या पेजने प्रत्यक्षात निवडलेली वाहतूक दर्शवतात.
जुने फोरम पोस्ट उत्पादने वर्षांपूर्वी वापरणे थांबवलेल्या वाहतुकीचे वर्णन करतात, म्हणून लेखावर नाही तर ब्राउझरने नोंदवलेल्यावर विश्वास ठेवा. नोंद पूर्णपणे नसल्यास, क्लायंट कोडने कधीही कनेक्शनचा प्रयत्न केला नसावा, जे आधीच्या स्क्रिप्ट किंवा कॉन्फिगरेशन अपयशाकडे निर्देश करते. पेज लोड होणे हे फक्त दस्तऐवज पोहोचल्याचे सिद्ध करते, आणि तोच फरक तुम्ही नेटवर्क डीबग करत आहात की नाही हे ठरवतो.
सेटअप, वितरण आणि आयुष्य वेगवेगळ्या पद्धतीने अयशस्वी होतात
WebSocket 101 स्थितीसह उत्तर मिळणाऱ्या HTTP अपग्रेडने उघडते, आणि त्यानंतर सर्व काही पेज आणणे नाही तर फ्रेममध्ये बांधलेले संदेश असते; हे दोन टप्पे 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 प्रोफाइलचे नाव आणि तुम्ही ज्या नेटवर्कवर होता ते जोडा, मग वाचणारा कोणीही सहा प्रश्न न विचारता चाचणी पुन्हा करू शकतो. कुकीज, अधिकृतता हेडर आणि संदेशांचे मुख्य भाग झाकून टाका, आणि संपूर्ण संग्रह निर्यातीपेक्षा वेळ स्तंभाचा स्क्रीनशॉट निवडा. फ्रेम आणि नेटवर्क संग्रहात खाजगी संदेश आणि सत्र टोकन असू शकतात, म्हणून काही जोडण्यापूर्वी तपासा.
अपयश शांत बंद असेल तर बंद कोड आणि त्यापूर्वीचा निष्क्रिय कालावधी समाविष्ट करा, कारण ती जोडी सहसा कालबाह्यतेचा मालक ओळखते. कालबाह्यता मूल्य स्वतः अंदाज न लावता नोंद अनुप्रयोग किंवा गेटवेच्या मालकाकडे सुपूर्द करा. समर्थित keepalive वर्तनाबद्दलचे त्यांचे उत्तर तिकीट बंद करणारे उत्तर असते.