TTL چیست و چگونه بر کش تأثیر می‌گذارد؟

یک بار مشتری‌ای زنگ زد و با لحن سردرگم پرسید: من رکورد DNS سایت را دو ساعت پیش عوض کردم، ولی هنوز روی گوشی خودم سایت قدیمی باز می‌شود. روی لپ‌تاپ من سایت جدید باز می‌شود، روی موبایل او نه. اول فکر کردیم مشکل از مرورگر است، بعد از ISP. اما وقتی در پنل DNS نگاه کردیم، دیدیم مقدار TTL (Time To Live) روی ۸۶۴۰۰ ثانیه (یک روز) تنظیم شده بود. همین عدد، باعث شده بود بعضی دستگاه‌ها تا یک روز نسخه قدیمی را کش کنند. آن روز برای اولین بار جدی گرفتم چیزی را که تا آن موقع فقط یک عدد ساده در پنل DNS می‌دیدم.

TTL یا Time To Live (زمان زنده‌بودن)، یکی از مفاهیم بنیادین در سیستم‌های کش است. این عدد، مدت زمانی است که یک نسخه از داده در کش ذخیره می‌شود قبل از این‌که منقضی شود و از منبع اصلی دوباره دریافت شود. TTL هم در DNS (Domain Name System) کاربرد دارد، هم در کش مرورگر، هم در CDN (Content Delivery Network) و هم در کش سرور. مفهوم کلی DNS را در DNS چیست و چگونه کار می‌کند؟ آورده‌ام؛ این مقاله، به این عدد کلیدی و تأثیرش بر سرعت و پایداری سایت می‌پردازد.

TTL چیست و چه چیزی را کنترل می‌کند؟

TTL یا Time To Live، یک عدد است که به سیستم‌های کش می‌گوید داده چقدر می‌تواند در حافظه کش بماند. بعد از اتمام این زمان، نسخه کش‌شده منقضی (Expired) می‌شود و دفعه بعد، سیستم باید داده را از منبع اصلی دوباره بخواند. TTL در لایه‌های مختلف وب، معانی متفاوتی دارد اما مفهوم اصلی یکی است: تعیین مدت اعتبار داده کش‌شده.

در سایت وردپرسی، TTL در چند لایه وجود دارد:

• DNS TTL: مدت زمانی که یک رکورد DNS در سرورهای بازگشتی و کش مرورگر ذخیره می‌شود.
• Browser TTL: مدت زمانی که مرورگر یک فایل (تصویر، CSS، JS) را بدون بررسی مجدد از سرور استفاده می‌کند.
• CDN TTL: مدت زمانی که لبه‌های CDN نسخه‌ای از محتوا را نزدیک خودشان نگه می‌دارند.
• Server Cache TTL: مدت زمانی که کش سرور (مثل Redis یا Memcached) یک مقدار را نگه می‌دارد.

این لایه‌ها، مستقل از هم کار می‌کنند اما در کنار هم تجربه کاربری نهایی را می‌سازند. مدیریت TTL یعنی تصمیم بگیرید هر لایه چقدر باید داده را نگه دارد. تصمیم درست، تعادل بین دو هدف متضاد است: سرعت (با کش طولانی) و تازگی (با کش کوتاه).

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

TTL در DNS: چرا تغییرات آنی اعمال نمی‌شود؟

DNS TTL، مهم‌ترین کاربرد TTL برای مدیران سایت است. وقتی کاربری آدرس سایتی را در مرورگر وارد می‌کند، بعد از اولین کوئری DNS، پاسخ (که شامل IP سرور است) در چند لایه کش ذخیره می‌شود: کش مرورگر، کش سیستم‌عامل، کش روتر، و کش سرورهای بازگشتی ISP. TTL تعیین می‌کند این پاسخ چقدر معتبر است.

اگر TTL را روی ۳۶۰۰ ثانیه (یک ساعت) تنظیم کنید، یعنی هر لایه کش می‌تواند تا یک ساعت این پاسخ را بدون بررسی مجدد استفاده کند. اگر بعد از این مدت تغییری در رکورد DNS بدهید، ممکن است تا یک ساعت طول بکشد تا همه کاربران نسخه جدید را ببینند. این مفهوم، پایه چیزی است که به آن پراپاگیشن DNS می‌گویند. توضیحات بیشتر در پراپاگیشن DNS چیست و چقدر طول می‌کشد؟ آمده است.

