CDN রেসপন্স পড়া — curl দিয়ে এজের ভেতরটা দেখা

গল্পে বুঝি

বিরুনি চট্টগ্রাম থেকে রাজশাহীতে মায়ের জন্য একটা পার্সেল পাঠিয়েছিল। চার দিন পর মা ফোন করে বলল, “বাক্সটা এসেছে, কিন্তু ভেতরের আচারের বয়াম ভাঙা।” বিরুনি রাগ করে কুরিয়ার অফিসে গেল। কাউন্টারে বসা কিন্দি তর্ক করল না, বলল, “বাক্সটার গায়ের সিলগুলো দেখান তো।”

বাক্সের গায়ে চারটা স্ট্যাম্প: “আগ্রাবাদ বুকিং, সকাল ১০টা”, “ঢাকা সর্টিং হাব, রাত ২টা, বাক্স ভেজা”, “বগুড়া ট্রানজিট, সকাল ৯টা”, “রাজশাহী ডেলিভারি, বিকাল ৪টা”। কিন্দি বলল, “দেখুন, ঢাকা হাবে লেখা ‘ভেজা’। গোলমাল ওখানে, ডেলিভারিম্যানের দোষ না।” আরেকটা বাক্সে আবার একটাই স্ট্যাম্প ছিল, “রাজশাহী লোকাল স্টক থেকে দেওয়া”, মানে ওটা চট্টগ্রাম থেকে আসেইনি, শহরের গুদামে আগে থেকে রাখা ছিল। আর সব বাক্সে একটা ছোট ট্র্যাকিং নাম্বার থাকে, যার শেষ তিন অক্ষর বলে কোন শাখা শেষবার হাত দিয়েছে।

কিন্দি আরেকটা কথা বলল: “অনেকে মনে করে বাক্স ঠিক এসেছে কারণ বাসার দারোয়ান বলেছে। কিন্তু দারোয়ান হয়তো গত সপ্তাহের বাক্সটাই আবার দেখাচ্ছে, যেটা নিচতলায় পড়ে ছিল। স্ট্যাম্প না দেখে কিছু বিশ্বাস করবেন না।”

মিলিয়ে নিই: বাক্সের গায়ের স্ট্যাম্পগুলো হলো রেসপন্স হেডার। “ঢাকা হাবে ভেজা” হলো Cache-Status বা X-Cache-এর মতো হেডার যা বলে কোন লেয়ারে কী হয়েছিল। “লোকাল স্টক থেকে দেওয়া” হলো cache HIT, চট্টগ্রাম থেকে আসা হলো origin থেকে MISS। বাক্স কত দিন গুদামে পড়ে ছিল তা হলো Age হেডার। ট্র্যাকিং নাম্বারের শেষ অক্ষর হলো কোন PoP উত্তর দিল তার চিহ্ন (যেমন cf-ray-এর শেষ অংশ বা X-Served-By)। আর দারোয়ানের পুরনো বাক্স দেখানো হলো ব্রাউজারের নিজের ক্যাশ, যা CDN পর্যন্ত যায়ই না। কিন্দির পদ্ধতিটাই এই চ্যাপ্টার: অনুমান না, হেডার পড়ুন।

প্রথম নিয়ম: সঠিক কমান্ড দিয়ে দেখুন

curl -I সবসময় ঠিক না

curl -I একটা HEAD রিকোয়েস্ট পাঠায়। অনেক CDN আর origin HEAD আর GET আলাদাভাবে সামলায়: কোথাও HEAD ক্যাশ থেকে উত্তর পায় না, কোথাও origin HEAD-এ আলাদা হেডার দেয়, কোথাও এজ রুল শুধু GET-এ লাগে। ফলে curl -I বলে MISS, অথচ আসল ব্রাউজার HIT পাচ্ছে, অথবা উল্টো।

আসল GET পাঠিয়ে শুধু হেডার দেখুন, বডি ফেলে দিন:

