رکورد A را عوض کرده‌اید، پنل DNS هم ذخیره شده، اما سایت هنوز روی IP قدیمی بالا می‌آید. یا بدتر: از موبایل باز میشود و از لپ‌تاپ نه. این وضعیت تقریباً همیشه یک معنی دارد؛ جایی بین مرورگر شما و سرور authoritative، یک نسخهی قدیمی از پاسخ DNS نشسته و هنوز TTL آن تمام نشده. مشکل این است که «جایی» چند لایه دارد و هر لایه با ابزار خودش پاک میشود.
اول بفهمید کدام لایه جواب قدیمی میدهد
قبل از هر پاک‌کردنی، باید بفهمید پاسخ از کجا می‌آید. اگر این را رد نکنید، فقط دارید حدس می‌زنید و ممکن است ساعت‌ها کش مرورگر را پاک کنید در حالی که مشکل در ریزالور ISP است.
ابزار اصلی، dig است. این را بزنید:
dig +short example.com A
dig @1.1.1.1 +short example.com A
dig @8.8.8.8 +short example.com Aخط اول از ریزالور پیش‌فرض سیستم شما می‌پرسد. دو خط بعدی مستقیم از Cloudflare و Google می‌پرسند. اگر جواب خط اول با دو خط دیگر فرق دارد، کش محلی یا ریزالور ISP شما آلوده است. اگر هر سه یکی بودند ولی مرورگر چیز دیگری نشان میدهد، مشکل داخل خود سیستمعامل یا مرورگر است.
برای دیدن TTL باقی‌مانده، +short را بردارید:
dig example.com A | grep -A1 "ANSWER SECTION"عددی که کنار رکورد می‌بینید، ثانیه‌های باقی‌مانده تا انقضای کش است. اگر ۳۶۰۰ می‌بینید و TTL رکورد شما ۳۶۰۰ بوده، یعنی همین الان تازه کش شده و باید صبر کنید. اگر عدد کوچک و رو به کاهش است، کش در حال تمام‌شدن است.
لایهی اول: کش مرورگر
مرورگرها کش DNS خودشان را دارند و مستقل از سیستمعامل عمل می‌کنند. کروم و فایرفاکس هر دو این کش را نگه می‌دارند و در حالت عادی با بستن تب پاک نمی‌شود.
در کروم به chrome://net-internals/#dns بروید و روی «Clear host cache» بزنید. در فایرفاکس، about:networking#dns و دکمه‌ی Clear DNS Cache. اگر از Edge استفاده می‌کنید، همان آدرس کروم با پیشوند edge:// کار میکند.
نکته‌ای که خیلی‌ها نمی‌دانند: حالت Incognito کش DNS جداگانه ندارد و از همان کش سیستم استفاده میکند. پس اگر فکر می‌کنید با پنجره‌ی ناشناس تست تمیزی می‌گیرید، اشتباه می‌کنید.
لایهی دوم: کش سیستمعامل
هر سیستمعامل یک resolver محلی دارد که پاسخ‌ها را برای همه‌ی برنامه‌ها کش میکند. این لایه معمولاً همان چیزی است که «از موبایل باز میشود ولی از لپ‌تاپ نه» را توضیح میدهد.
| سیستمعامل | دستور پاک‌کردن |
|---|---|
| Windows | ipconfig /flushdns |
| macOS (Big Sur و بعد) | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux با systemd-resolved | sudo resolvectl flush-caches |
| Linux با nscd | sudo systemctl restart nscd |
در macOS اگر نسخه‌تان قدیمی‌تر از Big Sur است، دستور فرق دارد و باید sudo killall -HUP mDNSResponder را تنها بزنید. در لینوکس هم اگر resolvectl را ندارید، احتمالاً systemd-resolved نصب نیست و باید سراغ nscd بروید. با systemctl status systemd-resolved میتوانید مطمئن شوید کدام یکی روی سیستم فعال است.
در ویندوز، اگر بعد از ipconfig /flushdns هنوز جواب قدیمی می‌گیرید، یک قدم دیگر هم هست: ipconfig /release و بعد ipconfig /renew. این کار لیز DHCP را هم تازه میکند و اگر DNS سرور از DHCP آمده باشد، ممکن است مقدار جدید بگیرد.
لایهی سوم: ریزالور ISP
اینجا جایی است که بیشترین سردرگمی پیش می‌آید. ریزالور ISP شما (یا ریزالور داخلی شبکهی شرکتی) پاسخ‌ها را با TTL خودش کش میکند و شما هیچ کنترلی روی آن ندارید. نمی‌توانید زنگ بزنید و بگویید کش‌تان را پاک کنید؛ معمولاً چنین امکانی وجود ندارد.
راه‌حل عملی این است که موقتاً از ریزالور ISP عبور کنید. یکی از این دو را امتحان کنید:
dig @9.9.9.9 +short example.com A
dig @1.1.1.1 +short example.com Aاگر جواب درست از این‌ها آمد ولی از ریزالور پیش‌فرض نه، مشکل قطعاً همان لایه است. برای تست واقعی در مرورگر، DNS سیستم را موقتاً به 1.1.1.1 تغییر دهید و بعد از تأیید، برش گردانید. یا اگر میخواهید فقط یک برنامه از DNS دیگری استفاده کند، در لینوکس با systemd-resolved میتوانید برای یک دامنه‌ی خاص سرور مشخص تعریف کنید.
اینجا اشتباه می‌کنند: خیلی‌ها بعد از تغییر رکورد، فوراً TTL را روی ۳۰۰ ثانیه می‌گذارند و فکر می‌کنند مشکل حل شده. اما TTL جدید فقط برای پاسخ‌های بعدی اعمال میشود؛ رکوردی که همین الان در کش ریزالور ISP با TTL قدیمی ۸۶۴۰۰ نشسته، تا پایان همان مقدار باقی میماند. علامتش هم این است که بعد از چند ساعت هنوز بخشی از کاربران سایت قدیمی را می‌بینند و بخشی سایت جدید را. اگر می‌دانید فردا مهاجرت دارید، TTL را یک روز قبل کم کنید، نه روز مهاجرت.
لایهی چهارم: ریزالورهای عمومی
Google و Cloudflare و Quad9 هم کش دارند، ولی رفتارشان با ISP فرق میکند. این‌ها معمولاً به TTL رکورد شما احترام می‌گذارند و اگر TTL را کوتاه کرده باشید، سریع تازه می‌شوند. مشکل اصلی این‌جاست که کاربران زیادی از این ریزالورها استفاده می‌کنند و اگر رکورد شما در کش آن‌ها با مقدار قدیمی نشسته باشد، درصد قابل‌توجهی از ترافیک شما هنوز به سرور قدیمی می‌رود.
خبر خوب این است که این لایه را میتوانید تست کنید و مطمئن شوید. اگر dig @8.8.8.8 جواب درست میدهد، یعنی Google تازه شده و بقیه‌ی کاربران هم به‌زودی تازه می‌شوند. اگر نه، فقط صبر می‌خواهد.
وقتی مشکل واقعاً DNS نیست
گاهی همه‌ی این لایه‌ها را پاک می‌کنید و باز هم سایت قدیمی می‌آید. در این حالت دو احتمال باقی میماند که کم‌تر به آن‌ها فکر میشود.
اول، کش سمت سرور. اگر از CDN یا پروکسی معکوس استفاده می‌کنید، آن لایه هم نسخهی قدیمی صفحه را نگه می‌دارد و ربطی به DNS ندارد. دوم، کش اپلیکیشن. اگر روی وردپرس کار می‌کنید و افزونه‌ی کش دارید، ممکن است صفحه‌ی قدیمی از کش خود افزونه سرو شود. برای این حالت‌ها، ممیزی افزونه وردپرس کمک میکند بفهمید کدام افزونه مسئول کش است و آیا اصلاً لازم است.
یک راه سریع برای جدا کردن این دو حالت: با curl -I https://example.com هدرها را ببینید. اگر X-Cache: HIT یا مشابهش را دیدید، مشکل DNS نیست و باید کش لایهی اپلیکیشن را پاک کنید. اگر هدرها تازه بودند ولی مرورگر چیز دیگری نشان میدهد، برگردید سراغ لایهی اول و دوم.
روش درست تست بعد از هر تغییر
ترتیب کار مهم است. اگر این ترتیب را رعایت نکنید، ممکن است چند بار یک لایه را پاک کنید و نتیجه نگیرید.
- اول با
dig @1.1.1.1مطمئن شوید رکورد روی سرور authoritative درست است. اگر اینجا غلط است، هیچ پاک‌کردنی کمکی نمی‌کند. - بعد کش سیستمعامل را پاک کنید و دوباره
digبزنید. - سپس کش مرورگر را پاک کنید و در یک تب تازه تست کنید.
- در آخر اگر هنوز مشکل بود، DNS سیستم را موقتاً عوض کنید تا از ریزالور ISP عبور کنید.
برای بررسی سریع‌تر، میتوانید از ابزارهای رایگان سرورنت برای تست DNS و بررسی پاسخ سرور استفاده کنید؛ این‌ها از چند نقطه‌ی جغرافیایی مختلف نگاه می‌کنند و تفاوت ریزالورها را بهتر نشان می‌دهند.
یک نکته‌ی عملی دیگر: اگر روی سرور خودتان کار می‌کنید و میخواهید ببینید سرور چه چیزی می‌بیند، از داخل خود سرور dig بزنید. اگر سرور شما روی هاست لینوکس است، این تست چند ثانیه‌ای جواب میدهد و خیلی وقت‌ها نشان میدهد مشکل اصلاً از سمت شما نیست.
چه زمانی صبر کردن درست‌ترین کار است
اگر TTL رکورد شما ۸۶۴۰۰ ثانیه (یک روز) بوده و همین الان آن را عوض کرده‌اید، هیچ دستوری در دنیا نمی‌تواند کش ریزالور ISP را زودتر از موعد پاک کند. در این حالت صبر کردن تنها راه است و هر کار دیگری وقت تلف‌کردن است. تنها استثنا این است که بتوانید موقتاً DNS کاربران را به ریزالور دیگری هدایت کنید که عملاً برای سایت عمومی ممکن نیست.
درس اصلی این است: TTL را قبل از مهاجرت کم کنید، نه بعدش. اگر این یک کار را انجام دهید، بیشتر دردسرهای کش DNS از بین می‌رود.
پرسش‌های پرتکرار
چرا بعد از تغییر رکورد DNS سایت هنوز قدیمی باز میشود؟
چون پاسخ قدیمی در یکی از چهار لایهی کش باقی مانده است: مرورگر، سیستمعامل، ریزالور ISP یا ریزالور عمومی. تا وقتی TTL آن نسخهی قدیمی تمام نشود، آن لایه همان جواب را میدهد. با dig @1.1.1.1 میتوانید بفهمید کدام لایه هنوز قدیمی است.
چطور کش DNS ویندوز را پاک کنم؟
در Command Prompt با دسترسی Administrator دستور ipconfig /flushdns را بزنید. اگر جواب نداد، ipconfig /release و بعد ipconfig /renew را هم امتحان کنید. توجه کنید که این فقط کش سیستمعامل را پاک میکند، نه کش مرورگر و نه کش ریزالور ISP.
آیا حالت ناشناس مرورگر کش DNS را دور میزند؟
نه. حالت Incognito کش DNS مستقل ندارد و از همان کش سیستمعامل استفاده میکند. اگر میخواهید تست تمیزی بگیرید، باید کش سیستم را پاک کنید یا از یک شبکهی دیگر با ریزالور متفاوت تست بگیرید.
TTL را چند بگذارم تا مهاجرت راحت باشد؟
اگر مهاجرت برنامهریزیشده دارید، حداقل یک روز قبل TTL را به ۳۰۰ ثانیه کاهش دهید و بعد از مهاجرت و تأیید، دوباره به مقدار قبلی برگردانید. اگر TTL را روز مهاجرت کم کنید، رکورد قدیمی که با TTL بلند در کش ریزالورها نشسته تا پایان همان مدت باقی میماند و کاری نمیتوان کرد.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!