سه واقعیت که باید درباره DNS TTL بدانید:

1. TTL قابل دور زدن نیست: اگر کاربری در مرورگرش رکورد را کش کرده باشد، هیچ راهی برای مجبور کردن او به دریافت نسخه جدید وجود ندارد، مگر منتظر بمانید تا TTL تمام شود.
2. همه لایه‌ها همزمان به‌روز نمی‌شوند: ممکن است ISP شما رکورد را تازه کرده باشد ولی مرورگر کاربر هنوز نسخه قدیمی را داشته باشد.
3. TTL طولانی، ریسک تغییرات را بالا می‌برد: اگر فردا بخواهید هاست را عوض کنید، TTL طولانی به‌معنی انتظار طولانی برای اعمال تغییرات است.

TTL در کش مرورگر: Cache-Control و Expires

در سطح فایل‌های استاتیک، TTL با هدرهای HTTP مدیریت می‌شود. دو هدر اصلی:

• Cache-Control: استاندارد مدرن، با مقدار max-age که TTL را به ثانیه تعیین می‌کند. مثلاً Cache-Control: max-age=86400 یعنی فایل تا یک روز در مرورگر کش می‌شود.
• Expires: روش قدیمی‌تر، با یک تاریخ مشخص که بعد از آن فایل منقضی می‌شود.

در وردپرس، این هدرها به‌طور خودکار تنظیم نمی‌شوند مگر با افزونه‌های بهینه‌سازی یا تنظیمات سرور. برای فایل‌های نسخه‌بندی‌شده (با پارامتر ?ver=1.2.3)، می‌توانید TTL طولانی تعیین کنید، چون در صورت تغییر فایل، نسخه هم عوض می‌شود. روش تنظیم این هدرها در پیکربندی افزونه کش وردپرس آمده است.

یک نکته ظریف که در پروژه‌ها زیاد می‌بینم: TTL بسیار طولانی برای فایل‌های CSS و JS، بدون نسخه‌بندی، باعث می‌شود بعد از آپدیت قالب، کاربران نسخه قدیمی را ببینند و سایت به‌هم بریزد. همیشه TTL طولانی را با نسخه‌بندی ترکیب کنید.

TTL در CDN: تعادل بین سرعت و تازگی

CDNها هم از TTL برای کنترل مدت نگهداری محتوا در لبه‌ها استفاده می‌کنند. تنظیم TTL در CDN، تصمیم مهمی است:

TTL کوتاه در CDN

مزیت: محتوای تازه سریع‌تر در لبه به‌روز می‌شود. عیب: CDN باید دفعات بیشتری به مبدأ مراجعه کند و بار روی هاست شما بیشتر می‌شود.

TTL طولانی در CDN

مزیت: بار مبدأ کم می‌شود و تحویل محتوا سریع‌تر است. عیب: تغییرات محتوا دیرتر در لبه‌ها اعمال می‌شود و کاربران ممکن است نسخه قدیمی را ببینند.

در تجربه من، تنظیمات بهینه به این شکل است: برای فایل‌های استاتیک (تصویر، CSS، JS) TTL طولانی (۳۰ روز تا یک سال) و برای HTML TTL کوتاه (چند دقیقه تا چند ساعت). این ترکیب، بهترین تعادل را ایجاد می‌کند. نقش CDN در سرعت سایت و تنظیمات دقیق آن در CDN چیست و چگونه سرعت سایت را بهبود می‌دهد؟ و راه‌اندازی CDN برای سایت وردپرسی آمده است.

تنظیم TTL: مقدار مناسب چقدر است؟

انتخاب TTL مناسب، بسته به نوع داده و سناریوی سایت متفاوت است. جدول زیر راهنمای عملی من است:

نکته: TTL نامناسب، در هر دو جهت مشکل‌ساز است. TTL خیلی کوتاه باعث فشار به سرور می‌شود و TTL خیلی بلند باعث دیدن محتوای قدیمی. در پروژه‌های خودم، ابتدا با مقادیر محافظه‌کارانه شروع می‌کنم و بعد از پایدار شدن سایت، TTL را بهینه می‌کنم. تنظیم دقیق در تنظیم TTL مناسب برای دامنه آمده است.

