موقعیت دیتاسنتر؛ هاست ایران یا خارج، CDN و سئو

دو نسخه از یک فروشگاه را تصور کنید. سرور ایران برای کاربر تهران TTFB خوبی دارد، اما به سرویس قیمت‌گذاری خارجی و خزنده‌های بین‌المللی مسیر ناپایداری دارد. سرور اروپا به Origin سریع پاسخ می‌دهد، ولی Checkout کاربران بعضی اپراتورهای موبایل ایران در ساعات شلوغ کند می‌شود. انتخاب برنده از روی پینِ نقشه ممکن نیست؛ باید مسیر واقعی کاربر، Cache، درخواست‌های داینامیک، وابستگی‌ها، پایداری و هزینه تغییر را با هم سنجید.

این راهنما برای مالک سایت، تیم SEO، توسعه‌دهنده، SRE/DevOps و خریدار Hosting نوشته شده است. ابتدا اثر مکان دیتاسنتر بر RTT، TTFB و Core Web Vitals را تفکیک می‌کنیم؛ سپس ادعاهای SEO، هاست ایران یا خارج، CDN/Edge، امنیت و Data residency، معماری تاب‌آور، RUM/Synthetic، Pilot و مهاجرت را پوشش می‌دهیم. پاسخ کوتاه این است: مکان Origin مهم است، اما «نزدیک‌ترین کشور» به‌تنهایی بهترین معماری را تعیین نمی‌کند.

موقعیت دیتاسنتر چه بخشی از Performance را تغییر می‌دهد؟

هر درخواست مسیر User→Resolver→Edge/CDN→Origin→Dependency را طی می‌کند. فاصله و مسیر شبکه روی Round-trip time اثر دارند؛ اما Peering، ازدحام، Packet loss، Route detour، اتصال مجدد و صف Backend می‌توانند از فاصله جغرافیایی مهم‌تر باشند. کاربری که به Edge نزدیک Cache hit می‌گیرد، شاید اصلاً Origin دور را لمس نکند؛ درخواست شخصی‌سازی‌شده Checkout تقریباً همیشه تا Origin و سرویس‌های داخلی می‌رود.

بنابراین «IP سرور نزدیک است» فقط یک Proxy ابتدایی است. Anycast یا Reverse proxy می‌تواند IP Edge را نشان دهد، نه محل Origin؛ ابزار IP geolocation نیز کیفیت مسیر، منطقه واقعی Cloud یا Cache status را اثبات نمی‌کند.

فیزیک شبکه: فاصله کف Latency است، نه کل آن

سیگنال در فیبر سریع حرکت می‌کند، اما مسیر کابل خط مستقیم روی نقشه نیست. هر Request ممکن است از Routerها، شبکه‌های Transit و نقطه‌های Peering متعدد عبور کند. Queueing و Retransmission نیز زمان اضافه می‌کنند. Ping پایین به یک IP الزاماً HTTP سریع نمی‌دهد، چون DNS، TLS، Backend و Resource loading هنوز باقی‌اند.

Observed latency ≈
propagation distance + routing/peering detour
+ queueing + packet-loss retransmission
+ DNS + connection/TLS setup
+ origin queue/app/database/dependency work
+ response transfer + browser processing

مکان وقتی بیشترین اثر را دارد که Round tripهای متعدد، Cache miss زیاد و پاسخ Origin-bound باشد. Connection reuse، HTTP/۲ یا HTTP/۳، Edge compute، Cache و کاهش Dependency call می‌توانند تعداد رفت‌وبرگشت‌ها را کم کنند، ولی Backend کند را درمان نمی‌کنند.

TTFB را به اجزا بشکنید

Time to First Byte از شروع Navigation تا رسیدن اولین بایت پاسخ است و معمولاً DNS، اتصال، TLS، Redirect، زمان رفت‌وبرگشت و پردازش Server را در خود دارد. TTFB بالا را نباید فوراً به کشور سرور نسبت داد. سند Chrome برای بهینه‌سازی TTFB به Backend، شبکه، Redirect و CDN به‌عنوان مسیرهای تشخیص اشاره می‌کند.

