চ্যাট পাতা লোড হয় কিন্তু লাইভ সংযোগ ব্যর্থ হয়: কোথায় দেখবেন
পাতা আর চ্যাট ট্রান্সপোর্ট আলাদা অনুরোধ। WebSocket, ইভেন্ট স্ট্রিম বা লং পোল পরীক্ষা করুন, তারপর সেটআপ, ডেলিভারি আর লাইফটাইম আলাদা করুন।
চ্যাট পাতা লোড করার আগে নেটওয়ার্ক প্যানেল খুলুন, তারপর শেল আঁকে যে অনুরোধ তা নয়, বরং বার্তা বহন করে যে অনুরোধ তা খুঁজুন। ডকুমেন্ট, স্ক্রিপ্ট, সাইন-ইন বিনিময় আর চ্যাট ট্রান্সপোর্ট সবই ভিন্ন হোস্টে যেতে পারে। VPN চ্যাট ভেঙেছে বলে বেশিরভাগ রিপোর্ট আসলে ওই চারটি অনুরোধের একটির ব্যর্থতা বর্ণনা করে। ক্রম অনুসারে সেগুলো দেখুন, উত্তর সাধারণত প্রথম দুই মিনিটেই দেখা যায়।
যে অনুরোধ বার্তা বহন করে তা খুঁজুন
পাতা স্থির হলে ধরন অনুসারে ফিল্টার করুন: WebSocket আলাদা এন্ট্রি হিসেবে দেখা যায়, ইভেন্ট স্ট্রিম বর্ধমান প্রতিক্রিয়াসহ খোলা থাকে, আর লং পোল নিয়মিত বিরতিতে পুনরাবৃত্তি হয়। আপডেট বহন করে যেটি, তার স্কিম, হোস্ট, পোর্ট আর স্ট্যাটাস লিখে রাখুন। সাইন-ইনের আগে না পরে শুরু হয়েছে তা লক্ষ্য করুন, কারণ প্রমাণীকরণের আগে খোলা ট্রান্সপোর্ট সাধারণত পরে খোলার চেয়ে ভিন্ন নকশা। আপগ্রেড অনুরোধ বা গৃহীত কনটেন্ট টাইপের জন্য অনুরোধ হেডার পড়ুন, কারণ সেগুলোই দেখায় মোতায়েন করা পাতা আসলে কোন ট্রান্সপোর্ট বেছে নিয়েছে।
পুরোনো ফোরাম পোস্ট এমন ট্রান্সপোর্ট বর্ণনা করে যা পণ্যগুলো বছরের পর বছর আগে ব্যবহার বন্ধ করেছে, তাই নিবন্ধের বদলে ব্রাউজার যা রেকর্ড করেছে তাতে ভরসা করুন। এন্ট্রি একেবারে না থাকলে ক্লায়েন্ট কোড হয়তো কখনোই সংযোগের চেষ্টা করেনি, যা আগের কোনো স্ক্রিপ্ট বা কনফিগারেশন ব্যর্থতার দিকে ইঙ্গিত করে। যে পাতা লোড হয় তা কেবল প্রমাণ করে ডকুমেন্ট পৌঁছেছে, আর সেই পার্থক্যই ঠিক করে আপনি আদৌ নেটওয়ার্ক ডিবাগ করছেন কি না।
সেটআপ, ডেলিভারি আর লাইফটাইম ভিন্নভাবে ব্যর্থ হয়
WebSocket খোলে HTTP আপগ্রেড দিয়ে যার উত্তর 101 স্ট্যাটাস, আর এর পরে সবকিছু পাতা আনার বদলে ফ্রেম করা বার্তা, দুটি পর্যায় যাকে RFC 6455 স্পষ্টভাবে আলাদা রাখে। ইভেন্ট স্ট্রিম স্ট্রিমিং কনটেন্ট টাইপ দিয়ে উত্তর দেয় আর প্রতিক্রিয়ার বডি খোলা রাখে। দুটোই খুলতে ব্যর্থ হতে পারে, খুলে কিছু না পৌঁছাতে পারে, বা খুলে পৌঁছে তারপর নিঃশব্দে মরে যেতে পারে।
wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events
প্রোফাইলে হাত দেওয়ার আগে প্রথম অর্থবহ ব্যর্থতা ধরে রাখুন, কারণ তিনটি সময়ভেদ ভিন্ন স্তরের দিকে ইঙ্গিত করে। হ্যান্ডশেক কখনো সম্পূর্ণ না হলে একই হোস্টে সাধারণ HTTPS অনুরোধের সঙ্গে তুলনা করুন, দেখুন আদৌ কিছু পৌঁছায় কি না। সম্পূর্ণ হয় কিন্তু বার্তা না এলে ফ্রেম বা স্ট্রিম বডি দেখুন, যখন অন্য কোনো অ্যাকাউন্ট থেকে কেউ পরীক্ষামূলক বার্তা পাঠায়। কাজ করে তারপর থেমে গেলে সঠিক সময় আর ক্লোজ কোড লিখুন, কারণ ওই জোড়াই বলে দেয় কোন প্রান্ত হাল ছেড়েছে।
কোড 1006 মানে সকেট ক্লোজ ফ্রেম ছাড়াই বন্ধ হয়েছে, ব্রাউজারের ভেতর থেকে মধ্যস্থ ডিভাইস বা নিষ্ক্রিয় টাইমআউট এমনই দেখায়। VPN হার্টবিট প্রমাণ করে না ভেতরের অ্যাপ্লিকেশন সেশন এখনো সজীব।
লাইভ হোস্ট আলাদা গন্তব্য
চ্যাট ব্যাকএন্ড প্রায়ই নিজস্ব হোস্টনেমে থাকে, কখনো ভিন্ন পোর্টে বা আলাদা সার্টিফিকেটের পিছনে। ওই গন্তব্যের নিজস্ব রেজলিউশন, রুট আর প্রক্সি ব্যবস্থাপনা দরকার, আর স্প্লিট টানেলিং পাতা অন্তর্ভুক্ত করে সকেট বাদ দিতে পারে। ক্লায়েন্ট মেশিন থেকে লাইভ হোস্টনেম রিজলভ করুন এবং ওই নেটওয়ার্কে প্রত্যাশিত ঠিকানায় উত্তর দেয় কি না নিশ্চিত করুন। ঠিক ওই হোস্টনেমের জন্য সার্টিফিকেট চেইন দেখুন, কারণ সাইট ঢাকা ওয়াইল্ডকার্ড সবসময় সকেট এন্ডপয়েন্ট ঢাকে না।
পথে প্রক্সি থাকলে নিশ্চিত করুন এটি আপগ্রেড বা দীর্ঘস্থায়ী প্রতিক্রিয়া মঞ্জুর করে, বাফার করে না। HTML পুনর্লিখন করা কর্পোরেট প্রক্সি প্রায়ই WebSocket আপগ্রেড খারাপভাবে সামলায়, ফলে পাতা দেখা যায় কিন্তু চ্যাট কখনো সংযুক্ত হয় না। তাই একই পণ্যে দুটি অনুরোধ একই হোস্টে দুটি অনুরোধ নয়।
গন্তব্যের তালিকা ঠিক করুন, নিরাপত্তা যাচাই নয়
গন্তব্যের তালিকা ঠিক করা রাউটিং পরিবর্তন এবং তা রুটের মালিকের কাজ। সার্টিফিকেট যাচাই শিথিল করা বা Origin হেডার সরানো নিরাপত্তা পরিবর্তন এবং তা নীতির মালিকের কাজ, যিনি বিরলভাবে টিকিট ডিবাগ করা ব্যক্তি। সংযোগ দেখা দেওয়ার দ্রুততম উপায় সাধারণত ঘটনা সম্ভব করার দ্রুততম উপায়।
কিছু বদলানোর আগে অ্যাপ্লিকেশন মালিককে জিজ্ঞাসা করুন ব্যাকএন্ড কোন অরিজিন গ্রহণ করে, এবং সেই উত্তর প্রক্সি নিয়ন্ত্রণকারীকে দিন। শুধু টানেলের মধ্য দিয়ে সার্টিফিকেট ত্রুটি দেখা দিলে বাইপাস বসানোর বদলে আটকানো ডিভাইস পরীক্ষা করুন।
হস্তান্তরের জন্য যথেষ্ট রেকর্ড করুন
উপযোগী নথিটি ছোট: পাতার URL, লাইভ এন্ডপয়েন্ট, হ্যান্ডশেক ফলাফল, প্রথম ব্যর্থতার সময়, এবং পুনঃসংযোগের চেষ্টা হয়েছে কি না। VPN প্রোফাইলের নাম আর আপনি যে নেটওয়ার্কে ছিলেন তা যোগ করুন, যেকোনো পাঠক ছয়টি প্রশ্ন না করেই পরীক্ষাটি পুনরাবৃত্তি করতে পারবেন। কুকি, অনুমোদন হেডার আর বার্তার বডি সংস্করণ করুন, এবং সম্পূর্ণ আর্কাইভ এক্সপোর্টের বদলে টাইমিং কলামের স্ক্রিনশট পছন্দ করুন। ফ্রেম আর নেটওয়ার্ক আর্কাইভে ব্যক্তিগত বার্তা ও সেশন টোকেন থাকতে পারে, তাই কিছু সংযুক্ত করার আগে পরীক্ষা করুন।
ব্যর্থতা নিঃশব্দ ক্লোজ হলে ক্লোজ কোড আর তার আগের নিষ্ক্রিয় বিরতি যোগ করুন, কারণ ওই জোড়াই সাধারণত টাইমআউটের মালিক চিহ্নিত করে। নিজে টাইমআউট মান অনুমান না করে রেকর্ডটি অ্যাপ্লিকেশন বা গেটওয়ে মালিকের কাছে দিন। সমর্থিত কিপঅ্যালাইভ আচরণ সম্পর্কে তাদের উত্তরই টিকিট বন্ধ করে।