Gerçekte Kaç Adet Proxy’ye İhtiyacınız Var?

Geonode adresinde proxy satıyoruz; bu da bu makalenin, planladığınızdan daha az satın almanız gerektiğini savunduğunu gösteriyor. Bu gerçekten de bizim tutumumuzdur: Aşırı büyük bir proxy havuzu sizi daha güvenli hale getirmez ve trafiğe dayalı fiyatlandırmada maliyeti bile daha yüksek olmaz — bu da, insanların bunu düzeltecek faturayı hiç görmeden yanlış bir zihinsel modele sahip oldukları anlamına gelir. Önemli olan rakam, tek bir hedefe karşı eşzamanlı erişim sayısıdır ve bu, bir öğleden sonra içinde ölçülebilir. Bu yazından tek bir şey çıkaracaksanız, size verebileceğimiz herhangi bir rakam yerine bir sonraki bölümdeki ölçümü esas alın.

İşe Yarayan Tek Yöntem

Üç adım, hepsi deneysel.

Birinci adım: Adres başına üst sınırı belirleyin. Gerçek iş yükünüzü tek bir adresten çalıştırın, istek oranını kademeli olarak artırın ve hedefin ne zaman direnmeye başladığını tespit edin — 429 hataları, doğrulama istekleri, yavaşlayan yanıtlar veya bozulmuş içerik. Bu eşik değeri, o hedef için adres başına kapasitenizdir ve bu hesaplamada tahmin niteliğinde olmayan tek sayıdır.

İkinci adım: Gerekli veriminizi belirtin. Kaç istek, ne kadar süre boyunca. “Ne kadar süre boyunca” kısmında dürüst olun, çünkü bu denklemde diğer her şeyden daha fazla rol oynar.

Üçüncü adım: bölün. İstenen iş hacmini adres başına kapasiteye bölünce, gerekli eşzamanlı adres sayısı elde edilir. Yeniden denemeler ve değişkenlik için bir marj ekleyin — %50 cömert bir rakamdır; bundan daha fazlasına ihtiyacınız varsa, birinci adımdaki ölçümünüz muhtemelen iyimser olmuştur.

Yöntem budur. Bunun standart bir tavsiye olmaması, satın almadan önce bir test yapılmasını gerektirmesinden kaynaklanır ve satıcıların bunu önermek için hiçbir teşviki yoktur.

Birinci adımla ilgili bir not: Saniye başına tamamlanan yararlı yanıtları ölçün, denenen istekleri değil. İçeriği silinmiş 200 kodlu yanıtlar döndüren bir havuz düzgün çalışmıyor; ancak toplam başarı oranı metriği bunu sağlıklı olarak rapor edecektir. Yanıtta bilinen ve istikrarlı bir işaret olup olmadığını kontrol edin ve yalnızca bunu içeren yanıtları sayın.

Ölçümü Doğru Şekilde Gerçekleştirme

Tüm yöntem birinci adıma dayanmaktadır; bu nedenle, kendinizi yanıltmadan bunun nasıl yapılacağı konusunda net olmak önemlidir.

Test uç noktasına değil, gerçek hedefinize karşı test yapın. IP adresinizi yansıtan bir hizmet üzerinde yapılan bir test, proxy'nizin çalıştığını gösterir, ancak ilgilendiğiniz sitenin size nasıl davranacağı hakkında hiçbir bilgi vermez. Her hedefin kendine özgü bir toleransı vardır ve ihtiyacınız olan değer hedefe özeldir.

Yavaş yavaş artırın ve her şeyi kaydedin. Sınır olarak beklediğiniz değerin oldukça altında başlayın ve kademeli olarak artırın; her hızda bir örüntü görebilmek için yeterince uzun süre (en az birkaç dakika) bekleyin. Her adım için hızı, durum kodlarını, yanıt boyutlarını ve gerçek zamanı kaydedin:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Durum kodunu izlediğiniz kadar yanıt boyutunu da yakından izleyin. En yaygın geri dönüş türü 429 kodu değildir; daha küçük bir sayfa içeren 200 kodudur. Belirli bir hızda ortalama yanıt boyutunda bir düşüş, hedefin size daha az içerik sunmaya başladığını gösterir ve yalnızca durum kodlarını sayarsanız bu durum fark edilmez.