navigationStart
  ├─ redirect
  ├─ DNS lookup
  ├─ TCP/QUIC + TLS
  ├─ request travel to edge/origin
  ├─ queue + application + database + downstream APIs
  └─ response travel → responseStart (TTFB)

در Log/Trace، Server-Timing و زمان‌های App/DB/Dependency را ثبت کنید. اگر Backend ۹۰۰ms و مسیر ۸۰ms است، جابه‌جایی کشور سقف بهبود محدودی دارد. اگر Backend ۵۰ms اما RTT در p95 بعضی ISPها ۳۰۰ms است، معماری شبکه و Edge مهم‌تر می‌شود.

TTFB جزء Core Web Vitals نیست

Core Web Vitals فعلی LCP برای بارگذاری، INP برای پاسخ‌گویی تعامل و CLS برای ثبات بصری هستند. FID در سال ۲۰۲۴ با INP جایگزین شد. راهنمای رسمی Web Vitals ارزیابی را در صدک ۷۵ و جدا برای Mobile/Desktop توصیه می‌کند. TTFB و FCP شاخص‌های تشخیصی‌اند، نه عضو سه‌گانه Core Web Vitals.

Origin کند می‌تواند شروع HTML و در نتیجه کشف Resource مربوط به LCP را عقب بیندازد؛ اما LCP همچنین از اولویت تصویر، CSS، Font، Render و Client-side code اثر می‌گیرد. موقعیت سرور معمولاً INP را برای Interaction کاملاً Client-side حل نمی‌کند؛ در تعامل Server-bound، Network و Backend هر دو مؤثرند. CLS هم بیشتر به رزرو فضا، Font و DOM update مربوط است. برای تشخیص دقیق، راهنمای Core Web Vitals و RUM را ببینید.

رابطه موقعیت سرور و SEO را بدون اغراق بفهمید

Google می‌گوید Core Web Vitals در سیستم‌های رتبه‌بندی استفاده می‌شوند، اما امتیاز خوب تضمین صدر نتایج نیست و هیچ «سیگنال واحد Page experience» وجود ندارد. مستند Page experience در Google Search صراحتاً توصیه می‌کند به تجربه کلی توجه شود، نه فقط یک یا دو عدد.

• سرعت و دسترس‌پذیری برای کاربر ارزش مستقیم دارند؛ SEO تنها دلیل بهینه‌سازی نیست.
• Server location ممکن است از مسیر Performance اثر بگذارد، اما «کشور خاص = رتبه بالاتر» قاعده نیست.
• Bounce rate در Analytics را سیگنال رتبه‌بندی قطعی معرفی نکنید.
• محتوای مرتبط می‌تواند با Page experience ضعیف هم برای Query مناسب‌تر باشد.
• آزمایش Hosting را با Impression/Click/Conversion و رخدادهای هم‌زمان تفسیر کنید؛ تغییر رتبه را فوری به IP نسبت ندهید.

برای تفکیک Business outcome از امتیاز فنی، راهنمای سرعت سایت، UX، SEO و Conversion چارچوب مکمل است.

Server location فقط یک سیگنال Geotargeting غیرقطعی است

در سایت چندکشوری، Google به ccTLD، hreflang، URLهای محلی، زبان/ارز/نشانی، لینک‌ها و سیگنال‌های دیگر نگاه می‌کند. راهنمای رسمی سایت‌های چندمنطقه‌ای Google می‌گوید موقعیت سرور می‌تواند سیگنال باشد اما قطعی نیست، زیرا CDN و زیرساخت مناسب ممکن است در کشور دیگری باشند؛ برای ccTLD نیز Server location در جدول مزایا «irrelevant» آمده است.

دامنه .ir سیگنال کشور است، اما ترکیب «.ir + سرور ایران» تضمین رتبه یا نسخه طلایی نیست. برای زبان/کشورهای متعدد، URL جدا، hreflang متقابل و Self-canonical درست از حدس IP کاربر شفاف‌ترند. Redirect اجباری بر اساس IP می‌تواند نسخه‌ها را از کاربر یا Crawler پنهان کند.

Crawl budget: ظرفیت سرویس مهم است، نه نزدیکی به کاربر ایرانی

