سایتی که سرورش در آلمان است، برای بازدیدکننده‌ای در شیراز با مکث بالا می‌آید و برای مدیرش در برلین بی‌معطلی. CDN داخلی همین شکاف را می‌بندد: نسخه‌ای از فایل‌های سایت روی لبه‌هایی داخل ایران می‌ماند و کاربر داخلی آن را از نزدیک می‌گیرد. جابه‌جایی هفت گام دارد و زمان‌بندی‌اش را TTL فعلی رکوردهای شما تعیین می‌کند.

  1. از رکوردهای DNS خروجی بگیرید (برگشت: ندارد).
  2. در DNS فعلی TTL وب و NS را کوتاه کنید و به اندازه TTL قبلی صبر کنید (برگشت: مقدار قبلی).
  3. دامنه را در پنل CDN اضافه کنید؛ نیم‌سرور یا CNAME (برگشت: حذف دامنه).
  4. رکوردها را با فهرست گام یک تطبیق بدهید، ابر خاموش (برگشت: اصلاح رکورد).
  5. نیم‌سرورها را نزد ثبت‌کننده عوض کنید (برگشت: NSهای قبلی).
  6. پروتکل HTTPS تا مبدأ را تنظیم کنید و ابر وب را روشن کنید (برگشت: خاموش کردن ابر).
  7. قانون کش بنویسید و از دو شبکه بسنجید (برگشت: پاک کردن کش).

💡 ترتیبی که راه برگشت را باز نگه می‌دارد

لبه داخل کشور فایل‌های ثابت سایت را نزدیک کاربر نگه می‌دارد.
✅ تا گواهی لبه صادر نشده، HTTPS را پیش‌فرض نکنید.
✅ HSTS را آخر روشن کنید. مرورگر تا پایان مهلتش آن را رها نمی‌کند.

این کار بیشتر در DNS می‌گذرد و هر گامش راه برگشت دارد. عدد شبکه بیرونی را هم با فرمان‌های کلودفلر برای سایت ایرانی از اتصال خودتان بگیرید.

cdn داخلی، مسیر درخواست کاربر از لبه داخل کشور تا سرور مبدأ

مزیت شبکه توزیع داخلی، راه اتصال و قانون کش

مزیت اصلی CDN داخلی فاصله کوتاه است. درخواست کاربر ایرانی به لبه‌ای داخل کشور می‌رسد و فایل‌های ثابت از همان‌جا برمی‌گردند. لبه فقط برای چیزی سراغ سرور مبدأ می‌رود که در کشش نیست یا نباید باشد.

فایل‌های ثابت کنار کاربر

تصویرها، CSS، اسکریپت‌ها و فونت‌ها در لبه می‌مانند، انبار محله‌ای شرکت پخش مویرگی که سفارش را بی‌نیاز از کارخانه می‌کند. تا مهلت کش تمام نشده، لبه معمولاً این فایل‌ها را از مبدأ نمی‌خواهد. کندی PHP یا پایگاه داده اما با لبه درمان نمی‌شود.

نیم‌سرور یا CNAME؛ دو راه وصل شدن

مستند منبع دامنه CDN ابر آروان دو نوع اتصال را نام می‌برد: Full به معنی NS Delegate و Partial به معنی CNAME Setup. در اولی DNS کل دامنه به ارائه‌دهنده می‌رود و در دومی فقط نام‌های انتخابی به لبه اشاره می‌کنند. در منبع رکورد DNS آروان هر رکورد فیلد cloud دارد، یعنی «مدیریت رکورد توسط آروان»؛ در این متن به آن «ابر» می‌گوییم.

🎯 کدام راه به سایت شما می‌خورد

◀️ نیم‌سرور: همه رکوردها، از جمله MX، باید در پنل تازه باشند. رکورد ریشه دامنه هم همان‌جاست و گیر CNAME را ندارد.
◀️ CNAME: وقتی DNS را جای دیگری نگه داشته‌اید یا فقط www و زیردامنه فایل را می‌برید.
◀️ گیر CNAME ریشه دامنه است. به حکم RFC 1034، گره دارای CNAME نباید داده دیگری داشته باشد و ریشه همیشه SOA و NS دارد.

قانون کش؛ چه چیزی در لبه بماند

لبه یک کش مشترک است و پاسخ ذخیره‌شده را به چند کاربر می‌دهد. در استاندارد RFC 9111، پاسخ با Cache-Control: private نباید در کش مشترک بماند. no-store ذخیره را در هر کشی ممنوع می‌کند. s-maxage هم برای کش مشترک بر max-age مقدم است.

فایل ثابت با عمر طولانی در لبه بماند و صفحه ورود کش نشود. نام گزینه‌ها و رعایت سرآیندهای مبدأ را در مستند کش ارائه‌دهنده خودتان بخوانید.