Bunu günün farklı saatlerinde çalıştırın. Sitenin yoğun saatlerinde tolerans genellikle daha düşüktür ve sabah saat 3'te ölçülen bir sınır, öğle saatlerinde geçerli olmayacaktır. En kötü senaryoya göre hesaplayın.

İkinci bir adresle tekrarlayın. Bir adres saniyede iki istekle tıkanıyorsa ve ikinci bir adres de aynı anda aynı tıkanmaya uğruyorsa, sınır adres başına değildir — bu, alt ağınızda, istek yapınızda veya daha fazla adresin çözemeyeceği başka bir sorunda yatmaktadır. Bu önemli bir olumsuz sonuçtur ve elde etmek için fazladan bir çalıştırma gerektirir.

Sonra, sınıra ulaştığınızda değil, sınırdan önce durun. Hedefin tolere edebileceği maksimum hızda çalışmak, her sıradan dalgalanmanın sizi bu sınırın ötesine iteceği anlamına gelir. Ölçülen sınırın %60–70’i aralığında boyutlandırma yapmak, koşullar iyi olduğunda tamamlanan bir iş yerine, güvenilir bir şekilde tamamlanan bir iş sağlar.

Uygulamalı Örnek: Günlük Fiyat İzleme

En yaygın iş yükü ve cevabı insanları en çok şaşırtan durum.

Gereksinim: 50.000 ürün sayfasının günde bir kez kontrol edilmesi.

Ölçülen üst sınır: Hedef, hız sınırlaması uygulanmadan önce tek bir adresten yaklaşık her iki saniyede bir istek kabul eder — buna saatte 1.800 istek diyelim.

24 saate yayıldığında: 50.000 ÷ 24 ≈ saatte 2.100 istek.

Gerekli adres sayısı: 2.100 ÷ 1.800 ≈ 1,2. Yuvarlayıp bir marj ekleyelim: iki ila dört adres.

İki adres. Günde elli bin sayfa için, milyonlarca adres içeren bir havuz karşısında.

Şimdi bir varsayımı değiştirin. İşin gün boyunca yayılmak yerine iki saatlik bir zaman aralığı içinde tamamlanması gerektiğini varsayalım:

Gereksinim: 2 saatte 50.000 sayfa = saatte 25.000. Gerekli adres sayısı: 25.000 ÷ 1.800 ≈ 14, artı marj: yaklaşık 20.

Aynı hacim, aynı hedef, on kat daha fazla adres — bu, veri toplama gereksinimi değil, zamanlama kararından kaynaklanıyor.

Bu, bu makaledeki en yararlı içgörü. Kendinize tanıdığınız süre aralığı, en belirleyici değişkendir. Daha fazla adres satın almadan önce, işin gerçekten hızlı bir şekilde bitmesi gerekip gerekmediğini ve bu hızın ne kadar değerli olduğunu sorun. Veriler ertesi sabah tüketileceği için, çoğu zaman bu hızın hiçbir değeri yoktur.

Uygulama Örneği: Coğrafi Kontroller

Tamamen farklı bir yapı ve hesaplamalar da tam tersi yönde yapılır.

Gereksinim: 30 pazardaki bölgesel fiyatlandırma ve stok durumunu, günde dört kez, her pazar için 50 sayfa olmak üzere kontrol etmek.

Hacim: 30 × 4 × 50 = günde 6.000 istek. Önemsiz bir rakam.

İş hacmi için gerekli adresler: esasen bir tane. Bir güne yayılmış altı bin istek, her on dört saniyede bir istek demektir.

Kapsam için gerekli adresler: ihtiyaç duyduğunuz anda, 30 ülkenin her birinde en az bir çalışan çıkış noktası.

Buradaki kısıtlama hacim değil, varlık'tır. Değerlendirmeniz gereken şey, sağlayıcının ihtiyacınız olan belirli pazarlarda, hizmet verdiğiniz zamanlarda gerçekten güvenilir kapsama alanına sahip olup olmadığıdır — havuzda kaç adres olduğu değil. Üç pazarınızda kapsama alanı yetersiz olan on milyonluk bir havuz, otuz pazarın tamamını kapsayan on binlik bir havuzdan daha kötüdür.

Bu nedenle, coğrafi çalışmalar için “kaç tanesine ihtiyacım var” sorusu yanlış bir sorudur; “nereye güvenilir bir şekilde ulaşabilirsiniz ve bunu test edebilir miyim” sorusu ise doğru sorudur.