برای بیشتر سایت‌های کوچک، Crawl budget مسئله اول نیست. در سایت بزرگ یا دارای URLهای فراوان، Google Crawl capacity را با سلامت Host، زمان پاسخ، TTFB، 5xx و ۴۲۹ تنظیم می‌کند. مستند به‌روز Google Crawling Infrastructure Serving capacity و Crawl demand را جدا می‌کند.

سرور دور اما سریع و پایدار می‌تواند بهتر از سرور نزدیک با 5xx و Queue باشد. Sitemap، Duplicate/Faceted URL، Redirect chain، ۴۰۴/۴۱۰، Cache validation و کیفیت محتوا نیز اهمیت دارند. لوکیشن دیتاسنتر درمان URL inventory آشفته نیست.

Static، Dynamic و Personalized را پیش از انتخاب مکان تفکیک کنید

Cache ratio کل سایت کافی نیست؛ Hit/Miss را به Template، منطقه و Status بشکنید. سایت محتوایی با Hit بالا آزادی بیشتری در محل Origin دارد. فروشگاه داینامیک با چند API رفت‌وبرگشتی باید Origin را نزدیک داده و Dependencyها هم ببیند.

CDN فاصله را حذف نمی‌کند؛ مسیر را دوشاخه می‌کند

در Cache hit، Edge نزدیک می‌تواند Response را بدون Origin برگرداند. در Miss یا محتوای Dynamic، درخواست تا Origin ادامه می‌یابد. مستند Cache در Cloudflare نشان می‌دهد Static به‌طور پیش‌فرض Cacheable است ولی HTML داینامیک معمولاً نیاز به Rule دارد. این رفتار بین Providerها و تنظیمات متفاوت است.

CDN برای مخاطب جهانی، Offload، TLS termination و DDoS مفید است، اما باید PoP واقعی برای ISPهای هدف، مسیر Edge↔Origin، Cache policy، Purge و Failure را سنجید. راهنمای CDN برای سایت ایرانی Selection و پیاده‌سازی داخلی را عمیق‌تر پوشش می‌دهد؛ برای چندکشوری، معماری CDN بین‌المللی و SEO مرجع مرتبط است.

Cache-Control را قرارداد صحت بدانید

کش سریع اما اشتباه می‌تواند قیمت، حساب یا داده شخص دیگری را نمایش دهد. RFC ۹۱۱۱ برای HTTP caching Freshness، Validation، Cache key و محدودیت پاسخ Stale را تعریف می‌کند. private، no-store، no-cache و must-revalidate معنای یکسان ندارند.

Public versioned asset:
Cache-Control: public, max-age=31536000, immutable

Public HTML with controlled revalidation:
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=30
ETag: "page-v42"

Authenticated account response:
Cache-Control: private, no-store

این‌ها نمونه‌اند، نه نسخه عمومی. Cookie، Authorization، زبان، Device و Query می‌توانند Cache key را تغییر دهند. Cache poisoning، Key explosion، Stale inventory و Purge lag را با تست منفی پوشش دهید.

Origin را نزدیک کاربر بگذاریم یا نزدیک داده؟

برای صفحه عمومی، نزدیکی به کاربر مهم است؛ برای Transaction چندمرحله‌ای، نزدیک‌بودن App به Database، Search، Queue و Payment ممکن است مهم‌تر باشد. قرار دادن App در تهران و Database در اروپا می‌تواند هر Query را به چند RTT بین‌منطقه‌ای تبدیل کند. هم‌مکانی Compute و داده معمولاً مسیر داغ را کوتاه می‌کند، سپس Edge به کاربران نزدیک می‌شود.

End-to-end request budget
User → Edge                 40 ms
Edge → Origin              90 ms
Origin queue + app         70 ms
Origin → DB (5 round trips) 5 × 80 ms = 400 ms
Origin → payment API       180 ms
------------------------------------
Total before transfer      ≈ 780 ms

Moving only User→Origin cannot fix the 400 ms data chat.

Chatty protocol را Batch، Query را بهینه و Connection pool را درست کنید. سپس Region را انتخاب کنید. معماری بد با کابل کوتاه همچنان کند است.

هاست ایران یا خارج؟ سؤال را به Workload contract تبدیل کنید