curl -sS -o /dev/null -D - https://baytalhikma.org/books/algebra.jpg

• -sS — প্রগ্রেস বার বন্ধ, কিন্তু এরর দেখাবে
• -o /dev/null — বডি ফেলে দাও
• -D - — রেসপন্স হেডার stdout-এ ছাপো

ব্রাউজারের মতো রিকোয়েস্ট পাঠান

ব্রাউজার Accept-Encoding, Accept, User-Agent পাঠায়; curl ডিফল্টে কম পাঠায়। ক্যাশ কী বা Vary এগুলোর উপর নির্ভর করলে curl আর ব্রাউজার আলাদা কপি পায় (চ্যাপ্টার ৪)। কাছাকাছি আসতে:

curl -sS -o /dev/null -D - --compressed \
  -H 'Accept: text/html' \
  https://baytalhikma.org/

--compressed দিলে curl Accept-Encoding পাঠায়। ঠিক ব্রাউজারের রিকোয়েস্ট চাইলে DevTools-এর Network ট্যাবে রিকোয়েস্টে রাইট-ক্লিক করে “Copy as cURL” নিন।

একটা পূর্ণ রেসপন্স পড়া

নিচের রেসপন্সটা দেখানোর জন্য বানানো, কিন্তু প্রতিটা হেডার বাস্তব:

HTTP/2 200
date: Sun, 25 Oct 2026 08:14:02 GMT
content-type: image/jpeg
content-length: 184213
cache-control: public, max-age=86400
etag: "5f2a-63b1c9"
last-modified: Mon, 19 Oct 2026 11:02:40 GMT
age: 5321
vary: Accept-Encoding
cache-status: "ExampleCDN-edge"; hit; ttl=81079
via: 1.1 edge-dac-03 (ExampleCDN)
server-timing: cdn-cache;desc=HIT, edge;dur=2

লাইন ধরে ধরে:

হেডার	কে দেয়	কী বলে
cache-control	origin (বা CDN রুল)	কতক্ষণ ক্যাশ করা যাবে (চ্যাপ্টার ৩)
etag, last-modified	origin	revalidation-এর জন্য ভার্সন চিহ্ন
age	ক্যাশ	এই কপি ক্যাশে কত সেকেন্ড ধরে আছে
cache-status	প্রতিটা ক্যাশ লেয়ার	HIT/MISS আর কেন (RFC 9211)
via	প্রক্সি/CDN	রিকোয়েস্ট কোন প্রক্সি দিয়ে গেছে
server-timing	যে কেউ	কোন ধাপে কত মিলিসেকেন্ড

Age: সবচেয়ে বিশ্বস্ত চিহ্ন

Age ভেন্ডর-নিরপেক্ষ, স্ট্যান্ডার্ড (RFC 9111)। age: 5321 মানে কপিটা ৫৩২১ সেকেন্ড আগে origin থেকে এসেছিল। পরপর দুইবার রিকোয়েস্ট করুন:

age: 5321
age: 5323

Age বাড়ছে মানে আপনি একই ক্যাশড কপি পাচ্ছেন: HIT। প্রতিবার age: 0 বা হেডারটাই নেই মানে সম্ভবত প্রতিবার origin থেকে আসছে। দুইবার দুই রকম বড় সংখ্যা (age: 5321, তারপর age: 210) মানে দুইটা আলাদা এজ সার্ভার বা PoP উত্তর দিচ্ছে, যাদের ক্যাশ আলাদা।

তাজাভাবের হিসাব:

বাকি তাজা সময় = max-age (বা s-maxage) − Age
             = 86400 − 5321 = 81079 সেকেন্ড

উপরের cache-status-এর ttl=81079 ঠিক এটাই বলছে।

Cache-Status: স্ট্যান্ডার্ড ভাষায় HIT/MISS (RFC 9211)

