این صفحه پاسخ پرسشهای پرتکرار در راهاندازی و پیکربندی شبکه توزیع محتوا و سامانه نام دامنه ستون را گردآوری کرده است. اگر بهتازگی کار خود را آغاز کردهاید، ابتدا راهنمای شروع به کار سریع را دنبال کنید.
مفاهیم پایه
تفاوت CDN با میزبانی وب و محدودهٔ مسئولیت هر یک
CDN جایگزین میزبانی وب نیست. شبکه توزیع محتوا نسخهای از محتوای سرور آپاستریم را در سرورهای لبه و نزدیک به کاربر کش و تحویل میدهد، اما محتوا همچنان باید روی سرور آپاستریم شما موجود و در دسترس باشد.
در نتیجه، اگر سرور آپاستریم از دسترس خارج شود و محتوا نیز در کش موجود نباشد، CDN قادر به پاسخگویی نخواهد بود.
استفاده از CDN بدون دامنهٔ اختصاصی و کاربرد آدرس کانیکال
استفاده از CDN بدون دامنهٔ اختصاصی امکانپذیر است. هر سرویس CDN یک آدرس کانیکال (Canonical Hostname) اختصاصی دریافت میکند، مانند bbabb46219fe12fd5ef9cd6e380f5e6c.cdn.edge.sotoon.ir، که تمامی قابلیتهای CDN روی آن فعال و قابل استفاده است.
مراحل فعالسازی CDN از طریق انتقال مدیریت DNS و مدتزمان هر مرحله
ترتیب مراحل در روش «انتقال مدیریت DNS» به شرح زیر است:
دامنه را در پنل ثبت کنید و گزینهٔ انتقال مدیریت DNS را انتخاب نمایید.
رکوردهای فعلی (A، AAAA، CNAME، MX و …) را در پنل ستون تعریف کنید. برای سایتهای فعال، این کار را حتماً پیش از تغییر NS انجام دهید.
نامسرورهای ستون را در پنل ثبتکنندهٔ دامنه (مانند ایرنیک) جایگزین نمایید.
پس از شناسایی نامسرورهای جدید، وضعیت DNS در پنل به فعال تغییر میکند. مدت این مرحله به TTL پیشین رکوردهای NS و کش رجیسترار بستگی دارد؛ با TTL برابر ۳۰۰ ثانیه، رکورد حدوداً هر ۵ دقیقه از سرور مرجع بهروزرسانی میشود.
در بخش مدیریت DNS، روی آیکون ابر (پروکسی CDN) کنار هر رکوردی که باید پشت CDN قرار گیرد کلیک کنید.
ساخت سرویس در پنل معمولاً چند دقیقه زمان میبرد. انتشار نامسرورها ممکن است از چند دقیقه تا چند ساعت و در موارد نادر تا پایان TTL پیشین به طول انجامد.
اگر مایل به انتقال مدیریت DNS به ستون نیستید، هنگام ثبت دامنه گزینهٔ فقط استفاده از CDN (بدون انتقال DNS) را انتخاب کنید و سپس مراحل زیر را دنبال نمایید:
آدرس IP سرور اصلی را در بخش آپاستریم وارد کرده و تنظیمات TLS را انجام دهید.
رکورد TXT احراز مالکیت را در پنل DNS فعلی خود ایجاد کنید.
پس از تأیید مالکیت، ترافیک را به CDN هدایت کنید: برای زیردامنه یک رکورد CNAME به آدرس کانیکال ستون، و برای دامنهٔ ریشه یک رکورد ALIAS/ANAME یا رکورد A به Anycast IP ستون (185.166.104.3).
اگر تنها قصد انتقال یک زیردامنه را دارید و نامسرورهای دامنهٔ اصلی باید بدون تغییر بماند، همین روش را برای همان زیردامنه اجرا کنید.
اتصال تنها یک زیردامنه به CDN بدون تغییر نامسرورهای دامنهٔ اصلی
تغییر نامسرورهای کل دامنه ضروری نیست. برای همان زیردامنه (مثلاً cdn.example.com) یک سرویس CDN بسازید، مالکیت را با رکورد TXT احراز کنید و سپس رکورد A زیردامنه را به IPهای ستون یا رکورد CNAME آن را به آدرس کانیکال ستون تغییر دهید.
آیپیهای نیمبها (ویژه وبسایتهای ثبتشده در سامانه فناوری اطلاعات): 185.166.104.3 و 185.166.104.4
آیپیهای تمامبها: 185.166.104.6 و 185.166.104.7
چنانچه از پیش رکورد CNAME یا A برای این زیردامنه تعریف شده است، ابتدا آن را حذف و سپس رکورد جدید را ثبت کنید.
برای آزمودن CDN پیش از تغییر DNS عمومی، از curl --resolve روی Anycast IP استفاده کنید و همزمان لاگ لحظهای را فعال نمایید تا بررسی دقیقتری از پیکربندی CDN وبسایت خود داشته باشید:
بله، انتقال تنها یک زیردامنه امکانپذیر است و نیازی به انتقال کل دامنه یا تغییر NS های آن نیست. برای همان زیردامنه (مثلاً cdn.example.com) یک سرویس CDN بسازید، مالکیت را با رکورد TXT احراز کنید و تنها رکورد A یا CNAME همان زیردامنه را به ستون تغییر دهید؛ دامنهٔ اصلی و سایر زیردامنهها بدون تغییر باقی میمانند.
مقدار این رکورد به وضعیت ابر (پروکسی CDN) بستگی دارد:
ابر خاموش (DNS-only): مقدار رکورد A همان IP سرور اصلی (آپاستریم) است.
ابر روشن: ترافیک از CDN عبور میکند و پاسخ DNS ارائهشده به کلاینت، IPهای Anycast ستون خواهد بود، نه IP آپاستریم. IP آپاستریم را در بخش سرورهای آپاستریم وارد میکنید و لزوماً همان مقداری نیست که کلاینت از DNS دریافت میکند.
اگر مدیریت DNS را به ستون نسپردهاید و تنها از CDN استفاده میکنید، برای دامنهٔ ریشه میتوانید رکورد A را روی 185.166.104.3 تنظیم کنید (یا آیپیهای نیمبها و تمامبها مطابق راهنمای انتقال).
مقصد رکورد ALIAS یک نام دامنه است و پذیرش آدرس IP در آن مجاز نیست. ستون دامنهٔ مقصد را خود resolve میکند و در پاسخ DNS، آدرس IP آن را بازمیگرداند (سازوکاری مشابه CNAME Flattening).
رکورد ALIAS برای دامنهٔ ریشه مناسب است، زیرا طبق استاندارد DNS تعریف رکورد CNAME روی ریشه مجاز نیست. رکورد CNAME نیز تنها نام دامنه میپذیرد و نه آدرس IP.
CNAME مخفف Canonical Name است: نامی مستعار که یک دامنه یا زیردامنه را به دامنهٔ دیگری متصل میکند و خود آدرس IP بازنمیگرداند. Resolver پس از مشاهدهٔ CNAME به سراغ مقصد میرود تا در نهایت به رکورد A یا AAAA برسد.
محدودیتهای این رکورد عبارتاند از:
برای هر زیردامنه یا CNAME تعریف میشود یا A/AAAA، نه هر دو.
تنها یک رکورد CNAME برای هر نام مجاز است.
مقصد همواره یک نام دامنه است، نه آدرس IP.
تعریف آن روی دامنهٔ ریشه مجاز نیست و بهجای آن باید از ALIAS یا A استفاده شود.
در اتصال CDN بدون انتقال DNS، زیردامنه را با رکورد CNAME به آدرس کانیکال ستون (….cdn.edge.sotoon.ir) متصل میکنید.
TTL رکورد: برای نمونه مقدار ۳۰۰ به این معناست که کشکنندههای DNS تا ۵ دقیقه پاسخ پیشین را نگه میدارند.
کش مرورگر، سیستمعامل و Resolver محلی (اعم از ISP یا سرویسهای عمومی).
تغییر نامسرورها در رجیسترار: تا زمان شناسایی نامسرورهای جدید در پنل ستون.
رکورد TXT احراز هویت: معمولاً ۵ تا ۱۵ دقیقه تا انتشار در DNS جهانی.
چنانچه پس از اعمال تغییرات همچنان سایت روی سرویس پیشین باز میشود، با dig از شبکهای دیگر (مانند اینترنت همراه) بررسی کنید یا پیش از تغییر عمومی از فایل hosts سیستم خود استفاده نمایید.
روش صحیح: اگر دامنهٔ سرویس phone.example.com است، در فیلد نام تنها _collab-edge._tcp را وارد کنید. همین الگو دربارهٔ رکورد TXT احراز مالکیت نیز صدق میکند؛ برای دامنهٔ ریشه @ (یا خالی) و برای زیردامنه تنها پیشوند آن.
در رکوردهای DNS ستون فیلدی با عنوان لوکیشن وجود دارد که امکان محدود کردن یک رکورد به قاره یا کشور مشخص را فراهم میکند تا تنها از آن مناطق قابل مشاهده باشد. این قابلیت به اطلاعات مکانی موجود در EDNS درخواست وابسته است و در حال حاضر تنها از طریق API در دسترس بوده و در پنل ارائه نشده است.
برای تفکیک ترافیک وب روی CDN میان کاربران داخل و خارج کشور، GeoDNS راهکار مناسبی نیست؛ در این حالت باید از قوانین آپاستریم استفاده کنید و کاربران خارج از کشور را به سرور آپاستریم مجزایی هدایت نمایید.
تعریف چند مقدار با نام یکسان برای رکوردهای A و AAAA امکانپذیر است. با تعیین وزن، سهم هر مقدار در پاسخ DNS مشخص میشود؛ برای نمونه نسبت وزن ۱ به ۴ به معنای اختصاص حدود ۲۰ درصد به مقدار نخست و ۸۰ درصد به مقدار دوم است. وزن صفر باعث میشود مقدار مورد نظر در پاسخ درخواست DNS قرار نگیرد.
توجه داشته باشید که این سازوکار از توزیع بار میان سرورهای آپاستریم در CDN مستقل است.
آیکون ابر، پروکسی CDN را روی رکورد مربوطه فعال یا غیرفعال میکند. با فعال شدن ابر، ترافیک آن نام به شبکه توزیع محتوای ستون هدایت میشود و یک زوج سادهٔ «آپاستریم و قانون مسیر» بهصورت خودکار ایجاد میگردد.
کش در این حالت بهصورت پیشفرض غیرفعال است. برای فعالسازی کش، لوکیشن مربوطه را ویرایش کنید، وضعیت کش را روی استاندارد قرار دهید و گزینهٔ «نادیده گرفتن تنظیمات کش آپاستریم» را انتخاب نمایید.
چنانچه قانون مسیر و آپاستریم را بهصورت دستی تعریف کرده باشید، آن تنظیمات بر پیشفرض ابر اولویت دارند و تداخلی با مدیریت DNS ایجاد نمیکنند.
ترتیب صحیح راهاندازی و روشهای جایگزین فعالسازی CDN
دو مسیر اصلی برای این کار وجود دارد:
با DNS ستون (روش پیشنهادی): نامسرورها را به ستون بسپارید، رکوردها را تعریف کنید و سپس ابر را روی رکوردهای مورد نظر فعال نمایید.
بدون انتقال DNS: مالکیت را با رکورد TXT احراز کنید و رکورد CNAME/ALIAS/A را به آدرس کانیکال یا IP ستون تنظیم نمایید. در این حالت دکمهٔ ابر در پنل DNS ستون کاربردی ندارد، زیرا مدیریت DNS در جای دیگری انجام میشود.
برای سایتهای فعال توصیه میشود ابتدا رکوردها و ترجیحاً گواهی TLS (حالت وایلدکارد بههمراه DNS ستون) آماده شود و سپس ترافیک بهصورت قطعی به CDN منتقل گردد.
معنای آپاستریم quickcdn-atsign و محدودیت ویرایش آن
هنگامی که ابر را روی رکورد ریشه (@) فعال میکنید، ستون یک آپاستریم یکپارچه با DNS ایجاد میکند. نامی مانند quickcdn-atsign به همان رکورد @ (at-sign) اشاره دارد؛ یعنی آپاستریمی که از روی رکورد DNS ساخته شده است و نه بهصورت دستی.
آیکون ابر در کنار این سرور نشان میدهد که مبدأ از مدیریت DNS تأمین میشود. در API، اگر فیلد quickcdnIntegrity مقداردهی شده باشد، امکان تغییر آدرس آپاستریم از تنظیمات CDN وجود ندارد و برای تغییر IP آپاستریم باید همان رکورد DNS را ویرایش کنید.
مدتزمان احراز مالکیت دامنه و خطاهای رایج در ثبت رکورد TXT
پس از ثبت صحیح رکورد TXT، انتشار آن معمولاً ۵ تا ۱۵ دقیقه زمان میبرد (بسته به ارائهدهندهٔ DNS فعلی شما). ستون بهمحض مشاهدهٔ رکورد TXT، مالکیت را تأیید میکند.
اشتباه رایج، درج آدرس کانیکال یا کل مقدار احراز هویت در فیلد نام/Host است. نام رکورد برای دامنهٔ ریشه @ (یا خالی) و برای زیردامنه تنها پیشوند آن است؛ مقدار رکورد TXT نیز همان کد ارائهشده در پنل ستون است.
بله. هر سرویس CDN که بدون انتقال DNS ساخته شود، برای همان hostname به احراز مالکیت جداگانه نیاز دارد و رکورد TXT دامنهٔ اصلی، مالکیت زیردامنهٔ مجزا را اثبات نمیکند.
چنانچه مدیریت کامل DNS را به ستون منتقل کرده باشید، احراز مالکیت از طریق DNS خارجی ضرورتی ندارد؛ زیرا نامسرورهای ستون خود گواه مالکیت هستند.
با استفاده از DNS ستون میتوانید حالت وایلدکارد را فعال کنید تا چالش DNS-01 به کار گرفته شود. این روش برای دامنهای که ترافیک آن هنوز روی CDN قرار نگرفته مناسب است و پیشنیاز آن، تعریف DNS همان دامنه در همان فضای کاری است.
موانع رایج عبارتاند از:
وجود رکورد CNAME روی _acme-challenge که فرآیند صدور و تمدید را مختل میکند.
تعریف DNS دامنه در فضای کاری دیگر.
قطع دسترسی به صادرکننده (Let’s Encrypt) در زمان اختلال اینترنت بینالملل.
پس از صدور، اعمال گواهی روی سرورهای لبه ممکن است از چند دقیقه تا حدود سی دقیقه به طول انجامد.
گواهی خودکار توسط ستون تمدید میشود. در صورت عدم تمدید، علت معمولاً در پیکربندی سمت شماست: وجود رکورد CNAME روی _acme-challenge، نبود DNS ستون برای حالت وایلدکارد، یا قطع دسترسی به صادرکننده. گواهی دستی را باید پیش از انقضا خودتان جایگزین کنید.
توجه داشته باشید گواهی رایگان Let’s Encrypt در زمان اختلال اینترنت بینالملل ممکن است تمدید نشود؛ برای پایداری بیشتر، استفاده از گواهی تجاری دستی مناسبتر است.
گواهی وایلدکارد ستون تنها یک سطح را پوشش میدهد. گواهی *.example.com برای www.example.com کافی است، اما برای api.v2.example.com کفایت نمیکند.
برای پوشش این موارد، در بخش تنظیمات گواهی خودکار و از طریق گزینهٔ «افزودن زیردامنههای چندسطحی متفاوت به گواهی»، الگوهایی مانند *.v2.example.com را اضافه کنید.
در تنظیمات TLS گزینهٔ اجباری بودن TLS را فعال کنید تا درخواستهای ناامن HTTP بهصورت خودکار به HTTPS ریدایرکت شوند. برای اینکه مرورگر در مراجعات بعدی بدون نیاز به ریدایرکت مستقیماً از HTTPS استفاده کند.
چنانچه آپاستریم نیز درخواستهای HTTP را به HTTPS ریدایرکت کند و پروتکل آپاستریم روی HTTP تنظیم شده باشد، احتمال ایجاد حلقهٔ ریدایرکت وجود دارد. در این حالت یا پروتکل آپاستریم را به HTTPS تغییر دهید یا ریدایرکت آن را برای درخواستهای دریافتی از CDN غیرفعال کنید.
گواهی رایگان Let’s Encrypt روی نسخههای قدیمی اندروید (اندروید ۶ و پایینتر) ممکن است شناسایی نشود. برای پشتیبانی از این کاربران، یک گواهی تجاری تهیه کنید و آن را بهصورت دستی بارگذاری نمایید.
همچنین برای اینکه اپلیکیشن شما روی اندروید ۵ به بالا بدون مشکل کار کند، حداقل نسخهٔ TLS را روی `1.0 قرار دهید.
پیکربندی سلامتسنجی، پروتکل پیشفرض و رفتار سیستم در زمان خطا
سلامتسنجی از طریق فرم آپاستریم قابل پیکربندی است. در صورت خالی ماندن فیلدها، مقادیر پیشفرض ستون اعمال میشود. در بسیاری از حالتها بررسی پیشفرض از نوع TCP است که تنها باز بودن پورت را میسنجد.
استفاده از TCP بهتنهایی برای Failover توصیه نمیشود، زیرا باز بودن پورت لزوماً به معنای سلامت سرویس نیست و ممکن است وبسرور با وجود برقراری اتصال، پاسخ 503 بازگرداند. توصیه میشود از HTTP/HTTPS بههمراه یک مسیر سلامت مانند /health و در صورت نیاز Host Header صحیح استفاده کنید.
در حالت HTTP/HTTPS، هر پاسخی بهجز خطاهای 5xx نشانهٔ سلامت سرور در نظر گرفته میشود؛ بنابراین پاسخهایی مانند 204 یا 301 نیز سالم تلقی میشوند و لازم نیست مسیر سلامت حتماً 200 بازگرداند.
در صورت ناسالم تشخیص داده شدن، سرور از چرخهٔ توزیع بار خارج میشود. تستها هر ۵ ثانیه انجام میشوند و سرور با نخستین اتصال موفق مجدداً وارد مدار میگردد. سرورهای Passive تنها زمانی وارد مدار میشوند که تمامی سرورهای Active از دسترس خارج شده باشند.
پروتکل آپاستریم (HTTP یا HTTPS) نحوهٔ اتصال سرورهای لبهٔ ستون به سرور اصلی را تعیین میکند و از پروتکلی که کاربر برای اتصال به CDN استفاده کرده مستقل است. ارتباط کاربر تا CDN میتواند روی SSL باشد، در حالی که ارتباط CDN تا آپاستریم روی HTTP یا حتی با گواهی Self-signed برقرار شود؛ ستون در حال حاضر گواهی سمت آپاستریم را verify نمیکند.
در قوانین مسیر، اکشن متداول برای وب و API مقدار proxy_http است. اگر بکاند شما مبتنی بر gRPC است، باید پروتکل و اکشن متناظر gRPC را انتخاب کنید تا فریمهای HTTP/2 و gRPC بهدرستی به آپاستریم منتقل شوند. برای وبسایت و REST، همان HTTP کفایت میکند.
چنانچه آپاستریم درخواست HTTP را به HTTPS ریدایرکت کند ولی پروتکل آپاستریم روی HTTP تنظیم شده باشد، احتمال بروز ریدایرکت حلقوی وجود دارد.
هدر Host به سرور آپاستریم اعلام میکند کدام سایت باید سرو شود و در پیکربندیهای Virtual Hosting اهمیت ویژهای دارد. سه حالت برای آن قابل تعریف است:
استفاده از دامنهٔ سرور آپاستریم: مقدار Host برابر با دامنه یا آدرس تعریفشده برای سرور آپاستریم قرار میگیرد.
عدم استفاده بههمراه مقدار صریح: مقدار Host را خودتان تعیین میکنید.
عدم استفاده و مقدار خالی: هدر Host درخواست کاربر بدون تغییر به آپاستریم ارسال میشود.
چنانچه سلامتسنجی یا سرویسدهی سایت به دلیل «هاست ناشناخته» با خطا مواجه میشود، علت معمولاً نادرست بودن همین هدر است. در پیکربندیهای HTTPS، هدر Host نادرست میتواند به خطای عدم تطابق نام دامنه با گواهی نیز منجر شود.
اگر آپاستریم را بهصورت دستی ساختهاید: در بخش «سرورهای آپاستریم» همان سرور را ویرایش کنید. آدرس و پورت فیلدهای مجزایی هستند و پورت باید در بازهٔ 1 تا 65535 باشد.
اگر آپاستریم از ابر DNS ایجاد شده است (نام quickcdn-atsign و فیلد quickcdnIntegrity): برای تغییر آدرس باید همان رکورد DNS را ویرایش کنید؛ با این حال پورت آن از بخش تنظیمات آپاستریم قابل تغییر است.
سازوکار توزیع بار بین سرورهای آپاستریم و مفهوم وزن صفر
الگوریتم پیشفرض Weighted Round Robin است و سهم هر سرور متناسب با وزن آن تعیین میشود. برای توزیع برابر، وزن تمامی سرورها را یکسان قرار دهید. وزن صفر سرور را بهطور موقت از چرخه خارج میکند؛ اگر وزن تمامی سرورها صفر باشد، ترافیک تنها به آخرین سرور هدایت میشود. در صورت وجود تنها یک سرور، وزن بیاثر است.
برای استفاده از Consistent Hashing باید مقدار strategy را روی hash تنظیم کنید (بر مبنای IP کاربر یا هدرهای انتخابی).
اگر بهجای IP یک نام دامنه برای آپاستریم تعریف کنید، ستون آن را بهصورت خودکار resolve میکند و در صورت وجود چند IP، ترافیک بهصورت دورهای میان IPهای سالم توزیع میشود.
قوانین مسیر (لوکیشن): تنظیمات پایه برای هر مسیر یا هاست را تعیین میکنند؛ شامل کش، بازنویسی، CORS، هدرها، فایروال و آپاستریم پیشفرض. بدون تعریف حداقل یک لوکیشن (مانند /*)، تمامی درخواستها پاسخ 404 دریافت میکنند. اولین قانون منطبق اننتخاب خواهد شد.
قوانین آپاستریم: آپاستریم پیشفرض را بر اساس مشخصات هر درخواست (کشور، بات، IP، مسیر و …) بازنویسی میکنند. ارزیابی از بالا به پایین انجام میشود و در صورت تطابق چند قانون، آخرین قانون منطبق تعیینکننده است.
برای کاربران خارج از ایران یک آپاستریم خارجی تعریف کنید و با یک قانون آپاستریم (شرط کشور مخالف IR) ترافیک را به آن هدایت نمایید. برای این آپاستریم نیازی به ساخت قانون مسیر (لوکیشن) جداگانه نیست؛ ساخت لوکیشن اضافی اغلب باعث تداخل و اختلال در مسیریابی ترافیک میشود.
دریافت مداوم وضعیت BYPASS یا MISS با وجود فعال بودن کش
فعال بودن ابر تنها بهمعنای پروکسی شدن ترافیک است و کش سازوکار مستقلی دارد. علل رایج عبارتاند از:
نوع کش در قانون مسیر همچنان روی Bypass تنظیم شده است.
سرور آپاستریم هدر Cache-Control با مقادیر no-store، private یا no-cache ارسال میکند و گزینهٔ «نادیده گرفتن تنظیمات کش آپاستریم» فعال نشده است.
کوکی یا Query String برای هر درخواست نسخهٔ مجزایی ایجاد میکند.
نوع محتوا (Content-Type) در فهرست انواع قابل کش ستون قرار ندارد.
وضعیت کش را از هدر پاسخ x-zrk-cs بخوانید: مقدار HIT یعنی پاسخ از کش تأمین شده، MISS یعنی از آپاستریم دریافت و ذخیره شده و BYPASS یعنی محتوا عامدانه کش نشده است. در لاگ لحظهای نیز فیلد cache_status همین اطلاعات را ارائه میدهد.
در نوع کش استاندارد، آدرسهای image.jpg?size=small و image.jpg?size=large دو کلید کش مجزا محسوب میشوند.
اگر نوع کش را روی نادیده گرفتن Query String تنظیم کنید، هر دو درخواست یک فایل کششدهٔ یکسان دریافت میکنند. این گزینه برای پارامترهای تبلیغاتی (مانند UTM) مناسب است، اما برای نسخهبندی فایلها توصیه نمیشود.
تفاوت Edge TTL و Browser TTL و کاربرد حالت immutable
در حالت مدیریت دستی کش، سه پارامتر کلیدی در اختیار شماست:
Edge TTL (عمر کش در CDN): مدتزمانی که فایل در کش سرورهای لبهٔ ستون باقی میماند. پس از پایان این مدت، با رسیدن درخواست جدید، CDN نسخهٔ تازه را از آپاستریم دریافت میکند. این مهمترین پارامتر کش است.
Browser TTL (عمر کش در مرورگر): مدتزمانی که فایل در کش مرورگر کاربر باقی میماند. پس از این مدت، مرورگر مجدداً از CDN درخواست میکند.
حالت immutable: دستورالعملی که به هدر Cache-Control افزوده میشود و به مرورگر اعلام میکند این فایل هرگز تغییر نخواهد کرد. در نتیجه مرورگر حتی برای بررسی وجود نسخهٔ جدیدتر نیز درخواستی ارسال نمیکند. این حالت برای فایلهایی که نام آنها با هر تغییر عوض میشود (مانند app.a1b2c3d4.js) ایدهآل است.
در مقابل، اگر گزینهٔ استفاده از هدر Cache-Control سرور آپاستریم را انتخاب کنید، CDN به هدرهای ارسالی سرور شما احترام میگذارد و این تنظیمات نمایش داده نمیشوند.
در تنظیمات کش قانون مسیر، امکان ایجاد نسخههای مجزای کش بر مبنای ویژگیهای کاربر وجود دارد:
تفکیک بر اساس کشور: برای هر کشور یک نسخهٔ کش جداگانه ایجاد میشود. این قابلیت برای وبسایتهایی با محتوای بومیسازیشده (قیمت با واحد پول محلی یا متن چندزبانه) ضروری است.
تفکیک بر اساس دستگاه: برای ارائهٔ نسخههای متفاوت به کاربران موبایل و دسکتاپ کاربرد دارد.
توجه داشته باشید هر تفکیک اضافی، تعداد کلیدهای کش را افزایش و نرخ Hit را کاهش میدهد؛ بنابراین تنها در صورت نیاز واقعی آن را فعال کنید.
برای حذف محتوای قدیمی از کش، از Purge در پیشخان CDN استفاده کنید: پاکسازی کل کش (Purge All) یا یک مسیر مشخص (مسیر مطلق فایل مانند /images/a.png یا پیشوند مسیر مانند /images/*). الگوی Glob پشتیبانی نمیشود.
سازوکار Purge به صورت غیرفعال (Passive) است؛ یعنی محتوای مشخصشده در نخستین درخواست منطبق از کش حذف میشود و چنانچه در این بازه درخواستی برای آن دریافت نشود، از طریق مکانیزم cache inactivity بهصورت خودکار حذف خواهد شد.
محدودیتها: حداکثر ۳۰ مسیر در هر بار ارسال از پنل (برای تعداد بیشتر، مراحل را تکرار کنید یا از API استفاده نمایید) و در مجموع برای هر وبسایت حداکثر ۲۰٬۰۰۰ مسیر مطلق و ۱٬۰۰۰ پیشوند مسیر.
اگر کش استاندارد روی مسیری فعال باشد، سرویس CDN ممکن است در لایهٔ داخلی درخواست HEAD را به GET تبدیل کند تا کلید کش با کلید GET همتراز شود. به کلاینت همچنان پاسخ HEAD (بدون بدنه) ارائه میشود و این رفتار با استانداردهای HTTP و HTTP/2 سازگار است.
چنانچه به HEAD واقعی تا آپاستریم نیاز دارید، یکی از دو راهکار زیر را به کار بگیرید:
کش را برای آن مسیر از بخش قوانین مسیر غیرفعال کنید.
در فایروال یک قانون با اکشن Cache Bypass و شرط Http method برابر HEAD تعریف نمایید.
مرورگر هدرهای CORS را روی پاسخ همان دامنهای که منبع را ارائه میدهد بررسی میکند. این تنظیمات را میتوانید در قانون مسیر CDN اعمال کنید: مبدأهای مجاز (بهصورت دقیق و بههمراه پروتکل)، متدهای مجاز (درج OPTIONS برای درخواستهای preflight الزامی است) و هدرهای مجاز.
استفاده از * برای Allow-Origin تنها برای APIهای کاملاً عمومی مناسب است. همچنین توجه داشته باشید https://example.com و https://www.example.com دو مبدأ مجزا محسوب میشوند.
ستون بهصورت پیشفرض هدرهای زیر را به سرور آپاستریم ارسال میکند:
X-Stn-IP: آدرس IP واقعی کاربر
X-Stn-Country-Code: کد کشور کاربر
X-Forwarded-Host و X-Forwarded-Proto
در قانون مسیر امکان افزودن یا حذف هدرهای ارسالی به آپاستریم وجود دارد. در پاسخ ارسالی به کاربر نیز هدرهای x-zrk-cs (وضعیت کش)، x-zrk-sn (نام سرور لبه) و x-zrk-us (کد وضعیت آپاستریم) درج میشود. هدرهای Connection و CDN-Loop قابل حذف نیستند.
بازنویسی (Rewrite) آدرس را پیش از ارسال به آپاستریم تغییر میدهد و نشانی نمایشدادهشده در نوار مرورگر ثابت میماند. این قابلیت در تنظیمات اضافی قانون مسیر پیکربندی میشود.
ریدایرکت پاسخی با کد 301 یا 302 به کاربر بازمیگرداند و از بخش فایروال تنظیم میشود. در اکشن ریدایرکت فیلد مجزایی برای تعیین مبدأ وجود ندارد؛ مبدأ همان شرط (Constraint) تعریفشده برای قانون است و مقصد در فیلد Target اکشن مشخص میشود.
برای نمونه، جهت ریدایرکت /old-page به /new-page کافی است شرط Path با عملگر equals و مقدار /old-page تعریف کنید و در اکشن Redirect، مقدار Target را /new-page قرار دهید. تعریف Target بهصورت مسیر نسبی باعث میشود پروتکل و دامنهٔ اصلی (و در صورت استفاده از الگوی Glob روی هدر Host، حتی زیردامنهٔ درخواست) بهصورت خودکار حفظ شود.
ابتدا از فعال بودن فایروال برای آن سرویس CDN اطمینان حاصل کنید. سپس موارد زیر را بررسی نمایید:
ترتیب قوانین: قوانین از بالا به پایین ارزیابی میشوند و نخستین قانون منطبق اعمال میگردد. اگر اکشن آن قانون از نوع خاتمهدهنده (Block یا Redirect) باشد، پردازش متوقف شده و قوانین بعدی بررسی نخواهند شد.
منطق ترکیب شرطها: شرطها بهصورت OR از گروههای AND ارزیابی میشوند، یعنی (شرط ۱ و شرط ۲) یا (شرط ۳ و شرط ۴). اگر انتظار دارید چند شرط همزمان برقرار باشند اما آنها را در گروههای مجزا تعریف کردهاید، قانون زودتر از انتظار فعال میشود. با گزینهٔ معکوسسازی (Negate) نیز میتوانید اثر هر شرط را وارونه کنید.
قواعد نامگذاری: نام قانون تنها میتواند شامل حروف کوچک انگلیسی، اعداد و خط فاصله (-) باشد و باید با یک حرف آغاز شود.
دامنهٔ اعمال: قوانین فایروال روی تمامی دامنهها و زیردامنههای متصل به آن سرویس CDN اعمال میشوند.
برای عیبیابی، در لاگ لحظهای فیلدهای fw_rule_name و fw_rule_action را بررسی کنید.
محدودسازی نرخ درخواست (Rate Limit) و کدهای وضعیت آن
با اکشن ratelimit در فایروال میتوانید تعداد درخواست مجاز در یک بازهٔ زمانی مشخص را محدود کنید. دو متغیر اصلی این اکشن rate (تعداد درخواست مجاز) و period (بازهٔ زمانی) هستند.
کدهای وضعیت پیشفرض به شرح زیر است:
429 برای درخواستهایی که از حد مجاز عبور کردهاند.
هر دو کد و همچنین قالب HTML صفحهٔ خطا قابل سفارشیسازی هستند؛ برای صفحهٔ خطا میتوانید از یک قالب Jinja با طول حداکثر ۵۱۲۰ کاراکتر استفاده کنید و کد وضعیت را در بازهٔ ۲۰۰ تا ۴۹۹ تعیین نمایید.
قابلیت IP Set امکان دستهبندی مجموعهای از آدرسهای IP یا رنجهای شبکه (به فرمت CIDR) را تحت یک نام واحد فراهم میکند. بهجای درج تکتک آدرسها در قوانین مختلف، کافی است نام لیست را در شرط قانون انتخاب کنید.
نحوهٔ استفاده:
از مسیر «شبکه توزیع محتوا» و سپس «لیست IP Set»، یک لیست جدید با نامی توصیفی بسازید و آدرسها را وارد کنید. هر مقدار باید در یک خط جداگانه و به فرمت استاندارد CIDR باشد (مانند 5.52.0.0/16).
در قانون فایروال، پارامتر آدرس IP را انتخاب کرده و یکی از دو عملگر «در IP Set وجود داشته باشد» یا «در IP Set وجود نداشته باشد» را بهکار ببرید.
مزیت اصلی این روش آن است که با بهروزرسانی یک لیست، تمامی قوانین فایروالی که از آن استفاده میکنند بهطور خودکار بهروز میشوند. برای نمونه میتوانید یک IP Set شامل رنجهای آیپی ایران بسازید و دسترسی به بخش مدیریت سایت را تنها برای آن لیست مجاز کنید.
مسدودسازی کشورهای غیر از IR حجم ترافیک لایهٔ ۷ ورودی به CDN از خارج کشور را کاهش میدهد، اما محدودیتهای زیر را در نظر بگیرید:
حملاتی که از داخل ایران یا با آیپی ایرانی انجام میشوند همچنان برقرار میمانند.
اگر آدرس IP آپاستریم روی اینترنت در دسترس باشد، مهاجم میتواند مستقیماً به سرور آپاستریم حمله کند و CDN را دور بزند.
در برخی سناریوها مشاهده شده است که اطلاعات مالکیتی و کشور ثبتشدهٔ آیپی مهاجم بهروز نیست و تشخیص دقیق کشور آپاستریم روی لبهٔ CDN امکانپذیر نمیشود.
برای مقابلهٔ مؤثرتر، آیپیهای لبه را در فایروال سرور آپاستریم مجاز کنید و دسترسی مستقیم عمومی به آپاستریم را ببندید. همچنین از Rate Limit، IP Set و چالشهای JS و کپچا استفاده کنید و متریکهای بخش Security داشبورد (جهش Requests/Sec، توزیع کشور و Top URL) را زیر نظر بگیرید.
محدود کردن دسترسی سرور آپاستریم به آیپیهای لبهٔ ستون
فهرست آیپیهای لبه را از نشانی https://edge.sotoon.ir/ip-list.txt دریافت کرده و در فایروال سرور آپاستریم مجاز کنید. اسکریپت بهروزرسانی خودکار این فهرست در مستند مربوطه ارائه شده است.
این اقدام تضمین میکند که تنها ترافیک عبوری از CDN به سرور آپاستریم برسد و امکان دور زدن CDN از بین برود.
در بخش لینک امن پنل میتوانید با گزینهٔ «ساختن secret» کلید دریافت کنید یا از طریق API فیلد secrets را خودتان مقداردهی نمایید؛ این فیلد آرایهای شامل حداکثر ۵ رشته است که طول هر یک باید بین ۱۶ تا ۳۲ کاراکتر باشد.
امکان تعریف چند کلید همزمان برای چرخش کلید بدون قطعی سرویس فراهم شده است: ابتدا کلید جدید را اضافه کنید، سپس اپلیکیشن را بهروزرسانی نمایید و در پایان کلید قدیمی را حذف کنید.
توکن از فرمول MD5(path + secret + expire) ساخته میشود که در آن expire یک Unix Timestamp است، و لینک نهایی به شکل زیر خواهد بود:
قفل کردن لینک امن روی IP کاربر و تغییر نام پارامترها
دو قابلیت تکمیلی برای لینک امن در دسترس است:
قفل بر اساس IP: با فعال کردن گزینهٔ «در نظر گرفتن IP کلاینت»، لینک تولیدشده تنها برای کاربری با همان آدرس IP معتبر خواهد بود و تلاش سایر کاربران برای باز کردن آن مسدود میشود.
شخصیسازی نام پارامترها: چنانچه نامهای token و expire با پارامترهای موجود در اپلیکیشن شما تداخل دارند، میتوانید از بخش تنظیمات لینک امن نامهای دلخواه خود را برای آنها تعیین کنید.
اختلال در ایندکس گوگل یا دسترسی به sitemap پس از فعالسازی CDN
CDN محتوای سرور آپاستریم را تحویل میدهد؛ بنابراین فایل robots.txt و sitemap باید روی سرور شما موجود باشند و بدون مسدودسازی از طریق CDN در اختیار گوگل قرار گیرند. اگر گوگل نتواند robots.txt را دریافت کند، بهصورت پیشفرض فرض میکند که اجازهٔ دسترسی به هیچ بخشی را ندارد و تمامی صفحات را مسدود تلقی میکند.
فهرست بررسی:
اطمینان حاصل کنید https://yourdomain.com/robots.txt و sitemap با curl از بیرون قابل دریافت باشند.
بررسی کنید قوانین فایروال، خزندهٔ گوگل را مسدود نکرده باشند.
پس از هر تغییر در robots.txt، کش همان مسیر را Purge کنید.
اگر سرور آپاستریم داخل ایران است و خزنده از خارج کشور درخواست میفرستد، گزینهٔ بهبود سئو (Improved SEO) را روی آپاستریم ایران فعال نمایید.
از آنجا که robots.txt بهندرت تغییر میکند، توصیه میشود یک قانون مسیر اختصاصی برای /robots.txt با TTL طولانی (مثلاً ۲۱۶۰۰ ثانیه معادل ۶ ساعت) تعریف کنید تا همواره با وضعیت HIT و سرعت بالا پاسخ داده شود.
عدم ایندکس شدن یک صفحهٔ خاص معمولاً ناشی از خود صفحه، ریدایرکت یا خطای سرور آپاستریم است و ارتباطی با فعال بودن CDN ندارد.
ستون بهصورت خودکار پاسخ 403 به Googlebot بازنمیگرداند. علت معمولاً یکی از موارد زیر است: انطباق خزنده با یک قانون فایروال (شرط کشور، ASN، هدر User-Agent یا Rate Limit)، یا بازگرداندن 403 توسط خود سرور آپاستریم.
برای رفع مشکل، یک قانون با اکشن Allow و شرط رباتهای شناختهشده برابر True تعریف کنید و آن را بالاتر از قوانین Block قرار دهید. این شرط تمامی خزندههای معتبر شناساییشده (مانند Googlebot و Bingbot) را در بر میگیرد؛ اگر لازم است تنها گوگلبات تفکیک شود، شرط هدر User-Agent با عملگر contains و مقدار Googlebot را نیز اضافه کنید.
توجه داشته باشید خزندههای گوگل از خارج ایران درخواست ارسال میکنند؛ بنابراین اگر تنها قانون «کشور مخالف IR ← Block» تعریف شده باشد، ترافیک گوگل نیز مسدود خواهد شد مگر آنکه استثنای بالاتری برای آن در نظر بگیرید.
بهعنوان راهکار مکمل میتوانید رنجهای رسمی آیپی گوگل را در یک IP Set قرار داده و آن را مجاز کنید.
هدایت گوگلبات به هاست ایران و سایر کاربران خارجی به هاست خارج
ابتدا روی آپاستریم ایران، گزینهٔ بهبود سئو (Improved SEO) را از بخش تنظیمات پیشرفته فعال کنید. سپس در بخش «قوانین آپاستریم» دو قانون با ترتیب زیر تعریف نمایید:
قانون بالاتر — هدایت خزندهها به هاست ایران: آپاستریم هدف را آپاستریم ایران قرار دهید و شرط رباتهای شناختهشده برابر True را تعریف کنید. اگر میخواهید این قانون تنها روی بخشی از سایت اعمال شود (مثلاً /blog/*)، شرط مسیر را نیز اضافه کنید؛ در غیر این صورت فیلد مسیر را خالی بگذارید تا کل سایت را در بر گیرد.
قانون پایینتر — هدایت سایر کاربران خارجی به هاست خارج: آپاستریم هدف را آپاستریم خارج از کشور قرار دهید و شرط کشور مخالف IR را تعریف کنید.
ترتیب این دو قانون تعیینکننده است. خزندههای گوگل نیز درخواستهای خود را از خارج ایران ارسال میکنند؛ اگر قانون کشور مخالف IR بالاتر قرار گیرد، درخواست خزنده بلافاصله با آن منطبق شده و به هاست خارج هدایت میشود و قانون مربوط به خزندهها هرگز اجرا نخواهد شد. همواره قوانین خاصتر (رباتهای شناختهشده) را بالاتر از قوانین عمومیتر (کشور یا IP) قرار دهید.
برای صحتسنجی، در لاگ لحظهای روی User-Agent حاوی عبارت Googlebot فیلتر کنید و بررسی نمایید که فیلد upstream_name نام آپاستریم ایران را نشان دهد و upstream_response_time کاهش یافته باشد.
در قانون مسیر و از بخش تنظیمات اضافی، گزینهٔ ویرایش تصویر را فعال کنید. فیلترها پس از دریافت تصویر از سرور آپاستریم و پیش از تحویل به کاربر اعمال میشوند؛ در صورت فعال بودن کش، خروجی تغییریافته کش خواهد شد.
باقی ماندن ترنسکد ویدیو در وضعیت «در حال ساخت» و سازوکار پاکسازی خودکار
سرویس ترنسکد VOD در مرحلهٔ آلفا قرار دارد؛ ورودی آن از S3 دریافت میشود و خروجی شامل کیفیتهای مختلف و قالب HLS است. اگر فرآیند در وضعیت «در حال ساخت» متوقف بماند، دسترسی به باکت، قالب فایل ورودی و سهمیهٔ ترنسکد همزمان را بررسی کنید.
پاکسازی خودکار تنها رکورد ترنسکد را از فهرست حذف میکند (پس از ۱ ساعت برای موارد موفق و ۵ روز برای موارد ناموفق) و فایلهای خروجی در آبجکت استوریج حذف نمیشوند.
بررسی علت خطای هر درخواست با لاگ لحظهای و ارسال لاگ
لاگ لحظهای در پنل، درخواستها را بهصورت زنده نمایش میدهد (این قابلیت هزینهٔ جداگانه دارد). مهمترین فیلدهای آن عبارتاند از: cache_status، upstream_status، upstream_name، fw_blocked، fw_rule_name، country و response_time.
برای حجم بالای لاگ، از قابلیت ارسال لاگ (Log Forwarder) به مقاصدی مانند Kafka، Elasticsearch، Loki، AMQP یا Websocket استفاده کنید.
متریکهای تجمیعی در داشبورد مانیتورینگ در دسترس است؛ برای اتصال Grafana به Prometheus ستون، نقش cdn-viewer یا بالاتر لازم است.
متریک Requests تعداد درخواستهای ورودی به CDN در هر ثانیه را نشان میدهد (شامل کاربران و خزندهها) و معیاری از حجم ارسالی شما به ستون نیست. امکان فیلتر کردن بر اساس hostname و سرور لبه وجود دارد.
متریکهای 2xx Rate و 5xx Rate، نرخ Hit کش و نسبت ترافیک داخل به خارج در بخش Overview قرار دارند. بخش Connectivity خطاهای 5xx سرور آپاستریم را از خطاهای 5xx خود CDN تفکیک میکند و بخش Performance شامل زمان پاسخ و متریکهای تأخیر است.
برای اتصال Grafana، دیتاسورس https://monitoring.delivery.sotoon.ir را با Basic Auth (شناسهٔ فضای کاری و توکن بپا) پیکربندی کنید.
در نبود قانون مسیر (لوکیشن)، تمامی درخواستها پاسخ 404 دریافت میکنند. حداقل یک لوکیشن (مانند /*) تعریف کرده و آن را به آپاستریم متصل کنید.
با استفاده از لاگ لحظهای بررسی کنید که مقدار فیلد upstream_name بهدرستی انتخاب شده باشد و ترتیب قوانین مسیر مطابق انتظار شما باشد. همچنین از ارسال هدر صحیح به آپاستریم اطمینان حاصل کنید؛ این مورد از بخش تنظیمات آپاستریم و فیلد هدر هاست قابل پیکربندی است.
این کدها معمولاً نشان میدهند سرور لبه نتوانسته پاسخ سالمی از آپاستریم دریافت کند و بهمعنای ساخته نشدن سرویس روی CDN نیستند.
کد
معنای رایج
502 Bad Gateway
آپاستریم پاسخ معتبری ارائه نداده یا اتصال قطع شده است
503 Service Unavailable
آپاستریم تحت فشار یا از مدار خارج است، یا سلامتسنجی آن را ناسالم تشخیص داده است
504 Gateway Timeout
آپاستریم در مهلت تعیینشده پاسخ نداده است
مراحل تشخیص:
در داشبورد مانیتورینگ و بخش Connectivity بررسی کنید که خطای 5xx از آپاستریم است یا از CDN (ناشی از قطع ارتباط لبه با آپاستریم).
هدر پاسخ x-zrk-us کد وضعیت تحویلشده از آپاستریم به CDN را نشان میدهد و x-zrk-sn نام سرور لبه است. در صورت وجود مقدار در این هدر، ارتباط میان لبه و آپاستریم برقرار بوده و موضوع باید در سمت آپاستریم بررسی شود.
با لاگ لحظهای فیلدهای upstream_status و upstream_name را بررسی کنید.
اطمینان حاصل کنید فایروال سرور آپاستریم، آیپیهای لبهٔ ستون را مجاز کرده باشد؛ در غیر این صورت سرور لبه به آپاستریم دسترسی نخواهد داشت.
CDN بهخودیخود پاسخ 403 بازنمیگرداند، مگر در یکی از حالتهای زیر:
انطباق درخواست با یک قانون فایروال دارای اکشن Block (کد پیشفرض این اکشن 403 است و در بازهٔ ۲۰۰ تا ۴۹۹ قابل تغییر است).
نامعتبر یا منقضی بودن لینک امن.
بازگرداندن 403 توسط خود سرور آپاستریم.
برای تشخیص، در لاگ لحظهای فیلدهای fw_blocked، fw_rule_name و fw_rule_action را بررسی کنید. چنانچه فایروال در این موضوع نقشی نداشته باشد، پاسخ از سمت آپاستریم ارسال شده است.
بهجای بررسی کلی «کندی سایت»، تأخیر را به مؤلفههای زیر تفکیک کنید:
TLS Handshake و زمان اتصال تا سرور لبه: نشاندهندهٔ مشکل در شبکهٔ کاربر یا مسیر تا CDN.
زمان پاسخ آپاستریم (upstream_response_time): نشاندهندهٔ کندی یا فشار روی سرور آپاستریم.
نرخ Hit پایین: به این معنا که کش در حالت Bypass قرار دارد و تقریباً تمامی درخواستها به آپاستریم ارسال میشوند.
این متریکها در بخش Performance داشبورد در دسترس هستند. همان درخواست را با curl -w یا لاگ لحظهای بسنجید. انجام یک آزمایش موردی از چند شبکهٔ مختلف (اینترنت همراه، ثابت و خارج از کشور) نتیجهٔ دقیقتری نسبت به گزارش کلی ارائه میدهد.
اگر مشکل تنها برای برخی کاربران گزارش میشود، بهجای اتکا به گزارش شفاهی، از کاربر بخواهید خروجی ابزارهای استاندارد را ارسال کند. مستندات ستون برای سه محیط راهنمای گامبهگام ارائه میدهند:
در دسترس نبودن سایت از خارج ایران با وجود دسترسی از داخل کشور
در بیشتر موارد، سرور آپاستریم (میزبان داخل ایران) از اینترنت بینالملل در دسترس نیست یا فایروال آپاستریم آیپیهای خارجی را مسدود کرده است. CDN جایگزین میزبانی نیست؛ اگر سرور لبه نتواند به آپاستریم متصل شود، کاربر خارج از کشور نیز با خطا مواجه خواهد شد.
راهکارها:
دسترسی سرور آپاستریم از خارج کشور را با ابزارهایی مانند mtr یا آزمودن پورتهای 80 و 443 از یک شبکهٔ خارجی بررسی کنید.
یک آپاستریم خارج از کشور تعریف کرده و با یک قانون آپاستریم، ترافیک کشورهای غیر از IR را به آن هدایت نمایید.
چنانچه سرویس را با ابر (quickcdn) ساختهاید و لازم است پاسخ DNS برای داخل و خارج کشور متفاوت باشد، سرویس را به روش «فقط CDN» بسازید؛ تفکیک رکورد DNS بر اساس موقعیت جغرافیایی تنها از طریق API امکانپذیر است.
قابلیت بهبود دسترسیپذیری (Improved Availability) و تفاوت آن با بهبود سئو
در بخش تنظیمات پیشرفتهٔ آپاستریم، گزینهٔ بهبود دسترسیپذیری (Improved Availability) ترافیک را در زمان اختلال شبکه یا از دسترس خارج شدن بخشی از سرورها به مسیر یا سرور سالمتر هدایت میکند. اثربخشی این قابلیت زمانی بیشتر است که چند سرور آپاستریم در موقعیتهای جغرافیایی مختلف داشته باشید.
قابلیت بهبود سئو (Improved SEO) هدف متفاوتی دارد و مخصوص تسهیل دسترسی خزندههای موتورهای جستجو به سرور آپاستریم داخل ایران است. هر دو گزینه در پنل و روی تنظیمات آپاستریم قرار دارند.