Uygulamalı Örnek: Oturum Tabanlı Çalışma

Eşzamanlılık ve kimliğin aynı şey olduğu durum.

Gereksinim: Her biri çok adımlı işlem dizileri gerçekleştiren 10 adet kimlik doğrulaması yapılmış oturumu paralel olarak çalıştırmak.

Gerekli adres sayısı: 10; ayrıca bu adresler "sticky" olmalıdır — her oturum süresince tek bir adres tutulmalıdır.

Burada hacim önemli değildir. Önemli olan, her oturumun tutarlı bir kimliğe sahip olmasıdır: baştan sona aynı adres, eşleşen yerel ayar ve saat dilimi. İstekleri dört farklı ülkeden gelen bir oturum, bir oturum değil, bir kalıptır.

Kaçınılması gereken hata, bunun için istek başına dönen bir uç nokta kullanmaktır; bu, çoğu ağ geçidinde varsayılan ayardır. İstekler başarılı olur, oturum durumu kaybolur ve çıkış adresleri kontrol edilene kadar bu durum bir uygulama hatası gibi görünür.

Ayrıca, on eşzamanlı oturumun sonsuza kadar on adres anlamına gelmediğini de unutmayın — bu, aynı anda on adres anlamına gelir. Gün boyunca sırayla 200 oturum çalıştıran bir iş yükü için yine de yeniden kullanılan sadece on sabit adrese ihtiyaç vardır.

Neden Daha Fazlası Daha Güvenli Değildir?

Çoğu aşırı büyük ölçekli satın alımın ardındaki varsayım budur ve bu varsayım üç belirgin açıdan yanlıştır.

Engelleme, adrese göre değil alt ağa göre yapılır. Siteler genellikle /24 düzeyinde engelleme yapar. Bir bloktaki elli adres, o blok engellendiğinde tek bir adres gibi davranır; bu nedenle, dağılımı zayıf olan büyük bir adres havuzu, önemli olan anlamda büyük bir havuz değildir. Dağılım, sayıya üstündür ve bu mekanizmayı alt ağ kimliği nedir başlıklı yazımızda ele aldık.

Önemli olan sinyaldir, kimlik değil. İstekleriniz zamanlama, başlıklar veya TLS parmak izi açısından otomatikleştirilmiş gibi görünüyorsa, bunları daha fazla adrese yaymak sinyali ortadan kaldırmadan yayar. Sonuçta daha az değil, daha fazla adresi işaretlemiş olursunuz.

Kullanılmayan adresler geçerliliğini yitirir. Dönen bir havuzda, kullanmadığınız bir adresin hedefle iyi ya da kötü hiçbir ilişkisi yoktur. “Yedek kapasite” bulundurmak, herhangi bir şeyin stoklanması değildir.

İş hacminin gerektirdiğinden daha fazla adres tutmanın tek gerçek bir nedeni vardır: kaybetme oranı. Bir hedef zamanla adresleri işaretliyorsa, rotasyona dahil etmek için yedeklere ihtiyacınız olur. Bu gerçek bir gerekliliktir ve boyutlandırılması sezgiye değil, gözlemlenen işaretleme oranına göre yapılır — günde kaç adresin bozulduğunu ölçün ve birkaç gün yetecek kadar adres bulundurun.

Aslında Ne Satın Alıyorsunuz?

Bunu açıkça belirtmek gerekir, çünkü cevap fiyatlandırma modeline göre farklılık gösterir ve bu durum sorunun anlamını bile değiştirir.

Gigabayt başına fiyatlandırmada — ki bu, ev kullanıcıları ve genellikle veri merkezi trafiğinin satıldığı yöntemdir — aslında adres satın almıyorsunuz. Siz veri satın alıyorsunuz ve adres sayısı, planınızın değil, havuzun bir özelliğidir. Bu bağlamda “kaç proxy’ye ihtiyacım var” diye sormak bir kategori hatasıdır — asıl sorular, ne kadar trafik aktaracağınız ve havuzun ihtiyacınız olan bölgeleri kapsayıp kapsamadığıdır. Ev kullanıcıları trafiğimiz 0,79 $/GB’den, veri merkezi trafiğimiz ise 0,14 $/GB’den başlar; bu fiyatlar Eylül 2026 tarihinde fiyatlandırma sayfamız üzerinden kontrol edilmiştir.