TTL در زمان مهاجرت: استراتژی دو مرحله‌ای

TTL در زمان مهاجرت سایت یا تغییر هاست، نقش حیاتی دارد. استراتژی دو مرحله‌ای که در همه پروژه‌ها اجرا می‌کنم:

مرحله اول: کاهش TTL پیش از مهاجرت

حداقل ۲۴ ساعت قبل از مهاجرت، TTL رکوردهای DNS را به مقدار کم (مثلاً ۳۰۰ ثانیه یا ۵ دقیقه) کاهش دهید. این کار اجازه می‌دهد تا همه لایه‌های کش، سریع‌تر نسخه جدید را ببینند. اگر این کار را نکنید و TTL فعلی ۲۴ ساعت باشد، ممکن است بعد از مهاجرت، تا یک روز کاربران نسخه قدیمی را ببینند. روش کامل در چگونه سایت وردپرسی را به هاست جدید منتقل کنیم؟ آمده است.

مرحله دوم: بازگرداندن TTL بعد از پایداری

بعد از مهاجرت و اطمینان از پایداری (معمولاً ۴۸ ساعت)، TTL را به مقدار عادی (مثلاً ۱ ساعت) بازگردانید. این کار، بار روی سرور DNS را کم می‌کند.

یک نکته مهم: حتی اگر TTL را به ۵ دقیقه کاهش دهید، بعضی سرورهای DNS یا ISPها ممکن است حداقل TTL خودشان را اعمال کنند و مقدار کم شما را نادیده بگیرند. بنابراین، در تجربه من، زمان انتظار واقعی برای اعمال تغییرات، معمولاً بین چند دقیقه تا چند ساعت است، نه لحظه‌ای.

پایش و عیب‌یابی مشکلات TTL

وقتی مشکلی در کش یا DNS پیش می‌آید، تشخیص ریشه نیازمند ابزار و روش است. سه ابزار اصلی:

ابزار dig

با دستور dig example.com می‌توانید TTL فعلی رکورد را ببینید. با دستور dig +trace example.com مسیر کامل کوئری DNS را مشاهده می‌کنید. توضیحات کامل در چگونه DNS را عیب‌یابی کنیم؟ و بررسی لاگ‌های دیتابیس آمده است.

ابزار DNS Checker

سایت‌های آنلاین مثل DNS Checker، رکورد را از ده‌ها سرور در سراسر جهان بررسی می‌کنند. اگر بعضی سرورها نسخه جدید و بعضی نسخه قدیمی را نشان دهند، هنوز پراپاگیشن کامل نشده است.

Chrome DevTools

برای کش مرورگر، در تب Network، روی فایل مورد نظر کلیک کنید و هدرهای Cache-Control و Expires را ببینید. در ستون Size، عبارت (from disk cache) یا (from memory cache) نشان می‌دهد که فایل از کش خوانده شده است.

اشتباهات رایج در تنظیم TTL

پنج اشتباه که در پروژه‌ها زیاد دیده‌ام:

• TTL بسیار طولانی برای رکوردهای در حال تغییر: اگر روی سایت در حال توسعه کار می‌کنید و مدام رکوردها را عوض می‌کنید، TTL طولانی باعث سردرگمی می‌شود.
• TTL بسیار کوتاه برای سایت‌های پرترافیک: TTL ۳۰ ثانیه‌ای، بار سرورهای DNS را چند برابر می‌کند و می‌تواند به کندی کوئری‌های DNS منجر شود.
• تنظیم TTL در چند لایه همزمان: اگر TTL DNS و TTL کش مرورگر را همزمان طولانی کنید، ممکن است تغییرات تا چند روز اعمال نشود. همیشه لایه‌ها را جدا مدیریت کنید.
• فراموش کردن بازگرداندن TTL بعد از مهاجرت: TTL ۵ دقیقه‌ای برای همیشه، بار بی‌دلیل روی DNS است. بعد از پایداری، به مقدار عادی برگردانید.
• عدم پایش TTL رکوردهای حیاتی: بعضی ادمین‌ها فقط TTL سایت اصلی را مدیریت می‌کنند و رکوردهای ایمیل (MX) یا زیر‌دامنه‌ها را فراموش می‌کنند. تمام رکوردهای مهم باید TTL مدیریت‌شده داشته باشند. راهنمای کامل اشتباهات DNS در اشتباهات رایج در تنظیم DNS آمده است.

