اینترنت و شبکه

سی دی ان (CDN) چیست

سی دی ان شبکه ای از سرورها در نقاط مختلف دنیاست که کپی فایل های سایت شما را نگه می دارند تا هر بازدیدکننده از نزدیک ترین نقطه سرویس بگیرد. مهم ترین نکته ای که معمولا گفته نمی شود این است که سی دی ان به طور پیش فرض تصویر و فونت و فایل های ثابت را نگه می دارد و خود صفحه ها را نه؛ اینکه صفحه های شما هم در لبه بمانند یک قاعده جداگانه است که یا تعریفش کرده اید یا نکرده اید.

  • درس ۸ از ۱۲
  • مقدماتی
  • رایگان، بدون ثبت نام

یک سرور اصلی، ده ها کپی، و بازدیدکننده ای که نزدیک ترین را می گیرد

سرور اصلی

یک جا، و تنها جایی که محتوای تازه از آن بیرون می آید

  • سایت واقعا اینجا زندگی می کند
  • هر تغییری اول اینجا اتفاق می افتد
  • درخواست صفحه ها معمولا تا همین جا می آید
فقط برای آنچه لبه نگه داشته

بازدیدکننده ها

هر جای دنیا، هر کدام با فاصله خودشان

  • هر چه دورتر، سهم رفت و برگشت بیشتر
  • تصویر و فونت را از نزدیک می گیرند
  • مرورگرشان هم خودش یک کش جداگانه دارد

وقتی گره لبه کپی را داشته باشد، سرور اصلی اصلا خبردار نمی شود که کسی آمده است

گره های لبه

ده ها نقطه که فقط کپی نگه می دارند

  • هیچ وقت محتوای تازه نمی سازند
  • به قاعده پیش فرض تصمیم می گیرند، نه به خواسته شما
  • کپی را تا وقتی تازه بدانند نگه می دارند

این شکل مسیر چیزی را نشان می دهد که لبه نگهش داشته باشد. صفحه ها پیش فرض جزو آنها نیستند و فقط با یک قاعده صریح از خط وسط رد می شوند.

آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.

سی دی ان دقیقا چه کاری می کند؟

سایت شما روی یک سرور نشسته، در یک شهر مشخص. یک بازدیدکننده در همان شهر و یک بازدیدکننده در آن سر دنیا هر دو باید به همان یک ماشین برسند، و دومی ناچار است فاصله را تحمل کند. سی دی ان این فاصله را با یک ترفند ساده کوتاه می کند: کپی فایل ها را در ده ها نقطه دنیا نگه می دارد و هر درخواست را به نزدیک ترین نقطه می فرستد.

دو اصطلاح لازم است و بقیه اش جزئیات است. سرور اصلی همان ماشینی است که سایت واقعا روی آن است و تنها جایی است که محتوای تازه از آن بیرون می آید. گره لبه یکی از آن ده ها نقطه است که فقط کپی نگه می دارد. وقتی گره لبه چیزی را داشته باشد، خودش جواب می دهد و سرور اصلی اصلا خبردار نمی شود.

سود اصلی هم همین جاست و دوتاست. برای بازدیدکننده، مسیر کوتاه تر می شود. برای شما، بار سرور کم می شود، چون هر فایلی که لبه جواب داده یک درخواست است که به ماشین شما نرسیده. روی همین سایت، یک فایل فونت را که اندازه گرفتیم، لبه ۹۶ ساعت بود که کپی اش را نگه داشته بود و در تمام این مدت یک بار هم آن را از سرور ما نخواسته بود.

نقشه برجسته با یک برج مبدا سفید، برج های لبه آبی زیاد و خطوط قرمزی که به نزدیک ترین برج سبز می رسند

چه چیزی واقعا در لبه می ماند و چه چیزی نه؟

اینجا همان جایی است که تصور بیشتر صاحبان سایت با واقعیت جور در نمی آید، ولی نه به آن شکلی که فکر می کنید. تصور رایج این است که «سایتم را روی سی دی ان گذاشتم، پس صفحه هایم از نزدیک ترین نقطه سرو می شوند». این جمله به طور پیش فرض غلط است، و هر جا درست باشد به این دلیل است که کسی یک قاعده صریح برایش تعریف کرده.

