HTTP कैश एनालाइज़र — Cache-Control और CDN कैश स्टेटस जाँचें

ब्राउज़र और CDN कैसे तय करते हैं कि पेज कितनी देर कैश करना है?

हर कैश रिस्पॉन्स हेडर पढ़ता है: Cache-Control का max-age हर कैश के लिए अवधि देता है, s-maxage या CDN का अपना हेडर साझा कैश के लिए उसकी जगह लेता है, no-store स्टोर करने से रोकता है और private कॉपी को सिर्फ़ ब्राउज़र में रखता है। अवधि ख़त्म होने पर ETag या Last-Modified कैश को पूरा पेज दोबारा डाउनलोड करने के बजाय सस्ती कंडीशनल रिक्वेस्ट से रीवैलिडेट करने देते हैं। CDN यह नीति हर एज लोकेशन में अलग से लागू करता है, इसलिए उसका कैश स्टेटस और Age अलग-अलग विज़िटर के लिए अलग होते हैं।

सुरक्षा नोट: कुकी सेट करने वाला या निजी डेटा दिखाने वाला रिस्पॉन्स private या no-store होना चाहिए; अगर साझा कैश उसे स्टोर कर ले, तो अगले विज़िटर को किसी और का पेज मिल सकता है।

HTTP कैश एनालाइज़र कैसे इस्तेमाल करें

किसी पेज, फ़ाइल या API रिस्पॉन्स का URL डालें — या उसके रिस्पॉन्स हेडर दूसरे फ़ील्ड में पेस्ट करें।
अगर देखना है कि CDN रिस्पॉन्स स्टोर करता है या नहीं, तो "एज कैश देखने के लिए दो बार माँगें" पर टिक करें।
"कैशिंग जाँचें" दबाएँ और कैश नीति पढ़ें: नतीजा, ब्राउज़र और साझा कैश की अवधि, और रीवैलिडेशन कैसे होता है।
नतीजों को एक-एक करके सुलझाएँ, दोनों रिक्वेस्ट के CDN हेडर की तुलना करें, और सुझाई गई नीति को सर्वर या CDN पर अपने हिसाब से ढालें।

HTTP कैश एनालाइज़र की खूबियाँ

Mutqan सर्वर से URL फ़ेच करता है और सिर्फ़ रिस्पॉन्स हेडर पढ़ता है, या पेस्ट किए हेडर (raw रिस्पॉन्स, curl -I आउटपुट या "Name: value" लाइनें) बिना कुछ भेजे जाँचता है
कैशिंग नीति आसान शब्दों में बताता है: ब्राउज़र और साझा कैश रिस्पॉन्स स्टोर कर सकते हैं या नहीं, हर एक कितनी देर, और पुरानी कॉपी कैसे रीवैलिडेट होती है
मौजूद हर Cache-Control डायरेक्टिव समझाता है — max-age, s-maxage, public, private, no-cache, no-store, must-revalidate, immutable, stale-while-revalidate और बाक़ी
ETag और Last-Modified, Expires और Date, Age और Vary, और CF-Cache-Status, X-Cache, X-Served-By, CDN-Cache-Control व Surrogate-Control जैसे CDN हेडर पढ़ता है
नीति की ग़लतियाँ पकड़ता है: कुकी सेट करने वाला रिस्पॉन्स जिसे साझा कैश स्टोर कर सकते हैं, आपस में टकराते डायरेक्टिव, ग़लत तारीख़ें, Cookie या User-Agent पर Vary, बिना Vary: Accept-Encoding वाला कंप्रेस्ड रिस्पॉन्स, कोई validator न होना
चाहें तो URL दूसरी बार माँगकर दिखाता है कि जवाब देने वाले एज ने दोनों रिक्वेस्ट के बीच रिस्पॉन्स स्टोर किया या नहीं
रिस्पॉन्स के प्रकार के हिसाब से शुरुआती नीति सुझाता है — आँख मूँदकर कॉपी करने के लिए नहीं, ढालने के लिए

इनपुट और आउटपुट

