/proxies üzerindeki satır-başı dropdown beş tünelle çalışırken dosttur. Yüz kırkında cehennem azabına dönüşür. Bir noktada tünelleri tek tek durdurup-protokol-değiştirip-yeniden-başlatmaktan vazgeçer ve tüm filoya — ya da hassasça filtrelenmiş bir dilimine — tek seferde işlem yapmanın bir yoluna ihtiyaç duyarsınız.
Toplu işlemler tam olarak o an için inşa edilmiştir. Panel, birden fazla satırı işaretlediğiniz anda beliren yapışkan bir seçim çubuğu aracılığıyla bunları sunar; çubuktaki her eylem aynı zamanda REST API'sinde de mevcuttur, böylece kendi provisioning script'leriniz aynı mantığı yürütebilir. Bu rehber her iki yolu, ölçekte ısıran uç durumları ve her şeyi otomatik bir iş akışına nasıl bağlayacağınızı kapsar.
Satır-satır yönetim ölçekte neden bozulur
Eklediğiniz her ek proxy, rutin bakım için tıklama sayısını çarpar. Bir operatör kesintisinden sonra yirmi cihazlık bir havuzu yeniden başlatmak, bir scraping çalıştırmasından önce token grubundaki IP'leri döndürmek ya da yeni bir müşteri için bir partiyi HTTP'den SOCKS5'e geçirmek — bu işlemlerin her biri bir eylem almalı, yirmi ayrı işlem değil. Toplu araç olmadan operatörler API'ye karşı kırılgan shell döngüleri yazmak ya da daha kötüsü elle yapmak ve bir kısmını kaçırmak zorunda kalır.
Panelin toplu sistemi ve eşleşen API uç noktası bu boşluğu ortadan kaldırır. Satır başına yapabildiğiniz her şeyi, hangi öğelerin başarılı olduğunu ve hangilerinin yeniden denenmesi gerektiğini tam olarak bilmenizi sağlayan tutarlı bir id-başı sonuçla, herhangi bir ölçekte seçim başına yapabilirsiniz.
Paneldeki seçim çubuğu
/proxies'de her satırın sol oluğunda bir checkbox vardır. İkisini veya daha fazlasını işaretleyin; tablonun altından yapışkan bir eylem çubuğu kayar yukarı. Seçimler sıralama ve sütun filtrelemesinden sağ çıkar, bu yüzden en verimli iş akışı şudur: etikete, token'a veya protokole göre filtrele, filtrelenmiş sayfadaki tümünü seç, sonra işlemi uygula. Her eylemin yaptığı şey:
| Eylem | Ne yapar | Notlar |
|---|---|---|
| Başlat | Seçilen her tüneli edge'de ayağa kaldırır | Zaten çalışan proxy'ler hata değil, no-op'tur |
| Durdur | Listener'ları nazikçe yıkar ve edge portlarını serbest bırakır | Boştaki proxy'ler kullanım tahakkuk ettirmez; faturalama yalnızca aktifken işler |
| Protokol değiştir | Bir partiyi HTTP, HTTPS ve SOCKS5 arasında geçirir |
Port numarası aynı kalır; yalnızca kablo protokolü değişir |
| IP Döndür | Seçimdeki eşleştirilmiş her cihaza bir rotasyon ipucu gönderir | Yalnızca-upstream proxy'leri atlar; cihaz sıcak rotasyonu desteklemiyorsa nazikçe geri düşer |
| Sil | Seçilen proxy'leri kalıcı olarak kaldırır | Yıkıcı ve çift onaylı; kaydetmeden önce sayıyı yüzeye çıkarır |
Eşleşen API çağrısı
UI'daki her toplu eylem aynı REST uç noktasını çağırır. Script'lerden, CI pipeline'larından veya herhangi bir düzenleme katmanından doğrudan çağırabilirsiniz:
POST /api/v1/proxies/bulk
Authorization: Bearer $KEY
Content-Type: application/json
{
"action": "stop",
"ids": ["px_8x2q...", "px_3KZL...", "px_NPJX..."]
}Geçerli action değerleri panel çubuğunu yansıtır: start, stop, rotate, delete ve set_protocol. Sonuncusu hedef protokolü adlandırmak için fazladan bir body alanı alır:
{
"action": "set_protocol",
"protocol": "socks5",
"ids": ["px_8x2q...", "px_3KZL..."]
}Yanıt, tek bir geçti/kaldı yerine id-başı bir sonuç haritasıdır. Bu kasıtlıdır: iki yüzlük bir filoda, neredeyse hiçbir zaman bir token çevrimdışıyken tüm partiyi iptal etmek istemezsiniz.
{
"results": {
"px_8x2q...": { "ok": true, "state": "stopped" },
"px_3KZL...": { "ok": false, "error": "token_offline" },
"px_NPJX...": { "ok": true, "state": "stopped" }
},
"summary": { "ok": 2, "failed": 1 }
}Bir provisioning script'i results üzerinde döngü kurmalı, başarısız id'leri toplamalı ve çevrimdışı mobil cihazlar yeniden bağlandığında bunları yeniden denemeli — tam listeyi yeniden göndermek yerine.
Limitler ve edge'de ne olur
Bir çağrı en fazla 200 id kabul eder. Daha büyük filolar istemci tarafında parçalanmalıdır. Uç nokta hızlıdır ancak streaming değildir ve yavaş bir bağlantıda çok büyük tek bir çağrı, sunucu tüm emirleri sıraya almadan önce zaman aşımına uğrayabilir. 200 sınırı, panelin "sayfadaki tümünü seç" sayfa boyutuyla eşleşir, bu yüzden iki yüzey istemci tarafı mantığı olmadan senkronize kalır.
Uç nokta, kişisel API anahtarı başına dakikada 5 çağrı ile hız sınırlıdır. Müşteri API token'ları — bayi müşterilerinize verdiğiniz kapsamlı kimlik bilgileri — /bulk'u hiç çağıramaz. Toplu kontrol, hesap-sahibi bir primitive'dir; müşteriler kendilerine atanmış proxy'lerle kendi kimlik bilgileri aracılığıyla etkileşime girer. Tam ayrım için kişisel vs müşteri token'ları'nı okuyun.
Toplu durdurma işlemleri anlıktır — edge listener'ı senkron olarak keser. Toplu başlatma işlemleri async'tir — uç nokta emirler sıraya alınınca döner, ancak listener'ların edge sunucuda gerçekten bağlanması her biri için 2-5 saniye alır. Script'inizin canlı onay beklemesi gerekiyorsa, tüm durumlarrunning'e geçene kadar/api/v1/proxies?ids=...'i polleyin.
Kısmi başarısızlık: en yaygın neden ve doğru düzeltme
Bir satırın ok: false ile geri gelmesinin en yaygın tek nedeni token'ın çevrimdışı olmasıdır. Bağlantısını kaybetmiş eşleştirilmiş bir telefon bir rotasyon ipucu alamaz ya da protokol değişikliğini tamamlayamaz. Toplu uç nokta bunu tüm çağrıyı başarısız etmek yerine id başına yüzeye çıkarır. Doğru yanıt, başarısızlıkları hata türüne göre filtrelemektir: token_offline öğeleri daha sonra güvenle yeniden denenebilir; not_found öğeleri, filo manifestonuzdan kaldırılması gereken eskimiş id'lere işaret eder.
Bireysel cihazlar düştüğünde bile uygun kalması gereken havuzlar için otomatik devralma ve token grupları'nı değerlendirin — round-robin seçim, trafiğin şu anda bağlı olmayan bir cihaza asla gönderilmemesini sağlar.
Toplu işlemleri bir iş akışına entegre etmek
Otomatik filo yönetimi için en etkili örüntü üç adımlı bir döngüdür. Önce, API'ye bir liste çağrısı yaparak tüm proxy id'lerini alın. İkinci olarak, görevinizle ilgili kriterlere göre filtreleyin veya gruplandırın — protokol, etiket, token veya son görülme zamanı. Üçüncü olarak, filtrelenmiş id'leri 200'e kadar olan sayfalarda /bulk'a gönderin. Id kalmayıncaya kadar üçüncü adımı tekrarlayın.
Mevcut olanı işletmek yerine sıfırdan bir filo oluşturmak için — programatik provisioning —, bu rehberi uçtan uca tamamlayan Python ile programatik tünel oluşturma'ya bakın. Kota limitleri ve thread limitleri gibi müşteri-başı kontroller istemci düzeyinde ayarlanır, toplu uç nokta aracılığıyla değil — başlatma/durdurma döngülerinden bağımsız olarak yerinde kalırlar.
Ölçekte protokol seçimleri
Büyük bir filoda hangi protokolün kullanılacağına karar verirken set_protocol eylemi deney yapmayı kolaylaştırır. HTTP ve HTTPS, tarayıcı-güdümlü scraping ve çoğu API istemcisi için doğru varsayılandır. SOCKS5, ham TCP yönlendirmesine ihtiyaç duyduğunuzda daha iyidir — HTTP-dışı trafik, özel araçlar veya protokolü kendisi müzakere eden herhangi bir istemci. Tam ödünleşimleri HTTP vs SOCKS5: hangisini seçmeli yazısında okuyabilirsiniz. Toplu protokol değişikliği aynı portu koruduğu için, uç noktaya başvuran herhangi bir istemci yapılandırmasını güncellemeden bir partiyi geçirebilirsiniz — yalnızca proxy katmanındaki kablo protokolü değişir.
Başlayın
API ile henüz konuşmadıysanız, kişisel anahtarınızı almak ve kimlik doğrulamayı anlamak için ilk REST çağrınız ile başlayın. Anlamlı bir filo yönetiyor olduğunuzda, toplu uç nokta onu işletmenin tek en hızlı yoludur. Tam panele ve API'ye erişim için hesap oluşturun ya da toplu işlemlerin yanında başka neler mevcut olduğunu görmek için tam özellik setini keşfedin.