پیش فرض بر اساس پسوند فایل تصمیم می گیرد و نه بر اساس نوع محتوا. ارائه دهنده ای که این سایت پشت آن است، در مستندات خودش فهرست پسوندهایی را که پیش فرض نگه می دارد منتشر کرده: تصویر و فونت و فایل استایل و اسکریپت در آن هستند و صفحه های HTML صریحا نیستند. یعنی سایتی که تازه پشت یک سی دی ان می رود، فایل هایش را در لبه دارد و صفحه هایش را ندارد.

روی همین سایت آن قاعده اضافه شده و نتیجه اش قابل اندازه گیری است. پنج نشانی مختلف را گرفتیم و هر پنج تا از لبه جواب دادند؛ عمر کپی صفحه اول بین دو درخواست پشت سر هم از ۱۲۶ به ۱۲۷ ثانیه رفت، یعنی لبه دارد نسخه ذخیره شده خودش را می دهد و اصلا سراغ سرور ما نمی رود. در همان لحظه یک فایل فونت با کپی ۹۶ ساعته و یک تصویر با کپی ۱۷۴ ساعته، یعنی بیش از هفت روز، از لبه جواب دادند.

یک تکه دیگر که ارزش دیدن دارد: صفحه های این سایت دو هدر کش متفاوت با دو مخاطب متفاوت می فرستند. به مرورگر می گویند هر بار دوباره بپرس، و به لبه می گویند سی روز نگهش دار. اینها با هم متناقض نیستند؛ دو گیرنده مختلف اند، و همین است که اجازه می دهد یک صفحه هم در لبه بماند و هم برای کسی که وارد حسابش شده تازه بماند.

و حالا تله ای که یک بعدازظهر را می خورد و تقریبا هیچ جا نوشته نشده: اگر با درخواست HEAD بررسی کنید جواب غلط می گیرید. روی همین صفحه اول، درخواست HEAD می گوید محتوا پویا در نظر گرفته شده و درخواست GET روی همان نشانی و در همان لحظه می گوید از لبه آمد. دلیلش این است که قاعده کش فقط درخواست های GET را شامل می شود. اگر روزی مطمئن بودید صفحه هایتان باید کش شوند و هدر خلافش را گفت، اول به شکل درخواست خودتان شک کنید و بعد به تنظیمات.

تصمیمی که لبه برای هر درخواست می گیرد

آیا این چیز از آنهایی است که لبه پیش فرض نگه می دارد؟

بله

از لبه جواب می گیرد

  • تصویر، فونت، فایل های سبک: پسوندشان در فهرست پیش فرض است
  • سرور اصلی هیچ کاری انجام نمی دهد
  • روی این سایت کپی ها ۹۶ و ۱۷۴ ساعته بودند
خیر

پیش فرض تا سرور اصلی می رود

  • خود صفحه ها: پیش فرض کش نمی شوند
  • بدون قاعده صریح، هر بازدید یک درخواست کامل به ماشین شماست
  • روی این سایت آن قاعده اضافه شده، پس صفحه ها هم از لبه می آیند

این تصمیم پیش فرض است و با یک قاعده صریح عوض می شود. رفتار پیش فرض هر ارائه دهنده هم با دیگری فرق دارد، پس تنها مرجع، هدر پاسخ خود سایت شماست.

برای بازدیدکننده ایرانی یک سایت خارجی چه فرقی می کند؟

منطقش ساده است و اثرش نامتقارن. هر چه بازدیدکننده از سرور اصلی دورتر باشد، سهم بیشتری از زمان صرف رفت و برگشت می شود، و دقیقا در همین حالت است که یک کپی نزدیک بیشترین سود را دارد. برای بازدیدکننده ای که در همان شهر سرور است، لبه تقریبا هیچ چیزی اضافه نمی کند.

ولی نصف ماجرا همان بخش قبل است. اگر برای صفحه ها قاعده ای تعریف نشده باشد، آن بازدیدکننده دور همچنان برای خود صفحه تا سرور اصلی می رود و فقط تصویرها و فونت ها را از نزدیک می گیرد. اگر تعریف شده باشد، خود صفحه هم از لبه می آید و بیشترین سود این کار دقیقا همان جا در می آید. پس اندازه سودی که می برید به یک تصمیم پیکربندی بستگی دارد، نه به اینکه سرویس را خریده اید.

حالا صادقانه بگوییم این درس چه چیزی را نمی داند. ما نمی توانیم اندازه بگیریم که یک بازدیدکننده در ایران چه مسیری طی می کند و کدام گره لبه به او جواب می دهد، چون این سرور در اروپاست و هر اندازه گیری از اینجا فقط مسیر خودش را نشان می دهد. هر عددی که یک آموزش درباره «سرعت سی دی ان از ایران» به شما بدهد، اگر از داخل ایران گرفته نشده باشد، ساختگی است. تنها آزمایش معتبر این است که خود شما یا یکی از کاربرانتان از همان جایی که واقعا هستید اندازه بگیرید.

