Sticky mi, rotating proxy mi: oturuma göre IP modeli nasıl seçilir?

Bu rehber üç oturum modelini (istek başına rotasyon, süreli sticky oturum, statik IP) tanımlar, IP oturum ortasında değiştiğinde neyin bozulduğunu ve IP başına hız sınırlarının seçimi nasıl etkilediğini açıklar. Sonunda senaryo tablosu, karma (hybrid) kurgular ve sticky kimlikleri rotating havuzdan ayıran bir Python örneği vardır. Örneklerde gateway gw.weproxy.com.tr:8989, kimlik bilgileri ise USER ve PASSWORD yer tutucularıdır.

Sticky, rotating ve statik IP arasındaki fark nedir?

Üç model de aynı soruyu farklı yanıtlar: hedef site art arda gelen iki isteği aynı IP’den mi görecek? Proxy türü (residential, mobil, datacenter, ISP) IP’nin nereden geldiğini belirler. Oturum modeli ise o IP’nin ne kadar süre sizinle kalacağını belirler. Tür seçimi için residential, mobil, datacenter ve ISP karşılaştırmasına bakın; bu yazı yalnızca oturum modelini ele alır.

İstek başına rotasyon

Rotating modda gateway her yeni istek veya her yeni bağlantı için havuzdan farklı bir çıkış IP’si seçer. Hedef site 1.000 isteği 1.000 farklı adresten görebilir. Bu, IP başına sayaçları dağıtır ama istekler arasında “aynı kullanıcı” izlenimi oluşmaz.

Pratikte rotasyon çoğu gateway’de bağlantı düzeyinde olur. HTTPS isteğinde istemci proxy’ye CONNECT ile bir tünel açar; aynı keep-alive tüneli yeniden kullanılırsa sonraki istekler aynı çıkıştan gidebilir. İstek başına farklı IP bekliyorsanız her isteği yeni bağlantıyla gönderin.

Süreli sticky oturum

Sticky oturumda bir oturum kimliği (session ID) belirli bir çıkış IP’sine bağlanır. Aynı kimlikle gelen bütün istekler, süre dolana veya çıkış cihazı çevrimdışı olana kadar aynı IP’den çıkar. Süre dolunca aynı kimlik havuzdan yeni bir IP alır.

Residential ve mobil havuzlarda IP’ler gerçek cihazlardan geldiği için sticky süre bir üst sınırdır, garanti değildir. Cihaz ağdan düşerse oturum süresi bitmeden IP değişebilir. Kritik adımları süre sınırının rahatça içine sığacak şekilde planlayın.

Statik IP

Statik proxy’de IP size paket dönemi boyunca atanır ve havuzla paylaşılmaz. Oturum süresi diye bir kavram yoktur; IP siz değiştirene veya paket bitene kadar aynı kalır. Haftalarca aynı kimlikle çalışması gereken hesaplar, IP whitelist isteyen paneller ve uzun süreli otomasyonlar için bu model kullanılır.

Sticky oturum nasıl ayarlanır?

Sağlayıcıların çoğu sticky davranışı iki yoldan biriyle açar. Birincisi oturum kimliğini kullanıcı adına eklemektir: kullanıcı adı, sizin seçtiğiniz bir session ID ve bazen süre veya ülke parametresi taşır. Gateway aynı ID’yi gördükçe aynı çıkışı kullanır. İkincisi port tabanlı ayrımdır: bazı sağlayıcılar belirli port aralıklarını sticky, diğerlerini rotating olarak ayırır.

WeProxy residential ve mobil havuzlarında sticky davranış, kullanıcı adına bir session kimliği eklenerek açılır. Bu yöntemle residential havuzda 24 saate, mobil havuzda 60 dakikaya kadar aynı çıkış IP’si sabitlenebilir. Kullanıcı adının tam biçimi ürüne göre değişir; doğru biçimi müşteri panelindeki bağlantı bilgilerinden kopyalayın, elle tahmin etmeyin.

Session ID seçerken üç kural işe yarar:

1. Bir kimlik, bir ID. Her hesap veya tarayıcı profili kendi session ID’sini kullanmalıdır. İki profil aynı ID’yi paylaşırsa hedef site iki farklı kullanıcıyı aynı IP’den görür.
2. ID’yi kalıcı saklayın. Süreç yeniden başladığında rastgele yeni ID üretirseniz aynı hesap yeni IP ile döner. ID’yi profil kaydıyla birlikte bir dosyada veya veritabanında tutun.
3. Yeni IP gerektiğinde ID’yi değiştirin. IP engellenmişse aynı ID ile tekrar denemek aynı çıkışa döner. Yeni bir ID yeni bir çıkış demektir.

