Aynı proxy portu, Wildberries'i parse ederken 50 paralel isteği rahatlıkla kaldırabilir — ve bu arada Facebook Ads Manager'da üç eşzamanlı oturumdan sonra "yanabilir". Sorun proxy'nin kalitesinde değil, farklı trafik türlerinin IP üzerinde farklı yükler oluşturmasındadır. Bu makalede, gerçek akış limitini göreviniz için nasıl hesaplayacağınızı ve basit bir matematik hatası yüzünden hesaplarınızı veya proxy havuzunuzu nasıl yakmayacağınızı inceleyeceğiz.
Proxy portunda "akış" nedir
Akış, belirli bir anda proxy üzerinden yapılan bir paralel bağlantıdır. Eğer Dolphin Anty anti-detect tarayıcısında 10 sekme açtıysanız ve hepsi aynı anda Instagram'ı aynı proxy portu üzerinden yüklüyorsa, bu 10 akıştır. Eğer Python'da bir parser, aynı anda Wildberries'e 50 istek gönderiyorsa, bu 50 akıştır.
Önemli olan: akış sayısı, internet hızından değil, bir IP adresinden hedef siteye birim zamanda görülen "eşzamanlı kişilik" sayısından bahseder. Facebook, Instagram, TikTok'un anti-fraud sistemleri ve pazar yerlerinin koruma mekanizmaları, IP'yi yasaklayıp yasaklamayacaklarına karar verirken bu sayıyı analiz eder.
Bir arbitrajcı ve SMM uzmanı için akış genellikle bir anda açık olan bir hesaba eşittir. Pazar yerinde bir satıcı için akış, bir parser veya fiyat izleme scriptinin eşzamanlı HTTP isteğidir. Trafik türündeki farklılık, bir portta ne kadar akışın güvenli bir şekilde tutulabileceğini belirler.
Akış limitini ne etkiler
"Proxy N akış tutar" şeklinde evrensel bir rakam yoktur — bu, yasaklamalara yol açan bir efsanedir. Gerçek limit, bir dizi faktörün birleşimiyle belirlenir:
- IP türü. Yerleşik, mobil ve veri merkezi proxy'leri, anti-fraud sistemleri tarafından farklı şekilde algılanır. Mobil IP, genellikle bir gerçek kişiyi temsil eder, bu nedenle farklı çerezlerle 2-3 eşzamanlı oturum bile şüpheli görünür.
- Hedef platform. Facebook ve TikTok, davranışsal kalıpları çoğu pazar yerinden daha sıkı bir şekilde analiz eder. Wildberries ve Ozon, öncelikle istek sıklığına bakar, "kişilik" sayısına değil.
- İstek türü. Ürün fiyatını almak için basit bir GET isteği, hafif bir yük oluşturur. Yetkilendirme, medya yükleme ve arayüzle etkileşim içeren tam bir oturum, ağır bir yük oluşturur.
- Proxy sağlayıcısı. IP adresleri havuzu, döngü hızı ve teknik kapasite, farklı sağlayıcılarda büyük farklılıklar gösterir.
- Trafik amacı. Çoklu hesap yönetimi, IP'deki "kişilik" benzersizliğini gerektirirken, parse etme sadece kimlik bağımsız bir bant genişliği gerektirir.
Bu nedenle, "proxy akış limitinden" değil, "belirli bir görev için belirli bir platformda akış limitinden" bahsetmek daha doğrudur.
Çoklu hesap yönetimi için hesaplama (SMM ve arbitraj)
Çoklu hesap yönetimi için altın kural basit: bir hesap — bir IP — bir oturum. Yani, idealde, bir proxy portunda tam olarak 1 aktif akış olmalıdır, eğer Facebook Ads, TikTok Ads veya Instagram hesapları söz konusuysa. Sorun, proxy'nin teknik sınırlamalarında değil, anti-fraud sistemlerinin IP + cihaz parmak izi + davranış bağlamını takip etmesindedir. Eğer iki hesap aynı IP üzerinde farklı anti-detect tarayıcı sekmeleri aracılığıyla aynı anda "oturum açıyorsa", bu, zincir yasaklama riskini önemli ölçüde artırır — tüm hesap zincirinin anında yasaklanması.
Pratikte, SMM ajanslarında ve arbitraj ekiplerinde şu dağıtım mantığı kullanılır:
| Görev | 1 portta akış sayısı | Açıklama |
|---|---|---|
| Facebook Ads hesapları oluşturma | 1 | Kesinlikle 1 hesap için 1 stabil IP, tercihen sabit (sticky session) |
| Müşteri Instagram hesaplarını yönetme | 1 | Kısa süreli eşzamanlı oturum bile anomali olarak algılanır |
| TikTok Ads ile ısınma | 1 | TikTok, bir oturum içinde IP değişikliklerine karşı özellikle hassastır |
| Hesapların toplu kontrolü (işlem yapmadan) | 2-3 | Ana aktivite için risk oluşturmadan hafif kontrol işlemleri için kabul edilebilir |
Bu şemada IP'nin stabilitesi kritik öneme sahiptir: eğer proxy, oturum ortasında adres değiştirirse, bu hesap ile "kişilik" arasındaki bağı koparır ve cihaz değişikliği olarak görünür. Bu nedenle, çoklu hesap yönetimi için genellikle yerleşik proxy'ler alınır, böylece bir IP uzun süreli olarak sabit tutulabilir (sticky session 10 dakikadan birkaç saate kadar), ve özellikle hassas platformlar için mobil proxy'ler, en "insan gibi" trafik profili sağlar.
Dolphin Anty, AdsPower, Multilogin veya GoLogin gibi anti-detect tarayıcılarında bu ayar basitçe yapılır: her hesabın profilinde kendi proxy portu belirtilir, tüm tarayıcı için ortak bir havuz yerine. Profil ayarlarını açın → "Proxy" bölümüne gidin → her hesap için ayrı verileri (IP, port, kullanıcı adı, şifre) girin → kaydedin. Böylece iki hesabın aynı anda aynı IP üzerinde olma durumunu fiziksel olarak dışlamış olursunuz.
Pazar yerlerinin parse edilmesi için hesaplama
Wildberries, Ozon veya Avito'yu parse ederken mantık tersinedir. Burada "kişilik" kavramı yoktur — "bir IP'den birim zamanda istek sıklığı" kavramı vardır. Pazar yerlerinin koruma mekanizmaları, eşzamanlı akış sayısına değil, istek hızına ve davranış kalıbına (aynı aralıklar, duraksama olmaması, aynı başlıklar) tepki verir.
Pratik hesaplama şu formüle dayanır:
Pratikte, çoğu büyük pazar yeri için güvenli koridor — 1-3 saniye arasında istekler arasında duraksama ile bir veri merkezi IP'si başına 3-8 eşzamanlı akıştır. Bu değeri aştığınızda, 403 ve 429 yanıtlarının yüzdesi artar (captcha, isteklerin geçici olarak engellenmesi).
| Platform | 1 IP başına önerilen akış sayısı | İstekler arasındaki gecikme |
|---|---|---|
| Wildberries (ürün kartları) | 3-6 | 1-2 sn |
| Ozon (fiyat izleme) | 4-8 | 1-2 sn |
| Avito (ilanların parse edilmesi) | 2-4 | 2-4 sn |
| Yandex.Market | 3-5 | 1-3 sn |
Eğer amacınız büyük bir ürün hacmini hızlı bir şekilde aşmaksa, doğru yol bir IP'yi limitin üzerinde "yüklemek" değil, IP adresleri havuzunu artırmak ve yükü dağıtmaktır. 1000 ürün ve 1,5 saniye gecikme ile 5 akış limiti olan bir IP, 5 dakikada yaklaşık 200 isteği işleyebilir — ancak 10 IP'lik bir havuz ile aynı işlem yaklaşık 30 saniye sürecektir. Bu tür görevlerde hız/maliyet oranı açısından en uygun olanlar veri merkezi proxy'leridir — bunlar yerleşik olanlardan daha hızlıdır ve yetkilendirme gerektirmeyen halka açık sayfaların parse edilmesi için yeterlidir.
Yerleşik vs mobil vs veri merkezi: akış tablosu
Aşağıda, proxy türüne ve görev niteliğine bağlı olarak güvenli eşzamanlı akış limitini hızlı bir şekilde tahmin etmeye yardımcı olan genel bir tablo bulunmaktadır. Rakamlar tahmini olup belirli bir platforma bağlıdır, ancak planlama için doğru büyüklük sıralarını verir.
| Proxy türü | Çoklu hesap yönetimi (akış/port) | Parse etme (akış/port) | Özellik |
|---|---|---|---|
| Yerleşik proxy'ler | 1 | 3-5 | Platformların yüksek güveni, esnek döngüleme |
| Mobil proxy'ler | 1 | 2-3 | Maksimum "insanlık", ancak sınırlı bant genişliği |
| Veri merkezi proxy'leri | sosyal medya için önerilmez | 5-10 | Yüksek hız ve düşük fiyat, ancak sosyal medya tarafından daha kolay tespit edilir |
Dikkat: veri merkezi proxy'leri, teknik olarak birden fazla Instagram hesabı açmanıza izin vermez, ancak bu tür IP'ler sosyal medya tespit veritabanlarında "sunucu" olarak daha sık yer alır, bu da tek bir akışta bile yasaklama riskini önemli ölçüde artırır. Sosyal medya ve reklam platformları için akış sayısından daha önemli olan, IP'nin türü ve itibarıdır.
Yük hesaplamasında yaygın hatalar
Pratikte, çoğu yasaklama ve engelleme, kötü proxy'lerden değil, akışların yanlış dağıtımından kaynaklanmaktadır. İşte en sık yapılan hatalar:
- Genel proxy havuzu tüm anti-detect tarayıcı için. Eğer profil ayarlarında her hesap için bireysel bir port belirtilmemişse, sistem iki profili aynı IP üzerinden yönlendirebilir.
- Parser'daki gecikmeleri göz ardı etmek. İstekler arasında duraksama olmadan çalışan bir script, otomasyon olarak hemen tespit edilen bir kalıp oluşturur, hatta akış bir tane olsa bile.
- Aynı portta görevleri karıştırmak. Bir proxy'yi aynı anda hem hesap ısınması hem de akış parse etme için kullanmak, ani yasaklamaların tipik bir nedenidir.
- Aktif bir oturum ortasında IP döngüsü. Çoklu hesap yönetimi için sticky oturum önemlidir: bir hesapla çalışırken IP değişikliği, hesabın tehlikeye girdiği gibi görünür.
- Akışları "göz kararı" hesaplamak. Platformun yanıt süresini ve gerçek limitlerini dikkate almadan, IP'yi aşırı yüklemek veya proxy havuzunu etkisiz bir şekilde kullanmak kolaydır.
Kontrol listesi: gerekli akış sayısını nasıl hesaplayabilirsiniz
Göreve başlamadan önce — ister Facebook Ads hesapları oluşturma, ister Wildberries'de fiyat izleme olsun — kısa bir kontrol listesinden geçin:
- Trafik türünü belirleyin: çoklu hesap yönetimi (1 hesap = 1 akış = 1 IP) veya parse etme (1 IP üzerinde birden fazla istek kabul edilebilir).
- Platformun kamuya açık istek limitleri (rate limits) veya belgelenmiş yasaklama eşikleri olup olmadığını kontrol edin.
- Sosyal medya ve reklam panelleri için yerleşik veya mobil IP'leri seçin ve 1 akışı portta kesin olarak sabitleyin.
- Parse etme için "istek limiti ÷ yanıt süresi" formülünü hesaplayın ve yük artışları için %20-30 ekleyin.
- İstekler arasında duraksamaları manuel olarak ayarlayın, hatta parse etme aracı bunu varsayılan olarak gerektirmiyorsa bile.
- Ölçeklenmeden önce küçük bir IP havuzunda test edin — böylece belirli bir platformun yasaklama eşiğini gerçekçi bir şekilde görebilirsiniz.
- Hata günlükleri (403, 429, captcha) tutun — bu kodların artışı, mevcut akış limitinin aşıldığını gösterir.
Sonuç
"Proxy portu kaç akış tutar" sorusuna evrensel bir cevap yoktur — her şey trafik türüne bağlıdır. Facebook Ads, TikTok Ads veya Instagram için çoklu hesap yönetiminde kural şudur: 1 hesap — 1 IP — 1 akış ve burada IP'nin itibarı, bant genişliğinden daha önemlidir. Wildberries, Ozon veya Avito'yu parse etmek için, istekler arasındaki duraksamalar doğru ayarlandığında, bir IP üzerinde güvenli bir şekilde 3-8 eşzamanlı akış tutabilirsiniz.
Eğer amacınız zincir yasaklama riski olmadan birçok hesabı oluşturmak ve yönetmekse, yerleşik proxy'lere ve sabit oturum desteğine dikkat edin, özellikle hassas platformlar için mobil proxy'leri tercih edin. Eğer amacınız fiyat ve ürün kartlarını hızlı ve büyük ölçekte parse etmekse, IP'nin "insanlığı"ndan daha önemli olan hız için birkaç veri merkezi proxy'sinin havuzunu kullanarak yükü eşit şekilde dağıtmak, güvenli akış limitini aşmadan daha mantıklıdır.