ایمیل کوتاه است و لحن رسمی دارد: «به دلیل الزامات قانونی، ما دیگر قادر به ارائه خدمات به حساب شما نیستیم.» بدون هشدار قبلی، بدون مهلت، بدون امکان خروجی گرفتن از داده‌ها. سرویسی که سه سال است بخشی از محصول شما روی آن کار می‌کند، از همین لحظه وجود ندارد.

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

مشکل سه لایه دارد، نه یک لایه

وقتی از «تحریم وب سرویس‌ ها» حرف می‌زنیم، معمولاً سه مشکل متفاوت را با هم قاطی می‌کنیم. جدا کردنشان مهم است، چون هر کدام راه‌حل متفاوتی دارد.

1. لایه اول، دسترسی. بسیاری از سرویس‌ ها درخواست‌ های ارسال‌ شده از IP ایران را با خطای ۴۰۳ رد می‌کنند. زیرساخت‌ های ابری بزرگ، بخش عمده‌ای از پلتفرم‌های توسعه و حتی برخی پروتکل‌ های مدرن وب در این دسته‌اند. این لایه آزاردهنده است ولی معمولاً با واسطه قابل مدیریت است.
2. لایه دوم، پرداخت. کارت‌ های بانکی ایرانی در هیچ درگاه بین‌ المللی پذیرفته نمی‌شوند. راه‌حل رایج، کارت‌ های مجازی با کارمزد بالا و نوسان قیمت ارز است؛ یعنی هزینه‌ای که در ابتدای سال بودجه‌بندی کرده‌اید، تا پایان سال چند برابر می‌شود.
3. لایه سوم، تداوم. این لایه است که واقعاً خطرناک است و کمتر به آن فکر می‌شود. حتی اگر دسترسی و پرداخت را حل کرده باشید، حساب شما هر لحظه ممکن است با یک بررسی هویتی یا تشخیص موقعیت جغرافیایی بسته شود؛ همراه با تمام داده‌ها، تنظیمات و تاریخچه. مشکل پرداخت گران است، مشکل تداوم مرگبار است.

با تشدید محدودیت‌ها در سال ۲۰۲۶، فهرست سرویس‌ های مسدود شده طولانی‌تر و اجرای قوانین سخت‌ گیرانه‌تر شده است. سرویس‌هایی که تا دیروز با کمی زحمت کار می‌کردند، امروز اکانت‌ های ایرانی را فعالانه شناسایی و محدود می‌کنند.

چرا «دور زدن» یک استراتژی نیست؟

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

سه دلیل روشن:

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

نتیجه: دور زدن را فقط برای ابزارهای جانبی و غیرحیاتی نگه دارید. برای هر سرویسی که در مسیر کاربر نهایی قرار دارد، جایگزین پایدار لازم است.

جایگزین‌ها به تفکیک دسته

جدول زیر تصویر کلی را می‌دهد؛ در ادامه، دسته‌ های مهم‌ تر را با جزئیات بررسی می‌کنیم.

زیرساخت ابری: بزرگ‌ ترین وابستگی، بالغ‌ ترین جایگزین

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

پیامک و کد تایید: جایی که سرویس خارجی از اول هم جواب نمی‌داد

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

دلیلش ساختار شبکه مخابراتی است. سرویس‌ هایی مثل Twilio پیامک را از مسیرهای بین‌ المللی به اپراتورهای ایرانی تحویل می‌دهند؛ مسیرهایی که تأخیر بالا، نرخ تحویل نامطمئن و هزینه دلاری برای هر پیامک دارند. مهم‌تر اینکه این مسیرها به خط خدماتی و ارسال با الگو دسترسی ندارند، یعنی کد تایید شما برای میلیون‌ها کاربری که پیامک تبلیغاتی را مسدود کرده‌اند اصلاً نمی‌رسد. سرویس احراز هویت پیامکی فایربیس هم دقیقاً به همین دلیل برای شماره‌های ایرانی ناپایدار است.

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

ایمیل تراکنشی: سخت‌ ترین دسته برای مهاجرت

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

پرداخت: مشکل از قبل حل شده بود

