Rotating Proxy Gateway Mantığı: Tek Uç Nokta Nasıl Çalışır?

Rotating proxy gateway, uygulamanızın bağlandığı tek bir host ve port çiftidir; arkasındaki IP havuzunu, hangi isteğin hangi adresten çıkacağını ve bozuk adreslerin devreden alınmasını sağlayıcı tarafı yönetir. Uygulama bir proxy URL’si tanımlar, gerisini gateway yapar. Bu modelin karşısında proxy listesi vardır: yüzlerce host ve port çiftini bir dosyada tutar, her isteğe hangisini vereceğinize kendi kodunuzla karar verirsiniz.

İki model aynı sonuca farklı yerlerden ulaşır. Listede rotasyon sizin kodunuzdadır; gateway’de sağlayıcının altyapısındadır. Bu farkın sonuçları kod miktarında olduğu kadar hata yönetiminde, bağlantı davranışında ve kota hesabında da görünür. Bu yazı o sonuçları tek tek ele alıyor; rotasyon modlarının genel anlatımı rotating proxy nedir rehberinde, aralık seçimi ise rotasyon aralığı rehberinde var.

RotatingProxy kataloğundaki beş ürün de gateway modeliyle çalışır ve hepsi aynı protokol setini sunar: HTTP, HTTPS ve SOCKS5. Uygulama tarafında tek bir ayar değişir; IP türü, lokasyon ve rotasyon davranışı ürün ve parametre seçimiyle belirlenir.

Yapılandırma: Listede her adres ayrı satırdır ve adresler değiştikçe dosya güncellenir. Gateway’de tek bir URL vardır; havuz büyüse de küçülse de uygulama tarafında hiçbir şey değişmez.

Seçim mantığı: Listede sıralı döngü, rastgele seçim ya da ağırlıklı dağıtım kodu sizde durur ve her istemcide ayrı yazılır. Gateway’de seçim, kullanıcı adına ya da panele yazılan kurala göre sağlayıcı tarafında yapılır; Scrapy, Playwright ve requests aynı kuralı paylaşır.

Sağlık kontrolü: Listedeki bir adres yanıt vermeyince bunu fark eden, listeden çıkaran ve bir süre sonra geri alan kod sizin sorumluluğunuzdadır. Gateway havuzdaki adresi kendisi devreden alır; siz yalnız bağlantı zaman aşımı gibi uç hataları görürsünüz.

Kimlik doğrulama: Listede her adresin ayrı kullanıcı adı ve şifresi olabilir ya da IP whitelist ile açılır. Gateway’de tek bir kimlik bilgisi vardır ve 407 yanıtı tek bir anlama gelir: kimlik bilgisi ya da whitelist yanlış. Bu hatanın ayrıntısı bağlantı sorunları rehberinde.

Kota: Listede her adresin kendi sınırı vardır ve toplam kullanım adres adres toplanır. Gateway’de GB bazlı ürünlerde tek bir sayaç, port bazlı ürünlerde ise satın alınan port sayısı ölçüttür; hangi IP’den çıkıldığı sayaç için önemsizdir.

Ölçeklenme: Liste modelinde daha fazla IP, daha büyük dosya ve daha karmaşık seçim kodu demektir. Gateway’de havuzun büyüklüğü uygulamadan görünmez; bir makineden de yüz makineden de aynı URL’ye bağlanılır.

Gateway tek adres olduğu için ülke, oturum kimliği ve rotasyon tipi gibi tercihler adresle değil, bağlantıyla birlikte gider. En yaygın taşıma yolu kullanıcı adına eklenen eklerdir: kullanıcı adının sonuna belirli bir ayraçla ülke kodu ya da oturum adı yazılır, gateway bu ekleri okuyup kuralı uygular. Ek sözdizimi sağlayıcıya göre değişir ve panelde yazar; kodda kendi uydurduğunuz bir biçim çalışmaz.

İkinci yol panel ayarlarıdır. Rotasyon tipi ya da varsayılan lokasyon gibi tercihler bir kez panelde seçilir ve o kimlik bilgisiyle gelen her bağlantıya uygulanır. Kullanıcı adı ekleri istek bazında, panel ayarları hesap bazında geçerlidir; ikisi çakıştığında hangisinin öncelikli olduğu panel dokümanında yazar ve kurulumda bir kez test edilmelidir.

Oturum kimliği gateway’in en önemli parametresidir. Aynı kimlikle gelen bağlantılar aynı çıkış IP’sine yönlenir, kimlik değişince yeni IP atanır. IPv4 residential ve mobile ürünlerde sticky ve rotating oturum seçenekleri bir arada bulunur; IPv4 datacenter ürünü istek başına ya da oturum bazlı rotasyonla çalışır; IPv6 datacenter ve IPv6 residential ürünlerde rotasyon oturum yapılandırmalıdır. Kimliği birim işe bağlamak, yani iş başında üretip iş bitince atmak, akış ortasında IP değişmesini önler.

