Rotating Mobile Proxy

Rotating mobile proxy kullandığınızda istemciniz önce RotatingProxy gateway’ine bağlanır, kimliğini doğrular ve isteği oradan bir mobil operatör ağına bırakır. Hedef sunucu bağlantıyı ofis hattınızdan ya da bulut sunucunuzdan değil, LTE veya 5G abonelerine adres dağıtan bir operatörün IPv4 bloğundan gelmiş gibi görür. Bu ürünü residential ve datacenter seçeneklerinden ayıran şey tam olarak bu ağ kimliğidir. Protokol tarafında fark yoktur: üç ürün de HTTP, HTTPS ve SOCKS5 ile çalışır.

Ağ kimliği tek bir değerden oluşmaz. Hedefin elinde birkaç katman vardır ve her biri testinizi farklı biçimde etkiler. Aşağıdaki tablo, mobil çıkışta hangi katmanın ne gösterdiğini ve QA ya da ölçüm işinde bunun ne anlama geldiğini özetler.

Son satır pratikte sık sorulan bir soruyu yanıtlar: proxy, HTTPS trafiğinizi açıp okumaz. İstemci CONNECT isteğiyle ya da SOCKS5 el sıkışmasıyla bir tünel ister ve TLS oturumu doğrudan hedefle kurulur. Gateway hangi alan adına bağlandığınızı ve ne kadar veri aktardığınızı bilir; içerik uçtan uca şifreli kalır. Test ortamınızda trafiği incelemek istiyorsanız kendi hata ayıklama proxy’nizi zincirin başına koymanız gerekir. Mobil çıkış bu katmanın yerini tutmaz.

IPv4 adresleri kıt olduğu için mobil operatörler abonelerine çoğu zaman doğrudan genel IP vermez. Cihaz operatörün iç ağında özel bir adres alır. İnternete çıkarken taşıyıcı sınıfı NAT, kısaca CGNAT, bu adresi az sayıda genel IPv4 adresinden birine ve çoğu kurulumda o adresin bir port aralığına eşler. RFC 6598 bu iç katman için ayrı bir paylaşımlı adres alanı tanımlar, RFC 6888 ise CGNAT cihazlarından beklenen davranışları sıralar. Sonuç basittir: aynı anda çok sayıda gerçek abone aynı genel IP’yi paylaşabilir.

Bu yapı rotating mobile proxy kullanıcısı için iki yönlü sonuç doğurur. İlk yönü avantaj gibi görünür. Bir web sitesi tek bir mobil IP’yi tamamen engellerse, o IP’nin arkasındaki gerçek kullanıcıları da dışarıda bırakma riskini alır. Bu nedenle pek çok sistem mobil adreslere karşı kalıcı IP engeli yerine daha yumuşak önlemler kullanma eğilimindedir. Bunun bir garanti olmadığını, yalnızca genel bir eğilim olduğunu not edin; hedef sistemin nasıl davranacağını ancak kendi ölçümünüz gösterir.

İkinci yönü sık gözden kaçar: paylaşımlı IP’nin itibarı da paylaşımlıdır. Aynı adresi o anda kullanan başka bir abonenin davranışı, sizin isteğinizin nasıl karşılanacağını etkileyebilir. IP başına hız sınırı uygulayan bir API, siz tek istek atmış olsanız bile sınırın bir kısmını başkaları tarafından tüketilmiş halde bulabilir. Test sonuçlarınızda açıklanamayan tekil 429 yanıtları ya da ek doğrulama ekranları görüyorsanız ilk şüpheli kodunuz değil, paylaşılan adresin o anki geçmişi olabilir.

CGNAT’ın ölçüme bir etkisi daha vardır. Sunucu loglarında ve analitikte tek IP’den gelen trafik tek kullanıcı anlamına gelmez. Kendi uygulamanızın analitiğinde “IP başına oturum” gibi metrikler kullanıyorsanız, mobil test trafiğinin bu metrikleri bozmaması için test isteklerini bir başlıkla ya da test hesabıyla etiketleyin ve raporlamada ayrı tutun.

