काही वेबसाइट्स फक्त VPN सुरू असतानाच का अयशस्वी होतात?

एक साइट अयशस्वी होते आणि बाकी सर्व लोड होत असते, यावरून टनेल ट्रॅफिक वाहून नेत असल्याचे सिद्ध होते, आणि हे बहुतेकांना वाटते त्यापेक्षा जास्त समस्या मर्यादित करते। तीन निरीक्षणे उर्वरित गोष्टी लावतात: तुम्हाला HTTP प्रतिसाद मिळाला का, होस्टनाव पत्त्यात सोडवले गेले का, आणि लहान विनंत्या पुढे जातात का तर मोठ्या अडकतात। या उत्तरांपूर्वी VPN बद्दल अंदाज लावणे सहसा दोष काढून टाकण्याऐवजी त्याचे स्थान बदलते।

निरीक्षणे क्रमाने हाताळा, कारण ज्या साइटने उत्तर दिले ती त्याचवेळी निराकरणात अयशस्वी झाली असू शकत नाही। काहीच लोड होत नसेल, तर तुम्ही चुकीच्या फांदीत आहात, आणि जोडलेले पण इंटरनेट नसलेल्या स्थितीच्या तपासण्या लागू होतात।

त्रुटी संदेशाला फांदी निवडू द्या

नकार, बॉट-आव्हान किंवा त्रुटी पृष्ठ म्हणजे सेवेने उत्तर दिले, म्हणजे पॅकेट एखाद्या ॲप्लिकेशनपर्यंत पोहोचले आणि परत आले। हे प्रश्न साइटच्या प्रवेश धोरणाकडे नेते, जे निर्गम पत्ता, खाते किंवा प्रकाशित न केलेल्या विनंती-नमुन्यांचे वजन करू शकते। नाव-निराकरणातील अयशस्वीता साइटपर्यंत कधीच पोहोचली नाही, आणि पत्ता ही सर्वप्रथम तपासण्याची गोष्ट आहे। टाइमआउट दोन्हींच्या मध्ये आहे: काहीतरी पाठवले गेले आणि कुणीही त्याची पुष्टी केली नाही।

प्रमाणपत्र इशाऱ्यांचा समावेश चौथ्या फांदीत होतो। त्यांचा अर्थ असा की ज्या गोष्टीची ओळख ब्राउझर सत्यापित करू शकला नाही तिने कनेक्शनला उत्तर दिले, म्हणजे एकतर तुमच्या बाजूचा प्रॉक्सी किंवा खरी विसंगती जी तुम्ही क्लिक करून ओलांडू नये। हे मार्गाचा नव्हे, विश्वासाचा प्रश्न माना।

उत्तर देणाऱ्या साइटने तुटलेली टनेल सिद्ध केलेली नाही

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

फक्त ब्राउझरमध्ये होणाऱ्या अयशस्वीता पुरेशा सामान्य आहेत की त्या लवकर तपासाव्यात। एखादे पृष्ठ एका समर्थित ब्राउझरमध्ये लोड होऊन दुसऱ्यात अयशस्वी होत असेल, तर ते प्रोफाइल स्थिती, सामग्री-अडवणूक किंवा ब्राउझरच्या आतच संरचित एन्क्रिप्टेड DNS कडे निर्देश करते। Chrome च्या सुरक्षित DNS विषयक मार्गदर्शक सूचना ती सेटिंग कुठे आहे हे सांगतात, आणि ती समर्थित नियंत्रणाने बदलणे उपकरण रीसेट करण्यापेक्षा बरे।

जेव्हा फक्त मोठे स्थानांतरण अडकतात, पॅकेटचा आकार पाहा

जे पृष्ठ आपले शीर्षक रेखाटून नंतर अडकते, त्याची सही कधीही सुरू न होणाऱ्या पृष्ठापेक्षा वेगळी असते। लहान प्रतिसाद पुढे जाऊ शकतात तर पूर्ण आकाराचा पेलोड कुठेतरी टाकला जातो जो प्रेषकाला संकेत देऊ शकत नाही, आणि ब्राउझरमधून मार्ग MTU अयशस्वीता अशीच दिसते। गाळण्याबद्दल सिद्धांत मांडण्यापूर्वी त्याच होस्टला एक छोटी विनंती आणि एक मोठी पाठवून तुलना करा। मार्ग MTU शोधाने मार्गावरील सर्वात लहान दुव्याचा आकार शिकायला हवा, आणि तो गाळलेल्या नेटवर्ककडून नेहमी टाकल्या जाणाऱ्या ICMP प्रतिसादांवर अवलंबून असतो।

त्या गृहीतकाची एका ping ऐवजी आकार-स्कॅनने चाचणी करा। स्थिर पेलोड आकारावर सुरू होणारी अयशस्वीता हा मजबूत पुरावा आहे, तर इकडे-तिकडे फिरणारी अयशस्वीता नाही।

अयशस्वी झालेल्या विनंतीवरच सुधारणेची पुष्टी करा

मूळ क्रिया पुन्हा तपासा, मुख्यपृष्ठ नाही, कारण कॅशे केलेले कवच रेखाटले जाऊ शकते तर साइन-इनमागील API कॉल अजूनही अयशस्वी होतो। खालील आदेश त्याच होस्टवर नाव-निराकरण, लहान विनंती आणि मोठी विनंती वेगळ्या करतात। होस्टनाव आणि मार्ग खऱ्या अर्थाने तुटलेल्या विनंतीतल्या मूल्यांनी बदला।

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

जर dig चे उत्तर ब्राउझरने वापरलेल्यापेक्षा वेगळे असेल, तर रिझॉल्व्हर हा चल आहे, आणि ब्राउझरची स्वतःची DNS सेटिंग पाहण्याची जागा आहे। जर लहान विनंती स्थिती परत करते तर मोठी अडकते, तर पॅकेट-आकार फांदीवर काम करा। जर दोन्ही वेळ संपवतील, तर निर्गम मार्ग आणि त्या पत्त्याबद्दल साइटचा दृष्टिकोन पुन्हा मेजावर आहेत।

ज्या बदलामुळे मूळ विनंती यशस्वी झाली तो ठेवा आणि बाकी पूर्ववत करा। ब्राउझर, रिझॉल्व्हर आणि क्लायंटवरील एकाच वेळच्या बदलांचा ढीग तुम्हाला कोणता महत्त्वाचा होता हे सांगू देत नाही।