قاعدهٔ اول زیرساخت ساده است: سرور را نزدیک کاربر بگذار. اگر مشتریهای شما بیرون از ایراناند، این قاعده یعنی سرور خارج از ایران؛ مسیر بینالمللِ کوتاهتر، تجربهٔ پایدارتر و زمان پاسخ قابلاتکاتر برای همان کاربرها. اگر مخاطبتان ترکیبی است، پاسخ هم ترکیبی است: هر گروه از سرورِ نزدیک خودش سرویس بگیرد. این مقاله برای کسبوکارهایی است که مشتری خارجی دارند یا در راه دارند؛ چهار سناریوی واقعی، معماری دوسروره، و چکلیست انتخاب را با هم میبینیم.
مسئلهٔ واقعی: کاربر شما کجاست؟
هر درخواست وب، سفری فیزیکی است روی فیبر و مسیریابها، و طول این سفر را جای سرور و کاربر تعیین میکند. کاربری در فرانکفورت که به سروری در تهران وصل میشود، از چند شبکهٔ میانی و گلوگاه بینالملل عبور میکند؛ همان کاربر به سروری در همان قاره، مسیری چندبرابر کوتاهتر دارد. مفهوم تأخیر و اجزایش را مستند آموزشی Cloudflare دربارهٔ latency خوب باز کرده و برای دیدن مسیرها و اندازهگیری واقعی، شبکهٔ جهانی RIPE Atlas مرجع بیطرف است.
پس پیش از هر تصمیم، یک کار کوچک انجام دهید: از تحلیلگر سایت یا گزارش فروش، سهم جغرافیایی کاربران را دربیاورید. عدد واقعی، بحث را از سلیقه به مهندسی میبرد. سایتی با ۹۵ درصد کاربر داخلی، جای دیگری از این تصمیم میایستد تا فروشگاهی که نیمی از سفارشهایش از خارج میآید.
چهار سناریویی که سرور خارج برایشان جدی است
- فروش و خدمات به مشتری خارجی: صادرات، گردشگری سلامت، خدمات فریلنسی به کارفرمای بینالمللی. مشتریای که پولش را از خارج میفرستد، تجربهٔ وبش را هم با استاندارد همانجا میسنجد.
- مخاطب ایرانیِ خارج از کشور: رسانه، آموزش، فروش فایل و اشتراک برای فارسیزبانان اروپا و آمریکای شمالی. زبان فارسی است و جغرافیا خارجی؛ سرور هم باید همانجا باشد.
- محصول SaaS با بازار جهانی: ابزاری که از روز اول قرار است مشتری بینالمللی بگیرد، از روز اول باید روی زیرساخت بینالمللی بنشیند تا بعداً اسبابکشی نکند.
- سرویسهای وابسته به APIهای خارجی: بعضی سرویسهای بینالمللی، درخواست از IP خارج از محدودهٔ خودشان را بهتر و پایدارتر پاسخ میدهند. اگر بکاند شما مدام با چنین سرویسهایی حرف میزند، اجرای همان بخش روی سرور خارج، خطاهای پراکنده را کم میکند.
یکی از این چهار را زمینیتر کنیم. کلینیکی را تصور کنید که بیمار بینالمللی میپذیرد و سایتش روی سروری در تهران است. متقاضی از مونیخ فرم مشاوره را باز میکند: هر کلیک از گلوگاه بینالملل عبور میکند، گالری تصاویر دیر بالا میآید، و در بدترین لحظه، ارسال فرم با خطای اتصال میماند. همان صفحه روی سروری در فرانکفورت، برای همان متقاضی، مثل هر سایت اروپایی دیگری رفتار میکند. هزینهٔ جابهجایی، از یک بیمارِ ازدسترفته کمتر است؛ حساب این سناریو همیشه همینقدر کوتاه است.
کدام معماری برای کدام ترکیب مخاطب؟
| ترکیب مخاطب | معماری پیشنهادی | یادداشت |
|---|---|---|
| تقریباً همه داخل ایران | سرور داخل (سرور مجازی ایران) | پروندهٔ جداگانه دارد و قبلاً تحلیلش کردهایم |
| تقریباً همه خارج | سرور خارج (سرور مجازی آلمان یا فرانسه) | سادهترین حالت؛ همهچیز یکجا، نزدیک کاربر |
| ترکیبی، دو محصولِ جدا | دو سرور مستقل، هرکدام کامل | کمدردسرترین ترکیبی؛ فقط دیتای مشترک را همگام کنید |
| ترکیبی، یک محصول واحد | دو سرور + مسیریابی جغرافیایی | حرفهایترین و پرکارترین؛ ادامهٔ مقاله |
معماری دوسروره در عمل
اصل کار در تصویر بالاست و اجرایش سه تصمیم دارد. اول، تقسیم چه چیزی: معمولاً لایهٔ نمایش و کش در هر دو سمت تکرار میشود و منبع حقیقتِ داده یکجا میماند. دوم، مسیریابی: یا زیردامنههای جدا برای هر بازار، یا DNS جغرافیایی که کاربر را بیسروصدا به سرور نزدیکش بفرستد. سوم، همگامسازی: سفارشها و حسابها با چه فاصلهای و از چه مسیری بین دو سمت جابهجا شوند.
یک هشدار ضدپیچیدگی هم لازم است: تا وقتی ترافیک خارجیتان کم است، دو سرور نگه ندارید. سایت روی یک سرور آلمان بهعلاوهٔ CDN برای محتوای ایستا، تا مدتها هر دو گروه کاربر را با کیفیت قابلقبول سرویس میدهد و فقط یک زیرساخت برای نگهداری دارید. معماری دوسروره را وقتی بیاورید که دادهٔ مصرف، وزن هر دو سمت را نشان داده باشد.
پیچیده بهنظر میرسد و برای شروع، لازم نیست باشد. نسخهٔ سادهٔ همین الگو را زیاد پیاده کردهایم: سایت اصلی روی سرور داخل برای بازار ایران، و لندینگ انگلیسی با فرم سفارش روی سرور آلمان برای مشتری خارجی. دو قطعهٔ کوچک، هرکدام سر جای درست، و ارتقا به نسخهٔ کامل هر وقت داده گفت لازم است.
چرا آلمان پیشفرضِ خوبِ «خارج» است؟
برای پوشش اروپا و بخش بزرگی از مخاطب جهانیِ کسبوکارهای ایرانی، دیتاسنترهای آلمان انتخاب اول ما هستند: زیرساخت پایدار، اتصال قوی به شاهراههای اینترنت اروپا، و مسیر برگشتِ قابلقبول به ایران برای مواقعی که تیم شما از داخل به سرور سر میزند. فرانسه هم گزینهٔ همردهٔ همان منطقه است و در پلنهای فرانسه ارائه میشود.
اگر بازار هدفتان جای دیگری است، همان قاعدهٔ اول برقرار است: نزدیکِ کاربر. مخاطبِ عمدتاً خلیجفارسی یا آسیای شرقی، محاسبهٔ خودش را دارد و در جلسهٔ مشاوره با دادهٔ واقعی شما بررسی میشود.
این بحث با «سرعت برای کاربر ایرانی» فرق دارد
در راهنمای سرور ایران یا آلمان پرسش این بود: برای کاربرِ داخل ایران کجا میزبانی کنیم؟ آنجا پای نوسان مسیرهای بینالملل برای کاربر داخلی وسط بود و پاسخ، اغلب سرور داخل. اینجا صورتمسئله برعکس است: کاربرِ بیرون از ایران، و همان منطق، جهتِ مخالف را نشان میدهد. دو مقاله مکملاند و کنار هم، نقشهٔ کامل تصمیم موقعیت را میسازند.
ملاحظات عملی که روز خرید اهمیت پیدا میکنند
- پرداخت ریالی: سرور خارج معمولاً یعنی پرداخت ارزی و کارت بینالمللی. گرفتن سرویس از ارائهدهندهٔ ایرانی با دیتاسنتر خارجی، این گره را باز میکند: فاکتور ریالی، سرور در فرانکفورت.
- پشتیبانی در ساعت و زبان شما: وقتی نیمهشب چیزی خراب شد، تیکتِ فارسی با پاسخ سریع، با تجربهٔ تیکت انگلیسی به دیتاسنتری در قارهٔ دیگر قابل مقایسه نیست.
- قوانین داده: دادهٔ کاربر اروپایی روی سرور اروپا، با الزامات حریم خصوصی همانجا همراه است. سیاست حریم خصوصی روشن و رمزگذاری در انتقال و ذخیره، حداقلهای جدی گرفته شدناند.
- دسترسی تیم از داخل ایران: پنل مدیریت و SSH باید برای تیم شما از داخل کشور روان باشد؛ پیش از خرید، همین را با یک حساب آزمایشی تست کنید.
- مسیر رشد: از مجازی شروع کنید و مطمئن شوید پلهٔ بعدی، از پلن بزرگتر تا سرور اختصاصی، بدون اسبابکشیِ دردناک در دسترس است. منطق انتخاب بین این دو را در راهنمای اختصاصی یا مجازی نوشتهایم.
قبل از خرید، مسیر را اندازه بگیرید
تصمیم موقعیت را میشود با نیمساعت اندازهگیری، از حدس به عدد رساند. سه آزمایش ساده:
- از سمت کاربر: از چند مشتری یا همکار در بازار هدف بخواهید آدرس تست ارائهدهنده را باز کنند و زمان پاسخ را گزارش بدهند. ده دقیقه، چند پیام، دادهٔ واقعی.
- با ابزار بیطرف: در RIPE Atlas از پروبهای همان کشورها به IP تست پینگ بگیرید؛ خروجی، میانگین و نوسان مسیر را از دهها نقطهٔ واقعی نشان میدهد.
- از سمت خودتان: با mtr یا traceroute از دفترتان به سرور آزمایشی نگاه کنید تا کیفیت مسیرِ مدیریتیِ خودتان هم معلوم شود.
این سه عدد را برای دو یا سه موقعیت کاندید تکرار کنید و کنار هم بگذارید. انتخابی که بعد از این جدول انجام شود، به سلیقه ربطی ندارد و بعداً هم قابل دفاع است. همین جدول را نگه دارید؛ شش ماه بعد، برای بازبینی تصمیم یا دفاع از آن جلوی مدیرمالی، دوباره به کارتان میآید. زیرساخت خوب، مستنداتِ تصمیمهایش را هم دارد.
سروری که رو به اینترنت جهانی است، حفاظ پایه میخواهد
سرور با IP عمومی، از دقیقهٔ اول زیر اسکنهای خودکار است؛ این را در لاگ هر سرور تازهای میشود دید. پیش از بردن ترافیک واقعی، این حداقلها را ببندید:
- ورود فقط با کلید: ورود رمزی SSH را خاموش کنید؛ حملههای سعیوخطا دقیقاً همان را میکوبند.
- فایروال با فهرست کوتاه: فقط پورتهای لازم باز باشند و پنلهای مدیریتی پشت محدودیت IP یا VPN بنشینند.
- مسدودسازی خودکار: ابزارهایی مثل fail2ban تلاشهای تکراری را خودشان میبندند؛ نصبشان چند دقیقه است.
- بهروزرسانی و پایش: وصلههای امنیتی سیستمعامل سر وقت، و هشدارِ خودکار برای ورودهای مشکوک و مصرف غیرعادی.
- بکاپ بیرون از همان سرور: قاعدهٔ همیشگی، اینجا حیاتیتر؛ نسخهٔ پشتیبان در موقعیت جغرافیایی دیگری بماند.
اگر تیم لینوکسی ندارید، این فهرست را بهعنوان تعریفِ «سرویس مدیریتشده» از ارائهدهنده بخواهید و اجرایش را مکتوب تحویل بگیرید.
اشتباهات رایج
- تصمیم بدون دادهٔ جغرافیایی: مبنای مهاجرت باید گزارش تحلیلگر باشد؛ «حس میکنم کاربر خارجی داریم» فقط شروعِ خوبی برای رفتن سراغ همان گزارش است.
- بردن همهچیز به خارج برای بخش کوچکی از کاربران: اگر ۹۰ درصد مخاطب داخل است، جابهجایی کامل یعنی بدتر کردن تجربهٔ اکثریت برای اقلیت. معماری ترکیبی برای همین ساخته شده.
- فراموش کردن بکاپِ برونسروری: سرور خارج هم سرور است؛ نسخهٔ پشتیبان باید جای دیگری بماند.
- خرید از برند ناشناس بهخاطر چند دلار: دیتاسنتر ارزانِ بیپشتیبان، در اولین حادثه گران میشود؛ این را در تجربهٔ مشتریهایی که با سرورِ رهاشده پیش ما میآیند زیاد دیدهایم.
- همزمانی مهاجرت با کمپین بینالمللی: قاعدهٔ همیشگی؛ زیرساخت را در هفتههای آرام جابهجا کنید.
سوالات متداول دربارهٔ سرور خارج از ایران
آیا CDN جای سرور خارج را میگیرد؟
برای محتوای ایستا تا حد خوبی بله: تصویر و فایل و صفحات کششده از لبهٔ نزدیکِ کاربر سرو میشوند و تجربهٔ جهانی بهتر میشود. کارهای پویا (ورود، سبد، جستجو، API) همچنان تا سرور اصلی سفر میکنند. اگر محصولتان پویاست و کاربر جدی خارجی دارید، CDN مکمل است و جای سرورِ نزدیک را نمیگیرد؛ ترکیب هر دو، معماری استاندارد این سناریوست.
برای سایت دوزبانه با مشتری داخلی و خارجی چه کنیم؟
الگوی سادهٔ دوسروره: نسخهٔ فارسی روی سرور داخل، نسخهٔ بینالمللی روی سرور خارج، و دادهٔ مشترک (سفارش، حساب) با همگامسازی منظم. اگر محصول واحد و درهمتنیده است، مسیریابی جغرافیایی روی یک دامنه راهحل کاملتر است و پیادهسازیاش کار مهندسیِ یکباره است.
سرور خارج برای سئوی گوگل بهتر است؟
گوگل موقعیت سرور را سیگنال تعیینکننده نمیداند و هدفگیری جغرافیایی از راههای دیگر (دامنه، تنظیمات سرچکنسول، زبان) انجام میشود. اثر واقعی سرور بر سئو از مسیر سرعت است: سرور نزدیکِ کاربر، تجربهٔ سریعتر و Core Web Vitals بهتر برای همان کاربران میسازد. تصمیم را با کاربر بگیرید؛ سئو دنبالش میآید.
میشود بعداً از سرور ایران به آلمان مهاجرت کرد؟
بله و مسیرش همان مهاجرت استاندارد سرور است: راهاندازی موازی مقصد، انتقال و همگامسازی داده، تست کامل، و سوئیچ DNS در ساعت خلوت. با برنامه، قطعیِ محسوسی در کار نیست. آنچه مهاجرت را سخت میکند وابستگیهای ثبتنشده است؛ از حالا مستندسازی کنید که چه چیزهایی روی سرور فعلی زنده است.
از داخل ایران، مدیریت سرور خارجی دردسر دارد؟
با ارائهدهندهٔ درست، تفاوتی با سرور داخل حس نمیکنید: پنل فارسی، پرداخت ریالی، و پشتیبانی که خودش با دیتاسنتر طرف است. چیزی که باید پیش از خرید تست کنید، روانی دسترسی SSH و پنل از اینترنت داخل کشور است؛ یک حساب آزمایشی این را ده دقیقهای روشن میکند.
هزینهٔ سرور خارج چقدر بیشتر از داخل است؟
سطح قیمت به منابع و دیتاسنتر بستگی دارد و جدول بهروزش را صفحهٔ سرور مجازی میگوید؛ عددی که اینجا بنویسیم، زودتر از خود مقاله کهنه میشود. نکتهٔ بودجهای پایدارتر این است: در معماری ترکیبی، هر سمت را بهاندازهٔ مخاطب همان سمت بخرید، و مجموع، معمولاً از «یک سرور بزرگ در جای اشتباه» اقتصادیتر درمیآید.