আগে প্রতিটা CDN নিজের হেডার বানাত। RFC 9211 একটা কমন ফরম্যাট দিয়েছে: প্রতিটা ক্যাশ লেয়ার নিজের একটা এন্ট্রি যোগ করে, origin-এর কাছের লেয়ার আগে, ইউজারের কাছের লেয়ার পরে।

cache-status: "Shield-SIN"; fwd=uri-miss; stored, "Edge-DAC"; fwd=uri-miss; stored

পড়ুন ডান থেকে বাঁয়ে, ইউজারের দিক থেকে: ঢাকার এজে কপি ছিল না (uri-miss), সে সিঙ্গাপুরের shield-কে জিজ্ঞেস করল; সেখানেও ছিল না, shield origin থেকে আনল; দুইজনই কপিটা রেখে দিল (stored)। পরের রিকোয়েস্টে:

cache-status: "Shield-SIN"; hit, "Edge-DAC"; hit; ttl=3590

অথবা যদি ঢাকার কপি থাকে, তাহলে শুধু "Edge-DAC"; hit — shield-এর কাছে যাওয়াই লাগেনি।

গুরুত্বপূর্ণ প্যারামিটার:

প্যারামিটার	মানে
hit	এই লেয়ার ক্যাশ থেকে দিয়েছে, পরের দিকে যায়নি
fwd=uri-miss	এই URL-এর কোনো কপি নেই
fwd=vary-miss	URL-এর কপি আছে, কিন্তু Vary মেলেনি
fwd=miss	কপি নেই, কারণ নির্দিষ্ট না
fwd=stale	কপি ছিল, কিন্তু মেয়াদ শেষ, তাই সামনে পাঠাল
fwd=request	রিকোয়েস্ট নিজেই ক্যাশ এড়াতে বলেছে (যেমন no-cache)
fwd=bypass	কনফিগ বলেছে এটা ক্যাশ লুকআপ করো না
fwd-status=304	সামনের সার্ভার কী স্ট্যাটাস দিয়েছিল (revalidation হলে 304)
ttl=N	আর কত সেকেন্ড তাজা
stored	এবার পাওয়া রেসপন্স রেখে দিয়েছে
collapsed	একই জিনিসের অন্য রিকোয়েস্টের সাথে জুড়ে একটা fetch হয়েছে (চ্যাপ্টার ৭)
key=...	ক্যাশ কী (কিছু ক্যাশ দেখায়)
detail=...	ভেন্ডরের নিজস্ব বাড়তি তথ্য

ভেন্ডর হেডার

Cache-Status-এর আগের যুগের হেডারগুলো এখনো সবচেয়ে বেশি দেখবেন। ২০২৬ সালের অক্টোবর অনুযায়ী ভেন্ডরের নিজের ডক থেকে যাচাই করা:

Cloudflare: cf-cache-status

ভ্যালু	মানে
HIT	ক্যাশে ছিল
MISS	ক্যাশযোগ্য, কিন্তু ছিল না; origin থেকে আনা
EXPIRED	ছিল, মেয়াদ শেষ; origin থেকে আবার আনা
STALE	মেয়াদ শেষ কপি দেওয়া হয়েছে কারণ origin-এ পৌঁছানো যায়নি
UPDATING	মেয়াদ শেষ কপি দেওয়া হয়েছে, পেছনে origin থেকে রিফ্রেশ চলছে
REVALIDATED	origin conditional রিকোয়েস্টে বলেছে কপি বদলায়নি
BYPASS	রিকোয়েস্ট ক্যাশযোগ্য ছিল, কিন্তু origin-এর রেসপন্স ক্যাশযোগ্য না
DYNAMIC	Cloudflare আগেই ঠিক করেছে এটা ক্যাশযোগ্য না, লুকআপই হয়নি
NONE / UNKNOWN	ক্যাশের প্রশ্নই আসেনি (Worker-এর রেসপন্স, WAF ব্লক, রিডাইরেক্ট)