قانون «۸۰٪ کاربر ایرانی = هاست ایران» یا «خارج همیشه پایدارتر» قابل اتکا نیست. Workload contract باید توزیع کاربر، Device/ISP، Cacheability، مسیرهای Critical، Dependencyها، داده، SLO، Recovery، دسترسی تیم، هزینه و برنامه رشد را ثبت کند.

سناریوهای شبکه ایران را جداگانه آزمایش کنید

میانگین «Iran» تنوع اپراتور ثابت/موبایل، شهر، ساعت و مسیر را پنهان می‌کند. Probe از چند شبکه و شهر، صبح/اوج/تعطیل و مسیرهای IPv4/IPv6 اجرا کنید. همچنین سناریوی اختلال اینترنت بین‌الملل، Route change، DNS failure، CDN PoP bypass و ناتوانی تیم در دسترسی به Control plane را تمرین کنید.

• سایت عمومی داخلی، API خارجی و Third-party script را جدا بسنجید.
• درگاه، پیامک، نقشه، CAPTCHA، Font و Analytics می‌توانند Critical path را بشکنند.
• صفحه‌ای که HTML داخلی دارد اما JS حیاتی خارجی‌اش نمی‌رسد «در دسترس» نیست.
• Dashboard Provider یا Repository ممکن است از شبکه عملیات قابل دسترسی نباشد؛ Break-glass لازم است.
• فرضیات Access/Payment/Renewal/Support را دوره‌ای بازآزمایی کنید.

مخاطب بین‌المللی به معماری چندمنطقه‌ای نیاز قطعی ندارد

برای شروع، Origin واحد سالم + CDN + Cache policy + RUM ممکن است کافی باشد. Multi-region فعال هزینه Replication، Consistency، Failover، Observability و عملیات را بالا می‌برد. فقط وقتی مسیرهای Dynamic، SLO یا Residency با معماری ساده برآورده نمی‌شوند، Active-passive یا Active-active را Pilot کنید.

DNS بخشی از Availability و مهاجرت است

DNS کند یا اشتباه، Origin سریع را بی‌اثر می‌کند. TTL را نه همیشه کم و نه همیشه زیاد بگذارید؛ فرکانس تغییر، Cache، بار Authoritative و زمان Failover را بسنجید. Health check باید تجربه End-to-end را بسنجد، نه فقط بازبودن Port. Failover DNS نیز به TTL، Cache resolver و State داده وابسته است و آنی نیست.

Ownership دامنه، Registrar lock، MFA، DNSSEC، دسترسی Break-glass و ثبت تغییرات حیاتی‌اند. راهنمای مدیریت DNS، DNSSEC و مهاجرت Runbook دقیق‌تر این لایه است.

Third-partyها مکان معماری را خنثی می‌کنند

Tag manager، Ad script، Chat widget، Font، Video، Map و Payment می‌توانند LCP/INP یا تکمیل Journey را محدود کنند. Waterfall و Resource timing را بر اساس Domain و Region بشکنید. Self-host یا حذف هر Third-party تصمیم حقوقی/امنیتی/عملیاتی دارد؛ فقط بهبود سرعت نیست.

برای Checkout، Timeout و Fallback وابستگی مهم‌تر از Load صفحه خانه است. Script غیرحیاتی را Lazy و با Consent مناسب بار کنید؛ Dependency حیاتی SLO، Circuit breaker و مسیر Degraded می‌خواهد.

Availability را با Fault domain طراحی کنید

دو VM در یک Rack یا یک Region Multi-region نیستند. Power، شبکه، Storage، Control plane، DNS، CDN، Database، Backup و تیم عملیات Fault domainهای جدا دارند. Provider marketing را با معماری واقعی و تست Failure تطبیق دهید.

Availability scenario contract
Failure: primary region unreachable
Detection: end-to-end probes from 3 target networks
Decision time: 5m
RTO / RPO: 30m / 5m
Failover: DNS or traffic manager → warm standby
Data gate: replication lag < approved RPO
Fallback: read-only catalog; checkout paused with clear message
Return: reconcile writes → controlled failback → evidence review

Backup در همان Account/Region یا Snapshot بدون Restore test Recovery نیست. برای RTO/RPO، Restore rehearsal و Communication، راهنمای بازیابی فاجعه و Backup را ببینید.