Stripe و PayPal هیچ‌ وقت برای بازار ایران گزینه نبودند، پس اینجا بحران جدیدی وجود ندارد. درگاه‌های داخلی به شبکه بانکی متصل‌اند، مستندات API قابل قبولی دارند و برای بازار داخلی تنها راه هستند. اگر مشتری خارجی دارید، مسئله پیچیده‌تر و بیشتر حقوقی است تا فنی.

نقشه، پوش و مانیتورینگ

برای نقشه، سرویس‌ های ایرانی با پوشش خوب معابر داخلی و API مسیریابی در دسترس‌ اند و برای نیازهای پایه، OpenStreetMap روی سرور خودتان کاملاً کافی است. برای پوش نوتیفیکیشن، سرویس‌ های داخلی وجود دارند، هرچند وابستگی نهایی به زیرساخت گوگل و اپل در سطح سیستم‌ عامل باقی می‌ماند. برای مانیتورینگ و آنالیتیکس، ابزارهای متن‌ باز خود میزبان مثل Matomo، Sentry و Grafana نه‌ تنها جایگزین کامل هستند، بلکه داده کاربران را هم در اختیار خودتان نگه می‌دارند.

چارچوب اولویت‌ بندی: از کجا شروع کنیم؟

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

1. آیا در مسیر حیاتی کاربر است؟ اگر بسته شود، کاربر نمی‌تواند ثبت‌ نام کند، بخرد یا وارد شود؟
2. آیا داده کاربران ایرانی از آن عبور می‌کند یا در آن ذخیره می‌شود؟
3. اگر فردا صبح بسته شود، مهاجرت چند روز طول می‌کشد؟

سرویسی که به هر سه پاسخ «بله، بله، بیش از یک هفته» می‌دهد، اولویت اول شماست. معمولاً سه دسته در این گروه قرار می‌گیرند: احراز هویت و کد تایید، زیرساخت هاست و درگاه پرداخت. ابزارهای توسعه، CI و مانیتورینگ اولویت پایین‌تری دارند و می‌توانند در فاز دوم بیایند.

یک اصل معماری که از شوک بعدی محافظت می‌کند

مشکل اصلی بسیاری از تیم‌ها این نیست که از سرویس خارجی استفاده کرده‌اند؛ این است که کد محصول مستقیماً به آن سرویس گره خورده است. کلاینت Twilio در بیست جای کد صدا زده شده، منطق ذخیره‌ سازی S3 در لایه دامنه نشت کرده و تغییر سرویس‌ دهنده یعنی بازنویسی.

راه‌حل قدیمی و همچنان درست: هر سرویس بیرونی را پشت یک واسط داخلی قرار دهید. یک ISmsSender، یک IStorageProvider، یک IEmailSender. پیاده‌سازی‌ ها قابل تعویض باشند و تغییر سرویس‌دهنده به تغییر چند خط تنظیمات خلاصه شود. این کار فقط برای امروز نیست؛ اگر سرویس داخلی فعلی هم روزی دچار مشکل شد، همین لایه شما را نجات می‌دهد.

چهار اشتباهی که مهاجرت را خراب می‌کند

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

اگر از پیامک شروع می‌کنید

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

جمع‌ بندی

تحریم وب سرویس‌ های خارجی سه مشکل جدا دارد: دسترسی، پرداخت و تداوم. دو تای اول را می‌شود با زحمت مدیریت کرد؛ سومی است که یک شب محصول شما را از کار می‌اندازد. راه‌ حل، دور زدن نیست؛ جایگزین‌ کردن اولویت‌ بندی‌ شده است: اول سرویس‌ های مسیر حیاتی کاربر، بعد بقیه. برای بیشتر دسته‌ها گزینه داخلی بالغی وجود دارد و برای بعضی مثل پیامک، گزینه داخلی از ابتدا هم انتخاب درست‌تر بود. از همین امروز فهرست کنید محصول شما به چند سرویس خارجی وابسته است و هر کدام در برابر سه سؤال بالا چه پاسخی می‌دهد. اگر این فهرست را ندارید، ریسک شما بزرگ‌تر از چیزی است که فکر می‌کنید.