Mobil uygulama ve mobil web QA ekiplerinin en sık düştüğü tuzak, proxy’yi “cihazı o ülkeye taşıyan” bir araç gibi görmektir. Oysa proxy yalnız ağ katmanındaki çıkış noktasını değiştirir. Uygulamanız konum ya da pazar kararını başka bir sinyalden alıyorsa, Türkiye’den çıkan bir mobil IP kullansanız bile ekranda Almanya içeriği görmeye devam edebilirsiniz. Bu bir ürün hatası değil, test tasarımının eksik kaldığının işaretidir.

Aşağıdaki tablo, mobil bir istemcinin coğrafya ve pazar belirlerken kullandığı yaygın sinyalleri, rotating mobile proxy’nin bunlardan hangisini etkilediğini ve diğerlerini testte nasıl kontrol edeceğinizi gösterir.

Bu tablodan çıkan pratik yöntem, sinyalleri tek tek değiştirerek uygulamanızın kararı neye göre verdiğini bulmaktır. Önce yalnız çıkış IP’sini değiştirin; cihaz dili ve hesap ülkesi sabit kalsın. İçerik değişiyorsa kararı IP veriyordur. Değişmiyorsa sırayla locale, mağaza ülkesi ve hesap ülkesini değiştirin. Bu ayrıştırma bir kez yapıldığında, hangi test vakasının gerçekten mobil çıkışa ihtiyaç duyduğu da netleşir. Bu liste kısaldıkça GB bütçesi de doğrudan küçülür.

Aşağıdaki sıra, bir mobil web ya da uygulama testini rotating mobile çıkışla ilk kez kuran ekip için tasarlandı. Her adım bir öncekinin doğru çalıştığını varsayar; bir adım başarısızsa sonrakine geçmeden sorunu çözün.

1. Kapsamı yazın: hangi ülkeler, hangi ekranlar ve önceki bölümdeki tabloya göre hangi sinyaller test edilecek. Ürünün kapsaması 180+ ülke olarak belirtilir; ülkeleri ürün sayfasındaki doğrulanmış lokasyon listesinden seçin.
2. Panelden bağlantı bilgilerini alın: kimlik doğrulama yöntemi, protokol (HTTP, HTTPS veya SOCKS5), oturum türü (sticky ya da rotating) ve ülke seçiminin nasıl yapıldığı. Bu değerleri tahmin etmeyin, panelde ve sipariş adımında gösterildiği haliyle kullanın.
3. Komut satırından doğrulayın: aşağıdaki kod bloğuyla birkaç ardışık istek atın; durum kodunu, yanıt boyutunu ve çıkış IP’sini görün. Rotating modda IP’nin değiştiğini, sticky modda sabit kaldığını burada teyit edin.
4. Tarayıcı tabanlı mobil web testini proxy ile başlatın: Playwright gibi bir araçta mobil cihaz profili, proxy ayarı ve kaynak filtresi birlikte tanımlanır. Örnek betik trafik tasarrufu bölümündedir.
5. Android emülatörünü proxy ile açın: emülatörün -http-proxy parametresi tüm TCP bağlantılarını verilen proxy üzerinden geçirir. iOS Simulator ayrı bir proxy ayarı tutmaz, Mac’in sistem ağ ayarlarındaki proxy’yi kullanır.
6. Gerçek cihazda Wi-Fi ağının gelişmiş ayarlarından manuel proxy tanımlayın. iOS’ta bu ekranda kimlik doğrulama seçeneği vardır; Android’in ekranında ise kullanıcı adı ve şifre alanı yoktur. Android için panelinizde IP whitelist seçeneği varsa onu kullanın ya da test makinesinde kimlik doğrulamayı üstlenen yerel bir aktarma proxy’si çalıştırın.
7. Uygulamanızın sistem proxy’sini gerçekten okuduğunu doğrulayın. Örneğin Flutter uygulamalarının kullandığı Dart HttpClient, cihazın proxy ayarını kendiliğinden uygulamaz; test derlemesinde proxy açıkça tanımlanmalıdır. Kendi ağ katmanınızı yazdıysanız aynı kontrolü orada da yapın.
8. İlk gün ölçün: bir tam test koşusunun kaç megabayt harcadığını kaydedin. Paket seçimini bu ölçümle yapın, tahminle değil.

