← Torna al blog

Proxy per ZennoPoster e BAS nel 2026: flussi, rotazione e monitoraggio del traffico

ZennoPoster 7.9.1 ha imparato a contare il traffico per ogni proxy, mentre 7.9.2 e BAS 30.8.0 sono passati a Chromium 152 e 153. Analizziamo passo dopo passo: quale modalità di rotazione scegliere per gli account e il parsing, come assegnare ai flussi le proprie porte dall'elenco in ZennoPoster e dalla risorsa in BAS, perché una porta non può essere assegnata a due account consecutivi e quanti gigabyte consuma il modello browser.

📅29 settembre 2026
Proxy per ZennoPoster e BAS nel 2026: flussi, rotazione e monitoraggio del traffico

ZennoPoster e BAS (Browser Automation Studio) sono due costruttori di bot popolari nell'ambiente russofono: vengono utilizzati per raccogliere registrazioni, riscaldamento, pubblicazione e parsing. Entrambi utilizzano proxy come principale risorsa, e gli errori più comuni non riguardano il formato della stringa, ma lo schema: due flussi si collegano a un solo IP, l'indirizzo cambia nel mezzo della registrazione, e il modello del browser scarica decine di gigabyte di immagini durante la notte. Entro l'autunno del 2026, controllare questo è diventato più semplice: ZennoPoster 7.9.1 del 11 agosto ha imparato a contare il traffico per ogni proxy direttamente dal progetto, mentre ZennoPoster 7.9.2 (17 settembre) e BAS 30.8.0 (16 settembre) hanno aggiornato i browser a Chromium 152 e 153. Di seguito è riportato uno schema operativo "un flusso - un IP" per entrambi i programmi, la scelta della rotazione in base al compito e il calcolo del traffico prima che arrivi la fattura.

Cosa è cambiato nel 2026 e perché è importante per i proxy

Se i modelli funzionano su versioni all'inizio dell'anno, parte dei problemi con i proxy può essere risolta con un semplice aggiornamento. Dalle note di rilascio di ZennoLab e Bablosoft, cinque punti sono importanti per lavorare con i proxy:

  • ZennoPoster 7.9.0 (25 giugno). Il cubo "Elaborazione immagine → Salvataggio immagine → URL" ha imparato a lavorare tramite proxy. Prima di questo, il cubo andava a cercare l'immagine senza proxy, con l'IP della macchina su cui gira il modello, una piccola perdita che è facile non notare.
  • ZennoPoster 7.9.1 (11 agosto). È stato introdotto il conteggio del traffico in entrata e in uscita in byte per ogni proxy: per i browser Chromium e ChromiumFromZB (incluso WebSocket, senza risposte dalla cache) e per tutti i cubi HTTP - normali, alternativi e TLS. I dati sono disponibili nel codice tramite l'oggetto ZennoPoster.ProxyTrafficInfo.
  • Nella stessa versione l'emulazione dei dati geografici e del fuso orario ha iniziato a considerare gli indirizzi IPv6, e i profili ZennoBrowser con proxy SOCKS5 in integrazione hanno smesso di bloccarsi per timeout all'avvio.
  • ZennoPoster 7.9.2 (17 settembre). API HTTP pubblica per oltre 100 operazioni, tre server MCP per assistenti IA e modalità agente del cubo "IA Agente", che gestisce autonomamente il browser del compito. Il motore è Chromium 152.
  • BAS 30.8.0 (16 settembre). Il motore è stato aggiornato alla versione 153, sono state introdotte la modalità Agente, che crea, modifica e testa script in base a una descrizione testuale, e un modulo per la generazione di codici di autenticazione a due fattori.

Conclusione pratica: prima di scalare i modelli, aggiornate almeno a ZennoPoster 7.9.1 e BAS 30.8.0. Il conteggio del traffico per ogni proxy è esattamente ciò che mancava quando si pagava per i gigabyte.

Passo 1. Scegli la modalità di rotazione in base al compito