इनपुट

जाँचने के लिए URL — कोई भी सार्वजनिक http:// या https:// पता; सिर्फ़ होस्ट नाम देने पर https:// जोड़ा जाता है।
या रिस्पॉन्स हेडर पेस्ट करें — ब्राउज़र में जाँचे जाते हैं और URL की जगह लेते हैं; स्टेटस लाइन वैकल्पिक है (न हो तो 200 माना जाता है)।
एज कैश देखने के लिए दो बार माँगें — डिफ़ॉल्ट रूप से बंद; अंतिम URL पर एक और रिक्वेस्ट भेजता है।

आउटपुट

सारांश — नतीजा, ब्राउज़र और साझा कैश की अवधि, Age, मौजूद validator और HTTP स्टेटस।
कैश नीति — एक वाक्य में नतीजा, ब्राउज़र और साझा कैश का व्यवहार, अवधि कहाँ से आती है, रीवैलिडेशन, Vary और मापा गया URL।
Cache-Control डायरेक्टिव, नतीजे और CDN व प्रॉक्सी हेडर — हर एक का मतलब; नतीजे CSV में डाउनलोड हो सकते हैं।
दो रिक्वेस्ट की तुलना और दूसरी रिक्वेस्ट क्या दिखाती है — जब दूसरी रिक्वेस्ट माँगी गई हो।
सुझाई गई शुरुआती नीति — इस प्रकार के रिस्पॉन्स के लिए उदाहरण हेडर।

HTTP कैश एनालाइज़र का उदाहरण

एज पर एक घंटे कैश होने वाला पर कुकी से बँटा पेज

इनपुट:

जाँचने के लिए URL: https://shop.example.com/ · एज कैश देखने के लिए दो बार माँगें: चालू

आउटपुट:

Verdict Cacheable · Browser lifetime 5 minutes · Shared-cache lifetime 1 hour · Validators ETag · HTTP status 200
Verdict: Cacheable: browsers may reuse it for 5 minutes and shared caches for 1 hour.
Revalidation: Conditional request with If-None-Match: W/"5f8d-1a2b3c"
Warning (Vary): Vary on Cookie splits the cache into a variant per value, so few requests are served from it.
cf-cache-status MISS → HIT; age — → 2
The edge that answered stored the response: the first request was MISS and the second a HIT.

HTTP कैश एनालाइज़र के नतीजे कैसे पढ़ें

दो अवधियों वाले "कैश होने लायक़" नतीजे का मतलब है कि ब्राउज़र और साझा कैश कॉपी अलग-अलग समय तक रखते हैं: s-maxage या CDN का अपना हेडर CDN को पेज ब्राउज़र से ज़्यादा देर रखने देता है, और ब्राउज़र फिर CDN से पूछते हैं।

no-cache का मतलब "कैश नहीं" नहीं है: कॉपी स्टोर होती है और हर इस्तेमाल से पहले जाँची जाती है, जो ETag के साथ सस्ता है (304 जवाब में बॉडी नहीं होती)। स्टोर करने से रोकने वाला डायरेक्टिव no-store है।

कुकी या ऑथेंटिकेशन वाली समस्या सबसे पहले ठीक करें: एक व्यक्ति के लिए बना रिस्पॉन्स स्टोर करने वाला साझा कैश उसे अगले विज़िटर को दे सकता है।

CDN स्टेटस और Age उस एज के बारे में हैं जिसने उस पल Mutqan सर्वर को जवाब दिया। MISS के बाद HIT का मतलब है कि उस एज ने रिस्पॉन्स स्टोर किया; दूसरे एज अपना कैश अलग से भरते हैं।

HTTP कैश एनालाइज़र कब इस्तेमाल करें