# HEDEF_URL: çıkış IP’sini düz metin olarak döndüren kendi uç noktanız
# Şifrede özel karakter varsa URL kodlamasıyla yazın (ör. @ yerine %40)

# 1) Beş ardışık istek: rotating modda IP değişmeli, sticky modda sabit kalmalı
for i in 1 2 3 4 5; do
  curl -s -x http://KULLANICI:ŞİFRE@GATEWAY:PORT -w "  | durum %{http_code} | %{size_download} bayt | %{time_total} sn\n" HEDEF_URL
done

# 2) SOCKS5 ile alan adını proxy tarafında çözdürmek (socks5h)
curl -s -x socks5h://KULLANICI:ŞİFRE@GATEWAY:PORT HEDEF_URL

# 3) Android emülatörünü mobil çıkış üzerinden başlatmak
emulator -avd TEST_CIHAZI -http-proxy http://KULLANICI:ŞİFRE@GATEWAY:PORT

Ürün sticky ve rotating oturum seçenekleriyle sunulur. Hangisini seçeceğiniz ürünün değil, test vakasının özelliğidir. Kural kısaca şudur: sunucu tarafında durum taşıyan, yani oturum çerezi, sepet, ödeme belirteci ya da cihaz doğrulaması içeren akışlar tek IP’de tamamlanmalı; birbirinden bağımsız tekil kontroller ise IP değiştirerek yapılabilir. Sticky oturumun aynı IP’yi ne kadar süre koruduğunu ve modun bağlantı bilgisinde nasıl seçildiğini panelde ve sipariş adımında kontrol edin; test süresini bu değere göre planlayın.

Tabloda dikkat çeken nokta, rotating modun yalnızca tekil ve bağımsız gözlemlerde öne çıkmasıdır. Mobil QA’de akışların çoğu durum taşıdığı için sticky mod daha sık kullanılır; rotasyon ise örneklem çeşitliliği gereken ölçümlerde değer kazanır. İki modu aynı test paketinde birlikte kullanacaksanız, her test vakasının hangi modla koştuğunu raporlara yazdırın. Aksi halde başarısız bir vakanın düzenekten mi üründen mi kaynaklandığını ayırmak zorlaşır.

Rotating Mobile paketleri GB bazlıdır, tek seferlik ödenir ve süre sınırı yoktur: satın aldığınız kota bitene kadar kullanılır. Paket listesi 2 GB ile 1000 GB arasında sekiz kademeden oluşur. Fiyatı doğru okumanın yolu toplam tutara değil GB başına maliyete bakmaktır. Aşağıdaki son sütun, katalog fiyatının paket boyutuna bölünmesiyle hesaplanmıştır.

Tablodan üç sonuç çıkar. Birincisi, 10, 20 ve 50 GB paketlerin birim fiyatı aynıdır; 50 GB almak 10 GB’a göre birim maliyeti düşürmez, yalnız daha seyrek sipariş vermenizi sağlar. İkincisi, birim fiyattaki ilk gerçek düşüş 100 GB kademesindedir: 2,50 USD’den 2,25 USD’ye inmek yüzde 10’luk bir farktır. Somut olarak 100 GB’ı tek pakette almak 225 USD, on adet 10 GB paketle almak 250 USD tutar. Üçüncüsü, 100 GB’tan sonra düşüş yavaşlar. 500 GB’ı beş adet 100 GB paket yerine tek seferde almak 1.125 USD yerine 1.100 USD, yani yalnız 25 USD fark yaratır. 1000 GB paket ise on adet 100 GB pakete göre 150 USD daha düşüktür.

