
به اشتراک بگذارید

به اشتراک بگذارید
سایتی که سرورش در آلمان است، برای بازدیدکنندهای در شیراز با مکث بالا میآید و برای مدیرش در برلین بیمعطلی. CDN داخلی همین شکاف را میبندد: نسخهای از فایلهای سایت روی لبههایی داخل ایران میماند و کاربر داخلی آن را از نزدیک میگیرد. جابهجایی هفت گام دارد و زمانبندیاش را TTL فعلی رکوردهای شما تعیین میکند.
💡 ترتیبی که راه برگشت را باز نگه میدارد
لبه داخل کشور فایلهای ثابت سایت را نزدیک کاربر نگه میدارد.
✅ تا گواهی لبه صادر نشده، HTTPS را پیشفرض نکنید.
✅ HSTS را آخر روشن کنید. مرورگر تا پایان مهلتش آن را رها نمیکند.
این کار بیشتر در DNS میگذرد و هر گامش راه برگشت دارد. عدد شبکه بیرونی را هم با فرمانهای کلودفلر برای سایت ایرانی از اتصال خودتان بگیرید.
📌 برنامه روز جابهجایی
◀️ مزیت لبه نزدیک، راه اتصال و کش
◀️ گواهی لبه و گواهی مبدأ
◀️ روز تغییر نیمسرور و TTL
◀️ رفتار سایت در اختلال اینترنت بینالملل

مزیت اصلی CDN داخلی فاصله کوتاه است. درخواست کاربر ایرانی به لبهای داخل کشور میرسد و فایلهای ثابت از همانجا برمیگردند. لبه فقط برای چیزی سراغ سرور مبدأ میرود که در کشش نیست یا نباید باشد.
تصویرها، CSS، اسکریپتها و فونتها در لبه میمانند، انبار محلهای شرکت پخش مویرگی که سفارش را بینیاز از کارخانه میکند. تا مهلت کش تمام نشده، لبه معمولاً این فایلها را از مبدأ نمیخواهد. کندی PHP یا پایگاه داده اما با لبه درمان نمیشود.
مستند منبع دامنه 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 بفرستد و مسیرهایشان مستثنا شود. بعد با دو مرورگر جدا وارد شوید و مقایسه کنید.

با روشن شدن CDN داخلی، مرورگر کاربر اتصال TLS را با لبه برقرار میکند و قفلی که میبیند مال گواهی لبه است. پشتش مسیر دومی هست، از لبه تا سرور شما. هر دو رمزنگاری میخواهند.
طبق راهنمای تنظیمات HTTPS ابر آروان (آبان ۱۴۰۵)، فعال کردن HTTPS یک گواهی رایگان Let’s Encrypt صادر میکند که فعلاً حدود سه ماه اعتبار دارد و خودکار تمدید میشود. خود Let’s Encrypt اعلام کرده از ۱۰ فوریه ۲۰۲۷ این عمر ۶۴ روز میشود. راه دیگر آپلود کلید و گواهی خودتان در قالب PEM است.
گزینه «پروتکل ارتباط آروان با سرورهای اصلی» سه مقدار دارد: HTTP، HTTPS و خودکار، که پروتکل را از درخواست کاربر میگیرد. مستند برای دو مقدار آخر فقط یک شرط میگذارد: سرور از HTTPS پشتیبانی کند.
مقدار HTTP رمزنگاری را در لبه تمام میکند. کاربر قفل میبیند، ولی رمز عبور و کوکی از لبه تا سرور بیرمز میروند. اگر سرور هم درخواست HTTP را به HTTPS برگرداند، حلقه درست میشود. رمزنگاری تا مبدأ هنوز به معنای وارسی گواهی سرور نیست. مستند آروان درباره سنجش گواهی مبدأ چیزی نمیگوید. HTTPS را برگزینید، گواهی معتبر روی سرور نگه دارید و سنجش را از پشتیبانی بپرسید.
همان راهنما هشدار میدهد که HSTS بعد از فعال و کش شدن، تا پایان مهلتش تغییرپذیر نیست. پس تا مطمئن نشدهاید برنمیگردید، روشنش نکنید.
با نشانی مبدأ، میشود بیواسطه لبه به سرور رسید. بعد از پایدار شدن، درگاه وب سرور، یعنی 80 و 443، را فقط برای بازه IPهایی باز بگذارید که ارائهدهنده رسماً منتشر میکند، و فهرست را بهروز نگه دارید. این قانون راه برگشت را میبندد؛ پیش از خاموش کردن ابر، پورتها را برای همه باز کنید.

طبق RFC 1034، TTL سقف زمانی است که رکورد در کش resolverها میماند. پیش از رفتن به CDN داخلی، در DNS فعلی TTL رکوردهای وب را کوتاه کنید. بعد دستکم به اندازه TTL قبلی صبر کنید تا نسخههای کششده قدیمی کنار بروند؛ روز جابهجایی بعد از این انتظار است.
استاندارد RFC 1034 رکوردهای NS واگذاری را در زون والد میگذارد، برای ir یعنی ایرنیک، و TTL آنها دست شما نیست. اما بخش 5.4.1 در RFC 2181 پاسخ authoritative را از داده ارجاع معتبرتر میداند، پس resolverها ممکن است NS را از زون فعلی شما با TTL خودتان نگه دارند. TTL رکورد NS را هم کوتاه کنید. مراحل تغییر نیمسرور دامنه در ایرنیک را از پیش مرور کنید.
در روش نیمسرور، رکوردی که در پنل تازه نباشد از روز تغییر وجود ندارد. اینها بیشتر جا میمانند، معمولاً همانهایی که سالها کسی سراغشان نرفته:
ورود خودکار رکوردها را هم با خروجی گام یک تطبیق بدهید. ابر رکوردهای سرور ایمیل خاموش بماند.
🔸 فرمانهای 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 MXdig @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 شما، کدام رکورد نزدیک بود جا بماند؟
مستنداتی که تنظیمها از آنها آمده