Safari के खोज क्लिक को उसके रीडायरेक्ट के ज़रिए ट्रेस करें
खोज क्लिक पेज तक पहुँचने से पहले रीडायरेक्टर, सहमति पेज या साइन-इन से गुज़र सकता है। क्लिक की गई श्रृंखला की सीधी विज़िट से तुलना करें और विफल होने वाला चरण नाम दें।
खोज परिणाम शायद ही उस पेज से सीधे लिंक करते हैं जिसका वे नाम लेते हैं। एक क्लिक रीडायरेक्टर, सहमति के बीच वाले पेज या साइन-इन सेवा से गुज़र सकता है, और हर हॉप एक अलग अनुरोध है जो अपने आप विफल हो सकता है। Safari का Network टैब उस क्रम को दिखाई देता रखता है, पर केवल तब जब आप क्लिक से पहले रिकॉर्डिंग शुरू करें। पहला विफल URL ही उपयोगी प्रमाण है, परिणाम में दिखाया गया पता नहीं।
क्लिक से पहले कैप्चर शुरू करें
टैब पर Web Inspector खोलें और खोज परिणाम छूने से पहले Network पर जाएँ। Preserve Log चालू करें ताकि पेज को बदलने वाले नेविगेशन के बाद भी सूची बनी रहे। मौजूदा प्रविष्टियाँ साफ़ करें, फिर ठीक एक क्लिक करें। पेज लोड होने के बाद शुरू हुई कैप्चर आपके ज़रूरी अनुरोध को पहले ही खो चुकी है।
बिना निजी डेटा वाला पेज इस्तेमाल करें और पूरी तुलना के दौरान ब्राउज़र प्रोफ़ाइल और VPN स्थिति अपरिवर्तित रखें। इनमें से कोई एक बीच में बदलने पर दोनों रास्ते तुलनीय नहीं रहते।
रीडायरेक्ट क्रम में पढ़ें
पंक्तियाँ ऊपर से नीचे पढ़ें और स्थिति कोड का पालन करें। जिसका Location फ़ील्ड किसी दूसरे होस्ट की ओर इशारा करता है, वह 301 या 302 हॉप है, गंतव्य नहीं। उसके बाद का अनुरोध अपने नाम-खोज, 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, स्थिति और समय रखें।
पहला विफल अनुरोध, उससे पहले का हॉप और रीडायरेक्ट स्थिति सौंपें। यह त्रयी अगले व्यक्ति को पूरी ट्रेस पढ़े या खाते को छुए बिना आपका रास्ता दोबारा बनाने देती है।