2 GB paket listede “Karşılama 1+1” etiketiyle görünür ve katalogdaki en düşük GB başı fiyata sahiptir. Kampanya koşullarını sipariş adımında kontrol edin; bu sayfa koşulları yorumlamaz. Bu paketin asıl değeri fiyatından çok pilot ölçüme uygun olmasıdır: gerçek test koşunuzun GB tüketimini düşük maliyetle ölçüp büyük paketi bu veriye göre seçebilirsiniz.

Rakamların gerçek bir plana nasıl dönüştüğünü görmek için bir e-ticaret şirketinin QA ekibini ele alalım. Ekip kendi mobil web ödeme akışını ve mobil uygulamasının API’sini Türkiye, Almanya ve Birleşik Krallık için test ediyor. Amaç, her ülkede doğru ödeme yöntemlerinin, para biriminin ve kargo seçeneklerinin göründüğünü doğrulamak. Aşağıdaki değerlerin tamamı varsayımdır; kendi ölçümünüzle değiştirmeniz gerekir.

• Varsayım 1: Mobil web ödeme akışı 6 ekrandan oluşuyor ve görseller dahil ekran başına ortalama 1,5 MB veri aktarılıyor; akış başına 9 MB.
• Varsayım 2: Her ülkede 2 cihaz profili (küçük ve büyük ekran) ve günde 4 koşu var; günde 3 × 2 × 4 = 24 akış.
• Varsayım 3: Ayda 22 iş günü test koşuluyor.
• Varsayım 4: API test paketi 120 çağrıdan oluşuyor; çağrı başına başlıklar dahil ortalama 25 KB, paket başına 3 MB. Ülke başına günde 4 koşu var.
• Varsayım 5: Yeniden denemeler, yönlendirmeler ve beklenmeyen trafik için yüzde 25 pay ekleniyor.
• Varsayım 6: Hesapta 1 GB = 1000 MB alınıyor; ölçüm 1024 ile yapılsa bile bu tercih tahmini güvenli tarafta bırakır.
• Varsayım 7 (optimize senaryo): Günlük 4 koşudan yalnız biri ekran görüntüsü alan görsel koşu. Diğer üçünde görsel, video ve yazı tipi istekleri engelleniyor ve ekran başına aktarım 0,3 MB’a iniyor.

Optimizasyonsuz senaryoda ayda yaklaşık 6,9 GB tüketiliyor. Bu tüketim için 100 GB paket almak 14 aydan uzun bir kota stoku demektir; 2,25 USD’lik birim fiyat avantajı bu kadar uzun bir ön ödemeyi çoğu zaman haklı çıkarmaz. 10 GB paketle başlayıp ölçüm doğrulandıktan sonra boyutu büyütmek daha mantıklıdır. Süre sınırı olmadığından artan kota kaybolmaz, ama test kapsamınız değişirse elinizde atıl kota kalabilir.

Kaynak filtresi tek başına aylık tüketimi yüzde 51 civarında azaltıyor: 6,93 GB’tan 3,37 GB’a. Filtre testin doğruluğunu bozmaz, çünkü işlevsel koşular ödeme yöntemlerinin listelenip listelenmediğine bakar, görsellerin piksellerine bakmaz. Görsel regresyona ayrılan tek koşu tam sayfayı yüklemeye devam eder.

Bir adım daha atılabilir. Ekip sinyal ayrıştırması sonucunda ödeme yöntemi listesinin IP’ye değil hesap ülkesine göre belirlendiğini, yalnız kargo seçeneklerinin IP’ye baktığını tespit ederse, ödeme ekranlarını residential ya da datacenter çıkıştan koşup mobil çıkışı yalnız kargo adımına ayırabilir. Bu durumda karşılaştırma tablosundaki oranlar doğrudan devreye girer: mobil olmak zorunda olmayan her GB, residential’de yaklaşık yarı, datacenter’da yaklaşık dörtte bir maliyetle taşınır.