Risposta breve: per lavorare con gli account è necessaria una sessione sticky con una porta separata per ogni flusso; per il parsing con richieste HTTP - un nuovo IP per ogni richiesta; per il parsing del browser senza accesso all'account - una sessione sticky con intervallo breve.

In ProxyCove, la modalità è impostata tramite la porta. La porta 824 cambia IP ad ogni richiesta. Le porte 10000–20000 funzionano con rotazione per intervallo: ogni porta fornisce il proprio IP e lo mantiene per un tempo specificato - da 1 a 120 minuti. L'intervallo può essere modificato nelle impostazioni di rotazione nella scheda proxy.

  • Registrazione, riscaldamento, pubblicazione. L'account ha bisogno di un indirizzo stabile per l'intero ciclo. Impostate l'intervallo con un margine rispetto alla durata di un ciclo: se la registrazione con conferma email richiede 20-25 minuti, prendete 40-60. Cambiare IP nel mezzo del modulo è una causa tipica di checkpoint.
  • Raccolta dati con cubi GET/POST. Ogni richiesta è autonoma, non è necessario mantenere la sessione. La porta 824 distribuisce il carico sul pool e riduce la possibilità di incorrere in limiti su un solo IP.
  • Parsing del browser senza login. Qui la rotazione per ogni richiesta è dannosa. Secondo i dati di Web Almanac 2025, la pagina media su desktop fa 77 richieste a diverse risorse, e sulla porta 824 parti di una stessa pagina verranno inviate da indirizzi diversi. Per i sistemi anti-bot questo comportamento è atipico, quindi scegliete una porta sticky con un intervallo di 1-5 minuti e cambiate IP tra le pagine, non all'interno di esse.

Passo 2. Scegli il tipo di proxy

Il tipo determina non solo il prezzo per gigabyte, ma anche come la piattaforma si relaziona all'indirizzo:

  • Residenziali - IP di provider domestici. Scelta base per modelli di browser, marketplace, scraping SEO e registrazioni su siti di media severità. In ProxyCove i proxy residenziali con scelta di paese e intervallo di rotazione costano $2,70 per GB.
  • Mobile - indirizzi di operatori di telecomunicazioni. Con un solo IP di questo tipo tramite CGNAT, molti abbonati reali accedono contemporaneamente alla rete, quindi i social network li bloccano con maggiore cautela. Questa è la scelta per account sui social network e piattaforme rigorose: i proxy mobili costano $3,80 per GB.
  • Data center - $1,50 per GB, veloci e economici, ma le loro sottoreti sono ben conosciute dai sistemi anti-bot. Adatti per scraping HTTP su siti favorevoli e API, ma una cattiva scelta per account sui social network.

Se per la piattaforma è importante una geografia stabile, e non un indirizzo specifico, attivate il targeting per città o operatore (ASN). L'IP cambierà, ma all'interno di una sola città o rete, come un utente normale. Il targeting è più costoso: per i residenziali - $4,70 per GB.

Passo 3. Prepara la lista "una porta - un flusso"

  1. Apri la scheda proxy nel pannello di controllo di ProxyCove e attiva la rotazione per intervallo.
  2. Nel campo "Numero di flussi" indica quante righe sono necessarie. Le porte non vengono tariffate separatamente - paghi solo per il traffico, quindi prendi una lista 2-3 volte più lunga del numero di flussi. Perché - lo spiegheremo più avanti.
  3. Scegli il formato http o socks5. Il pannello genererà righe con le porte 10000, 10001, 10002 e così via: ogni riga è una sessione separata con il proprio IP.
  4. Salva la lista in un file, ad esempio proxies.txt. La riga appare così: socks5://login:[email protected]:10000.

Se è attivato il targeting, i parametri di paese, città o ASN vengono aggiunti al login tramite punto e virgola. Copiate l'intera riga e non modificarla manualmente: un errore nei parametri romperà l'autenticazione o il targeting.

Passo 4. ZennoPoster: il proprio proxy per ogni flusso

