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, स्थिती व वेळ ठेवा।
पहिली अयशस्वी विनंती, तिच्यापूर्वीचा हॉप आणि रीडायरेक्ट स्थिती सुपूर्द करा। हा त्रिकट पुढच्या व्यक्तीला पूर्ण ट्रेस न वाचता किंवा खात्याला स्पर्श न करता तुमचा मार्ग पुन्हा तयार करू देतो।