امنیت را با محل کشور ساده‌سازی نکنید

«داخل امن‌تر» یا «خارج امن‌تر» حکم مفیدی نیست. کنترل فیزیکی، Tenant isolation، Patch، IAM، Encryption، Key ownership، Log، WAF/DDoS، Supply chain، Staff access، Incident response و Evidence را ارزیابی کنید. CDN می‌تواند Origin را پنهان و حمله حجمی را جذب کند، اما Misconfiguration یا Bypass ممکن است Origin را آشکار بگذارد.

• Origin فقط ترافیک Proxy/Load balancer مجاز را بپذیرد، اگر معماری اجازه می‌دهد.
• Admin plane با MFA، Least privilege، VPN/Zero Trust و Audit محافظت شود.
• Secret و Backup از محیط Production جدا و Rotation آزموده شود.
• Patch/EOL و مسئولیت Managed service در قرارداد روشن باشد.
• Pen-test و DDoS exercise در Scope Provider و Application تفکیک شوند.

برای محیط اشتراکی، راهنمای امنیت هاست اشتراکی مرز Provider/Customer، Isolation و مهاجرت را پوشش می‌دهد.

Data residency، Privacy و قرارداد را مستقل بررسی کنید

مکان Server با مکان Backup، Log، CDN cache، Support access و Subprocessor یکی نیست. Data map باید هر کپی، مسیر و کلید را نشان دهد. نیازهای قراردادی و قانونی به نوع داده، صنعت، طرف قرارداد و حوزه خدمت وابسته‌اند؛ این مقاله حکم حقوقی درباره میزبانی داخل یا خارج نمی‌دهد.

Data residency را با Data sovereignty، Localization و Jurisdiction مخلوط نکنید. Vendor باید Location، انتقال، حذف، Breach notification، Audit، Exit و بازگرداندن داده را مستند کند؛ سپس مشاور واجد صلاحیت آن را با الزام واقعی تطبیق دهد.

TCO را فراتر از قیمت ماهانه محاسبه کنید

Compute، Storage و Bandwidth فقط شروع‌اند. CDN egress، Request، WAF، Backup، Snapshot، Managed DB، Support، Tax/Invoice، Migration، Observability، DDoS، IP، Cross-region replication و نیروی عملیات را وارد کنید. برای سرویس خارجی، نرخ ارز، روش پرداخت، تعلیق و هزینه خروج Scenario جدا دارند.

Annual TCO range =
compute + storage + requests + bandwidth/egress
+ CDN/WAF/DNS + DB/cache/search/queue
+ backup/DR + monitoring/log retention + support
+ migration/engineering/operations + security/compliance evidence
+ FX/payment/suspension/incident reserve
- measured savings from cache/offload/right-sizing

قیمت ارزان با Oversell، I/O محدود، Support کند یا Restore ناموفق گران می‌شود. Cost را به Successful request و Business journey پیوند دهید، نه فقط GB/RAM.

Measurement plan: Synthetic و RUM را کنار هم بگذارید

Synthetic برای مقایسه کنترل‌شده از Probeهای ثابت و RUM برای تجربه کاربران واقعی است. Lab یک Laptop/شبکه را شبیه‌سازی می‌کند؛ Field توزیع Device/ISP/Cache/Session را نشان می‌دهد. CrUX پوشش عمومی مفیدی دارد اما ممکن است برای URL کم‌ترافیک داده نداشته باشد؛ RUM اختصاصی با Privacy مناسب جزئیات Journey را می‌دهد.

برای تعریف SLI/SLO، Trace و Alert مبتنی بر Journey، راهنمای Observability و مانیتورینگ مسیر کامل‌تری ارائه می‌دهد.

Benchmark نماینده بسازید، نه تست Speedtest فروشنده

یک کپی Production-like با Dataset، Cache policy، TLS، DB و Third-party نماینده بسازید. از چند ISP/شهر و منطقه خارجی، Cold/Warm، Logged-out/Logged-in و Peak load را اجرا کنید. Median تنها کافی نیست؛ p75/p95/p99، Error و Packet loss را ثبت کنید.