DYNAMIC আর BYPASS-এর পার্থক্য ডিবাগিংয়ে গুরুত্বপূর্ণ: DYNAMIC মানে CDN-এর রুল (যেমন HTML ডিফল্টে ক্যাশ হয় না) ক্যাশ করতে দেয়নি; BYPASS মানে origin-এর হেডার (যেমন no-store, private, বা Set-Cookie) দেয়নি। প্রথমটার সমাধান CDN রুলে, দ্বিতীয়টার origin-এ।

Cloudflare-এর https://আপনার-ডোমেইন/cdn-cgi/trace এন্ডপয়েন্ট বলে কোন ডেটা সেন্টার আপনাকে সার্ভ করছে (Cloudflare-এর ডক এটা এই কাজের জন্যই উল্লেখ করে):

curl -s https://baytalhikma.org/cdn-cgi/trace | grep -E '^(colo|loc|ip|http|tls)='

ip=203.0.113.45
loc=BD
colo=DAC
http=http/2
tls=TLSv1.3

(আউটপুট দেখানোর জন্য বানানো; ফিল্ডগুলো নিজে চালিয়ে মিলিয়ে নিন।) cf-ray হেডারের শেষেও সাধারণত একটা তিন অক্ষরের লোকেশন কোড থাকে, যেমন cf-ray: 8d2f1a7c3e9b40aa-DAC। সাপোর্ট টিকেটে এই রে আইডিটা দিন, ওরা ঠিক রিকোয়েস্টটা খুঁজে পায়।

Fastly: X-Cache, X-Served-By

Fastly-র ডক অনুযায়ী X-Cache শুধু HIT বা MISS। কিছু জিনিস খেয়াল রাখার মতো: যে রিকোয়েস্ট ইচ্ছা করে ক্যাশ পাশ কাটিয়েছে (PASS), সেটাও MISS দেখায়; আর stale কপি বা পেছনে revalidation চলার সময়ের রেসপন্স HIT দেখায়। shielding চালু থাকলে একাধিক সার্ভারের রিপোর্ট কমা দিয়ে আসে:

x-served-by: cache-sin-xxxx-SIN, cache-dac-xxxx-DAC
x-cache: MISS, HIT

(আউটপুট দেখানোর জন্য বানানো।) এখানে ঢাকার এজে HIT, তাই shield আর origin-এ যেতে হয়নি। Fastly-র ডক বলে, restart ছাড়া MISS বাদে যেকোনো এন্ট্রি মানে রিকোয়েস্ট origin-এ যায়নি। X-Served-By-এর নামের ধরন ভেন্ডর বদলাতে পারে, তাই প্যাটার্ন নিজে দেখে নিন।

অন্যরা

CloudFront, Akamai, Bunny, Gcore এবং অন্যরা X-Cache, X-Cache-Status, বা নিজস্ব নামে একই ধরনের হেডার দেয়, কেউ কেউ শুধু একটা বিশেষ debug রিকোয়েস্ট হেডার পাঠালে দেয়। ভেন্ডর বদলালে প্রথম কাজ: ডকে খুঁজুন “cache status header” আর “debug header”। নাম যাই হোক, প্রশ্ন একই তিনটা: এই লেয়ারে ছিল কি? না থাকলে কেন? আর কে উত্তর দিল?

কোন PoP উত্তর দিচ্ছে, আর একটা নির্দিষ্ট এজকে জিজ্ঞেস করা

“আমার এখানে ঠিক আছে, সিঙ্গাপুরের ইউজার বলছে পুরনো ফাইল” — এমন সমস্যায় আপনাকে অন্য PoP-কে জিজ্ঞেস করতে হবে। উপায় তিনটা:

1. ওই এলাকার একটা মেশিন থেকে চালান — একটা ছোট VPS, বা কোনো মাল্টি-লোকেশন টেস্টিং সার্ভিস।
2. --resolve দিয়ে নির্দিষ্ট এজ IP-তে পাঠান — যে CDN-এ আলাদা PoP-এর আলাদা IP (unicast বা GeoDNS) আছে, সেখানে কাজ করে।
3. anycast CDN-এ IP সব জায়গায় এক, তাই রাউটিং ঠিক করে কোন PoP। তখন প্রথম উপায়টাই একমাত্র ভরসা।