GB bazlı bir üründe tasarruf, testten bir şey çıkarmak değil, testin ihtiyaç duymadığı baytları mobil çıkıştan geçirmemek demektir. Aşağıdaki teknikler kabaca etkisi büyükten küçüğe sıralanmıştır; her birinin test geçerliliğine olası etkisini de not ettik.

• Kaynak filtresi: İşlevsel koşularda görsel, video ve yazı tipi isteklerini tarayıcı düzeyinde iptal edin. Görsel regresyon koşularında filtre kapalı kalmalıdır.
• Bölünmüş yönlendirme: Yalnız IP’ye duyarlı alan adlarını, örneğin uygulamanızın API’sini, mobil çıkıştan; CDN’deki statik dosyaları doğrudan bağlantıdan geçirin. Bir PAC dosyası bunu tarayıcı ya da cihaz düzeyinde yapar. Bedeli, statik dosyaların CDN tarafında test makinesinin konumuna göre yönlendirilmesidir; CDN davranışını test etmiyorsanız sorun değildir.
• Önbellek: Aynı koşu içinde tarayıcı önbelleğini kapatmayın. Her ekranda yeniden indirilen ortak JavaScript ve CSS dosyaları, fark edilmeden kotanın büyük kısmını tüketebilir. İstek yakalayan test araçlarının önbelleği kapatıp kapatmadığını da kontrol edin.
• Sıkıştırma: İstemcinizin Accept-Encoding başlığıyla gzip veya br desteğini bildirdiğinden emin olun. Elle yazılmış API istemcilerinde bu başlık bazen eksik kalır.
• Koşullu istekler: Değişmeyen kaynaklar için ETag ve If-None-Match kullanan istemciler, 304 yanıtı aldığında gövdeyi yeniden indirmez.
• Örnekleme: Kendi reklam yerleşimleriniz veya içerik varyasyonları gibi istatistiksel kontrollerde her kombinasyonu her gün taramak yerine dönüşümlü örneklem kullanın; kapsam haftanın sonunda tamamlanır.
• Yeniden deneme disiplini: Başarısız isteği sınırsız tekrarlayan bir döngü, kotayı sessizce tüketen en yaygın hatadır. Üst sınır ve artan bekleme süresi tanımlayın.
• Arka plan trafiği: Gerçek cihazda Wi-Fi proxy’si tanımlıysa işletim sistemi güncellemeleri, uygulama mağazası ve diğer uygulamalar da aynı çıkıştan geçebilir. Test cihazında otomatik güncellemeleri ve gereksiz uygulamaları kapatın.

Aşağıdaki betik ilk ve en etkili tekniği uygular: mobil cihaz profiliyle bir sayfayı açar, işlevsel koşuda ağır kaynakları engeller ve proxy üzerinden aktarılan toplam veriyi yazdırır. Locale ve saat dilimi, test edilen ülkenin senaryosuna göre bilinçli olarak ayarlanır; böylece içerik değiştiğinde hangi sinyalin etkili olduğunu ayırabilirsiniz.

from playwright.sync_api import sync_playwright

AGIR_TURLER = {"image", "media", "font"}
GORSEL_KOSU = False  # ekran görüntüsü alınacak koşuda True yapın
toplam_bayt = 0


def filtre(route):
    if not GORSEL_KOSU and route.request.resource_type in AGIR_TURLER:
        return route.abort()
    return route.continue_()


def say(istek):
    global toplam_bayt
    # istek ve yanıtın başlık + gövde boyutları (sıkıştırılmış aktarım)
    toplam_bayt += sum(max(v, 0) for v in istek.sizes().values())