تغییری که می دهید کی به بازدیدکننده می رسد؟

این عملی ترین بخش کل موضوع است و همان جایی است که تیم های تازه کار وقت زیادی را هدر می دهند. جواب کوتاه: هر چیزی که در لبه نشسته باشد، تا وقتی لبه آن را تازه بداند عوض نمی شود. و اگر صفحه هایتان هم کش شده باشند، این شامل خود صفحه ها هم می شود؛ ویرایش روی سرور انجام شده و بازدیدکننده هنوز نسخه قبلی را می بیند.

دلیلش را همین درس تا اینجا داده است. فایل های ثابت این سایت با اجازه یک ساله کش می شوند و همان طور که دیدید یکی از آنها همین حالا کپی ۱۷۴ ساعته دارد. اگر همان فایل را با همان نام عوض کنید، لبه دلیلی ندارد دوباره بپرسد؛ کپی اش هنوز از نظر خودش تازه است. صفحه ها هم با اجازه سی روزه در لبه نشسته اند. و مرورگر بازدیدکننده کش خودش را دارد، که آن یکی حتی از دسترس شما بیرون است.

برای فایل های ثابت راه حل حرفه ای پاک کردن کش نیست، عوض کردن نام است. اگر نشانی فایل تغییر کند، دیگر همان فایل نیست و همه از سر می گیرند. روی همین سایت فایل های افزونه ها یک شماره نسخه در نشانی دارند و همین یک قاعده کوچک، تفاوت بین «تغییر دادم و هیچ اتفاقی نیفتاد» و «تغییر دادم و همان لحظه دیده شد» است. صریح بگوییم چون خودمان بهایش را داده ایم: یک ویرایش در فایل استایل یک افزونه، بدون بالا بردن شماره نسخه، عملا هیچ چیزی را برای بازدیدکننده عوض نمی کند. برای خود صفحه ها این ترفند باز نیست، چون نشانی صفحه همان چیزی است که در گوگل ثبت شده و عوض کردنش خودش یک ضرر است؛ آنجا تنها راه، پاک کردن هدفمند همان چند نشانی است.

و درباره پاک کردن کش، یک هشدار که در تبلیغ ها نیست. پاک کردن مجانی نیست. هر صفحه ای که از کش بیرون انداخته می شود باید دوباره ساخته شود، و اگر کل سایت را یکجا پاک کنید همه آن ساختن ها همزمان به سرور شما می رسد. روی سروری که چند سایت روی آن است، یک پاک کردن سراسری بی موقع می تواند همه شان را با هم کند کند. قاعده ما این است: فقط همان نشانی هایی را پاک کنید که واقعا عوض شده اند.

عمر یک تغییر، از ویرایش تا چشم بازدیدکننده

  1. ۱

    فایل را روی سرور عوض می کنید

    از این لحظه سرور اصلی نسخه تازه را دارد. تنها جایی که دارد.

  2. ۲

    لبه هنوز نسخه قدیم را دارد

    و دلیلی هم ندارد دوباره بپرسد، چون از نظر خودش کپی اش تازه است.

  3. ۳

    مرورگر بازدیدکننده هم نسخه قدیم را دارد

    این یکی از دسترس شما بیرون است و با هیچ پاک کردنی از سمت شما خالی نمی شود.

  4. ۴

    نام فایل را عوض کنید، تمام

    نشانی تازه یعنی فایل تازه، پس همه از سر می گیرند. این کار جای پاک کردن کش را می گیرد و ریسکش صفر است. برای خود صفحه ها این راه باز نیست.

این ترتیب برای یک فایل ثابت است. برای صفحه ای که در لبه نشسته هم همین اتفاق می افتد، با این تفاوت که نشانی صفحه را نمی شود عوض کرد و تنها راه، پاک کردن هدفمند همان نشانی است.

کی سی دی ان به درد شما نمی خورد؟

یک موضع صریح بگیریم، چون تقریبا هیچ منبعی این را نمی گوید. اگر همه بازدیدکننده های شما در یک کشورند و سرور اصلی هم در همان کشور است، سی دی ان به سرعت آنها چیز زیادی اضافه نمی کند و حتی می تواند یک ایستگاه اضافه به مسیر صفحه اضافه کند. در این حالت پول و پیچیدگی اش را بابت چیز دیگری می دهید، نه بابت سرعت.

