راه اندازی CDN ایران گام‌به‌گام؛ از نام‌سرور تا روشن کردن ابر
این راهنما مسیر عملی بردن دامنه پشت CDN را به ترتیب درست نشان می‌دهد: افزودن دامنه، ثبت رکوردها، تغییر نام‌سرور، انتخاب حالت SSL و آزمون با dig و curl. هزینه‌ی دوره‌ی آزمایش هم با نرخ واقعی پنل حساب شده است.
اگر تصمیمتان را گرفته‌اید و فقط می‌خواهید دامنه را بی‌دردسر پشت شبکه‌ی توزیع محتوا ببرید، این راهنما همان مسیر عملی است. راه اندازی CDN در عمل پنج کار پشت‌سرهم است: افزودن دامنه به پنل، ثبت رکوردهای DNS، تغییر نام‌سرور (NS) نزد ثبت‌کننده‌ی دامنه، انتخاب حالت SSL و در پایان آزمون با چند فرمان ساده. ترتیب این کارها مهم است؛ بیشتر قطعی‌هایی که هنگام انتقال پیش می‌آید از جابه‌جا انجام دادن همین گام‌هاست. اگر هنوز با مفهوم نود لبه و کش آشنا نیستید، پیش از ادامه نوشته‌ی CDN ایران چیست و چطور سرعت سایت را بالا می‌برد را بخوانید؛ این‌جا فقط سراغ انجام کار می‌رویم.
پیش از راه اندازی CDN: فهرست وارسی
پیش از آن‌که در پنل چیزی بسازید، این موارد را آماده کنید:
- دسترسی به پنل ثبت‌کننده‌ی دامنه. برای دامنه‌ی ir همان حسابی که دامنه را با آن ثبت یا تمدید کرده‌اید.
- آی‌پی سرور مبدأ و درگاهی که سایت روی آن اجرا می‌شود.
- فهرست کامل رکوردهای فعلی DNS، به‌ویژه MX و TXT که اگر جا بمانند ایمیل از کار می‌افتد.
- وضعیت HTTPS روی مبدأ: گواهی دارد یا نه، و آیا وب‌سرور همه‌ی درخواست‌های HTTP را به HTTPS هدایت می‌کند.
- سرور مبدأ آماده. اگر هنوز سروری ندارید، می‌توانید یک سرور ساعتی ایران بسازید که معمولاً در حدود یک دقیقه آماده می‌شود و سپس دامنه را روی CDN ایران ابر ویرا ببرید؛ هر دو در دیتاسنتر ایران‌اند.
برای برداشتن فهرست رکوردها، اگر پنل DNS فعلی خروجی نمی‌دهد، هر نوع را جدا بپرسید:
dig +short NS example.ir
dig +short A example.ir
dig +short A www.example.ir
dig +short MX example.ir
dig +short TXT example.irخروجی را جایی نگه دارید؛ در گام دوم با همین فهرست مقایسه می‌کنید. اگر زیردامنه‌های دیگری مثل api یا mail دارید، آن‌ها را هم جداگانه بپرسید، چون dig زیردامنه‌ها را خودبه‌خود فهرست نمی‌کند.
گام ۱: افزودن دامنه به پنل CDN
در پنل CDN دامنه‌ی اصلی را بدون www و بدون https وارد کنید؛ یعنی فقط example.ir. زیردامنه‌ها بعداً به‌صورت رکورد زیر همین دامنه تعریف می‌شوند و لازم نیست هر کدام را جدا اضافه کنید.
پس از افزودن، پنل نام‌سرورهایی را نشان می‌دهد که باید در گام سوم نزد ثبت‌کننده‌ی دامنه ثبت شوند. آن‌ها را دقیق و بدون فاصله‌ی اضافه یادداشت کنید. هنوز به ثبت‌کننده دست نزنید؛ اول باید رکوردها کامل شوند.
گام ۲: ثبت رکوردها و تصمیم درباره‌ی ابر
تا وقتی NS عوض نشده، رکوردهایی که در پنل CDN وارد می‌کنید هیچ اثری روی سایت ندارند. همین فرصت را غنیمت بدانید و همه‌ی رکوردها را پیش از تغییر NS کامل کنید تا لحظه‌ی جابه‌جایی چیزی جا نماند.
کنار هر رکورد A یا CNAME تصمیم می‌گیرید ابر روشن باشد یا خاموش. با ابر روشن، پاسخ DNS آی‌پی نود لبه را برمی‌گرداند و درخواست‌ها از CDN عبور می‌کنند؛ کش، SSL لبه و دیوار آتش وب فقط در همین حالت کار می‌کنند. با ابر خاموش، DNS آی‌پی واقعی را برمی‌گرداند و CDN فقط نقش سرور نام را دارد.
| رکورد | مقدار نمونه | ابر |
|---|---|---|
| A برای @ | آی‌پی مبدأ وب | روشن |
| A یا CNAME برای www | آی‌پی مبدأ یا example.ir | روشن |
| A برای mail | آی‌پی سرور ایمیل | خاموش |
| MX | mail.example.ir | کاربرد ندارد |
| TXT (SPF و تأیید مالکیت) | همان مقدار قبلی | کاربرد ندارد |
| A برای زیردامنه‌ی SSH یا مدیریت سرور | آی‌پی سرور | خاموش |
دو نکته‌ی تکمیلی: اگر سرویسی دارید که با وب‌سوکت یا gRPC کار می‌کند، CDN از هر دو پشتیبانی می‌کند و می‌توانید ابر را برایش روشن بگذارید. اگر برنامه روی درگاهی جز ۸۰ و ۴۴۳ اجرا می‌شود، تنظیم درگاه‌های جایگزین را در پنل بررسی کنید و سپس ابر را روشن کنید.
گام ۳: تغییر NS نزد ثبت‌کننده
اگر از قبل DNS دیگری داشتید، یک کار احتیاطی هم هست: چند ساعت پیش از تغییر، TTL رکوردهای مهم را در DNS فعلی پایین بیاورید (مثلاً ۳۰۰ ثانیه) تا کش resolverها زودتر تازه شود.
سپس در پنل ثبت‌کننده، بخش ویرایش نام‌سرورهای دامنه را باز کنید و همه‌ی نام‌سرورهای قبلی را با نام‌سرورهایی که پنل CDN داده جایگزین کنید. ترکیب نام‌سرور قدیم و جدید یعنی بخشی از کاربران رکوردهای قدیمی را می‌گیرند و بخشی رکوردهای جدید را؛ رفتاری که عیب‌یابی‌اش بسیار سخت است.
انتشار تغییر NS زمان می‌برد و این زمان به ثبت‌کننده و کش resolverها بستگی دارد. برای دیدن پاسخ مستقیم از زنجیره‌ی DNS، نه از کش، از این فرمان استفاده کنید:
dig +trace NS example.irوقتی در خط‌های پایانی خروجی نام‌سرورهای جدید را دیدید، تغییر نزد ثبت‌کننده نشسته است، هرچند ممکن است برخی کاربران مدتی هنوز پاسخ قدیمی را از کش بگیرند.
گام ۴: انتخاب حالت SSL بر پایه‌ی وضعیت مبدأ
CDN گواهی SSL رایگان را روی لبه صادر می‌کند؛ پرسش اصلی این است که ارتباط لبه تا مبدأ چگونه باشد. این جدول را بر پایه‌ی وضعیت واقعی سرورتان بخوانید:
| وضعیت مبدأ | حالت پیشنهادی | کاری که روی مبدأ لازم است |
|---|---|---|
| گواهی ندارد و فقط HTTP دارد | انعطاف‌پذیر (موقت) | هدایت اجباری به HTTPS را روی وب‌سرور خاموش کنید |
| گواهی خودامضا یا منقضی دارد | کامل | درگاه ۴۴۳ روی مبدأ باز و فعال باشد |
| گواهی معتبر برای همین دامنه دارد | سخت‌گیرانه | تمدید خودکار گواهی را فعال نگه دارید |
حالت انعطاف‌پذیر را پله‌ی گذار بدانید، نه مقصد؛ در این حالت مسیر لبه تا مبدأ رمزنگاری نمی‌شود. یک راه عملی برای رسیدن به حالت سخت‌گیرانه این است که گواهی Let's Encrypt را پیش از روشن کردن ابر روی مبدأ بگیرید، وقتی دامنه هنوز مستقیم به سرور اشاره می‌کند؛ مثلاً روی سروری با Nginx:
sudo certbot --nginx -d example.ir -d www.example.irپیش‌نیازهای حالت سخت‌گیرانه و این‌که چرا رایگان بودن گواهی به‌تنهایی کافی نیست، در نوشته‌ی هشت معیار برای انتخاب یک CDN داخلی آمده است.
گام ۵: آزمون پس از روشن کردن ابر
پس از جابه‌جایی NS، این فرمان‌ها را به ترتیب اجرا کنید:
dig +short example.ir
curl -sI https://example.ir
curl -sIL http://example.ir
curl -sI https://example.ir/assets/style.css
curl -sI --resolve example.ir:443:ORIGIN_IP https://example.irهر خط این را می‌آزماید:
- dig: باید آی‌پی لبه برگردد، نه آی‌پی مبدأ. اگر هنوز آی‌پی مبدأ را می‌بینید، یا ابر برای آن رکورد خاموش است یا NS هنوز منتشر نشده.
- HTTPS اصلی: کد پاسخ باید ۲۰۰ یا یک هدایت معقول باشد، نه خطای ۵xx.
- دنبال کردن هدایت‌ها با -L: اگر خروجی پشت‌سرهم چند هدایت تکراری نشان داد، به حلقه‌ی هدایت خورده‌اید (پایین‌تر توضیح داده شده).
- فایل ایستا: همین فرمان را دو بار اجرا کنید و سرآیندهای پاسخ را مقایسه کنید؛ اگر سرآیندی برای وضعیت کش برمی‌گردد، بار دوم باید برخورد کش را نشان دهد.
- دور زدن لبه با --resolve: به‌جای ORIGIN_IP آی‌پی مبدأ را بگذارید. اگر این درخواست کار کند و درخواست عادی نه، مشکل در تنظیم CDN است نه در سرور.
بیرون از خط فرمان هم این‌ها را وارسی کنید: ارسال و دریافت یک ایمیل آزمایشی، ورود به بخش مدیریت سایت، و اگر وب‌سوکت دارید، برقراری اتصال زنده. در پایان، پایش سلامت مبدأ را در پنل فعال کنید تا اگر سرور از دسترس خارج شد زودتر بفهمید.
هزینه‌ی دوره‌ی آزمایش با نرخ واقعی
نرخ‌ها به تاریخ آبان ۱۴۰۵؛ بهای روز را ماشین‌حساب صفحه‌ی سفارش نشان می‌دهد. هزینه‌ی CDN فقط به‌ازای دانلود حساب می‌شود، با نرخ ۱٬۲۰۰ تومان برای هر گیگابایت، و آپلود رایگان است. پس برای آزمون، حجم ثابت ماهانه نمی‌خرید و فقط مصرف واقعی کسر می‌شود.
فرض کنید یک هفته سایت را پشت CDN آزمایش می‌کنید و ۴۰ گیگابایت دانلود از لبه دارید:
- ۴۰ گیگابایت × ۱٬۲۰۰ تومان = ۴۸٬۰۰۰ تومان
اگر برای آزمون یک مبدأ جدا بسازید، مثلاً طرح «اقتصادی ۲» (۲ هسته، ۲ گیگابایت رم، ۱۵ گیگابایت دیسک) با نرخ ساعتی ۱٬۶۴۴ تومان و سه روز روشن نگهش دارید:
- ۷۲ ساعت × ۱٬۶۴۴ تومان = ۱۱۸٬۳۶۸ تومان
ترافیک دانلود خود سرور ابری ساعتی هم جداگانه با نرخ ۱٬۰۰۰ تومان برای هر گیگابایت حساب می‌شود؛ هرچه کش درست‌تر تنظیم شود، درخواست کمتری به مبدأ می‌رسد. پس از آزمون، سرور را حذف کنید؛ خاموش کردن هزینه‌ی ساعتی را متوقف نمی‌کند. اگر قرار است مبدأ همیشه روشن بماند، حساب ساعتی در برابر ماهانه را در نوشته‌ی سرور ساعتی یا ماهانه؛ محاسبه‌ی سربه‌سر ببینید.
اشتباه‌های رایج
۱. تغییر NS پیش از کامل کردن رکوردها. نتیجه‌اش این است که ایمیل یا زیردامنه‌ای که فراموش شده بلافاصله از کار می‌افتد. راه پرهیز: فهرست خروجی dig را خط‌به‌خط با رکوردهای پنل CDN تطبیق دهید و تنها پس از آن سراغ ثبت‌کننده بروید.
۲. روشن کردن ابر برای رکوردهای غیروب. رکورد mail یا زیردامنه‌ای که برای SSH استفاده می‌کنید اگر از لبه عبور کند، اتصال ایمیل و SSH برقرار نمی‌شود. راه پرهیز: ابر را فقط برای رکوردهایی روشن کنید که ترافیک وب، وب‌سوکت یا gRPC دارند.
۳. حالت انعطاف‌پذیر همراه با هدایت اجباری به HTTPS روی مبدأ. لبه درخواست را با HTTP به مبدأ می‌فرستد، مبدأ آن را به HTTPS هدایت می‌کند و این چرخه تکرار می‌شود تا مرورگر خطای هدایت‌های بیش از حد بدهد. راه پرهیز: یا هدایت را روی مبدأ بردارید و آن را به لبه بسپارید، یا گواهی روی مبدأ نصب کنید و به حالت کامل یا سخت‌گیرانه بروید.
پرسش‌های متداول
هنگام تغییر نام‌سرور سایت قطع می‌شود؟
اگر رکوردها پیش از تغییر NS کامل باشند، نه؛ در دوره‌ی انتشار، بخشی از کاربران از مسیر قدیم و بخشی از مسیر CDN به همان مبدأ می‌رسند. قطعی معمولاً از رکورد جاافتاده یا حالت SSL نادرست است.
می‌شود فقط یک زیردامنه را پشت CDN برد؟
با تغییر NS، DNS کل دامنه به پنل CDN می‌آید، اما ابر را می‌توانید فقط برای همان زیردامنه روشن کنید و بقیه‌ی رکوردها را با ابر خاموش نگه دارید.
آی‌پی سرور مبدأ پس از روشن کردن ابر عوض می‌شود؟
خیر؛ آی‌پی سرور همان می‌ماند و فقط پاسخ DNS به‌جای آن آی‌پی لبه را نشان می‌دهد. برای همین آزمون با --resolve روی آی‌پی مبدأ همچنان کار می‌کند.
اگر بخواهم CDN را کنار بگذارم چه کنم؟
سریع‌ترین راه خاموش کردن ابر برای رکوردهای وب است تا DNS دوباره آی‌پی مبدأ را برگرداند. اگر می‌خواهید DNS را هم جابه‌جا کنید، پیش از برگرداندن NS رکوردها را در DNS مقصد کامل کنید.
جمع‌بندی
راه اندازی CDN وقتی بی‌دردسر است که ترتیب را رعایت کنید: دامنه را اضافه کنید، رکوردها را کامل و ابر هر کدام را تعیین کنید، سپس NS را یک‌جا عوض کنید، حالت SSL را با وضعیت واقعی مبدأ هماهنگ کنید و با dig و curl همه‌چیز را بیازمایید. پس از اولین راه اندازی CDN، قوانین مسیر و تنظیم کش را با فرصت کافی دقیق‌تر کنید. اگر می‌خواهید این مسیر را با مبدأ و نودهای لبه‌ی داخل ایران و هزینه‌ی مبتنی بر مصرف دانلود امتحان کنید، از ابر ویرا شروع کنید.
