Nodetonet sticky oturumları ile upstream sticky oturumları arasındaki fark nedir?

Nodetonet sticky oturumları, X-Session header'ına göre bir istek akışını aynı backend bağlantısına (upstream gateway veya mobil cihaz) sabitler. Upstream sticky oturumları ise o bağlantıyı upstream sağlayıcının kendi oturum mekanizmasını kullanarak belirli bir çıkış IP'sine sabitler. Bunlar ayrı TTL'lere sahip bağımsız katmanlardır. Her birini ayrı ayrı veya ikisini birlikte kullanabilirsiniz.

Upstream kullanırken yeni bir çıkış IP'sine nasıl dönerim?

Her iki oturum katmanını hemen düşürmek ve taze bir upstream çekimini zorlamak için sonraki isteğe X-Rotate: 1 header'ı gönderin. Alternatif olarak X-Session değerini değiştirin — yeni değer yeni bir upstream oturum belirtecine ve dolayısıyla yeni bir çıkış IP'sine eşlenir. Sabit upstream dizesi için (X-Session yok) dizedeki oturum değiştiricisini düzenleyin ve proxy'yi kaydedin.

Aynı X-Session header'ını kullansam da IP'm değişiyor. Neden?

En yaygın nedenler şunlardır: (1) upstream'in TTL'i sona erdi ve sessizce yeni bir çıkışa döndü, (2) upstream'in bölgesel havuzu tükendi ve orijinal çıkış kullanılamaz hale geldi, (3) bir upstream auth hatası edge'in bağlantıyı düşürüp yeniden kurmasına neden oldu ve oturumu sıfırladı. Değişikliği algılamak için what-is-my-ip uç noktası kullanın ve upstream yeniden çevirme işaretçisi için yanıt gecikmesini kontrol edin.

Upstream ile SOCKS5 üzerinden sticky oturumlar kullanabilir miyim?

Evet. SOCKS5'te HTTP header'ları olmadığı için oturumu auth kullanıcı adına gömin, örneğin uXXX-session-benim-oturumum. Nodetonet bunu orada okur ve aynı iki katmanlı sticky mantığını uygular. SOCKS5 istemcilerinin çözümlenmiş bağlantıyı çoğunlukla önbelleğe aldığını ve dolayısıyla oturumun bağlantının ömrü boyunca bağlanma zamanında etkili şekilde sabitlendiğini unutmayın.

Nodetonet'in 10 dakikalık TTL'i sona erdiğinde ancak upstream oturumu hâlâ yaşıyorsa ne olur?

Nodetonet eşleştirmesini düşürür, bu nedenle aynı X-Session değeriyle gelen sonraki istek yeni bir oturum olarak işlenir. Ancak türettiğimiz upstream oturum belirteci X-Session değerinizden deterministik olduğundan, upstream aynı belirteci tanıyabilir ve kendi TTL'inin geri kalanı boyunca orijinal çıkış IP'sini vermeye devam edebilir. Pratikte, upstream daha uzun yaşadığında IP'niz Nodetonet süre sonu üzerinde sık sık korunur.

Upstream ile web scraping için sticky oturumlar mı yoksa rotating proxy mi kullanmalıyım?