ولی این به معنی بی فایده بودنش نیست، و کسانی که سی دی ان را فقط ابزار سرعت می دانند نصف ماجرا را ندیده اند. سه سود دیگر مستقل از فاصله اند: جذب کردن ترافیک غیرعادی پیش از رسیدن به سرور شما، سرو کردن فایل های ثابت بدون بار انداختن روی ماشین اصلی، و مدیریت گواهی و اتصال امن در لبه. برای خیلی از سایت ها همین دومی به تنهایی ارزشش را دارد.

و سه هزینه واقعی که باید با چشم باز پذیرفت. یک لایه دیگر برای عیب یابی اضافه می شود و از این به بعد وقتی چیزی خراب است باید بپرسید سرور یا لبه. تغییرها با تاخیر می رسند: فایل ثابت تا وقتی نامش عوض نشود و صفحه تا وقتی همان نشانی پاک نشود. و رفتار پیش فرض هر ارائه دهنده با دیگری فرق دارد و در طول زمان هم عوض می شود، پس تنها منبع قابل اعتماد هدر پاسخ خودتان است و نه چیزی که شش ماه پیش جایی خوانده اید.

اگر گلوگاه سایت شما ساخته شدن صفحه است و نه فاصله، کار درست جای دیگری است و در مسیر افزایش سرعت سایت دنبال می شود.

مسیر سریع با هوش مصنوعی

راه معمولی فهمیدن اینکه سی دی ان چه کار می کند، باز کردن پنل آن و نگاه کردن به تنظیم هاست. راه سریع برعکس است: تنظیمات را نادیده بگیرید و هدرهای واقعی چند نشانی از سایت خودتان را بردارید، چون تنظیم می گوید چه چیزی خواسته شده و هدر می گوید چه اتفاقی افتاده. همین یک بازرسی، که ده دقیقه وقت می برد، معمولا دو یا سه چیز را نشان می دهد که صاحب سایت فکر می کرد جور دیگری است.

  1. شش نشانی از سایت خودتان بردارید که نمونه واقعی باشند: صفحه اول، یک صفحه داخلی، یک نوشته بلاگ، یک تصویر، یک فایل استایل و یک فونت.
  2. برای هر کدام هدرها را با یک درخواست GET بگیرید و نه HEAD: curl -s --compressed -D - -o /dev/null https://example.com/path. دلیلش در بخش دوم آمد و کل این بازرسی به آن بند است. سه خط از هر پاسخ مهم است و بقیه اش را می شود دور ریخت: وضعیت کش لبه، عمر کپی، و هدر کش خود شما.
  3. هر شش تا را با هم و با دستور زیر بدهید، نه یکی یکی. تمام ارزش این کار در مقایسه ردیف هاست: وقتی صفحه ها یک چیز بگویند و فایل ها چیز دیگری، الگو خودش را نشان می دهد. مدل سریع و ارزان کافی است؛ انتخاب امروزی هر رده در مرجع هوش مصنوعی نگه داشته می شود.
  4. جواب را به یک تصمیم تبدیل کنید و نه به یک گزارش. اگر فایل های ثابت عمر طولانی دارند و نامشان نسخه دار نیست، این مهم ترین کاری است که همین هفته باید انجام شود.

نسخه آماده کپی

نقش تو کارشناس کش و شبکه توزیع محتواست. فقط از روی جدول زیر قضاوت کن. رفتار پیش فرض هیچ ارائه دهنده ای را از حافظه ات اضافه نکن.

برای هر نشانی، سه چیز از هدر پاسخ آمده است: وضعیت کش لبه، عمر کپی به ثانیه (اگر بود)، و هدر کش خود سایت.

۱. صفحه اول: {وضعیت} | {عمر} | {هدر کش}
۲. یک صفحه داخلی: {وضعیت} | {عمر} | {هدر کش}
۳. یک نوشته بلاگ: {وضعیت} | {عمر} | {هدر کش}
۴. یک تصویر: {وضعیت} | {عمر} | {هدر کش}
۵. یک فایل استایل: {وضعیت} | {عمر} | {هدر کش}
۶. یک فونت: {وضعیت} | {عمر} | {هدر کش}