1. Baseline فعلی را حداقل یک چرخه ترافیکی ثبت کنید.
2. DNS/Edge/Origin/App/DB/Dependency را Instrument کنید.
3. همان Build و Dataset را روی گزینه‌ها اجرا کنید.
4. Cache hit/miss و Route را جدا کنید.
5. Load، Failover، Restore، Support و Access را تمرین کنید.
6. نتیجه را با Workload contract و TCO امتیاز دهید.

سه معماری نمونه برای ایران

سایت محتوایی فارسی: Origin واحد با کیفیت، CDN دارای مسیر مناسب برای مخاطب، HTML عمومی با Revalidation، Asset نسخه‌دار و RUM. مکان Origin بعد از سنجش Miss و مسیر مدیریت انتخاب می‌شود؛ Content/URL quality همچنان مالک SEO است.

فروشگاه داخلی: App/DB/Queue نزدیک به هم، Edge برای Asset و Public catalog، Checkout بدون Cache اشتراکی، PSP/SMS/Carrier با Timeout/Fallback، Backup جدا و سناریوی اختلال. انتخاب داخل/خارج از p95 Journey و Dependency map می‌آید.

SaaS دو بازار: URL/locale صریح، Edge جهانی، Tenant routing، Regionهای محدود بر اساس SLO/Data contract، Read/Write ownership و Failover آزموده. Active-active فقط اگر Consistency و عملیات آن توجیه شده باشد.

مهاجرت دیتاسنتر را به‌صورت Canary اجرا کنید

قبل از Cutover، Inventory DNS، Certificate، IP allowlist، Webhook، Cron، Queue، Email، Storage، Backup، Search Console و Monitoring را کامل کنید. TTL را زودتر و کنترل‌شده تنظیم کنید. Dataset را Sync، Integrity را بررسی و Freeze/dual-write را متناسب با سیستم انتخاب کنید.

Migration gate
1. restore rehearsal + data checksum
2. shadow/read traffic to new origin
3. synthetic + RUM + error/security comparison
4. small weighted canary
5. scale while watching p95 journey and guardrails
6. DNS cutover + old origin observation window
7. reconcile → decommission only after rollback expiry

Redirect، Canonical، Sitemap و URL نباید صرفاً با جابه‌جایی Hosting تغییر کنند. اگر Domain ثابت است، مهاجرت زیرساخت Site move محتوایی نیست؛ با این حال Crawl و Logها را زیر نظر بگیرید.

Scorecard انتخاب Provider و دیتاسنتر

برنامه ۹۰روزه انتخاب و بهینه‌سازی Hosting

روز ۱ تا ۳۰: Workload، مخاطب، ISP/شهر، Journey، Cacheability، Dependency، Data و SLO را Inventory کنید. RUM/Synthetic/Trace را راه بیندازید و Baseline p75/p95، Error، HIT/MISS، TCO و Incident را بگیرید. ادعاهای SEO را از نیاز Performance/Geotargeting جدا کنید.

روز ۳۱ تا ۶۰: دو یا سه گزینه را با Build/Dataset یکسان Pilot کنید. شبکه داخلی/خارجی، Peak، Cold/Warm، Failover، Restore، Support، Access و هزینه را بسنجید. CDN/Cache و Backend optimization را جدا آزمایش کنید تا اثر جابه‌جایی Region اشتباه محاسبه نشود.

روز ۶۱ تا ۹۰: Canary و سپس Cutover کنترل‌شده اجرا کنید. Scale وقتی p95 Journey، Error، Recovery و TCO بهترند؛ Hold وقتی فقط Ping/میانگین بهتر شده؛ Rollback وقتی Error، Data integrity، امنیت یا Critical dependency Guardrail را نقض کرده است. فرضیات را فصلی و پس از تغییر Route/Provider بازبینی کنید.

چک‌لیست تصمیم موقعیت دیتاسنتر