--resolve DNS এড়িয়ে নির্দিষ্ট IP-তে কানেক্ট করে, কিন্তু SNI আর Host ঠিক রাখে, তাই TLS আর ক্যাশ কী সঠিক থাকে:

# Ask one specific edge IP, keeping the real hostname for SNI and Host
curl -sS -o /dev/null -D - \
  --resolve baytalhikma.org:443:198.51.100.20 \
  https://baytalhikma.org/books/algebra.jpg

এজ বাইপাস করে origin-এ সরাসরি

“সমস্যা CDN-এ নাকি origin-এ?” — এটা প্রায় সব CDN ডিবাগিংয়ের প্রথম প্রশ্ন। origin-এর IP-তে সরাসরি একই রিকোয়েস্ট পাঠান:

# Same request straight to the origin, bypassing the CDN
curl -sS -o /dev/null -D - \
  --resolve baytalhikma.org:443:203.0.113.10 \
  https://baytalhikma.org/books/algebra.jpg

origin অন্য হোস্টনেমে থাকলে (যেমন origin.baytalhikma.org) কিন্তু আপনি পাবলিক হোস্টনেমের কনফিগ টেস্ট করতে চান, --connect-to ব্যবহার করুন: URL আর SNI থাকে পাবলিক নামে, TCP কানেকশন যায় অন্য হোস্টে।

curl -sS -o /dev/null -D - \
  --connect-to baytalhikma.org:443:origin.baytalhikma.org:443 \
  https://baytalhikma.org/

origin সঠিক উত্তর দিচ্ছে আর CDN ভুল দিচ্ছে, মানে সমস্যা ক্যাশে (পুরনো কপি, ভুল কী, ভুল রুল)। origin নিজেই ভুল দিচ্ছে, মানে CDN নির্দোষ; পার্জ করে লাভ নেই।

সময় কোথায় যাচ্ছে: curl -w

হেডার বলে কী হয়েছে; টাইমিং বলে কত খরচ হয়েছে। একটা টেমপ্লেট ফাইল বানান:

# ~/.curl-timing
     dns:  %{time_namelookup}s
 connect:  %{time_connect}s
     tls:  %{time_appconnect}s
    ttfb:  %{time_starttransfer}s
   total:  %{time_total}s
    size:  %{size_download} bytes
  remote:  %{remote_ip}
    http:  %{http_version}

curl -sS -o /dev/null -w @"$HOME/.curl-timing" https://baytalhikma.org/books/algebra.jpg

একটা MISS আর একটা HIT পাশাপাশি (দেখানোর জন্য বানানো সংখ্যা, ঢাকা থেকে, origin ফ্রাঙ্কফুর্টে):

            MISS        HIT
     dns:  0.012s      0.001s
 connect:  0.019s      0.018s
     tls:  0.041s      0.040s
    ttfb:  0.412s      0.047s
   total:  0.498s      0.061s

প্রতিটা সংখ্যা শুরু থেকে জমা (cumulative), তাই ধাপগুলোর পার্থক্য দেখুন:

ধাপ	হিসাব	কী বলে
DNS	dns	রেজলভার কত সময় নিল (DNS ট্র্যাক)
TCP	connect − dns	এজ কত দূরে; কাছের PoP হলে কয়েক মিলিসেকেন্ড
TLS	tls − connect	হ্যান্ডশেক; এজে TLS শেষ হয়, তাই এটাও কাছের PoP-এর উপর নির্ভর করে
সার্ভার	ttfb − tls	HIT হলে এজের ভেতরের সময়; MISS হলে এর মধ্যে origin পর্যন্ত যাওয়া-আসা
ডাউনলোড	total − ttfb	সাইজ আর ব্যান্ডউইথ