लॉन्च से पहले जाँचें कि वर्ज़न वाली फ़ाइलें लंबे समय तक कैश होती हैं और HTML पेज थोड़ी देर या रीवैलिडेशन के साथ।
पता करें कि CDN हर बार MISS क्यों करता है: no-store, private, Set-Cookie, Cookie पर Vary, या BYPASS या DYNAMIC स्टेटस ढूँढें।
पक्का करें कि निजी डेटा वाले पेज private या no-store हैं और साझा कैश उन्हें कभी स्टोर नहीं करते।
लोड टेस्ट, ब्राउज़र के developer tools या curl -I से कॉपी किए हेडर पेस्ट करके जाँचें, बिना कुछ फ़ेच किए।

समस्या निवारण

नतीजा "Heuristic" कहता है: रिस्पॉन्स न Cache-Control सेट करता है न Expires, इसलिए हर कैश अपनी अवधि ख़ुद चुनता है। कैशिंग अनुमान के लायक़ बनाने के लिए साफ़ नीति सेट करें।
दूसरी रिक्वेस्ट भी MISS है: हो सकता है रिस्पॉन्स एज पर कैश होने लायक़ न हो (कुकी, private, कोई BYPASS नियम), या दोनों रिक्वेस्ट अलग नोड पर पहुँचीं। दोबारा चलाएँ, और CDN के कैश नियम देखें।
हेडर आपके ब्राउज़र में दिखने वाले हेडर से अलग हैं: Mutqan सर्वर कोई कुकी नहीं भेजता और तय User-Agent इस्तेमाल करता है, इसलिए लॉगिन, डिवाइस या देश के हिसाब से बदलने वाली साइट उसे अलग जवाब दे सकती है। उन्हें जाँचने के लिए अपने ब्राउज़र के network पैनल से हेडर पेस्ट करें।
"This address cannot be reached from the Mutqan server" जैसा इनकार: निजी, आरक्षित और ब्लॉक पते कभी नहीं माँगे जाते। अंदरूनी सिस्टम के लिए हेडर पेस्ट करें।

HTTP कैश एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल

यह नतीजा किसके कैश के बारे में है?

हेडर वही हैं जो साइट ने Cloudflare नेटवर्क पर चलने वाले Mutqan सर्वर को भेजे। CDN हर क्लाइंट को उसके सबसे नज़दीकी नोड से जवाब देता है, इसलिए कहीं और बैठे विज़िटर को अलग Age या कैश स्टेटस मिल सकता है, और साइट देश, डिवाइस या कुकी के हिसाब से हेडर बदल सकती है। Cache-Control की नीति आमतौर पर हर जगह एक ही होती है; कैश स्टेटस एक नोड की झलक है।

max-age और s-maxage में क्या फ़र्क़ है?

max-age बताता है कि कोई भी कैश, ब्राउज़र समेत, सर्वर से पूछे बिना रिस्पॉन्स कितनी देर दोबारा इस्तेमाल कर सकता है। s-maxage सिर्फ़ CDN और प्रॉक्सी जैसे साझा कैश पर लागू होता है और वहाँ max-age की जगह लेता है, इसलिए साइट पेज को CDN में एक घंटे ताज़ा रख सकती है जबकि ब्राउज़र हर मिनट जाँचते हैं।

क्या no-cache का मतलब है कि रिस्पॉन्स कैश नहीं होता?

नहीं। no-cache कैश को रिस्पॉन्स स्टोर करने देता है, पर हर दोबारा इस्तेमाल से पहले सर्वर से जाँचना ज़रूरी करता है, जो ETag या Last-Modified होने पर 304 Not Modified जवाब से सस्ता पड़ता है। स्टोर करने पर पूरी रोक no-store लगाता है।

दूसरी रिक्वेस्ट HIT और पहली MISS क्यों दिखाती है?

पहली रिक्वेस्ट को उस एज के कैश में कुछ नहीं मिला, इसलिए एज ने पेज ओरिजिन से लिया और नीति ने इजाज़त दी तो स्टोर कर लिया; दूसरी रिक्वेस्ट को उसी स्टोर की गई कॉपी से जवाब मिला। अगर दोनों MISS हों, तो या तो रिस्पॉन्स एज पर कैश होने लायक़ नहीं, या दोनों रिक्वेस्ट अलग-अलग कैश नोड पर पहुँचीं।