In ZennoPoster, i proxy possono essere impostati globalmente, per progetto o per flusso. Per il lavoro multi-flusso, è più affidabile prendere la riga dalla lista all'interno del modello:

  1. Aggiungi nel ProjectMaker il blocco "Lista", attiva "Carica da file" e "Salva le modifiche della lista in un file", specifica il percorso a proxies.txt.
  2. Aggiungi "Operazione sulla lista": "Ottieni riga" → "Primo" con la casella di controllo "Elimina riga dopo il prelievo". Metti il risultato in una variabile, ad esempio proxy. L'eliminazione garantisce che due flussi paralleli non prendano la stessa porta.
  3. Aggiungi "Browser → Impostazioni → Imposta proxy" e passa {-Variable.proxy-}. Attiva l'emulazione della posizione e del fuso orario: il browser riceverà dati geografici e fuso orario dall'IP del proxy.
  4. In ogni cubo HTTP (GET, POST) specifica lo stesso proxy - tramite variabile o opzione proxy del progetto. Un campo proxy vuoto nel cubo significa richiesta con l'IP del server.
  5. Alla fine del ciclo - sia nel ramo di successo che in quello di errore - restituisci la riga alla fine della lista. Altrimenti, la lista si svuoterà gradualmente e ogni flusso fallito "mangerà" la porta per sempre.

Il ProxyChecker integrato è comodo per liste pubbliche, ma per un gateway con pagamento per traffico, il controllo regolare dell'intera lista è inutile: ogni controllo consuma megabyte pagati, e sulla porta 824 la richiesta successiva andrà comunque da un altro IP. Prima di un grande avvio, è sufficiente controllare un paio di righe.

Passo 5. BAS: risorsa con proxy e azione Proxy

  1. Crea una risorsa di tipo "File" o "URL" con la lista di proxy - proprio come consiglia la documentazione di Bablosoft, affinché l'utente del modello scelga la fonte.
  2. Nei parametri della risorsa, limita l'uso simultaneo della riga a un flusso. Qui vengono impostati anche i limiti per usi riusciti e non riusciti e l'intervallo tra gli usi - per le porte sticky, impostalo non inferiore all'intervallo di rotazione.
  3. Come prima azione del flusso, prima di caricare qualsiasi pagina, imposta "Proxy" e passa la riga dalla risorsa. BAS comprende molti formati, inclusi login:password@host:port e socks5://login:password@host:port, funziona con HTTP e SOCKS5 con autorizzazione e invia richieste DNS tramite proxy.
  4. Attiva nel'azione il cambio di geolocalizzazione e fuso orario in base all'IP del proxy.
  5. Se il modello accede al sito anche come client HTTP, imposta il proxy anche per esso: il client HTTP di BAS ha le proprie impostazioni, separate da quelle del browser.

Ci sono due caratteristiche di BAS da considerare. Il proxy cambia senza riavviare il flusso, con l'azione ripetuta "Proxy", - questo è comodo per cambiare IP in caso di errore. E se il proxy smette di rispondere, BAS riavvia il flusso e prende il successivo. Per il parsing questo è un vantaggio, per gli account - un rischio: il lavoro continuerà con un altro IP. Conserva il legame "account - porta" e restituisci l'account alla sua porta.

Passo 6. Calcola il traffico prima di avviare

Quando si paga per gigabyte, il modello del browser è la parte più costosa dello schema. Secondo i dati di Web Almanac 2025, la pagina principale media pesa 2862 KB su desktop, di cui 1058 KB sono immagini. 10.000 caricamenti di tali pagine - circa 28,6 GB, con proxy residenziali questo è circa $77. Senza immagini - circa 18 GB e $49. I numeri reali dipendono dal sito e dalla cache, ma l'ordine è chiaro: le immagini rappresentano più di un terzo della fattura.

  • BAS. Le azioni "Request mask deny" e "Request mask allow" vengono impostate prima del caricamento della pagina e accettano maschere con asterisco. Nella documentazione di Bablosoft, un esempio: vietare *.png, *.jpg e *.gif, e poi consentire l'immagine del captcha, in modo che venga caricata solo quella.
  • ZennoPoster. Il risparmio maggiore è spostare la raccolta dati dal browser ai cubi GET/POST: non caricano immagini, font e script. Nella finestra "Traffico" è visibile quali richieste pesano di più, e dalla versione 7.9.1 il volume per ogni proxy può essere letto dal codice tramite ZennoPoster.ProxyTrafficInfo, scritto nel log e fermato il flusso al superamento della soglia.
  • Attenzione ai social media. Una pagina senza immagini per un utente reale è rara, e su alcune piattaforme questo di per sé appare atipico. Per gli account è meglio limitarsi a bloccare video e media pesanti, lasciando le immagini.

