अर्को पृष्ठ लोड हुँदा एउटा मात्र तस्बिर किन असफल हुन्छ
तीन सर्तहरूले नेटवर्क गडबडीलाई रोकिएको अनुरोध र रेन्डरिङ त्रुटिबाट छुट्याउँछन्। मार्ग परिवर्तन गर्नुअघि ब्राउजरले छानेको URL पत्ता लगाउनुहोस्।
पृष्ठ लोड हुन्छ, पाठ देखिन्छ, र एउटा तस्बिर भाँचिएको प्रतिमा जस्तै रहन्छ। पहिलो प्रतिक्रिया सुरुङलाई दोष दिने हो, किनकि परिवर्तन भएको कुरा सुरुङ नै हो। त्यसअघि ब्राउजरले त्यो तस्बिरका लागि वास्तवमै कुन URL माग्यो भनी पत्ता लगाउनुहोस्, किनकि पृष्ठको URL र तस्बिरको URL दुई फरक प्रमाण हुन्। हराएको तस्बिरसम्बन्धी अधिकांश रिपोर्ट कहिल्यै काम गर्ने अनुरोध नपाएको होस्टमा पुग्छन्, र त्यो उत्तरका लागि नेटवर्क प्यानलमा एक पटक हेर्नु पुग्छ।
कहाँ हेर्ने भन्ने तीन सर्तले निर्धारण गर्छन्
पहिलो सर्त तस्बिर पृष्ठकै होस्टबाट आउँछ कि भन्ने हो। छुट्टै तस्बिर होस्टलाई आफ्नै नाम विश्लेषण, आफ्नै जडान र आफ्नै TLS पहिचान चाहिन्छ, त्यसैले लोड हुने पृष्ठले त्यसबारे केही भन्दैन।
दोस्रो सर्त ब्राउजरले पठाउनुअघि नै अनुरोध रोक्यो कि भन्ने हो। मिश्रित सामग्री, सामग्री सुरक्षा नीति र रेफरर नियमहरूले सामान्य सर्भर प्रतिक्रिया नबनाई तस्बिर रोक्न सक्छन्, त्यसैले सूचीमा कुनै असफल अनुरोध देखिँदैन।
तेस्रो सर्त डेलिभरी सफल भयो र रेन्डरिङ असफल भयो कि भन्ने हो, बाइटहरू आउने तर तस्बिर अझै नदेखिने अवस्था। यी तीन सर्तका तीन फरक मालिक छन्, र पहिलो मात्र नेटवर्कको प्रश्न हो।
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
ब्राउजरले वास्तवमै छानेको स्रोत पत्ता लगाउनुहोस्
पृष्ठको स्रोतमा देखिने URL प्रायः मागिएको URL हुँदैन। स्रोत-समूह, picture तत्वहरू र CSS पृष्ठभूमिले ब्राउजरलाई भ्युपोर्टको चौडाइ, पिक्सेल घनत्व वा ढाँचा समर्थनका आधारमा अर्को स्रोत छान्न दिन्छन्। अल्छी लोड हुने तस्बिर पृष्ठ कुनै निश्चित अवस्थामा नपुगुन्जेल बिल्कुलै मागिँदैन।
तत्व र अनुरोध सँगै जाँच्नुहोस्, र समस्या रिपोर्ट गर्दा अनुरोधसँगै सुरुवातकर्ता राख्नुहोस्। MDNको तस्बिर तत्व सन्दर्भ ले स्रोत छनोट, लोडिङ व्यवहार र रेफरर नियन्त्रण एकै ठाउँमा समेट्छ, जुन असफल URL कुन विशेषताले छान्यो भन्न पर्याप्त छ।
होस्टनाम, स्थिति, कुनै पनि रिडाइरेक्ट शृंखला र प्रतिक्रियाको सामग्री प्रकार रेकर्ड गर्नुहोस्। साइन-इन पृष्ठ फर्काउने 200 प्रतिक्रिया प्रयोगयोग्य तस्बिर होइन, र HTML त्रुटि पृष्ठमा रिडाइरेक्ट प्रकार नपढेसम्म बिग्रिएको फाइल जस्तै देखिन्छ।
नेटवर्कभन्दा पहिले स्थिति पढ्नुहोस्
समय सकिने, अस्वीकृत अनुरोध र डिकोडिङ त्रुटिलाई फरक अर्को कदम चाहिन्छ, र स्थिति कोडले नै तिनलाई छुट्याउँछ। समय सकिनेले नाम विश्लेषण, मार्ग वा जवाफ नदिने होस्टतर्फ संकेत गर्छ। अस्वीकृत अनुरोधले नीति वा अधिकार तहतर्फ संकेत गर्छ। डिकोडिङ त्रुटिले बाइट वा ढाँचातर्फ संकेत गर्छ।
अनुरोध बिल्कुलै नदेखिएमा नेटवर्क हेर्न छोड्नुहोस् र मार्कअप हेर्नुहोस्। सबैभन्दा सामान्य कारण स्रोत-समूहको त्यो प्रविष्टि हो जुन ब्राउजरले रुचाएको थियो र अब सर्भरमा छैन, त्यसपछि कुनै स्क्रिप्टले कहिल्यै दृश्यमान नबनाएको तत्व।
यही भिन्नताले यस प्रकारका रिपोर्टमा हुने अधिकांश व्यर्थ प्रयास रोक्छ।
ब्राउजरले रोक्दा पढ्ने कुनै प्रतिक्रिया हुँदैन
मिश्रित सामग्री परम्परागत उदाहरण हो: साधारण HTTP मार्फत तस्बिर माग्ने HTTPS पृष्ठले अनुरोध असफल नभई रोकिएको पाउँछ, र कन्सोलले कारण रेकर्ड गर्छ। सामग्री सुरक्षा नीतिले पनि त्यही आकार दिन्छ, सन्देशमा रोकिएको निर्देशको नाम हुन्छ। हेडर हटाउने रेफरर नीतिले हटलिङ्क-संरक्षित होस्टलाई तस्बिरको सट्टा प्लेसहोल्डर फर्काउन बाध्य पार्न सक्छ।
नेटवर्क मार्ग छुनुअघि रेकर्ड गरिएको कारण पढ्नुहोस्, किनकि मार्ग बदलिँदा यी अवरोध सुधारिँदैनन्। क्रस-ओरिजिन अनुमति थप्नु पनि समाधान होइन: अर्को होस्टको तस्बिर देखाउनु र त्यसका पिक्सेल canvasमा पढ्नु फरक कार्य हुन्, र दोस्रोलाई मात्र मानिसहरूले टाँस्ने हेडर चाहिन्छ।
तपाईंले व्यवस्थापन गर्ने साइटका लागि स्रोतको URL, प्रतिक्रिया वा नीति त्यसको मालिकसँग सुधार्नुहोस् र अधिकार तथा रेफररका सर्तहरू अक्षुण्ण राख्नुहोस्। तपाईंले नियन्त्रण नगर्ने साइटका लागि निजी वा म्याद सकिने स्रोत लिङ्क पुनः प्रकाशित गर्नुको सट्टा पृष्ठ र अनुरोधका प्रमाण त्यसको सहायता च्यानलमा पठाउनुहोस्।
प्रमाण नबदली मार्गको तुलना गर्नुहोस्
तपाईं साँच्चै पहुँच मार्ग परीक्षण गर्न चाहनुहुन्छ भने बाँकी सबै स्थिर राख्नुहोस्: त्यही पृष्ठ, त्यही खाता, त्यही छानिएको तस्बिर, एउटा अनुमत मार्ग परिवर्तन गरिएको। रेन्डर भएको नतिजाको सट्टा अनुरोध प्रविष्टिहरूको छेउछाउ तुलना गर्नुहोस्, किनकि रेन्डर भएको नतिजाले तस्बिर देखियो कि भन्ने मात्र बताउँछ, किन भन्ने होइन।
नयाँ मार्गमा लोड हुने तस्बिरले त्यो मार्ग अधिकृत छ भनी प्रमाणित गर्दैन, र भाँचिएको रहने तस्बिरले सुरुङ दोषी छ भनी प्रमाणित गर्दैन। तस्बिर हटाइएको वा पहुँच जानाजान सीमित गरिएको भए, प्रमाणपत्र जाँच बन्द गर्ने वा अरूको सुरक्षित सामग्री प्रतिलिपि गर्ने सट्टा समर्थित विकल्प प्रयोग गर्नुहोस्।
कामको क्रम: छानिएको URL पहिचान गर्नुहोस्, त्यसको स्थिति र प्रकार पढ्नुहोस्, रेकर्ड गरिएको रोकावट कारण छ कि जाँच्नुहोस्, त्यसपछि एक पटकमा एउटा मार्ग परिवर्तनको तुलना गर्नुहोस्।