Ayarın çalıştığını doğrulamanın en kısa yolu, aynı session ID ile art arda iki kez çıkış IP’nizi sorgulamaktır. Tarayıcıda My IP aracı bu kontrolü yapar; komut satırında api.ipify.org yeterlidir. İki değer aynıysa oturum sticky çalışıyordur.

Oturum ortasında IP değişirse ne bozulur?

Web uygulamaları kullanıcıyı çerezle tanır, ama birçoğu çerezin hangi IP’den geldiğini de kaydeder. RFC 6265 çerezi IP’ye bağlamaz; IP kontrolünü uygulama ve güvenlik katmanı ekler. Bu yüzden aynı istek, IP değiştiğinde bir sitede sorunsuz geçer, başka bir sitede oturumu düşürür.

Tipik bozulmalar şunlardır:

• Login oturumu düşer. Oturum çerezi IP veya ASN ile eşleştiriliyorsa yeni IP’den gelen istek oturum dışı sayılır. Kullanıcı yeniden giriş sayfasına yönlendirilir veya ek doğrulama istenir.
• Sepet ve checkout kırılır. Sepet sunucu tarafında oturuma bağlıdır. Ödeme adımında IP ve ülke değişirse dolandırıcılık kontrolü işlemi durdurabilir veya sepeti sıfırlayabilir.
• CSRF token reddedilir. Form, sayfayla birlikte üretilen bir token taşır ve bu token oturum çerezine bağlıdır. Oturum IP değişimi nedeniyle yenilenirse eski token geçersiz kalır ve form 403 ile döner. Mekanizma için MDN CSRF açıklamasına bakın.
• Bot korumasının çerezleri boşa gider. Bazı korumalar ilk ziyarette bir doğrulama çerezi verir ve bunu IP ile birlikte değerlendirir. Rotating modda her istek yeni IP’den geldiği için doğrulama her seferinde baştan başlar.
• Risk sinyali birikir. Aynı hesabın birkaç dakika içinde farklı şehir veya ülkelerden görünmesi, hesap güvenliği sistemlerinde “olağan dışı giriş” olarak işaretlenebilir.

Bu sorunların ortak noktası durumdur. Ürün listesi, arama sonucu veya herkese açık fiyat sayfası gibi durumsuz isteklerde IP değişimi hiçbir şeyi bozmaz. Durum taşıyan akışın tamamı aynı IP’den tamamlanmalıdır.

IP başına rate limit rotasyon kararını nasıl etkiler?

Hız sınırları çoğunlukla IP başına tutulur. Sunucu belirli bir sürede aynı adresten gelen istekleri sayar ve eşik aşılınca 429 Too Many Requests döner. RFC 6585 bu kodu tanımlar; sunucu genellikle Retry-After başlığıyla bekleme süresini bildirir.

Sticky ve statik modelde bütün istekler tek IP’nin sayacına yazılır. Bu yüzden sticky oturumda hız, hedefin o IP için kabul ettiği sınırın altında tutulmalıdır. Rotating modda sayaç havuza dağılır; tek bir IP’ye düşen istek sayısı küçük kalır.

Hız sınırı yalnızca IP’ye bağlı değildir. Hesap, oturum çerezi, API anahtarı veya cihaz parmak izi başına sınır koyan siteler de vardır. Bu durumda IP döndürmek sayacı sıfırlamaz; giriş yapmış bir hesabın istekleri hangi IP’den gelirse gelsin aynı hesap sayacına yazılır.

WeProxy paketlerinde thread ve eşzamanlı oturum sınırı yoktur. Bu nedenle 429 aldığınızda sınırı koyan taraf hedef sitedir. Teşhis ve geri çekilme stratejisi için proxy hata kodları rehberine bakın. Hız sınırını havuz büyüterek aşmaya çalışmak, hedefin kullanım şartlarını ihlal ediyorsa çözüm değildir.

Hangi senaryoda sticky, hangisinde rotating kullanılır?

Karar için iki soru sorun: akış durum taşıyor mu ve aynı kimliğin ne kadar süre yaşaması gerekiyor? Aşağıdaki tablo yaygın senaryoları bu iki soruya göre eşler.

