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

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