উপরের উদাহরণে connect আর TLS দুইবারই প্রায় সমান, কারণ দুইবারই ঢাকার কাছের এজ। পার্থক্য শুধু ttfb − tls-এ: MISS-এ প্রায় ৩৭০ ms (ফ্রাঙ্কফুর্ট পর্যন্ত যাওয়া-আসা আর origin-এর কাজ), HIT-এ ৭ ms। connect নিজেই ১০০ ms-এর বেশি হলে আপনি কাছের PoP-এ যাচ্ছেন না, সমস্যা রাউটিং বা DNS-এ (চ্যাপ্টার ২)।

ব্রাউজার DevTools আর ব্রাউজার ক্যাশের মিথ্যা

DevTools-এর Network ট্যাব কাজের, কিন্তু একটা ফাঁদ আছে: ব্রাউজারের নিজের ক্যাশ। Size কলামে “(disk cache)” বা “(memory cache)” লেখা থাকলে রিকোয়েস্টটা নেটওয়ার্কেই যায়নি; যে হেডার দেখছেন সেগুলো আগের কোনো সময়ের, সেই সময়ের Age আর cf-cache-status সহ। CDN-এ পার্জ করার পরও এই কপি দেখাবে।

নিয়ম:

1. ডিবাগ করার সময় DevTools-এ “Disable cache” টিক দিন (DevTools খোলা থাকলেই কাজ করে)।
2. স্ট্যাটাস 304 মানে ব্রাউজার জিজ্ঞেস করেছিল “আমার কপি কি এখনো ঠিক?”, সার্ভার বলেছে “হ্যাঁ”। বডি আসেনি, কিন্তু নেটওয়ার্কে গিয়েছিল।
3. Service Worker থাকলে Size কলামে “(ServiceWorker)” দেখাবে; সেটা আরেকটা ক্যাশ লেয়ার, Application ট্যাব থেকে বন্ধ বা আনরেজিস্টার করে টেস্ট করুন।
4. সন্দেহ হলে curl-ই চূড়ান্ত সত্য, কারণ curl-এর কোনো ক্যাশ নেই।

লেয়ার, ইউজার থেকে origin পর্যন্ত:

Service Worker → ব্রাউজার memory/disk cache → (কর্পোরেট প্রক্সি)
→ CDN এজ → CDN shield → origin-এর সামনের রিভার্স প্রক্সি ক্যাশ → অ্যাপ

প্রতিটা লেয়ার আলাদা ক্যাশ, আলাদা TTL। “পুরনো কন্টেন্ট” সমস্যায় কাজ হলো খুঁজে বের করা কোন লেয়ার পুরনোটা ধরে রেখেছে।

একটা ছোট ডিবাগ স্ক্রিপ্ট

একই URL তিনবার চাইলে HIT/MISS, Age-এর গতি আর এজ বদল সব একবারে দেখা যায়:

#!/usr/bin/env bash
# Usage: cdnprobe URL [count]
url="$1"; n="${2:-3}"
for i in $(seq 1 "$n"); do
  curl -sS -o /dev/null -D - --compressed "$url" \
    | grep -iE '^(age|cache-status|cf-cache-status|x-cache|x-served-by|cf-ray|via):' \
    | tr '\r\n' '  '
  echo
  sleep 1
done

$ cdnprobe https://baytalhikma.org/books/algebra.jpg
age: 0  cf-cache-status: MISS  cf-ray: 8d2f...-DAC
age: 1  cf-cache-status: HIT   cf-ray: 8d2f...-DAC
age: 2  cf-cache-status: HIT   cf-ray: 8d2f...-DAC