with sync_playwright() as p:
    tarayici = p.chromium.launch(proxy={
        "server": "http://GATEWAY:PORT",
        "username": "KULLANICI",
        "password": "ŞİFRE",
    })
    baglam = tarayici.new_context(
        **p.devices["Pixel 5"], locale="tr-TR", timezone_id="Europe/Istanbul"
    )
    sayfa = baglam.new_page()
    sayfa.route("**/*", filtre)
    sayfa.on("requestfinished", say)
    sayfa.goto("HEDEF_URL", wait_until="networkidle", timeout=60000)
    print(f"Aktarılan veri: {toplam_bayt / 1_000_000:.2f} MB")
    tarayici.close()

Betiğin çıktısı, örnek hesaptaki “ekran başına MB” varsayımının sizin uygulamanızdaki gerçek karşılığını verir. Playwright’ın bildirdiği yanıt gövdesi boyutu sıkıştırılmış aktarım boyutudur; bu yüzden GB tahmini için doğru ölçüdür. Yalnız bir noktaya dikkat edin: Playwright’ta route() ile istek yakalamak tarayıcının HTTP önbelleğini kapatır; bu yüzden betiğin ölçtüğü değer önbellekli bir koşunun üst sınırıdır ve ekran başına MB varsayımını biraz şişirebilir. Önbelleğin etkisini görmek için filtresiz koşuyu route() olmadan ayrıca ölçün ve iki değeri karşılaştırın. GORSEL_KOSU değerini bir kez True, bir kez False yaparak filtrenin sizin sayfalarınızda ne kadar tasarruf ettiğini de doğrudan ölçebilirsiniz.

function FindProxyForURL(url, host) {
  // Ülke kararını veren API mobil çıkıştan geçer
  if (dnsDomainIs(host, "api.ornek-uygulama.test")) {
    return "PROXY GATEWAY:PORT";
  }
  // Statik dosyalar, CDN ve diğer her şey doğrudan bağlanır
  return "DIRECT";
}

PAC dosyası kimlik bilgisi taşımaz. Tarayıcı kimlik doğrulamasını ilk bağlantıda sorar; otomatik testlerde bu sorun, panelinizde varsa IP whitelist ile ya da kimlik doğrulamayı üstlenen yerel bir aktarma proxy’siyle çözülür.

RotatingProxy’de rotasyonlu IPv4 çıkış üç ağ türünde sunulur ve üçü de aynı protokolleri, aynı GB bazlı ve süre sınırsız faturalama modelini paylaşır. Fark ağ kimliğinde ve fiyatta olduğu için karar, test adımının hangi ağ kimliğine ihtiyaç duyduğuna göre verilir. Aşağıdaki tablo tipik ihtiyaçları ürünle eşleştirir.

Bu tabloyu tek seferlik bir seçim olarak değil, katmanlı bir mimari olarak düşünmek daha verimlidir. Test paketinizi ağ kimliğine göre üç gruba ayırın: ağ türünden bağımsız olanlar datacenter’da, konut ağı yeterli olanlar residential’da, operatör IP’si şart olanlar mobilde koşsun. Üç ürün aynı protokolleri desteklediği için gruplar arasındaki fark çoğu zaman yalnız bağlantı bilgisidir. Test kodunuzda çıkışı bir yapılandırma değeri olarak tutarsanız, bir vakayı gruplar arasında taşımak tek satırlık bir değişiklik olur.

Mobil çıkışın gerçekten gerekli olup olmadığını anlamanın en güvenilir yolu küçük bir karşılaştırmalı denemedir. Aynı test vakasını aynı ülkeden önce residential, sonra mobil çıkışla koşun ve yanıtları karşılaştırın. İçerik, yönlendirme veya fiyat değişmiyorsa o vaka için mobil çıkışa ödediğiniz fark ölçüme bir şey eklemiyor demektir. Değişiyorsa, farkın kaynağını belgeleyin; bu belge ileride bütçe tartışmalarında mobil kotanın neden gerekli olduğunu gösteren en güçlü dayanak olur.

Genel bağlantı sorunlarının yanında, mobil çıkışla çalışırken daha sık karşılaşılan durumlar vardır. Aşağıdaki tablo belirtiyi, olası nedeni ve çözüm yolunu birlikte verir.