Confronta il tuo conteggio con il pannello: lì puoi vedere il saldo e il grafico di consumo per ogni proxy. I dati del provider vengono aggiornati con ritardo, quindi è più comodo mantenere il controllo operativo direttamente nel modello.

Insidie

  • Perdite di IP reale. Cubo HTTP senza proxy, salvataggio di immagini tramite URL in ZennoPoster fino alla versione 7.9.0, WebRTC. Come primo passo del modello, apri una pagina di verifica IP e WebRTC e confronta il risultato con l'indirizzo del proxy - è più economico che risolvere un ban.
  • Cambio di IP nel mezzo della sessione. Se l'intervallo di rotazione è più breve del ciclo dell'account, la piattaforma vede un salto dell'indirizzo tra i passaggi di un modulo. L'intervallo massimo in ProxyCove è di 120 minuti; per scenari lunghi, suddividi in sessioni brevi mantenendo il profilo.
  • Un IP per due account. Finché l'intervallo di rotazione non è scaduto, la porta restituisce il precedente indirizzo. Se la porta viene immediatamente assegnata al successivo account, questo accede alla rete con l'IP precedente. Ecco perché si consiglia di avere una lista lunga: con 30 flussi e 90 porte, ogni porta ha il tempo di "raffreddarsi" prima di essere riutilizzata.
  • Discrepanza geografica. Il fuso orario e la geolocalizzazione del browser devono corrispondere al paese dell'IP. Se il proxy è "tedesco", ma il sito mostra i Paesi Bassi, di solito il problema è nelle banche dati di geolocalizzazione, non nel proxy - ecco come funziona la geolocalizzazione IP e perché le banche dati non coincidono.
  • Impronta del motore. Le nuove versioni di Chromium portano nuovi segnali. In Chrome 152 è emersa la proprietà navigator.cpuPerformance - classe del processore, che dipende principalmente dal numero di core, e ZennoPoster 7.9.2 e BAS 30.8.0 funzionano su Chromium 152 e 153. Se i modelli girano su VPS con due core, mentre i profili mostrano desktop potenti, controlla cosa restituisce questa proprietà: analisi del nuovo segnale di rilevamento in Chrome 152.
  • Agenti IA e traffico. La modalità agente del cubo "IA Agente" in ZennoPoster 7.9.2 gestisce il browser del compito, il che significa che accede alla rete tramite il suo proxy. Il suo ciclo è limitato da un obbligatorio limite di iterazioni - non impostare un limite con un grande margine: ogni iterazione extra costa sia token che megabyte.

Conclusione

Lo schema per entrambi i programmi è lo stesso: una porta sticky separata per ogni flusso, un intervallo di rotazione più lungo del ciclo dell'account, una pausa prima del riutilizzo della porta, geolocalizzazione e fuso orario in base all'IP, proxy in tutte le richieste HTTP e conteggio del traffico fin dal primo giorno. Iniziate con un flusso: verificate l'IP, WebRTC e il fuso orario, eseguite un centinaio di cicli e osservate il consumo in ZennoPoster.ProxyTrafficInfo o nel pannello. Dopo di che, scalare il modello a decine e centinaia di flussi sarà più sicuro e conveniente. Per scenari di browser con account, scegliete proxy residenziali o mobili con rotazione per intervallo, per il parsing HTTP - una porta con un nuovo IP per ogni richiesta.