Oturum kimliği üretirken rastgele ve yeterince uzun bir dize kullanın. Sabit ya da sıralı kimlikler iki sorun çıkarır: aynı kimliği iki işçi aynı anda kullanırsa iki iş aynı IP’den çıkar; önceki koşudan kalan bir kimlik yeniden kullanılırsa gateway hâlâ o kimliği hatırlıyor olabilir ve beklediğiniz yeni IP yerine eskisini verir.

HTTPS hedeflerde istemci gateway’e önce bir CONNECT isteği gönderir; gateway hedef host ve porta bir tünel açar, TLS el sıkışması bu tünelin içinden hedefle doğrudan yapılır. Gateway yalnız hedef adresini görür, içerikteki URL yolunu ve gövdeyi görmez. Bu yüzden gateway tarafında yol bazlı bir kural yazılamaz; ülke ya da oturum seçimi tünel açılırken, yani bağlantı kurulurken belirlenir.

Rotasyon da bu noktada çalışır: çıkış IP’si tünel açılırken seçilir ve tünel kapanana kadar değişmez. İstemciniz keep-alive ile aynı TCP bağlantısını yeniden kullanıyorsa, o bağlantıdan geçen bütün istekler aynı IP’den çıkar. İstek başına rotasyon ayarladığınız halde loglarda aynı IP’yi art arda görüyorsanız sebep çoğunlukla budur; her istekte yeni IP için istemcinin bağlantı havuzunu kapatmak ya da her isteği yeni bağlantıyla göndermek gerekir.

Aynı davranış HTTP/2 kullanan istemcilerde daha belirgindir. HTTP/2 tek bağlantı üzerinden çok sayıda isteği aynı anda taşır; bu isteklerin tamamı tek bir tünelden ve dolayısıyla tek bir IP’den geçer. İstek başına rotasyon istiyorsanız proxy bağlantısında HTTP/1.1 ile kalmak ve bağlantı yeniden kullanımını kapatmak daha öngörülebilir sonuç verir.

SOCKS5 modelinde tünel TCP düzeyinde açılır ve gateway HTTP başlıklarını hiç görmez. Kimlik bilgisi SOCKS5 el sıkışmasında gönderilir; oturum ve ülke ekleri yine kullanıcı adına yazılır. Chromium tabanlı tarayıcılar kullanıcı adı isteyen SOCKS5 ile çalışmadığı için tarayıcı otomasyonunda HTTP uç noktası seçilir; bu ayrıntı Scrapy ve Playwright rehberinde var.

Gateway üç işi sizden alır: havuzdan IP seçmek, sağlıksız adresleri devreden çıkarmak ve oturum kimliğini IP’ye eşlemek. Bu üçü liste modelinde en çok hata üreten parçalardır; seçim kodu her istemcide ayrı yazıldığında bir istemci kuralı eksik uygular, sağlık kontrolü yavaş çalışır ya da iki işçi aynı adresi aynı anda tüketir.

Gateway dört işi sizden almaz. Birincisi hedefin hız sınırıdır: aynı IP’den pencere içinde çok istek giderse 429 yine gelir, gateway isteklerinizi hedefin kotasına göre yavaşlatmaz. İkincisi yanıt doğrulamadır: 200 koduyla dönen boş sayfa ya da doğrulama ekranı gateway için başarılı bir yanıttır. Üçüncüsü istemci izidir: başlık sırası, User-Agent ve zamanlama IP’den bağımsız olarak sizi tanıtır. Dördüncüsü yeniden deneme kararıdır; hangi hatada aynı oturumda kalınacağı, hangisinde yeni IP alınacağı uygulamada yazılır ve retry rehberindeki tabloya göre kurulur.

Bu ayrımın pratik sonucu şudur: gateway’e geçmek proxy yönetim kodunu küçültür ama hedef yönetim kodunu küçültmez. Hız sınırı takibi, yanıt doğrulama ve yeniden deneme politikası liste modelindeki gibi uygulamada kalır.

Deneyler için istemci IP’sini düz metin olarak döndüren bir uç nokta kullanın; kendi sunucunuzda tek satırlık bir sayfa da olur. Her deneyde aynı gateway adresi ve aynı kimlik bilgisi kullanılır, yalnız bağlantı biçimi ve kullanıcı adı ekleri değişir.

Birinci deney, istek başına rotasyonu doğrular: Oturum eki olmadan, her seferinde yeni bağlantı açarak üç istek gönderin. Üç farklı IP görmelisiniz. Aynı IP geliyorsa istemci bağlantıyı yeniden kullanıyordur ya da panelde varsayılan rotasyon oturum bazlı seçilidir.