IP başına fiyatlandırma konusunda — ki bu, ISS'lerin ve birçok veri merkezi ürününün satış şeklidir — ödediğiniz tutar tam anlamıyla IP sayısı ile orantılıdır ve bu hesaplamanın tamamı bir bütçe kalemidir. Bizim fiyatımız IP başına 1,25 $'dır. Burada yukarıdaki hesaplama parayla ilgilidir ve bunu doğru yapmak için harcadığınız yirmi dakikaya değer.

Hangi modelin size uygun olduğu, başlıkta belirtilen ücretten ziyade iş yükünüzün yapısına bağlıdır ve bu ikisi karşılaştırılamaz. Çok sayıda adrese ihtiyaç duyan bir iş yükü, kısa vadede trafik bazlı fiyatlandırmayı tercih eder; az sayıda adrese ihtiyaç duyan bir iş yükü ise IP başına fiyatlandırmayı tercih eder. Bu hesaplamayı proxy fiyatlandırma kılavuzunda ayrıntılı olarak ele aldık.

Genel Kurallar ve Sınırları

Ölçüm yapmadan önce bir başlangıç noktasına ihtiyacınız varsa, bunlar makul seçeneklerdir. Bunları kesin bir cevap olarak değil, daha sonra değiştirilecek bir ilk tahmin olarak değerlendirin.

İçselleştirilmesi gereken iki rakam. Neredeyse hiçbir iş yükü birkaç düzine eşzamanlı adresten fazlasına ihtiyaç duymaz ve gerçekten ihtiyaç duyanlar ya coğrafi niteliktedir (çok sayıda konum, her birinde düşük hacim) ya da kendi belirledikleri bir son teslim tarihine tabidir. Ve en sık değiştirilmesi gereken sayı adres sayısı değil, zamanlamadır.

Rakamı Yanlış Belirlediğinize Dair İşaretler

Çok az olması şu şekilde görünür: 429 hatalarının artması, sorunların ortaya çıkması, işlem ilerledikçe başarı oranının düşmesi, işlerin planlanandan daha geç tamamlanması. Çözüm, daha fazla eşzamanlılık veya daha uzun bir zaman aralığıdır.

Çok fazla olması şu şekilde görünür: hiçbir şey. İşte bu yüzden hata devam eder. Aşırı büyük bir havuz, trafik fiyatlandırmasında herhangi bir belirti göstermez, bu yüzden kimse bunu fark etmez. IP başına fiyatlandırmada ise bir fatura oluşturur ve bu da en azından sorunun ortaya çıkmasına neden olur.

"Çok az" gibi görünen ancak aslında öyle olmayan iki durum:

Engellenmiş bir havuz. Başarı oranı tüm adreslerde aynı anda çökerse, daha fazlasını eklemek işe yaramaz — hedefte bir değişiklik olmuştur ya da istek şekliniz adres dışı bir sinyal üzerinden tespit edilmektedir.

Yavaş bir hedef. Yanıtlar yavaş ama başarılıysa, daha fazla eşzamanlılık bir noktaya kadar verimi artırır, sonra durur. Saniye başına tamamlanan istek sayısını ölçün ve bu sayı sabit bir seviyeye ulaştığında artırmayı durdurun; bu, beklenenden daha erken gerçekleşecektir.

Genel teşhis: eşzamanlılığı kademeli olarak artırın ve saniye başına tamamlanan yararlı yanıt sayısını izleyin. Bu sayı artar, sabit bir seviyeye ulaşır, sonra düşer. Optimum seviye, sabit kalan seviyedir ve genellikle herkesin tahmin ettiğinden daha düşük bir sayıdır.

İnsanlar Ayrıca Şunu Soruyor

Web veri toplama için kaç tane proxy'ye ihtiyacım var?

Tahminde bulunmak yerine ölçüm yapın: Gerçek hedefinizde tek bir adresin sınırlanmaya başladığı istek oranını bulun, gerekli veri aktarım hızınızı bu sayıya bölün ve bir marj ekleyin. Çoğu iş yükü, binlerce değil, tek haneli veya düşük çift haneli eşzamanlı adres sayısına denk gelir.

Daha fazla proxy kullanmak engellenme olasılığımı azaltır mı?

Sadece engelleme adrese özgü ise. İstekleriniz zamanlama, başlık yapısı veya TLS parmak izi nedeniyle otomatik olarak tanımlanırsa, daha fazla adres kullanmak bu sinyali önlemek yerine havuzunuzun daha geniş bir kısmına yayar. Hız ve istek şekli, sayıdan daha önemlidir.

