কেন কিছু ওয়েবসাইট কেবল 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 সেটিংই দেখার জায়গা। যদি ছোট অনুরোধ অবস্থা ফেরত দেয় আর বড়টি আটকে যায়, প্যাকেট-আকার শাখা নিয়ে কাজ করুন। যদি দুটোই সময় শেষ করে, প্রস্থান পথ এবং সেই ঠিকানার প্রতি সাইটের আচরণ আবার টেবিলে।

যে পরিবর্তন মূল অনুরোধকে সফল করেছিল তা রাখুন এবং বাকিটা ফিরিয়ে নিন। ব্রাউজার, রিজলভার ও ক্লায়েন্টে একসঙ্গে করা পরিবর্তনের স্তূপ আপনাকে বলতে দেয় না কোনটি গুরুত্বপূর্ণ ছিল।