Reklam doğrulamada iki farklı ihtiyaç vardır. Bir reklamın farklı bölgelerde nasıl gösterildiğini görmek için rotating uygundur. Bir tıklamanın yönlendirme zincirini baştan sona izlemek içinse zincir boyunca aynı IP gerekir; burada kısa bir sticky oturum kullanılır. SEO, scraping ve reklam işlerinin ayrıntıları kullanım alanları yazısında ve web scraping sayfasında yer alır.

SERP kontrolünde rotasyon IP’yi değiştirir, ülkeyi değiştirmemelidir. Ülke hedeflemesini sabit bırakıp IP’yi döndürün; rastgele ülke, sıralama verisini bozar. Hedefleme seçenekleri için ülke, şehir ve ASN hedefleme rehberine bakın.

Sticky ve rotating birlikte nasıl kullanılır?

Gerçek iş akışlarının çoğu iki modeli birlikte kullanır. Durumsuz kısım rotating havuzdan, durumlu kısım sticky veya statik IP’den çıkar. Bu ayrım hem sayacı dağıtır hem oturumu korur.

Yaygın karma kurgular şunlardır:

• Keşif rotating, detay sticky. Kategori ve liste sayfaları rotating ile taranır. Login veya çok adımlı form gerektiren detay sayfası sticky oturumla açılır.
• Hesap başına sticky, hesaplar arasında farklı IP. Her hesap kendi session ID’siyle tek bir IP’de kalır. Hesaplar birbirinden farklı IP’lerden çıkar; böylece aynı IP’de birden fazla hesap görünmez.
• Statik ana kimlik, rotating yardımcı istekler. Hesap paneli statik IP’den yönetilir. Aynı iş için gereken herkese açık veri (örneğin rakip fiyat listesi) ayrı bir rotating akıştan toplanır.
• Kısa sticky blokları. Oturum gerektirmeyen ama art arda birkaç isteğin aynı IP’den gelmesinin daha doğal göründüğü sitelerde birkaç dakikalık sticky blokları kullanılır; blok bitince yeni ID ile devam edilir.

Karma kurguda en sık hata, iki akışın aynı çerez kavanozunu paylaşmasıdır. Rotating akıştan gelen çerezler sticky oturumun çerezlerine karışırsa site aynı oturumu farklı IP’lerden görür. Her akış kendi HTTP oturumunu ve çerez deposunu kullanmalıdır.

Python’da sticky kimlik ve rotating havuz nasıl kurulur?

Aşağıdaki örnek iki modeli ayrı tutar. Her sticky kimlik kendi session ID’sine ve kendi requests.Session nesnesine sahiptir; çerezler ve bağlantılar o kimlikte kalır. Rotating istekler ise oturum nesnesi kullanmadan, her seferinde yeni bağlantıyla gönderilir.

import uuid
import requests

GATEWAY = "gw.weproxy.com.tr:8989"
PASSWORD = "PASSWORD"
ROTATING_USER = "USER"
# Paneldeki sticky kullanıcı adı biçimini yazın; {sid} oturum kimliğinin yeridir
STICKY_USER_TEMPLATE = "USER_STICKY_FORMAT_{sid}"


def proxy_url(user):
    return f"http://{user}:{PASSWORD}@{GATEWAY}"


class StickyIdentity:
    def __init__(self, name, sid=None):
        self.name = name
        self.sid = sid or uuid.uuid4().hex[:12]  # kalıcı saklayın
        url = proxy_url(STICKY_USER_TEMPLATE.format(sid=self.sid))
        self.session = requests.Session()
        self.session.trust_env = False
        self.session.proxies = {"http": url, "https": url}

    def get(self, url, **kwargs):
        return self.session.get(url, timeout=(10, 30), **kwargs)

    def post(self, url, **kwargs):
        return self.session.post(url, timeout=(10, 30), **kwargs)


def rotating_get(url):
    # Oturum nesnesi yok, keep-alive yok: her çağrı yeni bağlantı
    proxy = proxy_url(ROTATING_USER)
    return requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers={"Connection": "close"},
        timeout=(10, 30),
    )


identities = {name: StickyIdentity(name) for name in ("profile-a", "profile-b")}

for name, identity in identities.items():
    first = identity.get("https://api.ipify.org").text
    second = identity.get("https://api.ipify.org").text
    print(name, first, second, "aynı IP" if first == second else "IP değişti")