• مسیر User→Edge→Origin→Dependency و Owner هر لایه مشخص است.
• TTFB به DNS/connect/TLS/network/app/DB/API شکسته شده است.
• LCP/INP/CLS فعلی با Field p75 و Mobile/Desktop سنجیده می‌شوند.
• Server location به‌عنوان سیگنال غیرقطعی SEO/Geo ثبت شده، نه تضمین رتبه.
• Static/Dynamic/Personalized/Write و Cache hit/miss تفکیک شده‌اند.
• Cache key، Freshness، Validation، Purge و داده خصوصی تست شده‌اند.
• Origin نزدیک کاربر و نزدیک داده با Budget end-to-end مقایسه شده‌اند.
• چند ISP/شهر/ساعت ایران و مسیر بین‌المللی در Pilot حضور دارند.
• Dependency خارجی، Control plane و Break-glass سناریو شده‌اند.
• DNS، Failover، RTO/RPO، Restore و Reconciliation تمرین شده‌اند.
• امنیت/Data location برای Origin/CDN/Backup/Log/Support جدا بررسی شده‌اند.
• TCO شامل Egress/CDN/DR/Support/Ops/FX/Exit است.
• مهاجرت Canary، Monitoring، Rollback و Decommission gate دارد.

جمع‌بندی: Region را با Evidence انتخاب کنید

فاصله جغرافیایی روی حداقل RTT اثر دارد، اما تجربه واقعی محصولِ Route، Cache، Backend، داده، Dependency، Browser و Device است. CDN می‌تواند Hit را نزدیک کاربر پاسخ دهد؛ Dynamic و Write هنوز به Origin وابسته‌اند. Core Web Vitals و Crawl capacity به سلامت کل سرویس مربوط‌اند و موقعیت سرور یک Shortcut قطعی برای SEO نیست.

به‌جای «هاست ایران یا خارج؟»، بپرسید کدام معماری برای Journeyهای حیاتی، کاربران و محدودیت‌های واقعی ما در p75/p95، Error، Recovery، امنیت و TCO بهتر است. پاسخ معتبر از RUM، Synthetic، Trace، Pilot و Failure rehearsal می‌آید؛ نه نقشه، Ping واحد یا شعار فروشنده.

سؤالات متداول موقعیت دیتاسنتر

آیا موقعیت سرور مستقیماً رتبه Google را بهتر می‌کند؟

موقعیت Server می‌تواند یکی از سیگنال‌های غیرقطعی مخاطب جغرافیایی باشد و از مسیر Performance اثر بگذارد، اما کشور خاص رتبه را تضمین نمی‌کند. برای هدف‌گیری بین‌المللی، ccTLD/URL محلی، hreflang و محتوای مناسب صریح‌ترند؛ Core Web Vitals خوب نیز تضمین رتبه بالا نیست.

برای سایت ایرانی هاست داخل بهتر است یا خارج؟

پاسخ عمومی ندارد. توزیع ISP/شهر، Journey داینامیک، محل DB/API، CDN، پایداری داخلی/بین‌المللی، Data contract، عملیات و TCO را بسنجید. دو گزینه را با Build یکسان و RUM/Synthetic در p75/p95 Pilot کنید؛ درصد کاربران به‌تنهایی تصمیم کافی نیست.

آیا CDN جای انتخاب Origin مناسب را می‌گیرد؟

در Cache hit، CDN می‌تواند رفت‌وبرگشت Origin را حذف کند؛ در Miss، Revalidation، محتوای شخصی و Write درخواست هنوز تا Origin می‌رود. بنابراین CDN اثر مکان را برای محتوای Cacheable کم می‌کند، اما معماری Backend، داده و Dependency را جایگزین نمی‌کند.

TTFB بالا یعنی دیتاسنتر دور است؟

نه. DNS، Redirect، اتصال/TLS، Route، Queue، App، Database و API خارجی همگی در TTFB نقش دارند. با Resource timing، Server-Timing، Trace و تست HIT/MISS سهم هر بخش را جدا کنید؛ سپس Region یا Backend را تغییر دهید.

پیش از مهاجرت دیتاسنتر چه چیزهایی را تست کنیم؟

Route چند ISP/شهر، p75/p95 Journey، Load، Cache، Error، Dependency، DNS، Certificate، Data sync، Backup/Restore، Failover، امنیت، Support، هزینه و Rollback را آزمایش کنید. مهاجرت را Shadow/Canary کنید و Origin قبلی را تا پایان پنجره بازگشت نگه دارید.