ولې ځینې وېبپاڼې یوازې هغه وخت ناکامېږي چې 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 تنظیم هغه ځای دی چې باید وګورل شي۔ که کوچنې غوښتنه حالت بېرته راوګرځوي په داسې حال کې چې لویه پاتې کېږي، د بنډل اندازې څانګه وکاروئ۔ که دواړه وخت پای ته ورسېږي، د وتلو لاره او د پاڼې چلند هغې پتې ته بیا پر میز دي۔

هغه بدلون وساتئ چې اصلي غوښتنه یې بریالۍ کړه او پاتې بېرته وګرځوئ۔ د براوزر، حل کوونکي او کلینټ پر بېلابېلو هممهاله بدلونونو غونډ دې کوي چې ونه شئ ویلی کوم یې مهم و۔