तकनीकी नोट्स

RFC 9111 HTTP कैशिंग परिभाषित करता है: Cache-Control डायरेक्टिव तय करते हैं कि रिस्पॉन्स स्टोर हो सकता है या नहीं और कितनी देर (हर कैश के लिए max-age, साझा कैश के लिए s-maxage, max-age न हो तो Expires में से Date घटाकर), Age कैश का अनुमान है कि ओरिजिन सर्वर ने कॉपी कितनी देर पहले बनाई या रीवैलिडेट की थी (RFC 9111 §5.1), और ETag या Last-Modified से पुरानी कॉपी को कंडीशनल रिक्वेस्ट से रीवैलिडेट किया जा सकता है जिसका जवाब 304 Not Modified होता है। immutable RFC 8246 से आता है, और stale-while-revalidate व stale-if-error RFC 5861 से।

URL मोड में तय हेडर प्रोफ़ाइल के साथ POST /api/v1/internet/http/fetch से एक GET भेजा जाता है; रीडायरेक्ट फ़ॉलो होते हैं और अंतिम रिस्पॉन्स जाँचा जाता है, बॉडी एक बाइट तक सीमित रहती है क्योंकि काम सिर्फ़ हेडर का है। दूसरी रिक्वेस्ट रीडायरेक्ट फ़ॉलो किए बिना अंतिम URL पर जाती है।

CDN स्टेटस हेडर वेंडर की परंपराएँ हैं, मानक नहीं: CF-Cache-Status Cloudflare का है (HIT, MISS, EXPIRED, BYPASS, DYNAMIC और दूसरे), X-Cache कई CDN और प्रॉक्सी इस्तेमाल करते हैं, और CDN-Cache-Control या Surrogate-Control सिर्फ़ CDN परत के लिए होते हैं।

सीमाएँ और कार्यप्रणाली

URL Cloudflare नेटवर्क पर चलने वाले Mutqan सर्वर से माँगा जाता है; CDN स्टेटस और Age उस एज के बारे में हैं जिसने उस रिक्वेस्ट का जवाब दिया, जो विज़िटर के सबसे नज़दीकी नोड से अलग हो सकता है।

जाँच सिर्फ़ रिस्पॉन्स हेडर पढ़ती है। यह ब्राउज़र मेमोरी या service worker कैश, हेडर को ओवरराइड करने वाले CDN नियम, या कैश कॉपी को हटाने से पहले असल में कितनी देर रखता है — यह नहीं देख सकती।

रिक्वेस्ट में कोई कुकी या क्रेडेंशियल नहीं जाते, इसलिए लॉगिन सेशन पर निर्भर कैशिंग नहीं दिखती।

सुरक्षा और गोपनीयता

पेस्ट किए हेडर कभी आपके ब्राउज़र से बाहर नहीं जाते। URL मोड में Mutqan सर्वर को URL मिलता है, वह उसे तय हेडर के साथ और आपकी किसी कुकी के बिना एक बार (कहने पर दो बार) माँगता है और कुछ स्टोर नहीं करता; सिर्फ़ रिस्पॉन्स हेडर लौटाए जाते हैं।

संदर्भ

RFC 9111: HTTP CachingIETF · 2022Cache-Control, Expires, ETag और वैलिडेटर कैसे तय करते हैं कि रिस्पॉन्स स्टोर और पुन: उपयोग हो सकता है या नहीं।
HTTP caching — MDNMDN Web Docs (Mozilla)प्राइवेट बनाम शेयर्ड कैश, फ़्रेशनेस, ETag / Last-Modified से वैलिडेशन और आम Cache-Control पैटर्न।
Prevent unnecessary network requests with the HTTP Cacheweb.dev (Google)Cache-Control पर व्यावहारिक गाइड: वर्ज़न वाले URL के साथ लंबा max-age, HTML के लिए ETag के साथ no-cache, निजी डेटा के लिए private, और ब्राउज़र रीवैलिडेट कैसे करते हैं।