پنج چیز بنویس:
۱. کدام ردیف ها واقعا از لبه جواب گرفته اند و کدام ها تا سرور اصلی رفته اند. ردیف ها را دسته بندی کن.
۲. آیا صفحه ها و فایل ها رفتار متفاوتی دارند؟ اگر بله، الگو را در یک جمله بگو.
۳. آیا هدر کشی که سایت می فرستد با کاری که لبه کرده جور در می آید؟ هر جا جور در نمی آید نام ببر.
۴. برای هر ردیف بنویس: اگر همین حالا این فایل را با همان نام عوض کنم، بازدیدکننده کی نسخه تازه را می بیند.
۵. یک کار، فقط یکی، که بیشترین اثر را دارد.

قاعده ها: وضعیت کش لبه بیش از دو حالت دارد؛ حالتی را که نمی شناسی عینا نقل کن و برایش معنی نساز. هیچ عددی نساز و هیچ هدری را که در جدول نیست فرض نکن. اگر عمر کپی برای ردیفی نیامده، بنویس «گزارش نشده» و از آن نتیجه نگیر. پاک کردن سراسری کش را پیشنهاد نکن.

قبل از اعتماد به خروجی: یک قاعده را خودتان باید نگه دارید، حتی اگر جواب چیز دیگری بگوید: پاک کردن سراسری کش کار آخر است، نه اول. اگر مشکل شما این است که تغییر یک فایل دیده نمی شود، راه حل نسخه دار کردن نام است و نه خالی کردن کش کل سایت، چون دفعه بعد دوباره همین اتفاق می افتد. و اگر سایت شما با چند سایت دیگر روی یک سرور است، یک پاک کردن سراسری در ساعت شلوغ همه آنها را با هم کند می کند. برای بررسی، فقط همان چند نشانی که واقعا عوض کرده اید کافی است.

هوش مصنوعی در این کار

این موضوع یکی از آنهایی است که مدل زبانی در آن دو رفتار کاملا متفاوت دارد و فرقشان را باید بشناسید. وقتی هدرهای واقعی را جلویش بگذارید، عالی است: الگو را در چند ردیف پیدا می کند، تناقض بین آنچه سایت خواسته و آنچه لبه کرده را می بیند و در چند ثانیه چیزی را می گوید که خواندنش دستی نیم ساعت طول می کشد. وقتی چیزی جلویش نگذارید و فقط بپرسید «رفتار پیش فرض فلان سرویس چیست»، از حافظه جواب می دهد و حافظه اش تاریخ دارد.

ابزارهایی که واقعا کمک می کنند

  • Claude برای دادن چند دسته هدر با هم و خواستن الگو، همان کاری که در مسیر سریع آمد، خوب کار می کند. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست، پس راه رسمی ثبت نام و پرداخت وجود ندارد.
  • Gemini Notebook راه درست پرسیدن درباره رفتار پیش فرض یک سرویس همین است: صفحه مستندات خود آن سرویس را بارگذاری کنید و سوال را از داخل همان سند بپرسید. جواب از متن خود ارائه دهنده می آید و تاریخ به روزرسانی همان صفحه هم جلوی چشمتان است. روی حساب گوگل کار می کند و ایران در فهرست مناطق در دسترس نیست.

کجا نتیجه معکوس می دهد

دو خطر مشخص، و هر دو در همین موضوع اتفاق می افتند. اول اینکه مدل رفتار پیش فرض یک سرویس را از حافظه اش می گوید. این حوزه ای است که در آن قاعده ها بین ارائه دهنده ها فرق دارند، بین طرح های همان ارائه دهنده هم فرق دارند و در طول زمان عوض می شوند؛ صفحه مستنداتی که همین درس به آن تکیه کرده تاریخ آخرین به روزرسانی را روی خودش دارد، که دقیقا نشان می دهد چرا حافظه یک مدل اینجا کافی نیست. انتروپیک خودش این گفتن با اطمینان چیزی که درست نیست را در مستنداتش توهم می نامد. دوم و پرهزینه تر: مدل به عنوان راه حل، پاک کردن کامل کش را پیشنهاد می کند، چون شایع ترین جوابی است که در اینترنت نوشته شده. روی سروری که چند سایت میزبانی می کند این یک عملیات پرهزینه است و مشکلی را که معمولا از نسخه دار نبودن نام فایل می آید هم حل نمی کند. موضع ما: مدل فقط اجازه دارد هدرهایی را که خودتان گرفته اید بخواند، و قاعده پیش فرض را باید از صفحه مستندات خود ارائه دهنده خواند، نه از مدل.