CGNAT bölümündeki tespit etik açıdan da önemlidir. Mobil bir adresi kullandığınızda o adresi aynı anda gerçek aboneler de kullanıyor olabilir. Bir hedef sistemi agresif istek hızıyla zorladığınızda verdiğiniz zarar yalnız size dönmez; aynı adresin arkasındaki insanlar da ek doğrulama ekranlarıyla ya da geçici kısıtlarla karşılaşabilir. Mobil çıkışla çalışırken istek hızını sabit hat kullanımından daha temkinli tutmak bu yüzden hem teknik hem etik bir gerekliliktir.

• Yalnız kendi uygulamanızı, kendi kampanyalarınızı ya da test etme yetkiniz olan sistemleri test edin. Reklam doğrulama sonuçlarını marka koruma ve kalite kontrol kapsamında yorumlayın.
• Hedef sitenin robots.txt dosyasına, kullanım koşullarına ve yayımlanmış hız sınırlarına uyun. Sınır yayımlanmamışsa düşük hızla başlayın ve hata oranı arttığında yavaşlayın.
• Başka bir platformun bot korumasını, CAPTCHA’sını ya da cihaz doğrulamasını atlatmak için kullanmayın.
• Test hesaplarında sentetik veri kullanın. Ekran görüntüleri ve loglar kişisel veri içeriyorsa KVKK kapsamındaki saklama ve erişim kurallarınızı test çıktılarına da uygulayın.
• Test trafiğini üretim analitiğinden ayırın; başlık, test hesabı ya da ayrı ortamla etiketleyin.

Aşağıdaki liste, bu sayfadaki adımları uygulamaya dökmek için kısa bir kontrol aracıdır. Her maddeyi işaretlemeden bir sonraki aşamaya geçmemek hem kotayı hem ekip zamanını korur.

• Test edilecek ülkeler ürün sayfasındaki doğrulanmış lokasyon listesinde mi?
• Her test vakası için kararı veren sinyal (IP, locale, mağaza ülkesi, hesap ülkesi, GPS) belirlendi mi?
• Yalnız operatör IP’sinin sonucu değiştirdiği vakalar mobil gruba, diğerleri residential veya datacenter grubuna ayrıldı mı?
• Panelde kimlik doğrulama yöntemi, protokol, oturum türü ve ülke seçimi kontrol edildi mi?
• Komut satırı testinde rotating modda IP değişimi, sticky modda sabitlik teyit edildi mi?
• SOCKS5 kullanılıyorsa socks5h ile uzak DNS çözümlemesi ayarlandı mı?
• Uygulamanın ağ kütüphanesinin proxy’yi gerçekten kullandığı doğrulandı mı?
• Bir tam koşunun MB tüketimi ölçüldü ve aylık tahmine yüzde 20 ile 30 arasında pay eklendi mi?
• Paket boyutu GB başı fiyat kademelerine göre seçildi mi (10, 20 ve 50 GB aynı birim fiyatta; ilk düşüş 100 GB’ta)?
• İşlevsel koşularda kaynak filtresi, tüm koşularda yeniden deneme üst sınırı tanımlı mı?
• Gerçek cihazda arka plan trafiği ve otomatik güncellemeler kapatıldı mı?
• İstek hızı, hedefin koşulları ve paylaşımlı IP gerçeği dikkate alınarak sınırlandı mı?
• Test trafiği üretim analitiğinden ayrılacak şekilde etiketlendi mi?

İlk haftanın sonunda gerçek tüketim verisi elinizde olur. Paket boyutunu ve test vakalarının ürünler arasındaki dağılımını bu veriye göre güncellemek, bir sonraki siparişi tahminden ölçüme taşır. Rotating mobile proxy bütçesi en verimli halini, yalnız operatör IP’sine gerçekten ihtiyaç duyan adımları taşıdığında alır.