for _ in range(3):
    print("rotating:", rotating_get("https://api.ipify.org").text)

STICKY_USER_TEMPLATE satırını paneldeki biçimle değiştirin. Rotating üründe session parametresi olmadan gönderilen istekler havuzdan çıkış alır; paketinizin varsayılan davranışını panelde doğrulayın. trust_env = False, ortamdaki HTTP_PROXY değişkeninin kodunuzdaki proxy’yi ezmesini önler.

Bu yapıda bir hesap bir StickyIdentity nesnesidir. Login, sepet ve form istekleri her zaman o nesnenin get ve post yöntemlerinden gider; CSRF token’ı ve oturum çerezi aynı çerez deposunda kalır. IP engellenirse yeni sid ile yeni bir nesne oluşturun ve login’i baştan yapın. Daha fazla bağlantı örneği için Python entegrasyonu sayfasına bakın. Bağlantı yeniden kullanımının rotasyonu nasıl etkilediği ve httpx ile aiohttp karşılıkları Python ile proxy kullanımı rehberinde anlatılıyor.

Hangi WeProxy ürünü hangi oturum modeline uyar?

Oturum modelini seçtikten sonra ürün seçimi daralır. Aşağıdaki eşleme yalnızca ürün sayfalarında yayımlanan özelliklere dayanır; başlangıç paketleri ve güncel koşullar ilgili ürün sayfasındadır.

Rotating Residential IPv4 iki modeli tek pakette sunar: session ID olmadan rotating, session ID ile sticky. Toplu scraping ile login’li adımları aynı pakette ayırmak isteyen ekipler için uygundur. Statik Residential IPv4, aynı kimliğin günlerce yaşaması gereken hesaplar ve whitelist isteyen paneller içindir. Sticky IPv6 ise IPv6 destekleyen hedeflerde, Hollanda, ABD, Birleşik Krallık, Almanya ve Kanada çıkışlarıyla süresi seçilebilir oturum sunar. Hedefin IPv6 kabul edip etmediğini satın almadan önce IPv4 vs IPv6 proxy rehberindeki testle doğrulayın.

Tüm paketlerde kullanıcı adı / şifre ve IP whitelist kimlik doğrulaması HTTP ve SOCKS5 üzerinde kullanılabilir. Thread ve eşzamanlı oturum sınırı yoktur; sınırı hedef sitenin kendi kuralları belirler.

Sık yapılan hatalar ve kontrol listesi

Oturum modeli hatalarının çoğu birkaç tekrar eden kalıba sığar:

• Login’li akışa rotating bağlamak. Liste taraması rotating kalabilir, ama giriş sonrası her adım sticky olmalıdır.
• Sticky’yi kalıcı sanmak. Sticky süre bir üst sınırdır. Günler süren kimlik için statik IP seçin.
• Tek sticky IP’ye yüksek eşzamanlılık yüklemek. Bütün istekler aynı sayaca yazılır. İşi birden fazla session ID’ye bölün veya hızı düşürün.
• Keep-alive ile rotasyon beklemek. Aynı tünel yeniden kullanılırsa IP değişmeyebilir. Rotating isteklerde yeni bağlantı açın.
• Ülkeyi rastgele bırakmak. SERP ve fiyat işlerinde ülke sabit kalmalı, yalnızca IP dönmelidir.

İşe başlamadan önce kısa bir kontrol listesi:

1. Akış durum taşıyor mu? Taşıyorsa sticky veya statik, taşımıyorsa rotating.
2. Aynı kimlik ne kadar yaşamalı? Dakikalar ve saatler için sticky, günler için statik IP.
3. Her hesap veya profil ayrı bir session ID ve ayrı bir çerez deposu kullanıyor mu?
4. Aynı ID ile iki ardışık sorguda aynı IP dönüyor mu? My IP aracı ile doğrulayın.
5. Hız, hedefin IP ve hesap başına sınırlarının altında mı? Retry-After değerine uyuluyor mu?
6. Otomasyon hedef sitenin şartlarına ve WeProxy kabul edilebilir kullanım kurallarına uygun mu?

Sticky süreklilik, rotating dağılım sağlar. Önce akışın durum taşıyıp taşımadığına, sonra kimliğin ne kadar yaşaması gerektiğine bakın. Bu iki yanıt modeli seçer; proxy türü ve ülke ondan sonra gelir.