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, स्थिति र समय राख्नुहोस्।
पहिलो असफल अनुरोध, त्यसअघिको हप र रिडाइरेक्ट स्थिति हस्तान्तरण गर्नुहोस्। त्यो त्रिकले अर्को व्यक्तिलाई पूरा ट्रेस नपढी वा खाता नछोई तपाईंको मार्ग पुनःउत्पादन गर्न दिन्छ।