कुछ वेबसाइटें केवल 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 सेटिंग देखने की जगह है। यदि छोटा अनुरोध स्थिति लौटाता है जबकि बड़ा अटकता है, तो पैकेट-आकार शाखा पर काम करें। यदि दोनों समय समाप्त कर दें, तो निकास पथ और साइट का उस पते के प्रति व्यवहार फिर मेज़ पर हैं।

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