پرسش‌های پرتکرار درباره TTL و کش

TTL چیست به زبان ساده؟

TTL یا Time To Live، یک عدد است که مدت زمان اعتبار داده در کش را تعیین می‌کند. بعد از این مدت، نسخه کش‌شده منقضی می‌شود و باید از منبع اصلی دوباره خوانده شود. TTL هم در DNS، هم در کش مرورگر، هم در CDN و هم در کش سرور استفاده می‌شود.

چرا TTL در DNS مهم است؟

TTL در DNS تعیین می‌کند تغییرات رکورد DNS چقدر طول می‌کشد تا در سراسر جهان اعمال شود. TTL طولانی به‌معنی انتظار بیشتر برای اعمال تغییرات است. TTL کوتاه، اعمال سریع‌تر ولی بار بیشتر روی سرورهای DNS.

چگونه TTL دامنه را تغییر دهیم؟

از پنل مدیریت DNS (پنل هاست یا پنل ثبت دامنه)، رکورد مورد نظر را ویرایش کنید و مقدار TTL را در ثانیه وارد کنید. مثلاً ۳۶۰۰ برای یک ساعت یا ۳۰۰ برای پنج دقیقه. بعد از ذخیره، تغییر بلافاصله اعمال می‌شود ولی اعمالش در سراسر جهان بسته به TTL قبلی زمان می‌برد.

بهترین مقدار TTL برای سایت چقدر است؟

برای اکثر سایت‌ها، TTL بین ۱ تا ۲۴ ساعت مناسب است. نزدیک مهاجرت، به ۵ دقیقه کاهش دهید. بعد از پایداری، به ۱ ساعت برگردانید. برای فایل‌های استاتیک (تصویر، CSS، JS) می‌توانید TTL ۳۰ روز یا بیشتر تنظیم کنید.

آیا TTL بر سئو تأثیر دارد؟

TTL به‌طور مستقیم بر سئو تأثیر ندارد. اما TTL نامناسب می‌تواند باعث شود تغییرات سایت دیرتر اعمال شود و در زمان‌های حساس مثل مهاجرت، تجربه کاربری و رتبه آسیب ببیند. توصیه من، مدیریت دقیق TTL در زمان‌های تغییر است.

تفاوت TTL و Cache-Control چیست؟

TTL یک مفهوم عمومی است که در لایه‌های مختلف استفاده می‌شود. Cache-Control یک هدر HTTP است که در لایه مرورگر و پروکسی، TTL را تعیین می‌کند. TTL در DNS جداگانه و از طریق پنل DNS تنظیم می‌شود. این دو مستقل از هم کار می‌کنند اما در نهایت تجربه کاربر را می‌سازند.

سخن پایانی: TTL، تعادل بین سرعت و کنترل

TTL یکی از آن تنظیماتی است که تا وقتی درست باشد، کسی به آن فکر نمی‌کند. اما روزی که سایت را مهاجرت می‌دهید یا محتوای مهمی را عوض می‌کنید، این عدد ساده می‌تواند تفاوت بین یک ساعت و یک روز انتظار باشد. TTL خوب، تعادل بین دو هدف متضاد است: سرعت (با کش طولانی) و کنترل (با کش کوتاه).

پیشنهاد عملی من سه گام است. اول، همین امروز TTL رکوردهای DNS دامنه خود را بررسی کنید. اگر روی ۸۶۴۰۰ یا بیشتر است و قصد مهاجرت دارید، همین الان به ۵ دقیقه کاهش دهید. دوم، برای فایل‌های استاتیک، TTL طولانی همراه با نسخه‌بندی تنظیم کنید. سوم، در تنظیمات CDN، TTL HTML را کوتاه و TTL فایل‌های استاتیک را طولانی نگه دارید.

اگر تجربه‌ای از تنظیم TTL یا مشکلی در این زمینه داشته‌اید — به‌خصوص اگر با پراپاگیشن طولانی یا مشکلات کش روبه‌رو شده‌اید — برایم بنویسید. همین تجربه‌های میدانی، به خواننده بعدی کمک می‌کند از دام‌های مشابه دوری کند. 🔄