⚠️ صفحه حساب یک نفر، جلوی چشم نفر بعدی

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

جای گواهی SSL با آمدن CDN عوض می‌شود

جای گواهی SSL با آمدن CDN عوض می‌شود

با روشن شدن CDN داخلی، مرورگر کاربر اتصال TLS را با لبه برقرار می‌کند و قفلی که می‌بیند مال گواهی لبه است. پشتش مسیر دومی هست، از لبه تا سرور شما. هر دو رمزنگاری می‌خواهند.

گواهی لبه؛ صادرشده یا آپلودی

طبق راهنمای تنظیمات HTTPS ابر آروان (آبان ۱۴۰۵)، فعال کردن HTTPS یک گواهی رایگان Let’s Encrypt صادر می‌کند که فعلاً حدود سه ماه اعتبار دارد و خودکار تمدید می‌شود. خود Let’s Encrypt اعلام کرده از ۱۰ فوریه ۲۰۲۷ این عمر ۶۴ روز می‌شود. راه دیگر آپلود کلید و گواهی خودتان در قالب PEM است.

پروتکل لبه تا مبدأ؛ ریسک حالت HTTP

گزینه «پروتکل ارتباط آروان با سرورهای اصلی» سه مقدار دارد: HTTP، HTTPS و خودکار، که پروتکل را از درخواست کاربر می‌گیرد. مستند برای دو مقدار آخر فقط یک شرط می‌گذارد: سرور از HTTPS پشتیبانی کند.

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

روشن کردن HSTS بعد از پایدار شدن

همان راهنما هشدار می‌دهد که HSTS بعد از فعال و کش شدن، تا پایان مهلتش تغییرپذیر نیست. پس تا مطمئن نشده‌اید برنمی‌گردید، روشنش نکنید.

مبدأ را فقط برای لبه باز بگذارید

با نشانی مبدأ، می‌شود بی‌واسطه لبه به سرور رسید. بعد از پایدار شدن، درگاه وب سرور، یعنی 80 و 443، را فقط برای بازه IPهایی باز بگذارید که ارائه‌دهنده رسماً منتشر می‌کند، و فهرست را به‌روز نگه دارید. این قانون راه برگشت را می‌بندد؛ پیش از خاموش کردن ابر، پورت‌ها را برای همه باز کنید.

روز جابه‌جایی NS را با TTL کوتاه شروع کنید

روز جابه‌جایی NS را با TTL کوتاه شروع کنید

طبق RFC 1034، TTL سقف زمانی است که رکورد در کش resolverها می‌ماند. پیش از رفتن به CDN داخلی، در DNS فعلی TTL رکوردهای وب را کوتاه کنید. بعد دست‌کم به اندازه TTL قبلی صبر کنید تا نسخه‌های کش‌شده قدیمی کنار بروند؛ روز جابه‌جایی بعد از این انتظار است.

نیم‌سرور در دو جا کش می‌شود

استاندارد RFC 1034 رکوردهای NS واگذاری را در زون والد می‌گذارد، برای ir یعنی ایرنیک، و TTL آن‌ها دست شما نیست. اما بخش 5.4.1 در RFC 2181 پاسخ authoritative را از داده ارجاع معتبرتر می‌داند، پس resolverها ممکن است NS را از زون فعلی شما با TTL خودتان نگه دارند. TTL رکورد NS را هم کوتاه کنید. مراحل تغییر نیم‌سرور دامنه در ایرنیک را از پیش مرور کنید.

فهرست رکوردها را دو بار بخوانید

در روش نیم‌سرور، رکوردی که در پنل تازه نباشد از روز تغییر وجود ندارد. این‌ها بیشتر جا می‌مانند، معمولاً همان‌هایی که سال‌ها کسی سراغشان نرفته:

  1. رکورد MX و TXTهای ایمیل (SPF و DKIM).
  2. رکوردهای TXT تأیید مالکیت سرویس‌ها.
  3. زیردامنه‌های قدیمی، مثل API موبایل.
  4. رکورد AAAA اگر سرور IPv6 دارد.

ورود خودکار رکوردها را هم با خروجی گام یک تطبیق بدهید. ابر رکوردهای سرور ایمیل خاموش بماند.

🔸 فرمان‌های dig برای روز تغییر

نیم‌سرورها با TTL خوانا (برای TTL اصلی، نه باقی‌مانده کش، با @ از نیم‌سرور فعلی بپرسید).
dig +noall +answer +ttlunits example.ir NS
مسیر واگذاری از ریشه تا زون والد.
dig +trace example.ir NS
پرسش از نیم‌سرور تازه پیش از تغییر (NEW-NS نام نیم‌سرور پنل است؛ TXT را هم همین‌طور بپرسید).
dig @NEW-NS +noall +answer example.ir MX
dig @NEW-NS +noall +answer www.example.ir A