Hedefe bağlıdır. Durumsuz tarama için — birçok bağımsız URL getirme — maksimum IP çeşitliliği için rotating mod kullanın (X-Session header'ı yok). Durum tutan akışlar için — giriş, ödeme, çok adımlı formlar — tüm akış boyunca aynı çıkış IP'sini korumak için sticky kullanın. Birçok scraping iş akışı ikisini karıştırır: keşif için rotate edin, durumu koruması gereken her oturum için sticky'ye geçin. Ayrıntılı bir döküm için rotating mobil proxy ne zaman kullanılır yazısına bakın.

Upstream ile sticky sessionlar — iki stickiness katmanı, tek kararlı IP

Bir upstream sağlayıcı işin içine girdiğinde stickiness biraz daha ilginç bir hal alır. Artık yolda iki sticky-session sistemi var: edge'imizde yaşayan Nodetonet'inki ve upstream'in gateway'inde yaşayan upstream'inki. İkisi de aynı işi yapıyor — bir istek akışını bir süre tek bir çıkış IP'sine sabitleme — ama her birinin kendi TTL'i, kendi anahtarlama şeması ve kendi "rotate" tanımı var. Bunları hizalamazsanız şaşırtıcı davranışlarla karşılaşırsınız: oturum ortasında kayıyor gibi görünen bir IP, her istekte taze bir upstream bağlantısı veya istediğinizde hiç rotate etmeyen bir oturum. Bu rehber her katmanda tam olarak ne olduğunu, ikisini birlikte temiz şekilde nasıl yapılandıracağınızı ve bir şeyler yanlış hissettirdiğinde neye bakacağınızı açıklıyor.

Genel olarak sticky oturumlara yeniyseniz önce upstream olmadan sticky oturumlar yazısını okuyun, sonra buraya dönün. Henüz bir upstream kurmadıysanız upstream residential yönlendirme yazısına bakın.

İki katman, sırasıyla

Upstream'i olan bir tünel üzerinden giden her istek, birbiri ardına iki sticky-session kararından geçer:

istemci
  → Nodetonet edge  (1. katman — hangi backend'i seçer)
  → upstream gateway  (2. katman — hangi çıkış IP'sini seçer)
  → çıkış IP
  → hedef site

1. Katman — Nodetonet'in sticky map'i. Edge, X-Session header'ına (veya oturum-etiketli kullanıcı adına, örn. user-session-abc) bakar. Bu değerden kararlı bir anahtar türetir ve aynı anahtarı taşıyan her isteği aynı backend bağlantısına yönlendirir. Upstream olmadan o backend eşleştirilmiş bir mobil cihaz olur. Upstream yapılandırılmışsa backend, o anahtarla ilişkilendirilmiş upstream gateway bağlantısıdır.

2. Katman — upstream'in sticky map'i. Upstream gateway kendi oturum göstergesine bakar — neredeyse her zaman proxy kullanıcı adına gömülü bir değiştirici — ve o oturumu belirli bir çıkış IP'sine kendi TTL'i süresince sabitler. Nodetonet kullanıcı adını değiştirmeden iletir, bu nedenle yapılandırdığınız herhangi bir upstream kullanıcı-adı değiştiricisi upstream'e değişmeden akar.

Bu iki-hop modelini anlamak bu rehberdeki her şeyin anahtarıdır. Her katman bağımsız olarak yapılandırılabilir ve iki TTL bağımsız sayaçlardır.

Temiz durum — tüm işi upstream'e yaptırın

Tek hedefiniz "sonraki N dakika boyunca aynı çıkış IP'si" ise ve bu pencereyi kapatmak için upstream'in TTL'ine güveniyorsanız, en basit yaklaşım oturumu tamamen upstream katmanında sabitlemek ve Nodetonet sticky'sini hiç kullanmamaktır:

# Proxy yapılandırmasına gömülü örnek upstream dizesi
gate.example-upstream.com:7000:user-acct-country-de-session-abc123:pass

Tünel üzerinden gönderdiğiniz her istek upstream'e o aynı kullanıcı adıyla ulaşır. Upstream aynı oturum belirtecini görür, size varsayılan TTL'i boyunca aynı çıkış IP'sini verir ve Nodetonet sadece byte'ları iletir, sticky işlemi yapmaz. Rotate etmek için upstream dizesindeki session-abc123 kısmını değiştirin ve kaydedin. Hemen sonraki istek taze bir çıkış alır.

Bu yaklaşım, kendi oturum durumlarını yöneten komut dosyaları ve araçlar için uygundur — çalışma başına kararlı bir IP'ye ihtiyaç duyan scrape işleri veya tek bir operatörün oturum yaşam döngüsünü açıkça yönettiği otomasyon.

Dinamik durum — Nodetonet üzerinden istemci başına oturum

Birden fazla bağımsız istemcinin — her biri kendi oturum header'ıyla tanımlı — N ayrı proxy kaydetmeden aynı anda farklı upstream çıkışlarına yönlendirilmesini isterseniz ne olur? İşte burada her iki katman iş birliği yapar.

HTTP/HTTPS'de X-Session: foo header'ı gönderirsiniz ya da SOCKS5 auth kullanıcı adına uXXX-session-foo olarak gömersiniz. Nodetonet'in edge'i bu değerden kararlı bir anahtar türetir ve upstream'e oturum başına bir tanımlayıcı içeren değiştirilmiş bir kullanıcı adıyla iletir. Sizin tarafınızdaki farklı bir X-Session değeri, upstream tarafında farklı bir oturum belirteci üretir ve farklı çıkış IP'leri alırsınız.

Eşleştirme deterministik ve sticky'dir: aynı X-Session: foo her zaman aynı upstream oturum belirtecine eşlenir, bu nedenle o eşleştirmenin ömrü boyunca güvenilir şekilde aynı çıkış IP'sini alırsınız. Varsayılan eşleştirme TTL'imiz 10 dakikadır — bundan sonra giriş düşülür ve aynı X-Session ile sonraki istek sıfırdan başlar.

Oturum yaklaşımı	Oturum belirtecini kim yönetir	En iyi kullanım	Rotasyon mekanizması
Sadece upstream (sabit dize)	Siz, proxy yapılandırmasında statik olarak	Tek-thread işler, operatör-kontrollü rotasyon	Upstream dizesini düzenle, proxy'yi kaydet
Nodetonet X-Session (dinamik)	İstemciniz, istek veya akış başına	N proxy olmadan çoklu-istemci, akış başına stickiness	`X-Session` değerini değiştir veya `X-Rotate: 1` gönder
Oturum header'ı yok	Hiçbiri — saf rotating	Yüksek hacimli tarama, maksimum IP çeşitliliği	İstek başına otomatik (veya upstream çekimi başına)

TTL uyumsuzluğu — gerçekte ne olur

İki TTL bağımsızdır. Her senaryoda beklenenler:

Nodetonet TTL'i önce sona erer (varsayılan 10 dk) ama upstream'inki daha uzundur. Bizim tarafımızdaki eşleştirme düşülür. Aynı X-Session'ı tekrar gönderirseniz yeni bir eşleştirme oluştururuz. Upstream tarafında türettiğimiz oturum belirteci anahtarınızdan deterministik olduğundan, upstream aynı belirteci yine görebilir ve size orijinal çıkışı verebilir. Pratikte: upstream uzun yaşıyorsa IP'niz Nodetonet TTL süresi dolduktan sonra genellikle korunur.
Upstream TTL'i önce sona erer. X-Session değeriniz hiç değişmemiş olsa bile upstream içinde tuttuğu oturum süresi dolduğu için sessizce yeni bir çıkışa döner. Herhangi bir şey yapmadan farklı bir IP alırsınız.
Her ikisi de birlikte sona erer (veya X-Rotate: 1 gönderirsiniz). Her iki katman durumu aynı anda düşürür ve sonraki istek tamamen taze bir upstream çekimi ve taze bir çıkış alır. Bu en temiz rotasyondur.

İki TTL eşleşmek zorunda değil — ama hangisinin daha kısa olduğunu bilmek rotasyon kadansınızı kimin kontrol ettiğini söyler. Öngörülebilir rotasyon istiyorsanız, bizimkinden daha kısa bir upstream oturum TTL'i ayarlayın (pek çok upstream sağlayıcı kullanıcı adında bir TTL ipucu kabul eder).

Stickiness "bozulduğunda" — yaygın tuzaklar

Beklenmedik IP değişikliklerine veya istenmeyen stickiness'a yol açan birkaç örüntü:

HTTP bağlantı havuzları. Bazı istemciler aynı TCP bağlantısını birçok istek boyunca yeniden kullanır. Sticky kararı bağlanma zamanında verilir, bu nedenle o bağlantıdaki tüm istekler, akış ortasında hangi oturum header'ını gönderirseniz gönderin aynı çıkışı paylaşır. Oturumları temiz şekilde değiştirmek için bağlantıyı kapatın ve yeniden açın.
Yanlış isteğe X-Rotate: 1 göndermek. Bu header, o oturum için her iki katmanın durumunu düşürür ve anında yeni bir upstream çekimini zorlar. Yanlışlıkla gönderirseniz (örn. yeniden deneme döngüsünden) sabitlenmiş IP'nizi beklenmedik şekilde kaybedersiniz.
Upstream tarafında havuz tükenmesi. Upstream'in istediğiniz bölge için havuzu tükenirse, orijinal çıkış artık erişilebilir olmadığı için "sticky" oturumunuz sessizce döner. Bu upstream'deki bir durumdur, Nodetonet değil. Kararlı bir oturum header'ına rağmen IP değişikliği olarak görürsünüz. Bunu tespit etmek için what-is-my-ip kontrollerini birleştirin.
Oturum ortasında upstream kimlik doğrulama hataları. Upstream herhangi bir nedenle 407 döndürürse (süresi dolmuş alt hesap, hız limiti), edge bağlantıyı düşürür, bu da oturum eşleştirmesini sıfırlayabilir. Bunları izole etmek için upstream auth hatalarını ayıklama yazısına bakın.
SOCKS5 oturum gömme. SOCKS5'te oturum, HTTP header'ı olmadığı için auth kullanıcı adına (uXXX-session-foo) gömülmelidir. İstemciniz çözümlenmiş SOCKS5 bağlantısını önbelleğe alıyorsa, oturum da bağlanma zamanında önbelleğe alınır.

Gerçek çıkış IP'sini inceleme

En hızlı doğruluk kontrolü: aynı oturum header'ıyla bilinen bir IP-yansıma uç noktasına birkaç kez vurun ve sonuçları karşılaştırın.

for i in 1 2 3; do
  curl -sx http://u8x2:p7q1@sub42.nodetonet.com:48888     -H "X-Session: test-oturumum" https://api.ipify.org && echo
done

IP üç çağrı boyunca sabit kalıyorsa her iki katman da sticky hizalamasındadır. Çağrı 1 ile 2 arasında değişiyorsa upstream TTL'inin sona erip ermediğini kontrol edin. Çağrı 2 ile 3 arasında değişiyor ama 1-2 arasında değişmiyorsa havuz tükenmesinden veya akış-ortası bağlantı havuzu yeniden kullanım sorundan şüphelenir. Her rotasyondan sonra çözümlenen çıkışı incelemek için yerleşik proxy checker aracımızı da kullanabilirsiniz.

Yanıt gecikmesi de başka bir sinyaldir: aradaki bir boşluktan sonra belirgin şekilde daha yavaş bir ilk çağrı genellikle upstream'in az önce yeni bir çıkış çevirdiği anlamına gelir — bu oturum sürekliliği değil, oturum sona ermesine işaret eder.

Upstream olmadan rotasyon: cihaz destekli stickiness

Yukarıdakilerin tümü bir upstream yapılandırdığınızı varsayar. Nodetonet'i yerel modda çalıştırıyorsanız — backend üçüncü taraf bir gateway yerine eşleştirilmiş bir Android cihazıysa — sticky oturumlar 1. katmanda aynı şekilde çalışır, ancak 2. katman cihazın kendisidir (özellikle operatör tarafından atanan IP'si). Yönetilecek ikinci bir TTL yoktur; IP, cihaz mobil atamasını koruduğu sürece kararlıdır. Bu mod hakkında ayrıntı için mobil proxy'ler ve rotating mobil proxy ne zaman kullanılır yazısına bakın.

Oturumlarla etkileşen istemci başına kontroller

Tünelinizi istemci başına kimlik bilgileriyle (kullanıcı/şifre doğrulama, IP izin listesi, istemci başına doğrulama) son müşterilere açıyorsanız, sticky oturumların istemci kimlik bilgisine değil upstream bağlantısına kapsanmış olduğunu unutmayın. Aynı X-Session değerleri gönderirse iki farklı istemci kimlik bilgisi aynı upstream oturum anahtarını üretebilir. Bu genellikle sorun değildir, ancak çıkış-IP düzeyinde istemci başına izolasyon gerekiyorsa, istemci başına farklı oturum önekleri veya ayrı proxy'ler kullanın. Tekil proxy'ler yerine havuzlar için token grupları, adlandırılmış bir havuz üzerinde yük devretmeli round-robin cihaz seçimi sağlar.

Başlayın

Denemeye hazır mısınız? Ücretsiz bir Nodetonet hesabı oluşturun, proxy ayarlarınız altında bir upstream yapılandırın ve iki katmanlı sticky kurulumunuzun çalıştığını doğrulamak için yukarıdaki curl döngüsünü çalıştırın. Tüm modlarda rotating ve sticky'nin tam bir yol gösterimi için rotating mobil proxy ne zaman kullanılır yazısına bakın.