Günde 1 milyon istek için kaç proxy gerekir?

Tamamen zaman aralığına bağlıdır. 24 saate yayıldığında bu, saniyede yaklaşık 12 istek demektir; bu da adres başına iki saniyede bir istek olarak, kabaca 25 eşzamanlı adres anlamına gelir. İki saate sıkıştırıldığında bu sayı on iki katına çıkar. Değişken olan hacim değil, zamanlamadır.

Her hesap için bir proxy'ye ihtiyacım var mı?

Oturum tabanlı her şey için, hesap başına değil, eşzamanlı oturum başına bir sabit adres gerekir. Gün boyunca sırayla çalıştırılan on hesap, ancak onunun tamamı aynı anda aktifse on adrese ihtiyaç duyar. Birçok platformun çoklu hesap kullanımını açıkça yasakladığını unutmayın; bu nedenle, buna göre tasarım yapmadan önce şartları kontrol edin.

Daha fazla IP'ye sahip olmak mı, yoksa daha iyi IP'lere sahip olmak mı daha iyidir?

"Daha iyi" derken, alt ağlar arasında iyi dağıtılmış ve hedefe uygun olanları kastediyoruz. Engelleme genellikle /24 düzeyinde gerçekleşir; bu nedenle, tek bir bloktaki elli adres tek bir adres gibi davranır. Daha küçük ve iyi dağıtılmış bir havuz, daha büyük ve yoğunlaşmış bir havuzdan daha iyi performans gösterir.

Proxy sayımın çok az olup olmadığını nasıl anlarım?

429 hatalarının artması, doğrulama sayfalarının görünmesi ve işlem ilerledikçe başarı oranının düşmesi. Eğer tüm adreslerde başarı oranı birden düşerse, bu farklı bir sorundur — hedefte bir değişiklik olmuştur ya da istekleriniz adres dışı bir sinyalle tespit edilmektedir ve daha fazla adresin olması bir fayda sağlamayacaktır.

Proxy sayısı fiyatı etkiler mi?

IP başına fiyatlandırmada doğrudan etkiler — satın aldığınız şey sayıdır. Gigabayt başına fiyatlandırmada ise hiç etkilemez, çünkü veri için ödeme yaparsınız ve adres sayısı havuzun bir özelliğidir. Bu nedenle bu iki model, nominal fiyatlar üzerinden karşılaştırılamaz.

Coğrafi hedefleme için kaç proxy gerekir?

İhtiyacınız olan her konum için bir adet güvenilir çıkış yeterlidir ve hacim genellikle önemsizdir. Bir sağlayıcıya sorulması gereken soru, kaç adrese sahip oldukları değil, belirli pazarlarınızda güvenilir kapsama alanına sahip olup olmadıkları ve taahhütte bulunmadan önce bunu test edip edemeyeceğinizdir.

Sonuç

İhtiyacınız olan sayı, tek bir ölçüm ve tek bir bölme işleminden elde edilir: Gerçek hedefinizde tek bir adresin hız sınırlamasına tabi olmaya başladığı noktayı bulun ve veri aktarım hızı gereksiniminizi bu sayıya bölün. Geri kalan her şey ayrıntılandırmadır.

Sonucu belirleyen değişken hacim değil, izin verdiğiniz penceredir. Günde elli bin sayfa için yirmi dört saate yayılmış birkaç adres ve iki saate yayılmış yirmi adres gerekir. Daha hızlı çalışmak için kapasite satın almadan önce, işin daha erken bitmesine gerçekten bağlı olan bir şey olup olmadığını kontrol edin — genellikle hiçbir şey yoktur ve mevcut en ucuz optimizasyon sabırdır.

Coğrafi işler söz konusu olduğunda ise soru tamamen farklı bir hal alır. Hacim önemsizdir, varlık her şeydir ve yararlı değerlendirme, havuzun ne kadar büyük olduğundan ziyade, bir sağlayıcının belirli pazarlarınızı güvenilir bir şekilde kapsayıp kapsamadığıdır. Bu, deneme sürümüyle test edilebilir; bir öğleden sonra sürer ve bir satıcının açılış sayfasında sunduğu herhangi bir rakamdan — bizimkiler dahil — daha fazla bilgi verir.