Safari-তে অনুসন্ধান ক্লিকের রিডাইরেক্টগুলো অনুসরণ করুন
একটি অনুসন্ধান ক্লিক পেজে পৌঁছানোর আগে রিডাইরেক্টর, সম্মতি পেজ বা সাইন-ইনের মধ্য দিয়ে যেতে পারে। ক্লিক করা চেইনটি সরাসরি ভিজিটের সঙ্গে তুলনা করুন এবং ব্যর্থ হওয়া ধাপটির নাম দিন।
অনুসন্ধান ফলাফল খুব কমই তাদের নাম দেওয়া পেজে সরাসরি লিঙ্ক করে। একটি ক্লিক রিডাইরেক্টর, সম্মতি-মধ্যবর্তী পেজ বা সাইন-ইন সেবার মধ্য দিয়ে যেতে পারে, আর প্রতিটি হপ আলাদা অনুরোধ যা নিজেই ব্যর্থ হতে পারে। Safari-র Network ট্যাব ওই ক্রমটি দৃশ্যমান রাখে, কিন্তু কেবল যদি আপনি ক্লিকের আগে রেকর্ডিং শুরু করেন। প্রথম ব্যর্থ URL-ই দরকারি প্রমাণ, ফলাফলে দেখানো ঠিকানাটি নয়।
ক্লিকের আগেই ক্যাপচার শুরু করুন
ট্যাবে Web Inspector খুলে অনুসন্ধান ফলাফল স্পর্শ করার আগেই Network-এ যান। Preserve Log চালু করুন যাতে পেজ প্রতিস্থাপনকারী নেভিগেশনের পরেও তালিকা টিকে থাকে। বিদ্যমান এন্ট্রিগুলো মুছে ফেলুন, তারপর ঠিক একটি ক্লিক করুন। পেজ লোডের পরে শুরু করা ক্যাপচার আপনার প্রয়োজনীয় অনুরোধটি ইতিমধ্যেই হারিয়েছে।
ব্যক্তিগত তথ্য নেই এমন পেজ ব্যবহার করুন এবং পুরো তুলনার সময় ব্রাউজার প্রোফাইল ও VPN অবস্থা অপরিবর্তিত রাখুন। মাঝপথে যেকোনোটি বদলালে দুই পথ তুলনার অযোগ্য হয়ে যায়।
রিডাইরেক্টগুলো ক্রমানুসারে পড়ুন
সারিগুলো উপর থেকে নিচে পড়ুন এবং স্ট্যাটাস কোড অনুসরণ করুন। যে 301 বা 302-এর Location অন্য হোস্টের দিকে দেখায় তা গন্তব্য নয়, একটি হপ। এর পরে আসা অনুরোধটি নিজস্ব নাম-লুকআপ, TLS হ্যান্ডশেক ও নীতি যাচাইসহ নতুন নেভিগেশন। কনটেন্ট আসার আগে ক্লিকটি কতগুলো হোস্ট স্পর্শ করে তা গুনুন।
WebKit-এর Network ট্যাব গাইড নথিভুক্ত করে কীভাবে অনুরোধের রেকর্ড ও Preserve Log অপশন আচরণ করে, যা একটি বিরল তালিকা ব্যাখ্যা করার আগে পড়া মূল্যবান। অনুপস্থিত সারি সাধারণত বোঝায় ক্যাপচার দেরিতে শুরু হয়েছে বা কোনো service worker ক্যাশ থেকে উত্তর দিয়েছে, ব্রাউজার হপ এড়িয়ে যায়নি।
সরাসরি নেভিগেশনের সঙ্গে তুলনা করুন
একই প্রোফাইল ও নেটওয়ার্কের অধীনে উদ্দিষ্ট চূড়ান্ত পেজে দ্বিতীয় পাস চালান, সরাসরি টাইপ বা পেস্ট করে। যে প্রথম সারিতে দুটি তালিকা আলাদা হয় সেখান থেকে তুলনা করুন। যদি ক্লিক করা পথ এমন কোনো মধ্যস্থতাকারীর কাছে ব্যর্থ হয় যাকে সরাসরি পথ কখনো স্পর্শ করে না, সমস্যা ওই মধ্যস্থতাকারীর কাছে। যদি দুটোই একই origin-এ পৌঁছায় এবং কেবল একটিই প্রত্যাখ্যান পায়, তাহলে অ্যাকাউন্ট অবস্থা বা অনুরোধের বিশদ ভালো সূত্র।
সময়চিহ্নসহ দুই ক্যাপচার পাশাপাশি রাখুন। সময়ের পার্থক্য কারণের প্রমাণ নয়, তবে পরবর্তীতে কোন সেবা তদন্ত করবেন তা সংকুচিত করে। প্রতিটি ব্যর্থ সারি কোন হোস্টের ছিল তা লিখে রাখুন, কারণ একই ব্রাউজার উপসর্গের বিভিন্ন ধাপে বিভিন্ন মালিক থাকে। সরাসরি পাসও ব্যর্থ হলে ক্লিক পথটিই পার্থক্যকারী নয়।
ব্যর্থতার ধাপটি নিখুঁতভাবে নাম দিন
সারির ত্রুটি-বার্তা সাইটটি ব্লকড—এই সাধারণ দাবির চেয়ে বেশি নির্দিষ্ট। নাম-সমাধানের ব্যর্থতা, কখনো শেষ না হওয়া সংযোগ, TLS ত্রুটি ও HTTP স্ট্যাটাস চারটি ভিন্ন ধাপ, চারটি ভিন্ন মালিক। ওই ধাপটি সাধারণ ব্যর্থতা হিসেবে নয়, কথায় লিখুন, তাহলে এসকেলেশনের লক্ষ্য স্পষ্ট হয়।
| Stage | What the row shows | Who owns it |
|---|---|---|
| Name resolution | No address, request never starts | Resolver or local DNS policy |
| Connection | Address known, transport never completes | Route, firewall or upstream reachability |
| TLS | Handshake error or certificate warning | Interception, clock or certificate trust |
| HTTP | A status code comes back | Origin, gateway or account policy |
Ping ও traceroute কোনো হোস্ট সম্পর্কে সূত্র যোগ করতে পারে, কিন্তু সেগুলো ব্রাউজারের রিডাইরেক্ট চেইন পুনরায় চালায় না বা HTTPS অনুরোধ সফল হয়েছে তা প্রমাণ করে না। এমনকি হোস্টে সফল ping একই হোস্টে TLS ব্যর্থতার সঙ্গে সহাবস্থান করতে পারে। ওয়েব-অনুরোধের রেকর্ডই মূল প্রমাণ রাখুন এবং পরের নেটওয়ার্ক পরীক্ষাগুলোকে সহায়ক বিবরণ হিসেবে দেখুন।
টোকেন ফাঁস না করে ট্রেস শেয়ার করুন
ট্রেস রপ্তানি বা পেস্ট করার আগে প্রতিটি URL, হেডার ও কোয়েরি প্যারামিটার পর্যালোচনা করুন। রিডাইরেক্ট চেইন প্রায়ই সেশন শনাক্তকারী, ইমেল ঠিকানা, সম্মতির অবস্থা বা স্বাক্ষরিত লিঙ্ক বহন করে। ওই মানগুলো বদলান বা ছেঁটে দিন, আর তদন্তের সত্যিই প্রয়োজনীয় origin, স্ট্যাটাস ও সময় রাখুন।
প্রথম ব্যর্থ অনুরোধ, তার আগের হপ এবং রিডাইরেক্ট স্ট্যাটাস হস্তান্তর করুন। এই ত্রয়ী পরের ব্যক্তিকে সম্পূর্ণ ট্রেস না পড়ে বা অ্যাকাউন্ট স্পর্শ না করে আপনার পথ পুনরুৎপাদন করতে দেয়।