İkinci deney, oturum kimliğini doğrular: Aynı oturum ekiyle, yine ayrı bağlantılarla üç istek gönderin. Üçü de aynı IP’den çıkmalıdır. Farklı IP geliyorsa ek sözdizimi yanlış yazılmıştır ya da ürün o rotasyon modunu desteklemiyordur.

Üçüncü deney, keep-alive etkisini ölçer: Oturum eki olmadan, tek bir bağlantıyı açık tutarak üç istek gönderin. Aynı IP’yi görmeniz beklenir; bu, bağlantı yeniden kullanımının rotasyonu nasıl etkilediğini gösterir ve birinci deneyle arasındaki fark, istemci ayarınızın hangi yöne çekildiğini söyler.

Dördüncü deney, lokasyon ekini doğrular: Ülke ekiyle üç istek gönderip dönen IP’lerin ülkesini bir konum veritabanında kontrol edin. Ülke tutmuyorsa ek sözdizimi ya da ülke kodu yanlıştır. Bu dört deney, kodu yazmaya başlamadan önce gateway ile istemci arasındaki her varsayımı birkaç dakikada ortaya çıkarır.

Birinci değişiklik proxy seçim katmanıdır. Listeden rastgele ya da sıralı adres seçen fonksiyon, dosyayı yeniden yükleyen zamanlayıcı ve adres başına başarı sayacı kaldırılır; yerine tek bir proxy URL’si gelir. Scrapy’deki proxy middleware, requests’teki proxies sözlüğü ve Playwright’taki proxy seçeneği aynı URL’yi alır.

İkinci değişiklik hata sınıflandırmasıdır. Liste modelinde bağlantı reddi, o adresin öldüğünü gösterir ve adres listeden düşülür. Gateway’de bağlantı reddi ya da 407, kimlik bilgisi ya da whitelist sorununa işaret eder ve adres değiştirmek bir işe yaramaz; bu hatalar yeniden deneme yerine doğrudan uyarı üretmelidir. 403 ve doğrulama sayfası ise yeni oturum kimliğiyle tek bir kez denenir.

Üçüncü değişiklik oturum yönetimidir. Liste modelinde sabit IP istemek, aynı adresi tekrar seçmek demektir. Gateway’de bu iş oturum kimliğine geçer: iş başında kimlik üretilir, o işin bütün isteklerine aynı kullanıcı adı ekiyle gider, iş bitince kimlik atılır. Kimliğin ömrü iş akışının süresine eşitlenir; zaman bazlı değişim yalnız akışsız işlerde kullanılır.

Dördüncü değişiklik eşzamanlılık sınırıdır. Liste modelinde eşzamanlılık adres sayısıyla sınırlıdır; gateway’de bu sınır kalkar ve istemci istediği kadar bağlantı açabilir. Hedefe giden istek hızını bu yüzden açıkça sınırlamak gerekir: alan adı başına eşzamanlı bağlantı sayısı ve saniyedeki istek sayısı yapılandırmaya sabit bir değer olarak yazılır, 429 oranına göre düşürülüp yükseltilir.

Geçişten sonra ilk gün loglarda üç sütun izlenir: istek başına çıkış IP’si, kullanılan oturum kimliği ve durum kodu. Aynı oturum kimliğinde farklı IP görünüyorsa ek sözdizimi, oturumsuz isteklerde aynı IP tekrar ediyorsa keep-alive, 407 birikiyorsa kimlik bilgisi kontrol edilir.

Gateway tek nokta olduğu için tek hata noktası mı? Uygulama tarafından bakıldığında tek adrestir, ama bu adres sağlayıcı tarafında birden fazla sunucuya dağıtılmış bir hizmettir. Yine de bağlantı zaman aşımı için yeniden deneme ve devre kesici kurmak gerekir; bu, liste modelinde de gereken bir önlemdir.

Gateway’in kendisi gecikme ekler mi? Her proxy bir atlama ekler ve gateway de öyledir. Ölçülebilir gecikme, gateway ile hedef arasındaki mesafeye ve seçilen IP türüne bağlıdır; keep-alive kullanmak ve hedefe yakın lokasyon seçmek bu ek süreyi küçültür.

Aynı gateway’i hem Scrapy hem Playwright kullanabilir mi? Evet, aynı URL ve kimlik bilgisiyle. İki araç aynı kotadan düşer; oturumlu ve oturumsuz istekleri farklı kullanıcı adı ekleriyle ayırmak hangi isteğin hangi IP’den çıktığını izlenebilir tutar.

Gateway ile liste birlikte kullanılır mı? Gereksizdir. Gateway zaten bir havuzu temsil eder; onu bir listeye koyup istemci tarafında döndürmek rotasyonu iki katmana böler ve oturum kimliğinin hangi katmanda tutulduğunu belirsizleştirir.