(আউটপুট দেখানোর জন্য বানানো।) প্রথমবার MISS, তারপর HIT আর Age বাড়ছে: স্বাস্থ্যকর। তিনবারই MISS হলে রেসপন্স ক্যাশই হচ্ছে না; চ্যাপ্টার ৩-এর হেডার আর চ্যাপ্টার ৪-এর ক্যাশ কী দেখুন।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত করার উপায়	সমাধান
curl -I বলে MISS, ব্রাউজারে দ্রুত	curl -sS -o /dev/null -D - দিয়ে আসল GET পাঠান	HEAD দিয়ে সিদ্ধান্ত নেবেন না
curl-এ HIT, ব্রাউজারে MISS (বা উল্টো)	DevTools থেকে “Copy as cURL” করে চালান	পার্থক্য Vary বা ক্যাশ কী-তে; চ্যাপ্টার ৪
সবসময় MISS	cdnprobe তিনবার; cache-control, set-cookie, vary দেখুন	origin হেডার ঠিক করুন (চ্যাপ্টার ৩)
Cloudflare-এ DYNAMIC	রেসপন্সের content type HTML কিনা	HTML ক্যাশ করতে চাইলে CDN-এ cache rule লাগবে
Cloudflare-এ BYPASS	origin no-store, private বা Set-Cookie পাঠাচ্ছে কিনা	origin ঠিক করুন, অথবা ইচ্ছাকৃত হলে মেনে নিন
Age লাফাচ্ছে (৫০০০, ২০, ৪০০০)	cf-ray বা x-served-by প্রতিবার বদলাচ্ছে কিনা	স্বাভাবিক, একাধিক এজ; সমস্যা হলে origin shield (চ্যাপ্টার ৭)
এক দেশে পুরনো কন্টেন্ট	ওই দেশের VPS থেকে cdnprobe, Age দেখুন	ওই PoP-এ পার্জ পৌঁছায়নি, বা origin-এর আরেকটা ইনস্ট্যান্স পুরনো
পার্জের পরও পুরনো দেখাচ্ছে	curl-এ নতুন কিন্তু ব্রাউজারে পুরনো	ব্রাউজার বা Service Worker ক্যাশ; ভার্সনড URL (চ্যাপ্টার ৬)
ttfb বেশি কিন্তু HIT	curl -w দিয়ে connect আর TLS আলাদা করে দেখুন	connect বেশি হলে দূরের PoP, রাউটিং বা DNS দেখুন
origin-এ সরাসরি গেলে ঠিক, CDN দিয়ে ভুল	--resolve দিয়ে origin, তারপর এজ	ক্যাশড পুরনো কপি বা CDN রুল; পার্জ বা রুল ঠিক করুন
origin নিজেই ভুল দিচ্ছে	একই --resolve origin টেস্ট	CDN নির্দোষ; অ্যাপ বা ডিপ্লয় দেখুন

মূল শিক্ষা

1. curl -I না, আসল GET দিয়ে হেডার দেখুন। curl -sS -o /dev/null -D -।
2. Age স্ট্যান্ডার্ড আর বিশ্বস্ত। বাড়ছে মানে HIT, শূন্য মানে origin, লাফাচ্ছে মানে আলাদা এজ।
3. Cache-Status ডান থেকে বাঁয়ে পড়ুন: ইউজারের কাছের লেয়ার শেষে।
4. ভেন্ডর হেডারের ভ্যালু শিখুন, বিশেষ করে “কেন ক্যাশ হলো না” অংশটা (যেমন DYNAMIC বনাম BYPASS)।
5. --resolve আর --connect-to দিয়ে নির্দিষ্ট এজ বা origin-কে জিজ্ঞেস করুন। HTTPS-এ শুধু Host হেডার যথেষ্ট না।
6. প্রথম প্রশ্ন সবসময়: origin সঠিক কিনা। origin ভুল হলে CDN-এ কিছু করে লাভ নেই।
7. curl -w দিয়ে সময় ভাগ করুন। connect বলে দূরত্ব, ttfb − tls বলে ক্যাশ আর origin।
8. ব্রাউজারের ক্যাশ CDN-এর ক্যাশ না। ডিবাগিংয়ে “Disable cache”, আর সন্দেহ হলে curl।