پیش از شروع، این کارت را دم دست بگذارید:

گام جابه‌جاییبرگشت همان گام
کوتاه کردن TTLمقدار TTL قبلی بعد از پایدار شدن
افزودن دامنه به پنلحذف دامنه
تغییر NS نزد ثبت‌کنندهنیم‌سرورهای قبلی؛ پخشش به TTL هر دو زون بسته است
روشن کردن ابر رکورد وبخاموش کردن ابر
بستن 80 و 443 به IPهای لبهباز کردن برای همه، پیش از خاموش کردن ابر
پروتکل HTTPS تا مبدأحالت قبلی رکورد، هرگز HTTP
قانون کشبرداشتن قانون، پاک کردن کش
روشن کردن HSTSندارد؛ برای همین گام آخر است

اگر اینترنت بین‌الملل مختل شود، سایت چه وضعی دارد؟

تا شبکه داخلی برقرار است، کاربر ایرانی به لبه CDN داخلی می‌رسد. لبه هم فقط چیزی را تحویل می‌دهد که در کش دارد و مهلتش نگذشته است. هر درخواستی که به مبدأ نیاز دارد، به مسیر لبه تا سرور شما وابسته است.

وقتی مبدأ بیرون از کشور است

صفحه‌های کش‌شده باز می‌شوند و فرم و پرداخت از دسترس خارج می‌شوند. تحویل نسخه کهنه بعد از پایان مهلت به تنظیمات ارائه‌دهنده بستگی دارد.

وقتی مبدأ هم داخل کشور است

فقط وابستگی‌های بیرونی می‌شکنند، مثل فونتی که مرورگر از دامنه خارجی می‌گیرد؛ آن‌ها را روی خود سایت بگذارید.

سنجش پاسخ لبه از دو شبکه

🔸 سرآیندهای پاسخ با curl -I

فرمان: curl -I https://www.example.ir/static/logo.png
گزینه -I با درخواست HEAD فقط سرآیندها را می‌آورد. از اینترنت داخلی و از سروری بیرون کشور بزنید. معیار قبول: هر دو پاسخ 200 و در اجرای دوم، سرآیند وضعیت کش برخورد (HIT). نام سرآیند را از مستند ارائه‌دهنده بگیرید.

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

با تغییر نیم‌سرور، ایمیل شرکت قطع می‌شود؟

اگر MX و TXTهای SPF و DKIM عیناً به پنل تازه بروند، نه. پیش از تغییر NS آن‌ها را از نیم‌سرور تازه بپرسید.

در DNS استاندارد نه؛ ریشه SOA و NS دارد و گره CNAME نباید داده دیگری داشته باشد.

نه. مستند آروان برای HTTPS تا مبدأ پشتیبانی سرور از HTTPS را شرط کرده و این بدون گواهی روی سرور ممکن نیست. سنجش اعتبار آن گواهی در مستند نیامده.

پروتکل لبه تا مبدأ HTTP است و سرور آن را به HTTPS می‌فرستد. پروتکل مبدأ را HTTPS کنید.

عدد ثابتی ندارد. resolverها NS را تا پایان TTL نگه می‌دارند، چه نسخه زون والد و چه زون فعلی. dig +trace نسخه زون والد را نشان می‌دهد.

نباید. مسیر مدیریت و ورود را مستثنا کنید و از مبدأ برایشان private بفرستید.

بله، با روش CNAME. فقط آن زیردامنه، مثلاً static، به لبه اشاره می‌کند و نشانی فایل‌ها در قالب هم باید عوض شود.

جمع‌بندی؛ هر گام CDN داخلی با راه برگشتش TTL وب و NS را زودتر کوتاه کنید و به اندازه TTL قبلی صبر کنید. پروتکل تا مبدأ را روی HTTPS بگذارید. پورت‌های بسته به IP لبه را پیش از هر برگشت باز کنید. صفحه کاربر واردشده جایی در کش مشترک ندارد و HSTS گام آخر است. در اختلال اینترنت بین‌الملل، لبه فقط آنچه را در کش دارد می‌رساند و صفحه پویا به محل سرور مبدأ بستگی دارد.

🚀 وقتی بخشی از مخاطب بیرون از ایران است

هزینه یک گام شبکه اضافه برای کاربر داخلی و جدول تصمیم بر پایه مخاطب.

در آخرین جابه‌جایی DNS شما، کدام رکورد نزدیک بود جا بماند؟

مستنداتی که تنظیم‌ها از آن‌ها آمده

وب داده
وب داده

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

مقاله‌ها: 288
پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *