شما یک نسخه جدید منتشر کردهاید و پس از یک ساعت یک گزارش باگ دریافت میکنید: «در آلمان نسخه اشتباه صفحه نمایش داده میشود»، «در ایالات متحده پرداخت کار نمیکند»، «در روسیه محتوا مسدود شده است». بازتولید این مشکل از ماشین محلی غیرممکن است. در اینجا است که پروکسیها از «ابزار دلالان» به یک ابزار کارآمد برای مهندس QA تبدیل میشوند.
در این مقاله بررسی میکنیم که چگونه به درستی از پروکسی برای تست رفتار وابسته به جغرافیا در اپلیکیشنها استفاده کنیم، کدام نوع پروکسی برای وظایف مختلف QA مناسب است و سناریوهای مرحله به مرحله را نشان میدهیم — از بررسی محتوای جغرافیایی تا تست دروازههای پرداخت.
چرا QA-testers به پروکسی نیاز دارند: سناریوهای واقعی
بسیاری از تیمها هنوز رفتار «بینالمللی» اپلیکیشن را فقط از ماشینهای محلی تست میکنند و به ندرت از VPN استفاده میکنند. این باعث ایجاد یک منطقه کور بزرگ میشود. VPN آدرس IP را تغییر میدهد، اما شبکه واقعی کاربر از کشور خاص — ارائهدهنده، نوع اتصال، اپراتور موبایل را شبیهسازی نمیکند. پروکسیها این امکان را میدهند که از طریق آدرس IP واقعی منطقه یا نوع شبکه به اینترنت دسترسی پیدا کنید.
در اینجا وظایف خاصی که QA-testers هر روز با آنها مواجه میشوند آورده شده است:
- محتوای جغرافیایی و محلیسازی. اپلیکیشن محتواهای مختلفی را بسته به کشور کاربر نمایش میدهد: قیمتها به ارز محلی، پیشنهادات منطقهای، بخشهای مسدود شده. بدون پروکسی، بررسی این موضوع غیرممکن است.
- سیستمهای پرداخت منطقهای. Stripe در اتحادیه اروپا و ایالات متحده به طور متفاوتی عمل میکند. PayPal در برزیل — یک مورد جداگانه است. تست جریان پرداخت باید دقیقاً از کشور مورد نظر انجام شود.
- CDN و کش. شبکه تحویل محتوا میتواند نسخههای مختلفی از منابع را از نقاط مختلف ارائه دهد. QA باید مطمئن شود که استاتیک به درستی برای کاربران در آسیا، اروپا و آمریکا بارگذاری میشود.
- مسدودسازیها و محدودیتها. در برخی کشورها، برخی از ویژگیهای اپلیکیشن به دلیل قوانین در دسترس نیستند. باید مطمئن شوید که مسدودسازی به درستی کار میکند و کاربر پیام واضحی را مشاهده میکند.
- آزمایش A/B بر اساس جغرافیا. اگر آزمایش فقط برای کاربران بریتانیا راهاندازی شده باشد، QA باید با IP بریتانیایی وارد شود و مطمئن شود که گزینه مورد نظر را میبیند.
- تست SEO. متا تگها، hreflang، نسخههای منطقهای صفحات — همه اینها باید با IP از کشور مربوطه بررسی شوند، در غیر این صورت موتور جستجو و کاربر واقعی چیزهای متفاوتی خواهند دید.
- تست سرعت از مناطق مختلف. زمان بارگذاری صفحه از سنگاپور و مسکو میتواند 3–5 برابر متفاوت باشد. پروکسیها این امکان را میدهند که این موضوع را در یک محل کار شبیهسازی کنید.
نکته کلیدی:
پروکسیها برای دور زدن مسدودسازیها «برای خود» نیستند. برای QA، این یک ابزار زیرساختی است که به شما امکان میدهد شرایط واقعی کاربر را از هر نقطهای از جهان مستقیماً از دسکتاپ تستکننده شبیهسازی کنید.
کدام نوع پروکسی برای تست مناسب است
همه پروکسیها به یک اندازه برای QA مفید نیستند. انتخاب نوع بستگی به این دارد که دقیقاً چه چیزی را تست میکنید. سه نوع اصلی و کاربرد آنها برای وظایف تستکننده را بررسی میکنیم.
پروکسیهای مسکونی
این آدرسهای IP کاربران واقعی خانگی از کشورهای خاص و شهرها هستند. وبسایت آنها را به عنوان افراد عادی میبیند، نه به عنوان مرکز داده یا شبکه شرکتی. پروکسیهای مسکونی انتخاب بهینه برای اکثر وظایف QA هستند: تست محتوای جغرافیایی، آزمایشهای A/B، جریانهای پرداخت و بررسی محلیسازی. آنها به طور دقیق کاربر واقعی را از کشور مورد نظر شبیهسازی میکنند.
مزایا برای QA: اعتماد بالا از طرف وبسایتها و اپلیکیشنها، پوشش جغرافیایی وسیع (بیش از 100 کشور)، امکان انتخاب شهر یا ارائهدهنده خاص. معایب — کمی کندتر از پروکسیهای مرکز داده، که باید در تست عملکرد در نظر گرفته شود.
پروکسیهای موبایل
آدرسهای IP اپراتورهای موبایل (3G/4G/5G). اینها به شدت مهم هستند زمانی که شما رفتار اپلیکیشن را برای کاربران موبایل تست میکنید. بسیاری از وبسایتها و اپلیکیشنها هنگام ورود با IP موبایل به طور متفاوتی عمل میکنند: نسخه موبایل را نمایش میدهند، محتوای دیگری را نشان میدهند و به طور متفاوتی موقعیت جغرافیایی را پردازش میکنند. پروکسیهای موبایل در تست اپلیکیشنهای موبایل از طریق شبیهسازها یا در بررسی واکنشپذیری نسخه وب ضروری هستند.
همچنین IPهای موبایل آدرسهای دینامیکی هستند که یک اپراتور به هزاران مشترک اختصاص میدهد. این بدان معناست که ترافیک تست شما حتی در صورت درخواستهای شدید مشکوک به نظر نمیرسد.
پروکسیهای مرکز داده
سریعترین و ارزانترین. برای تست بار، تستهای خودکار با تعداد زیادی درخواست، بررسی نقاط پایانی API مناسب هستند. پروکسیهای مرکز داده به راحتی به عنوان «کاربران غیر خانگی» شناسایی میشوند، بنابراین برای تست تجربه کاربری مناسبتر نیستند — اما برای بررسیهای فنی و بارگذاری انتخاب بهینه هستند.
| نوع پروکسی | برای کدام وظایف QA | سرعت | سطح اعتماد سایتها |
|---|---|---|---|
| مسکونی | محتوای جغرافیایی، محلیسازی، آزمایشهای A/B، دروازههای پرداخت | متوسط | بالا |
| موبایل | UX موبایل، تست در شرایط شبکههای موبایل | متوسط | بسیار بالا |
| مرکز داده | تست بار، بررسیهای API، تستهای فنی | بالا | پایین |
تست محتوای وابسته به جغرافیا: مرحله به مرحله
تست وابسته به جغرافیا — رایجترین سناریوی استفاده از پروکسی در QA است. اینجا نحوه انجام آن در عمل، بدون نوشتن کد، از طریق مرورگر معمولی آورده شده است.
مرحله 1. دادههای پروکسی را دریافت کنید
پس از اتصال به سرویس، شما دادههای اتصال را دریافت میکنید: هاست (IP یا دامنه)، پورت، نام کاربری و رمز عبور. برای پروکسیهای مسکونی معمولاً میتوانید کشور و شهر را مستقیماً در پنل کاربری یا از طریق پارامترها در رشته اتصال انتخاب کنید.
مثال رشته اتصال برای پروکسی مسکونی با انتخاب کشور به این صورت است: هاست شامل پارامتر کشور است (برای مثال، country-de برای آلمان)، پورت — استاندارد، نام کاربری و رمز عبور — اطلاعات کاربری شما.
مرحله 2. پروکسی را در مرورگر تنظیم کنید
برای تست دستی، راحتترین کار استفاده از افزونههای مرورگر است که به شما امکان میدهد به سرعت پروکسی را بدون تغییر تنظیمات سیستمی تغییر دهید. گزینههای محبوب: Proxy SwitchyOmega (Chrome/Firefox)، FoxyProxy (Firefox).
تنظیم مرحله به مرحله از طریق Proxy SwitchyOmega:
- افزونه را از Chrome Web Store نصب کنید.
- تنظیمات افزونه را باز کنید → روی «New Profile» کلیک کنید → «Proxy Profile» را انتخاب کنید.
- دادههای پروکسی را وارد کنید: پروتکل (SOCKS5 یا HTTP)، سرور (هاست)، پورت (پورت).
- اگر احراز هویت لازم است — نام کاربری و رمز عبور را در فیلدهای مربوطه وارد کنید.
- پروفایل را ذخیره کنید و از طریق آیکون افزونه در نوار مرورگر فعال کنید.
- به وبسایت whatismyip.com یا 2ip.ru بروید — مطمئن شوید که IP از کشور مورد نظر نمایش داده میشود.
مرحله 3. عناصر وابسته به جغرافیا را بررسی کنید
پس از اتصال پروکسی با جغرافیای مورد نظر، بررسی کنید:
- زبان رابط کاربری (تشخیص خودکار بر اساس IP)
- ارز قیمتها و روشهای پرداخت
- وجود/عدم وجود بخشهای خاص وبسایت
- بنرها و پیشنهادات برای منطقه خاص
- درستی تگهای hreflang (کد منبع صفحه را باز کنید)
- ریدایرکتها به زیر دامنههای منطقهای (برای مثال، de.site.com به جای site.com)
- بنرهای کوکی (در اتحادیه اروپا بر اساس GDPR الزامی است)
نکته:
در Proxy SwitchyOmega چند پروفایل برای کشورهای مختلف ایجاد کنید: DE، US، GB، CN، BR. این به شما این امکان را میدهد که در 10 ثانیه بین مناطق جابجا شوید و به سرعت تمام چکلیست را بدون مانورهای اضافی طی کنید.
تست از انواع مختلف شبکهها
علاوه بر جغرافیا، مهم است که رفتار اپلیکیشن را بسته به نوع شبکه کاربر تست کنید. این موضوع به ویژه برای محصولات با مخاطب جهانی که بخش قابل توجهی از کاربران از دستگاههای موبایل از طریق شبکههای اپراتوری وارد میشوند، حیاتی است.
شبکههای شرکتی و فایروالها
کاربران از شبکههای شرکتی اغلب از طریق سرورهای پروکسی شرکت و فایروالها کار میکنند که برخی از انواع درخواستها، اتصالات WebSocket یا CDNهای خارجی را مسدود میکنند. برای شبیهسازی چنین شرایطی، تستکنندگان از پروکسیهای مرکز داده با تنظیمات محدود استفاده میکنند — این امکان را میدهد که محیط شرکتی «سخت» را شبیهسازی کنند.
چه چیزی را در این سناریو بررسی کنید: آیا اعلانهای push کار میکنند، آیا فونتها از Google Fonts بارگذاری میشوند (که اغلب توسط فایروالهای شرکتی مسدود میشوند)، آیا احراز هویت از طریق OAuth به درستی کار میکند.
شبکههای موبایل (3G/4G/5G)
از طریق پروکسیهای موبایل، تستکننده نه تنها IP موبایل را دریافت میکند، بلکه شرایط واقعی شبکه موبایل را نیز تجربه میکند: تأخیرهای متفاوت، ویژگیهای NAT، هدرهای خاص درخواستها از اپراتورهای موبایل. برخی از اپلیکیشنها درخواستها را با IP موبایل به طور متفاوتی پردازش میکنند — به عنوان مثال، به جای نمایش نسخه وب، پیشنهاد دانلود اپلیکیشن را میدهند.
پروکسیهای موبایل را با شبیهساز دستگاهها در Chrome DevTools (حالت Device Toolbar) ترکیب کنید — این به شما این امکان را میدهد که محیطی نزدیک به کاربر واقعی ایجاد کنید.
ارائهدهندگان با دسترسی محدود
در برخی کشورها، ارائهدهندگان اینترنت برخی منابع را مسدود میکنند یا ترافیک به رقبای خود را کند میکنند. اگر محصول شما در بازارهایی با اینترنت محدود (چین، ایران، روسیه) کار میکند، تست از طریق پروکسیهای مسکونی از این کشورها تصویر واقعی از دسترسی به سرویس را نشان میدهد.
تست دروازههای پرداخت و ویژگیهای منطقهای
تست پرداخت — یکی از دردناکترین حوزهها برای QA در محصولات بینالمللی است. سیستمهای پرداخت به طور فعال از موقعیت جغرافیایی برای بررسی تقلب استفاده میکنند: اگر IP کاربر با آدرس پرداخت یا کشور کارت مطابقت نداشته باشد، تراکنش ممکن است رد شود یا به عنوان مشکوک علامتگذاری شود.
تستکننده QA باید دقیقاً چنین سناریویی را شبیهسازی کند: با IP از کشوری که کارت تستی صادر شده است وارد شود و تمام جریان پرداخت را طی کند. بدون پروکسی، انجام این کار از یک ماشین برای چندین منطقه غیرممکن است.
چه چیزی را باید از طریق پروکسی در تست پرداخت بررسی کنید
- نمایش روشهای پرداخت موجود (PayPal، Stripe، Klarna، SEPA، PIX — هر منطقه روشهای خاص خود را دارد)
- درستی تبدیل ارز و نمایش کمیسیونها
- عملکرد تأیید 3DS از کشورهای مختلف
- رفتار در صورت عدم تطابق IP و کشور کارت (باید پیام خطای درستی نمایش داده شود)
- مالیاتهای منطقهای (مالیات بر ارزش افزوده در اتحادیه اروپا، GST در استرالیا) — آیا به درستی محاسبه میشوند
- عملکرد روشهای پرداخت منطقهای: iDEAL در هلند، Sofort در آلمان، Boleto در برزیل
تست ویژگیهای منطقهای (GDPR، CCPA و غیره)
الزامات قانونی برای محصولات بسته به کشور کاربر متفاوت است. برای QA مهم است که مطمئن شود اپلیکیشن به درستی حوزه قضایی را شناسایی کرده و قوانین مورد نیاز را اعمال میکند:
- اتحادیه اروپا (GDPR): هنگام ورود با IP اروپایی، باید بنر کوکی با امکان انصراف از ردیابی نمایش داده شود
- کالیفرنیا (CCPA): لینک «Do Not Sell My Personal Information» باید برای کاربران کالیفرنیا نمایش داده شود
- روسیه: اگر دادههای کاربران روسی باید در سرورهای داخل روسیه ذخیره شوند — بررسی کنید که محلیسازی به درستی کار میکند
- چین: آیا سرویسهای خارجی (Google Analytics، Facebook Pixel) هنگام ورود با IP چینی مسدود میشوند و آیا صفحه به دلیل این موضوع خراب میشود
ابزارهای QA با پشتیبانی از پروکسی
پروکسیها را میتوان نه تنها به صورت دستی در مرورگر استفاده کرد، بلکه میتوان آنها را در تستهای خودکار و ابزارهای QA ادغام کرد. گزینههای اصلی را بررسی میکنیم.
Postman
برای تست API از طریق پروکسی در Postman: به Settings → Proxy → بروید و Use System Proxy را فعال کنید یا پروکسی را به صورت دستی مشخص کنید. این امکان را میدهد که بررسی کنید چگونه نقاط پایانی API به درخواستها از کشورهای مختلف پاسخ میدهند — این برای APIهای وابسته به جغرافیا که محتوای متفاوتی را بسته به IP باز میگردانند، актуال است.
Charles Proxy / Fiddler
این ابزارها ترافیک HTTP/HTTPS را ضبط میکنند و خودشان پروکسی هستند. میتوان آنها را طوری تنظیم کرد که ترافیک را از طریق یک سرور پروکسی خارجی (upstream proxy) عبور دهند. این امکان را میدهد که به طور همزمان درخواستها را ضبط و تجزیه و تحلیل کنید و با IP جغرافیایی مورد نیاز تست کنید.
در Charles: Proxy → External Proxy Settings → Use external proxy را فعال کنید و دادههای سرور پروکسی خود را وارد کنید.
Playwright و Selenium
برای تست خودکار، پروکسی در سطح پیکربندی مرورگر متصل میشود. در Playwright این کار از طریق پارامتر proxy هنگام ایجاد زمینه مرورگر انجام میشود. در Selenium — از طریق گزینههای ChromeDriver با مشخص کردن سرور پروکسی. این امکان را میدهد که تستهای مجموعه را از دهها کشور به صورت موازی بدون تنظیمات دستی اجرا کنید.
BrowserStack و Sauce Labs
پلتفرمهای ابری برای تست دارای ابزارهای داخلی برای تست از مناطق مختلف هستند. با این حال، امکانات آنها برای انتخاب ارائهدهنده خاص یا نوع شبکه (موبایل/خانگی) محدود است. پروکسیها انعطافپذیری بیشتری را فراهم میکنند: شما خودتان کشور، شهر، نوع IP و ارائهدهنده را انتخاب میکنید.
k6 و JMeter (تست بار)
برای تست بار از مناطق مختلف، پروکسیهای مرکز داده از طریق پیکربندی HTTP-client متصل میشوند. این امکان را میدهد که بار را از کاربران واقعی از کشورهای مختلف شبیهسازی کنید و بررسی کنید که چگونه CDN و متعادلکنندههای بار با ترافیک جغرافیایی توزیع شده کنار میآیند.
چکلیست: چه چیزی را باید از طریق پروکسی قبل از انتشار بررسی کنید
از این چکلیست برای هر انتشار که شامل مخاطب بینالمللی است استفاده کنید. توصیه میشود حداقل 3–5 منطقه کلیدی محصول خود را بررسی کنید.
📋 چکلیست تست جغرافیایی
محلیسازی و محتوا:
- ☐ زبان رابط کاربری به درستی بر اساس IP شناسایی میشود
- ☐ ارز و فرمتهای عددی به درستی نمایش داده میشوند
- ☐ بنرها و پیشنهادات منطقهای به مخاطب مناسب نمایش داده میشوند
- ☐ بخشهای مسدود شده از کشورهای مربوطه در دسترس نیستند
- ☐ تگهای hreflang به نسخههای منطقهای صحیح اشاره میکنند
- ☐ ریدایرکتها به زیر دامنههای منطقهای به درستی کار میکنند
پرداختها و الزامات قانونی:
- ☐ روشهای پرداخت صحیح برای منطقه در دسترس هستند
- ☐ مالیاتها به درستی محاسبه میشوند
- ☐ بنر کوکی برای کاربران از اتحادیه اروپا نمایش داده میشود
- ☐ لینک CCPA برای کاربران از کالیفرنیا نمایش داده میشود
- ☐ سیاست حفظ حریم خصوصی با الزامات منطقهای مطابقت دارد
عملکرد و دسترسی:
- ☐ صفحات در زمان قابل قبول از مناطق کلیدی بارگذاری میشوند
- ☐ CDN به درستی استاتیک را از نزدیکترین گرهها ارائه میدهد
- ☐ سرویسهای خارجی (تحلیل، چتباتها) در کشورهای هدف مسدود نمیشوند
- ☐ اپلیکیشن هنگام ورود با IP موبایل کار میکند
آزمایشهای A/B و آزمایشات:
- ☐ آزمایشهای هدفگذاری شده جغرافیایی به مخاطب مناسب نمایش داده میشوند
- ☐ کاربران از مناطق مستثنی نسخه کنترل را میبینند
- ☐ پرچمهای ویژگی بر اساس جغرافیا به درستی کار میکنند
اشتباهات رایج در تست از طریق پروکسی
حتی تستکنندگان با تجربه نیز در کار با پروکسی اشتباهاتی مرتکب میشوند. رایجترین آنها را بررسی میکنیم.
اشتباه 1: بررسی نکردن اینکه پروکسی واقعاً کار میکند
قبل از شروع تست، همیشه IP فعلی را در یک منبع مستقل (whatismyip.com، 2ip.ru، ipleak.net) بررسی کنید. گاهی اوقات پروکسی تنظیم شده است، اما مرورگر همچنان از اتصال مستقیم استفاده میکند — به ویژه اگر افزونه فعال نشده باشد یا با تنظیمات سیستمی تداخل داشته باشد.
اشتباه 2: نادیده گرفتن نشتهای DNS
درخواستهای DNS ممکن است از پروکسی عبور کنند و IP واقعی تستکننده را فاش کنند. این موضوع به ویژه در تست مسدودسازیهای جغرافیایی مهم است — وبسایت ممکن است کشور واقعی را بر اساس DNS شناسایی کند، حتی اگر آدرس IP تغییر کرده باشد. نشتهای DNS را از طریق ipleak.net یا dnsleaktest.com بررسی کنید.
اشتباه 3: استفاده از یک پروکسی برای تمام وظایف
پروکسیهای مرکز داده برای تست تجربه کاربری مناسب نیستند — وبسایت ممکن است برای آنها CAPTCHA یا صفحه مسدود شدهای را نمایش دهد که کاربر واقعی هرگز آن را نخواهد دید. از نوع صحیح پروکسی برای هر وظیفه استفاده کنید (به جدول بالا مراجعه کنید).
اشتباه 4: فراموش کردن کش مرورگر
هنگام جابجایی بین موقعیتهای جغرافیایی، مرورگر ممکن است محتوای کش شده از جلسه قبلی را ارائه دهد. همیشه کش و کوکیها را قبل از جابجایی به پروکسی جدید پاک کنید، یا از حالت ناشناس برای هر تست جغرافیایی جدید استفاده کنید.
اشتباه 5: مستند نکردن جلسات تست
هنگام یافتن باگ از طریق پروکسی، حتماً ثبت کنید: کشور و شهر پروکسی، نوع پروکسی (مسکونی/موبایل)، زمان تست، نسخه مرورگر. بدون این دادهها، برای توسعهدهنده دشوار خواهد بود که مشکل را بازتولید کند. یک اسکرینشات از تأیید IP را به گزارش باگ اضافه کنید.
اشتباه 6: اشتباه گرفتن پروکسی و VPN در مستندات
در تیمها اغلب در گزارشهای باگ نوشته میشود «از طریق VPN از آلمان بازتولید شد» — اما VPN و پروکسی به طور متفاوتی عمل میکنند. VPN تمام ترافیک را رمزگذاری میکند و IP را در سطح سیستم عامل تغییر میدهد، در حالی که پروکسی در سطح اپلیکیشن کار میکند. برای برخی از باگها، این یک تفاوت اساسی است. از عبارات دقیق در مستندات استفاده کنید.
نتیجهگیری
پروکسی برای تستکننده QA یک ابزار پایهای برای هر محصول با مخاطب بینالمللی است. آنها به شما این امکان را میدهند که شرایط واقعی کاربران از کشورهای مختلف را شبیهسازی کنید، محتوای وابسته به جغرافیا، دروازههای پرداخت، الزامات قانونی و رفتار CDN را بررسی کنید — همه اینها مستقیماً از محل کار، بدون سفر و ماشینهای دور از منزل.
نکات کلیدی: برای تست تجربه کاربری از پروکسیهای مسکونی استفاده کنید، برای سناریوهای موبایل — از پروکسیهای موبایل، و برای تست بار و API، پروکسیهای مرکز داده مناسب هستند. همیشه IP را قبل از شروع تست بررسی کنید، به نشتهای DNS توجه کنید و جلسات تست را با اشاره به پارامترهای جغرافیایی مستند کنید.
اگر میخواهید تست رفتار وابسته به جغرافیای اپلیکیشن خود را شروع کنید، پیشنهاد میکنیم پروکسیهای مسکونی را امتحان کنید — آنها حداکثر دقت را در شبیهسازی کاربر واقعی از کشور مورد نظر ارائه میدهند و انتخاب جغرافیایی انعطافپذیری را تا حد شهر و ارائهدهنده پشتیبانی میکنند.