راه‌اندازی CDN بدون قطعی؛ راهنمای گام‌به‌گام مهاجرت دامنه

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

چک‌لیست پیش از مهاجرت

در این مرحله عجله نکنید؛ تقریباً همه قطعی‌های حین مهاجرت ریشه‌شان در همین چهار بند است.

فهرست‌برداری کامل از رکوردهای DNS فعلی

از پنل DNS فعلی‌تان خروجی zone بگیرید یا دستی همه رکوردها را در یک فایل بنویسید: A، AAAA، CNAME، MX، TXT (شامل SPF و DKIM و DMARC)، SRV و CAA. مقدار TTL هر رکورد را هم یادداشت کنید.

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

IP مبدأ را جایی امن نگه دارید

بعد از مهاجرت، رکورد A دیگر IP سرور شما را نشان نمی‌دهد؛ آن IP را در همان فایل چک‌لیست ذخیره کنید، هم برای تست و هم برای rollback. هم‌زمان مطمئن شوید فایروال مبدأ ترافیک لبه را بلاک یا rate-limit نمی‌کند — از این به بعد همه درخواست‌ها از تعداد محدودی IP می‌آیند و قوانین ضدربات مبتنی بر «تعداد درخواست در هر IP»، اولین چیزی است که سایت را می‌خواباند.

بررسی کنید مبدأ هدر Host را می‌پذیرد

لبه، درخواست را با هدر Host: example.com به IP مبدأ می‌فرستد. اگر vhost پیش‌فرض تعریف نشده یا مبدأ فقط به نام دیگری پاسخ می‌دهد، نتیجه HTTP 404 یا نمایش سایت اشتباه است. این را قبل از هر کاری تست کنید:

curl -I --resolve example.com:443:ORIGIN_IP https://example.com/

اگر مبدأ پشت یک پنل میزبانی است و نام داخلی دیگری دارد، در nsin می‌توانید هدر Host ارسالی به مبدأ را override کنید.

دنبال URLهای مطلق hardcoded بگردید

در دیتابیس و قالب‌ها دنبال آدرس‌های مطلق با http://، آدرس‌های حاوی IP سرور و ساب‌دامنه‌های موقت (مثل origin.example.com) بگردید؛ در وردپرس مقادیر siteurl و home را چک کنید. این آدرس‌ها یا mixed content تولید می‌کنند یا کاربر را مستقیم به مبدأ می‌فرستند و کل زحمت CDN را دور می‌زنند.

کاهش TTL؛ ۴۸ ساعت قبل

مقدار TTL تعیین می‌کند resolverهای میانی چقدر پاسخ قدیمی را کش نگه دارند. اگر رکورد A شما TTL=86400 دارد، تغییر امروزتان ممکن است تا یک شبانه‌روز برای بخشی از کاربران اعمال نشود — و بدتر، اگر لازم شد برگردید، برگشت هم همان‌قدر طول می‌کشد.

پس ۴۸ ساعت قبل، TTL هر رکوردی را که قرار است تغییر کند به مقدار کوتاه (مثلاً TTL=300) کاهش دهید و دست‌کم به اندازه TTL قدیمی صبر کنید تا کش‌های قبلی منقضی شوند. TTL رکوردهای NS را زون بالادستی (مثلاً زون ir.) تعیین می‌کند و در کنترل شما نیست؛ برای همین باید رکوردها کامل وارد شوند، بعد نیم‌سرور عوض شود.

جدول زمان‌بندی مهاجرت

#	زمان	اقدام	معیار موفقیت
۱	T-48h	خروجی گرفتن از zone فعلی، ثبت IP مبدأ، کاهش TTL رکوردهای هدف به 300	خروجی dig برای رکوردها TTL کوتاه نشان می‌دهد
۲	T-24h	افزودن دامنه در پنل nsin، وارد کردن رکوردها، مشخص کردن اینکه کدام رکورد پروکسی شود و کدام DNS-only بماند	مقایسه یک‌به‌یک لیست رکوردها با خروجی مرحله قبل
۳	T-0	تست لبه با hosts یا --resolve، سپس تغییر نیم‌سرورها در پنل ثبت‌کننده دامنه	پاسخ HTTP 200 از لبه با محتوای درست، قبل از سوئیچ
۴	T+1h	پایش نرخ خطا، صدور گواهی SSL، نرخ hit کش و زنجیره ریدایرکت	نرخ 5xx در سطح قبل از مهاجرت، گواهی معتبر صادر شده
۵	T+24h	بازگرداندن TTLها به مقدار عادی، تنظیم دقیق قوانین کش، بررسی وضعیت خزش گوگل	افزایش پایدار cache hit و نبود خطای خزش

