سایت باز میشود، اما هر چند ساعت یکبار برای ده دقیقه «DNS_PROBE_FINISHED_NXDOMAIN» میگیرید. یا بدتر: مشتری از شهری دیگر زنگ میزند که سایت را نمیبیند و شما از دفتر خودتان همهچیز را سالم میبینید. این علامتها تقریباً همیشه یک ریشه دارند: نیم سرور شما جایی است که برای آن ساخته نشده. تصمیم واقعی هم این نیست که «کدام گزینه بهتر است»؛ تصمیم این است که کدام گزینه برای الگوی ترافیک و سطح دسترسی شما درست است.
نیم سرور دقیقاً چه چیزی را کنترل میکند
نیم سرور (Authoritative Nameserver) پاسخ نهایی به پرسشهای DNS را میدهد. وقتی کسی آدرس سایت شما را میزند، resolver از ریشه شروع میکند، به TLD میرسد و در آخر از نیم سرور شما میپرسد «رکورد A دامنه چیست؟». هرچه این حلقه کندتر یا ناپایدارتر باشد، کاربر قبل از اینکه حتی یک بایت از سایت شما را ببیند، منتظر میماند.
سه جا میتوانید این نقش را بسپارید: پنل ثبتکننده دامنه، کنترلپنل هاست، یا یک سرویس DNS ابری مستقل. تفاوت این سه در سرعت پاسخ، در کنترل رکوردها و در اینکه وقتی سرورتان میخوابد چه اتفاقی میافتد، خودش را نشان میدهد.
سه گزینه، سه رفتار متفاوت در بحران
| معیار | نیم سرور ثبتکننده | نیم سرور هاست | DNS ابری |
|---|---|---|---|
| سرعت انتشار تغییر رکورد | کند، گاهی بیش از ۲ ساعت | متوسط، معمولاً زیر ۳۰ دقیقه | سریع، اغلب زیر ۵ دقیقه |
| کنترل رکوردها | محدود، رابط قدیمی | وابسته به کنترلپنل | کامل، API و قالب |
| Failover خودکار | ندارد | بهندرت | دارد |
| هزینه | رایگان | رایگان | رایگان تا پلنهای حرفهای |
جدول بالا تصمیم را نمیگیرد. چیزی که تصمیم را میگیرد این است: اگر سرور اصلی شما از دسترس خارج شود، نیم سرور شما چه کاری میتواند بکند؟ نیم سرور ثبتکننده هیچ کاری نمیکند. نیم سرور هاست هم معمولاً همان IP را برمیگرداند تا وقتی که کسی دستی رکورد را عوض کند. فقط گزینه سوم است که میتواند خودش تصمیم بگیرد.
چرا TTFB شما بالا میرود و ربطش به نیم سرور چیست
یک اشتباه رایج این است که همهچیز را گردن سرور میاندازند. اگر TTFB سایت شما ۸۰۰ میلیثانیه است، اول با dig ببینید زمان پاسخ نیم سرور چقدر است:
dig @1.1.1.1 example.com A +stats
dig +trace example.com
در خروجی، فیلد Query time را نگاه کنید. زیر ۵۰ میلیثانیه طبیعی است. اگر روی ۳۰۰ تا ۶۰۰ میلیثانیه میچرخد، مشکل قبل از وبسرور شماست و هر بهینهسازی PHP بیفایده است. برای اینکه بفهمید کندی از کدام نقطه میآید، ابزارهای رایگان سرورنت تست DNS و TTFB را در چند نقطه جغرافیایی انجام میدهند و تفاوت را نشان میدهند.
نکتهای که کمتر گفته میشود: TTL رکوردها. اگر TTL را روی ۳۰۰ ثانیه گذاشتهاید و بعد میخواهید سرور را عوض کنید، مهاجرت شما تا ۵ دقیقه ناهمگون است. اگر روی ۸۶۴۰۰ گذاشتهاید، تا یک روز. قبل از هر مهاجرت، TTL را به ۳۰۰ کاهش دهید، یک روز صبر کنید، مهاجرت کنید، بعد برگردانید.
کجا واقعاً اشتباه میکنند
اینجا اشتباه میکنند: نیم سرور را روی هاست میگذارند و بعد هاست را عوض میکنند، بدون اینکه به این فکر کنند که نیم سرور هم با آن میرود. نتیجهاش این است که سایت برای همه از دسترس خارج میشود، نه فقط برای کسانی که IP قدیمی را کش کردهاند. علامتش هم دقیقاً این است: dig از سرور خودتان جواب میدهد، اما از بیرون SERVFAIL میگیرید. اگر نیم سرور روی هاست است، قبل از هر جابهجایی، رکوردهای NS را به یک سرویس مستقل منتقل کنید.
اشتباه دوم: گذاشتن هر دو NS روی یک ارائهدهنده. اگر آن ارائهدهنده مشکل پیدا کند، هر دو نیم سرور شما با هم میخوابند و هیچ افزونگیای ندارید. حداقل دو نیم سرور در دو شبکه متفاوت لازم است.
معیار انتخاب برای هر سناریو
سایت شخصی یا وبلاگ کمترافیک
نیم سرور هاست کافی است. ساده است، یک پنل دارید، و پیچیدگی اضافه به شما چیزی نمیدهد. فقط مطمئن شوید که کنترلپنل امکان ویرایش رکوردهای MX و TXT را میدهد؛ بعضی پنلهای ارزان این را پنهان میکنند.
فروشگاه یا سایت درآمدزا
اینجا DNS ابری را انتخاب میکنم. دلیلش سرعت نیست، قابلیت failover است. اگر سرور اصلی از دسترس خارج شود، رکورد به سرور پشتیبان میرود و مشتری شما متوجه نمیشود. هزینهاش این است که یک لایه پیچیدگی اضافه میشود و باید یاد بگیرید رکوردها را از API مدیریت کنید. برای تیمی که فقط یک نفر آن را میفهمد، این پیچیدگی میتواند خودش ریسک باشد.
سرویس با کاربران داخلی
اگر کاربران شما همه در ایران هستند، نیم سرور ابری خارجی همیشه بهترین گزینه نیست. مسیر شبکه و تحریمها میتواند باعث شود پاسخ DNS از داخل کندتر از یک نیم سرور داخلی باشد. اینجا تست کنید، نه اینکه فرض بگیرید. یک dig از دو نقطه داخل ایران کافی است تا تصمیم عوض شود.
مهاجرت نیم سرور بدون قطعی
- رکوردهای فعلی را کامل استخراج کنید:
dig example.com ANY +noall +answerو همچنینdig example.com MXوdig example.com TXT. - در سرویس جدید همه رکوردها را از قبل بسازید، از جمله رکوردهای تأیید ایمیل و SPF.
- TTL را به ۳۰۰ کاهش دهید و حداقل یک چرخه کامل صبر کنید.
- رکوردهای NS را در پنل ثبتکننده عوض کنید. این تنها مرحلهای است که برگشتپذیر نیست، پس قبلش مطمئن شوید همهچیز آماده است.
- با
dig +traceاز چند نقطه بررسی کنید که انتشار کامل شده.
اگر روی وردپرس کار میکنید، بعد از مهاجرت احتمالاً با مشکلاتی مثل اجرا نشدن کرون یا آدرسهای قدیمی در دیتابیس روبهرو میشوید. راهنمای انتقال وردپرس بدون افزونه دقیقاً همین مرحله بعد از تغییر DNS را پوشش میدهد.
وقتی نیم سرور درست است اما سایت کند میماند
اگر Query time زیر ۵۰ میلیثانیه است و باز هم سایت کند است، مشکل جای دیگری است. در وردپرس، کرون داخلی یکی از متهمهای همیشگی است؛ wp-cron وردپرس را با کرون واقعی سیستم جایگزین کنید. اگر تعداد افزونهها از ۳۰ گذشته، قبل از هر کار دیگری ممیزی افزونهها را انجام دهید. و اگر روی هاست اشتراکی هستید، بررسی کنید که آیا محدودیت ورودی/خروجی یا محدودیت پردازنده دارید یا نه.
برای سایتهای وردپرسی که ترافیک متوسط دارند، یک هاست لینوکس با کنترل کامل روی کرون و منابع، معمولاً از هاست اشتراکی ارزانتر تمام میشود، چون وقت شما را برای عیبیابیهای تکراری آزاد میکند. اگر سایت وردپرسی دارید و میخواهید بدون درگیری با تنظیمات سرور راه بیفتید، هاست وردپرس سرورنت این لایه را از دوش شما برمیدارد.
پرسشهای پرتکرار
آیا تغییر نیم سرور باعث قطعی سایت میشود؟
اگر درست انجام شود، نه. قطعی وقتی رخ میدهد که رکوردها را در سرویس جدید نساخته باشید یا TTL را قبل از مهاجرت کاهش نداده باشید. با TTL روی ۳۰۰ ثانیه، پنجره ناهمگونی حداکثر چند دقیقه است.
چند نیم سرور لازم است؟
حداقل دو نیم سرور، و بهتر است در دو شبکه متفاوت باشند. اگر هر دو روی یک ارائهدهنده باشند، خرابی آن ارائهدهنده هر دو را با هم از کار میاندازد و افزونگی واقعی ندارید.
آیا DNS ابری سرعت سایت را بالا میبرد؟
فقط بخش کوچکی از زمان بارگذاری مربوط به DNS است. اگر TTFB شما ۸۰۰ میلیثانیه است و زمان پاسخ DNS ۴۰ میلیثانیه، تغییر نیم سرور تقریباً هیچ فرقی نمیکند. اول با dig اندازه بگیرید، بعد تصمیم بگیرید.
چطور بفهمم نیم سرور فعلیام کدام است؟
دستور dig NS example.com +short را اجرا کنید. اگر خروجی نام سرورهای ثبتکننده یا هاست را نشان میدهد، همانجاست. اگر نام سرویس ابری میبینید، از قبل مهاجرت کردهاید.
قبل از هر تصمیمی، یک بار dig +trace بزنید و زمان هر مرحله را ببینید. عددی که میبینید، بیشتر از هر مقایسهای تصمیم شما را عوض میکند.
دیدگاهها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!