منبع ها: Cloudflare: default cache behavior Cloudflare: CDN-Cache-Control Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available

حد این توصیه

همه چیزی که این درس اندازه گرفته از یک سایت پشت یک ارائه دهنده مشخص است. قاعده های پیش فرض بین ارائه دهنده ها فرق دارند، بین طرح های یک ارائه دهنده هم فرق دارند و تغییر می کنند؛ پس آنچه اینجا منتقل می شود روش است، یعنی نگاه کردن به هدر پاسخ واقعی، نه فهرست پسوندها. مرز دوم مهم تر است: این سرور در اروپاست و ما نمی توانیم بسنجیم که یک بازدیدکننده در ایران چه مسیری طی می کند، کدام گره لبه به او جواب می دهد، یا اصلا لبه ای در دسترسش هست یا نه. هیچ عددی درباره تجربه بازدیدکننده داخل ایران در این درس نیامده، چون هیچ کدام را نداریم. و یک چیز آخر عمدا کنار گذاشته شده: تنظیم کردن قاعده های کش روی یک سرویس مشخص، که بستگی به پنل همان سرویس دارد و مستنداتش تنها مرجع درست است.

از تجربه خود ما

اعدادی که این درس رویشان بنا شده از هدرهای پاسخ همین سایت اند، در ۱۶ شهریور ۱۴۰۵. پنج نشانی HTML را با درخواست GET گرفتیم، صفحه اول و یک صفحه خدمات و یک نوشته بلاگ و نسخه انگلیسی صفحه اول و یک صفحه دیگر، و هر پنج تا از لبه جواب دادند؛ عمر کپی صفحه اول بین دو درخواست پشت سر هم از ۱۲۶ به ۱۲۷ ثانیه رفت، که یعنی لبه نسخه ذخیره شده خودش را می دهد. در همان دقیقه یک فایل فونت با کپی ۹۶ ساعته و یک تصویر با کپی ۱۷۴ ساعته جواب دادند و هر دو با اجازه کش یک ساله سرو می شوند. و چیزی که همین جلسه بهایش را داد و بهترین درس این صفحه است: اولین بار این بررسی را با درخواست HEAD انجام دادیم و هر پنج صفحه گفتند کش نشده اند. با GET، همان پنج نشانی در همان لحظه گفتند از لبه آمدند. قاعده کش این زون فقط درخواست های GET را شامل می شود، پس یک بررسی با HEAD نتیجه وارونه می دهد و هیچ پنل تنظیماتی این را به شما نمی گوید.

سوال هایی که واقعا پرسیده می شوند

سی دی ان سایت من را سریع می کند؟

بخشی از آن را، و اینکه چه بخشی، به یک تصمیم پیکربندی بستگی دارد. اگر برای صفحه ها قاعده ای تعریف نکرده باشید، زمان تا اولین بایت تقریبا همانی می ماند که بود و فقط تصویر و فونت زودتر می رسند. اگر تعریف کرده باشید، خود صفحه هم از لبه می آید و تفاوت آنجا محسوس می شود. ولی برای سایتی که صفحه اش کند ساخته می شود، سی دی ان مشکل را جابه جا هم نمی کند.

استایل سایتم را عوض کردم و هیچ اتفاقی نیفتاد؛ چرا؟

چون نشانی فایل عوض نشده و هم لبه و هم مرورگر بازدیدکننده کپی قدیمی را هنوز تازه می دانند. اگر آن فایل با اجازه طولانی کش شده باشد، این وضع می تواند روزها ادامه پیدا کند. راه حل درست، پاک کردن کش نیست؛ اضافه کردن یک شماره نسخه به نشانی فایل است، تا هر بار که چیزی عوض شد نشانی هم عوض شود.

از کجا بفهمم صفحه ام از لبه جواب گرفته یا از سرور خودم؟

از هدرهای پاسخ، نه از پنل تنظیمات، و حتما با یک درخواست GET. دنبال دو خط بگردید: وضعیت کش لبه، و عمر کپی؛ اگر عمر گزارش شده باشد یعنی لبه نسخه ای را نگه داشته و مدتش را هم می گوید. و مهم ترین نکته را دوباره بگوییم چون خودمان به آن خوردیم: این آزمایش را با درخواست HEAD نکنید. روی همین سایت، یک نشانی با HEAD می گوید محتوا پویا در نظر گرفته شده و همان نشانی با GET در همان لحظه می گوید از لبه آمد.