رکوردها را قبل از تعویض نیم‌سرور وارد کنید

ترتیب کار مهم است: اول دامنه را در پنل nsin اضافه کنید، رکوردها را وارد کنید و یک‌به‌یک با فایل چک‌لیست تطبیق دهید؛ فقط بعد از کامل شدن زون، نیم‌سرورها را در پنل ثبت‌کننده عوض کنید. اگر برعکس عمل کنید، دامنه مدتی به زونی خالی delegate شده و همه چیز — از وب تا ایمیل — با هم قطع می‌شود.

هنگام وارد کردن رکوردها، حواستان به تفکیک «پروکسی‌شده» و «DNS-only» باشد. رکوردهای ایمیل (MX و رکورد A که MX به آن اشاره می‌کند) و رکوردهای اعتبارسنجی باید DNS-only بمانند؛ هر رکورد وبی که می‌خواهید از کش، WAF و SSL لبه بهره‌مند شود، پروکسی می‌شود.

تست قبل از سوئیچ

مهم‌ترین گام همین است: لبه را ببینید قبل از این‌که دنیا آن را ببیند. دو راه دارید.

۱. پرس‌وجوی مستقیم از نیم‌سرورهای nsin. حتی وقتی دامنه هنوز delegate نشده، می‌توانید زون جدید را مستقیم بپرسید و IP لبه را بگیرید:

dig @<nameserver-nsin> example.com A +short

۲. override با فایل hosts یا سوئیچ --resolve. آن IP لبه را به دامنه‌تان نگاشت کنید و سایت را عملاً از روی CDN باز کنید، بدون این‌که کاربران تحت تأثیر باشند:

curl -I --resolve example.com:443:EDGE_IP https://example.com/

حداقل این‌ها را تست کنید: صفحه اصلی، یک صفحه عمیق، صفحه ورود، یک فایل استاتیک، یک فرم POST، مسیر پنل مدیریت و در صورت وجود، اتصال WebSocket. اگر گواهی هنوز در حال صدور است، رکورد CAA را چک کنید؛ CAA محدودکننده شایع‌ترین دلیل گیر کردن صدور است. جزئیات SSL رایگان و تمدید خودکارش در راهنمای گواهی SSL رایگان آمده است.

ساعت اول بعد از سوئیچ

در ساعت اول فقط پنج چیز را نگاه کنید:

• نرخ خطا — لاگ زنده درخواست‌ها را باز بگذارید و نسبت 502 و 504 را با baseline قبل از مهاجرت مقایسه کنید.
• صدور گواهی — تا وقتی گواهی لبه صادر و فعال نشده، مهاجرت تمام‌شده نیست.
• نرخ hit کش — در ابتدا پایین است و باید صعودی باشد. اگر ساکن ماند، معمولاً هدرهای Cache-Control مبدأ یا کوکی‌های سراسری مقصرند؛ منطق این ماجرا در نحوه کار کش در CDN توضیح داده شده.
• زنجیره ریدایرکت — با curl -IL مطمئن شوید بیش از یک پرش وجود ندارد.
• دسترسی خزنده‌ها — وضعیت خزش را در سرچ کنسول ببینید؛ نکات مربوط به دسترسی Googlebot از ایران دقیقاً همین‌جا به کار می‌آید.

در ساعت اول، «سایت بالا است» معیار نیست؛ معیار این است که نرخ خطای 5xx نسبت به قبل از مهاجرت تکان نخورده باشد.

خرابی‌های رایج و درمان‌شان

نشانه	علت	راه‌حل
حلقه ریدایرکت (ERR_TOO_MANY_REDIRECTS)	مبدأ هر درخواست HTTP را به HTTPS ریدایرکت می‌کند، ولی لبه با HTTP به مبدأ وصل می‌شود	ارتباط لبه با مبدأ را روی HTTPS بگذارید یا ریدایرکت مبدأ را مشروط به X-Forwarded-Proto کنید
همه لاگ‌های مبدأ یک IP نشان می‌دهند	اپلیکیشن REMOTE_ADDR را می‌خواند	خواندن IP واقعی از هدر مربوطه؛ در nginx با real_ip_header، در لاراول با TrustProxies
اتصال WebSocket قطع می‌شود	مسیر WebSocket زیر یک قانون کش رفته یا timeout کوتاه است	پروکسی WebSocket را فعال و مسیر آن را از کش خارج کنید
کاربران محتوای حساب یکدیگر را می‌بینند	قانون کش بیش از حد گسترده است	مسیرهای /wp-admin، /login و APIهای کاربری را استثنا کنید و bypass روی کوکی نشست بگذارید
ایمیل قطع شده	MX منتقل نشده یا رکورد میل پروکسی شده	رکوردهای ایمیل را DNS-only کنید

درباره IP واقعی کاربر

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

درباره کش شدن پنل مدیریت

قانون کش را هیچ‌وقت با scope گسترده روی /* تعریف نکنید. در nsin قوانین کش per-rule و مبتنی بر مسیرند؛ از الگوی دقیق استفاده کنید، برای مسیرهای احراز هویت‌شده قانون bypass بگذارید و بعد از هر تغییر قالب، purge کش را فراموش نکنید.

برنامه بازگشت

قبل از سوئیچ، معیار توقف را بنویسید: مثلاً «اگر نرخ 5xx بیش از ۱۵ دقیقه بالاتر از baseline بماند، برمی‌گردیم». تصمیم‌گیری وسط بحران، تصمیم‌گیری خوبی نیست.

بازگشت سریع: در پنل، پروکسی رکورد را خاموش و آن را DNS-only کنید. ترافیک مستقیم به مبدأ می‌رود و چون TTL را از قبل پایین آورده‌اید، ظرف چند دقیقه اعمال می‌شود. این روش ارجح است، چون DNS روی nsin می‌ماند و بعد از رفع مشکل دوباره پروکسی را روشن می‌کنید.

بازگشت کامل: برگرداندن نیم‌سرورها به ارائه‌دهنده قبلی، که به TTL رکورد NS وابسته است و ممکن است ساعت‌ها طول بکشد؛ پس زون قدیمی را تا ۷۲ ساعت بعد از مهاجرت حذف نکنید و مبدأ را هم خاموش نکنید.

پرسش‌های متداول

راه‌اندازی CDN چقدر طول می‌کشد؟

کار پنل چند دقیقه است: افزودن دامنه، وارد کردن رکوردها و فعال کردن پروکسی. آنچه زمان می‌برد انتشار تغییر نیم‌سرورهاست که به TTL بستگی دارد؛ با کاهش TTL از ۴۸ ساعت قبل، این پنجره کوتاه‌تر و قابل پیش‌بینی‌تر می‌شود.

آیا اتصال دامنه به CDN باعث قطعی سایت می‌شود؟

اگر رکوردها قبل از تعویض نیم‌سرور کامل وارد شده باشند و لبه را با hosts یا --resolve تست کرده باشید، نه. قطعی‌های واقعی تقریباً همیشه نتیجه زون ناقص، هدر Host پذیرفته‌نشده در مبدأ یا فایروالی است که IPهای لبه را بلاک می‌کند.

باید نیم‌سرورها را عوض کنم یا فقط رکورد A کافی است؟

nsin میزبانی کامل DNS ابری دارد و مسیر استاندارد، تغییر نیم‌سرورهاست؛ این کار مدیریت رکوردها، پروکسی، صدور گواهی و قوانین لبه را یکجا می‌کند و rollback را هم ساده‌تر نگه می‌دارد.

بعد از مهاجرت ایمیل دامنه‌ام قطع می‌شود؟

نه، به شرطی که رکوردهای MX و TXT عیناً منتقل شوند و رکورد A مربوط به سرور ایمیل DNS-only بماند. پروکسی کردن رکورد میل، رایج‌ترین اشتباهی است که ایمیل را می‌شکند.

قدم بعدی

مهاجرت بدون قطعی نتیجه نظم است، نه شانس: فهرست رکوردها را بگیرید، TTL را پایین بیاورید، زون را کامل کنید، لبه را پیش از سوئیچ تست کنید و معیار بازگشت را از قبل تعریف کنید. دامنه‌تان را در پنل nsin اضافه کنید و با دوره آزمایشی هفت‌روزه Enterprise، همین چک‌لیست را یک بار بدون ریسک اجرا کنید.