Se lavori con un gran numero di proxy — per fare scraping di marketplace, gestire più account sui social media o avviare pubblicità — conosci il problema: improvvisamente parte dei proxy smette di funzionare e i tuoi compiti si bloccano. L'health check (verifica della funzionalità) del pool di proxy risolve automaticamente questo problema: il sistema verifica ogni IP, esclude quelli non funzionanti e utilizza solo connessioni stabili.
In questa guida vedremo come configurare un health check automatico per il pool di proxy: dalla semplice verifica della disponibilità al monitoraggio avanzato con sostituzione dei proxy difettosi. Adatto per qualsiasi compito — dallo scraping di Wildberries al multi-accounting in Facebook Ads.
Che cos'è l'health check dei proxy e a cosa serve
L'health check (verifica della funzionalità) è un sistema automatico di monitoraggio del pool di proxy che controlla regolarmente ogni indirizzo IP per disponibilità, velocità e correttezza del funzionamento. Quando lavori con decine o centinaia di proxy, alcuni di essi smettono inevitabilmente di funzionare: scade la validità, l'IP viene bloccato, il provider blocca l'accesso o semplicemente la velocità diminuisce.
Senza l'health check, scoprirai il problema solo quando il compito fallisce con un errore: il parser non raccoglierà dati, l'account verrà bloccato a causa di un proxy non funzionante, oppure la pubblicità non verrà avviata. Con l'health check configurato, il sistema esclude automaticamente i proxy difettosi dalla rotazione e utilizza solo connessioni stabili.
A cosa serve l'health check:
- Stabilità operativa: esclusione dei proxy non funzionanti prima che possano compromettere il tuo compito
- Risparmio di tempo: non è necessario controllare manualmente ogni IP e cercare la causa degli errori
- Sicurezza degli account: un proxy lento o instabile può suscitare sospetti da parte della piattaforma
- Ottimizzazione dei costi: paghi solo per proxy funzionanti, non per l'intero pool
L'health check è particolarmente critico per le attività aziendali: se gestisci 30 account clienti su Instagram, fai scraping dei prezzi dei concorrenti su Ozon o avvii pubblicità su Facebook Ads — un'interruzione a causa di un proxy non funzionante può costare denaro e reputazione.
Metodi di verifica della funzionalità dei proxy
Esistono diversi livelli di verifica dei proxy — dalla semplice verifica della disponibilità a un'analisi approfondita dell'anonimato e della velocità. La scelta del metodo dipende dai tuoi compiti: per lo scraping è sufficiente una verifica di base, per il multi-accounting sui social media è necessaria una verifica della geolocalizzazione e dell'anonimato.
1. Verifica di base della disponibilità (Ping Check)
Il metodo più semplice è inviare una richiesta HTTP tramite il proxy a un server di test e controllare se è stata ricevuta una risposta. Di solito si utilizzano servizi pubblici come httpbin.org, ip-api.com o un proprio server di test.
Cosa viene verificato: se il proxy risponde alle richieste o meno (stato 200 OK). Questa è una verifica minima che esclude gli IP completamente non funzionanti.
Quando è sufficiente: scraping di dati pubblici, raccolta di informazioni da siti senza protezione rigorosa, compiti di massa dove la velocità di verifica è importante.
2. Verifica della velocità di risposta (Latency Check)
Viene misurato il tempo di risposta del proxy — quanti millisecondi passano dall'invio della richiesta alla ricezione della risposta. I proxy lenti (più di 3-5 secondi) possono causare timeout e sospetti da parte delle piattaforme.
Cosa viene verificato: tempo di risposta (latency) e stabilità della velocità. I proxy con latency superiore a 5000 ms vengono solitamente esclusi dal pool.
Quando è importante: lavoro con i social media (Instagram, TikTok), pannelli pubblicitari (Facebook Ads, Google Ads), compiti dove la velocità di caricamento delle pagine è importante.
3. Verifica della geolocalizzazione e della reputazione IP
Viene verificata la corrispondenza dell'IP con il paese e la città dichiarati, così come la reputazione dell'IP (se non è presente nelle liste nere, se non viene utilizzato per spam). Per proxy residenziali questo è critico — le piattaforme controllano la corrispondenza della geolocalizzazione con i dati dell'account.
Cosa viene verificato: paese e città dell'IP, provider, presenza in database di spam (DNSBL, Spamhaus), tipo di connessione (residenziale/datacenter).
Quando è critico: multi-accounting sui social media, arbitraggio di traffico, lavoro con account legati a città specifiche (ad esempio, pubblicazione di annunci su Avito).
4. Verifica dell'anonimato (Anonymity Level)
Viene determinato il livello di anonimato del proxy — se trasmette intestazioni che rivelano il tuo vero IP (X-Forwarded-For, Via). I proxy possono essere di tre tipi: trasparenti (trasmettono il vero IP), anonimi (nascondono l'IP, ma mostrano che si tratta di un proxy) ed elite (completamente anonimi).
Cosa viene verificato: presenza delle intestazioni X-Forwarded-For, X-Real-IP, Via, Proxy-Connection. Per le attività aziendali sono necessari solo proxy elite.
Quando è obbligatorio: lavoro con piattaforme con rigida protezione antifrode (Facebook, Google, TikTok), multi-accounting, arbitraggio di traffico.
| Metodo di verifica | Cosa verifica | Per quali compiti |
|---|---|---|
| Ping Check | Disponibilità (200 OK) | Scraping, raccolta dati di massa |
| Latency Check | Velocità di risposta | Social media, pannelli pubblicitari |
| Geo Check | Geolocalizzazione, reputazione IP | Multi-accounting, compiti locali |
| Anonymity Check | Livello di anonimato | Arbitraggio, piattaforme antifrode |
Configurazione di base dell'health check: verifica della disponibilità
Iniziamo con una semplice configurazione dell'health check, che verifica la disponibilità di ogni proxy nel pool. Questo metodo è adatto per la maggior parte dei compiti e richiede 10-15 minuti per la configurazione.
Passo 1: Preparazione della lista di proxy
Crea un file con i tuoi proxy nel formato IP:PORT:USER:PASS o http://user:pass@ip:port. Ogni proxy deve essere su una nuova riga.
Esempio di file proxies.txt:
192.168.1.100:8080:user1:pass1 192.168.1.101:8080:user2:pass2 192.168.1.102:8080:user3:pass3
Passo 2: Scelta dell'URL di test
Per verificare la disponibilità è necessario un server stabile che restituisca una risposta semplice. Opzioni popolari:
- httpbin.org/ip — restituisce l'indirizzo IP del proxy in formato JSON
- ip-api.com/json — restituisce IP e geolocalizzazione
- icanhazip.com — restituisce solo l'IP (il più veloce)
- Il tuo server personale — se è necessaria la verifica dell'accesso a un sito specifico
Per la verifica di base, httpbin.org/ip è sufficiente — è stabile e restituisce una risposta strutturata.
Passo 3: Configurazione dello script di verifica
Crea un semplice script che legge la lista di proxy, invia una richiesta tramite ciascuno e verifica lo stato della risposta. Ecco un esempio in Python (il linguaggio più popolare per tali compiti):
import requests
from concurrent.futures import ThreadPoolExecutor
import time
def check_proxy(proxy_line):
"""Verifica di un proxy"""
try:
# Analizziamo la stringa del proxy
parts = proxy_line.strip().split(':')
proxy_url = f"http://{parts[2]}:{parts[3]}@{parts[0]}:{parts[1]}"
proxies = {
'http': proxy_url,
'https': proxy_url
}
# Inviamo la richiesta con un timeout di 10 secondi
start_time = time.time()
response = requests.get('http://httpbin.org/ip',
proxies=proxies,
timeout=10)
latency = (time.time() - start_time) * 1000 # in millisecondi
if response.status_code == 200:
return {
'proxy': proxy_line,
'status': 'working',
'latency': round(latency, 2),
'ip': response.json().get('origin')
}
except Exception as e:
return {
'proxy': proxy_line,
'status': 'failed',
'error': str(e)
}
# Leggiamo il file con i proxy
with open('proxies.txt', 'r') as f:
proxies = f.readlines()
# Verifichiamo tutti i proxy in parallelo (fino a 20 contemporaneamente)
with ThreadPoolExecutor(max_workers=20) as executor:
results = list(executor.map(check_proxy, proxies))
# Salviamo i proxy funzionanti
working_proxies = [r for r in results if r and r['status'] == 'working']
with open('working_proxies.txt', 'w') as f:
for proxy in working_proxies:
f.write(proxy['proxy'])
print(f"Verificati: {len(proxies)}")
print(f"Funzionanti: {len(working_proxies)}")
print(f"Non funzionanti: {len(proxies) - len(working_proxies)}")
Questo script verifica tutti i proxy in parallelo (20 contemporaneamente), accelerando il processo di decine di volte. Il risultato è un file working_proxies.txt contenente solo proxy funzionanti.
Passo 4: Automazione della verifica
Affinché l'health check funzioni continuamente, imposta l'esecuzione automatica dello script secondo un programma:
Linux/Mac (cron):
# Verifica ogni 30 minuti */30 * * * * /usr/bin/python3 /path/to/check_proxies.py
Windows (utilità di pianificazione):
- Apri "Utilità di pianificazione" (Task Scheduler)
- Crea un nuovo compito → Attivatore: ogni 30 minuti
- Azione: esegui python.exe con il percorso al tuo script
⚠️ Importante:
Non controllare i proxy troppo frequentemente (più di una volta ogni 15 minuti) — questo crea un carico sui servizi di test e può portare a un blocco. Frequenza ottimale: ogni 30-60 minuti per proxy stabili, ogni 10-15 minuti per compiti dove la disponibilità è critica.
Monitoraggio avanzato: velocità, geolocalizzazione, anonimato
Per le attività aziendali, la verifica di base della disponibilità non è sufficiente — è necessario controllare la velocità, la geolocalizzazione e il livello di anonimato. Questo è particolarmente importante per il multi-accounting sui social media e l'arbitraggio di traffico, dove le piattaforme controllano rigorosamente i proxy.
Verifica della velocità e stabilità
Un proxy lento (latency superiore a 3-5 secondi) può suscitare sospetti da parte delle piattaforme: Instagram e Facebook monitorano il tempo di caricamento delle pagine, e una connessione lenta è un segnale di utilizzo di proxy. Inoltre, i proxy lenti rallentano il tuo lavoro e possono causare timeout.
Cosa controllare:
- Latency (tempo di risposta): tempo medio dalla richiesta alla risposta. Normativa: fino a 1000 ms per proxy residenziali, fino a 300 ms per data center
- Velocità di caricamento: quanti kilobyte al secondo vengono scaricati tramite il proxy. Normativa: minimo 500 Kbit/s
- Stabilità: verifica di 3-5 richieste consecutive — la latency non deve oscillare troppo (una variazione superiore al 50% è un cattivo segno)
Esempio di verifica avanzata della velocità:
def check_proxy_speed(proxy_url):
"""Verifica della velocità e stabilità"""
latencies = []
# Facciamo 5 richieste per controllare la stabilità
for i in range(5):
try:
start = time.time()
response = requests.get('http://httpbin.org/ip',
proxies={'http': proxy_url, 'https': proxy_url},
timeout=10)
latency = (time.time() - start) * 1000
latencies.append(latency)
time.sleep(0.5) # pausa tra le richieste
except:
return None
avg_latency = sum(latencies) / len(latencies)
max_latency = max(latencies)
min_latency = min(latencies)
stability = (max_latency - min_latency) / avg_latency * 100
return {
'avg_latency': round(avg_latency, 2),
'stability': round(stability, 2), # % di variazione
'status': 'good' if avg_latency < 3000 and stability < 50 else 'slow'
}
Verifica della geolocalizzazione
Per il multi-accounting è critico che la geolocalizzazione del proxy corrisponda ai dati dell'account. Se gestisci un account di un'azienda di Mosca tramite un proxy di Vladivostok — questo è un segnale rosso per la piattaforma. Utilizza il servizio ip-api.com per verificare la geolocalizzazione:
def check_proxy_geo(proxy_url):
"""Verifica della geolocalizzazione del proxy"""
try:
response = requests.get('http://ip-api.com/json',
proxies={'http': proxy_url, 'https': proxy_url},
timeout=10)
data = response.json()
return {
'ip': data.get('query'),
'country': data.get('country'),
'city': data.get('city'),
'isp': data.get('isp'),
'proxy_type': data.get('proxy'), # True se viene rilevato un proxy
'mobile': data.get('mobile') # True per IP mobili
}
except:
return None
Salva i dati di geolocalizzazione per ogni proxy e utilizzali nella distribuzione dei compiti: account da Mosca — tramite proxy di Mosca, annunci regionali su Avito — tramite proxy della città necessaria.
Verifica dell'anonimato
I proxy possono avere tre livelli di anonimato: trasparenti, anonimi ed elite. Per lavorare con Facebook, Instagram, TikTok e altre piattaforme con protezione antifrode sono necessari solo proxy elite — non trasmettono intestazioni che rivelano l'uso del proxy.
Cosa controllare:
- Intestazioni X-Forwarded-For, X-Real-IP, Via — devono essere assenti
- L'IP nella risposta deve corrispondere all'IP del proxy (non il tuo vero IP)
- User-Agent deve essere trasmesso senza modifiche
def check_proxy_anonymity(proxy_url):
"""Verifica del livello di anonimato"""
try:
response = requests.get('http://httpbin.org/headers',
proxies={'http': proxy_url, 'https': proxy_url},
timeout=10)
headers = response.json()['headers']
# Controlliamo la presenza di intestazioni che rivelano il proxy
proxy_headers = ['X-Forwarded-For', 'X-Real-Ip', 'Via', 'Proxy-Connection']
detected_headers = [h for h in proxy_headers if h in headers]
if len(detected_headers) == 0:
return 'elite' # completamente anonimo
elif 'X-Forwarded-For' not in headers:
return 'anonymous' # nasconde l'IP, ma mostra che si tratta di un proxy
else:
return 'transparent' # trasmette il vero IP
except:
return None
Per le attività aziendali utilizza solo proxy elite. I proxy mobili hanno per impostazione predefinita un livello elite, poiché utilizzano veri IP di operatori mobili.
Rotazione automatica: sostituzione dei proxy difettosi
L'health check diventa veramente utile quando non si limita a controllare i proxy, ma sostituisce automaticamente quelli non funzionanti con quelli funzionanti. Questo è critico per compiti continui: scraping di marketplace, monitoraggio dei prezzi, autopubblicazione sui social media.
Strategia 1: Pool con priorità
Crea due liste di proxy: principale (working) e di riserva (backup). L'health check controlla costantemente il pool principale e, al rilevamento di un proxy non funzionante, lo sostituisce con un proxy dal pool di riserva.
Come funziona:
- L'health check verifica tutti i proxy del pool principale ogni 30 minuti
- I proxy non funzionanti vengono spostati nella lista "in quarantena" (quarantine)
- Un proxy funzionante viene prelevato dal pool di riserva e aggiunto a quello principale
- Dopo 2-4 ore, i proxy in quarantena vengono verificati nuovamente — se funzionano, vengono restituiti al pool di riserva
Esempio di implementazione:
import json
from datetime import datetime, timedelta
class ProxyPool:
def __init__(self):
self.working = [] # pool principale
self.backup = [] # pool di riserva
self.quarantine = {} # {proxy: timestamp quando è stato messo in quarantena}
def check_and_rotate(self):
"""Verifica e rotazione dei proxy"""
failed_proxies = []
# Verifichiamo il pool principale
for proxy in self.working:
if not self.is_proxy_working(proxy):
failed_proxies.append(proxy)
self.quarantine[proxy] = datetime.now()
# Rimuoviamo i non funzionanti dal pool principale
self.working = [p for p in self.working if p not in failed_proxies]
# Aggiungiamo dalla riserva quanto necessario
needed = len(failed_proxies)
for i in range(needed):
if len(self.backup) > 0:
new_proxy = self.backup.pop(0)
if self.is_proxy_working(new_proxy):
self.working.append(new_proxy)
# Controlliamo la quarantena — se un proxy è in quarantena da più di 4 ore, lo verifichiamo
now = datetime.now()
for proxy, quarantine_time in list(self.quarantine.items()):
if now - quarantine_time > timedelta(hours=4):
if self.is_proxy_working(proxy):
self.backup.append(proxy)
del self.quarantine[proxy]
self.save_state()
def save_state(self):
"""Salvataggio dello stato del pool"""
state = {
'working': self.working,
'backup': self.backup,
'quarantine': {k: v.isoformat() for k, v in self.quarantine.items()}
}
with open('proxy_pool_state.json', 'w') as f:
json.dump(state, f)
Strategia 2: Round-robin con esclusione
Un approccio più semplice: utilizza tutti i proxy a turno (round-robin), ma in caso di errore escludi temporaneamente il proxy dalla rotazione per 30-60 minuti. Adatto per compiti dove la velocità è importante, non la stabilità ideale.
Come funziona:
- I proxy vengono selezionati in ordine: 1, 2, 3, 4, 1, 2, 3, 4...
- Se un proxy restituisce un errore, viene escluso per 30 minuti
- Dopo 30 minuti, il proxy torna automaticamente nella rotazione
- Se un proxy fallisce 3 volte di seguito — viene escluso per 4 ore
Questo metodo è utile per scraping e compiti di massa, dove è possibile saltare alcune richieste senza conseguenze critiche.
Strategia 3: Rotazione ponderata per metriche
Approccio avanzato: a ogni proxy viene assegnato un "peso" basato su metriche (velocità, stabilità, successo delle richieste). I proxy con peso elevato vengono utilizzati più frequentemente, quelli con peso basso meno frequentemente. Adatto per compiti critici: multi-accounting, arbitraggio.
Formula del peso:
weight = (success_rate * 0.5) + (speed_score * 0.3) + (uptime * 0.2) dove: - success_rate: % di richieste riuscite nell'ultima ora (0-100) - speed_score: 100 - (latency / 50) — più è veloce, più è alto - uptime: % di tempo in cui il proxy è stato disponibile nelle ultime 24 ore
I proxy con un peso superiore a 70 vengono utilizzati per compiti critici (accesso agli account), con un peso di 40-70 per compiti normali, sotto 40 vengono esclusi temporaneamente.
Strumenti pronti per l'health check del pool di proxy
Se non vuoi scrivere il tuo script, utilizza soluzioni pronte. Molte di esse hanno un'interfaccia web, API e integrazione con strumenti popolari.
1. ProxyChecker di Proxy-Store
Utilità gratuita per Windows/Linux con interfaccia grafica. Controlla disponibilità, velocità, anonimato e geolocalizzazione. Supporta HTTP, HTTPS, SOCKS4/5. Esporta i risultati in TXT, CSV, JSON.
Pro: interfaccia semplice, verifica rapida (fino a 1000 proxy al minuto), filtri per paese e velocità.
Contro: nessuna rotazione automatica, deve essere avviato manualmente.
2. Proxy Scraper & Checker
Progetto open-source in Python con raccolta automatica di proxy gratuiti e health check. Adatto per esperimenti e test, ma non per business (i proxy gratuiti sono instabili).
Pro: gratuito, raccolta automatica di proxy, verifiche personalizzabili.
Contro: qualità dei proxy gratuiti bassa, frequenti blocchi.
3. Proxy Pool Manager (soluzioni commerciali)
Servizi a pagamento con ciclo completo di gestione dei proxy: health check, rotazione automatica, API, integrazione con browser anti-detect (Dolphin Anty, AdsPower, Multilogin). Esempi: Bright Data Proxy Manager, Smartproxy Dashboard, Oxylabs Proxy Rotator.
Pro: tutto in una soluzione, supporto 24/7, integrazioni pronte.
Contro: costo elevato (da $50/mese), legame con un provider di proxy specifico.
4. Health check integrato nei browser anti-detect
Se utilizzi browser anti-detect per il multi-accounting, molti di essi hanno un controllo proxy integrato:
- Dolphin Anty: verifica di disponibilità e velocità all'aggiunta di proxy al profilo
- AdsPower: verifica automatica dei proxy prima dell'avvio del profilo
- Multilogin: tester proxy integrato con verifica dell'anonimato
- GoLogin: verifica della geolocalizzazione e della reputazione IP
Questi strumenti sono comodi per specialisti SMM e arbitraggisti che lavorano con un numero limitato di account (fino a 50-100). Per grandi volumi è necessaria una soluzione propria.
| Strumento | Tipo | Funzioni | Per chi |
|---|---|---|---|
| ProxyChecker | Utilità gratuita | Verifica disponibilità, velocità, anonimato | Piccole imprese, verifiche occasionali |
| Script personale | Open-source | Massima personalizzazione, automazione | Sviluppatori, grandi pool |
| Proxy Manager | SaaS commerciale | Health check, rotazione, API, supporto | Business, compiti critici |
| Browser anti-detect | Funzionalità integrata | Verifica di base all'avvio del profilo | SMM, arbitraggio, fino a 100 account |
Scenari di utilizzo per le aziende
Esaminiamo casi concreti in cui l'health check del pool di proxy risolve problemi aziendali reali.
Caso 1: Scraping dei prezzi dei concorrenti sui marketplace
Compito: un venditore su Wildberries fa scraping dei prezzi di 500 concorrenti ogni 2 ore, per correggere automaticamente i propri prezzi. Utilizza un pool di 50 proxy.
Problema senza health check: parte dei proxy viene bloccata da Wildberries dopo 100-200 richieste, il parser fallisce con errori e i dati vengono raccolti incompleti. È necessario controllare e sostituire manualmente i proxy ogni 2-3 giorni.
Soluzione con health check: ogni 30 minuti il sistema verifica tutti i 50 proxy con una richiesta a Wildberries. I non funzionanti (stato 403, 429 o timeout) vengono automaticamente sostituiti con quelli di riserva dal pool di 20 proxy di backup. Il parser utilizza sempre solo proxy funzionanti.
Risultato: la stabilità dello scraping è aumentata dal 70% al 98%, il lavoro manuale è diminuito da 2 ore al giorno a 10 minuti a settimana.
Caso 2: Multi-accounting per un'agenzia SMM
Compito: un'agenzia SMM gestisce 80 account Instagram di clienti tramite Dolphin Anty. Ogni account è legato al proprio proxy (1 account = 1 proxy).
Problema senza health check: se un proxy smette di funzionare, il manager lo scopre solo quando non riesce ad accedere all'account del cliente. Nel frattempo, Instagram può bloccare l'account a causa di "attività sospette" (cambiamento repentino di IP).
Soluzione con health check: ogni 60 minuti il sistema verifica tutti i 80 proxy (disponibilità + geolocalizzazione). Se un proxy non risponde, il manager riceve una notifica su Telegram e in Dolphin Anty vengono automaticamente aggiornate le impostazioni del profilo con un proxy di riserva della stessa città.
Risultato: il numero di blocchi degli account a causa di problemi con i proxy è diminuito da 5-7 al mese a 0-1. Risparmio: ~$500/mese per il ripristino degli account.
Caso 3: Arbitraggio di traffico su Facebook Ads
Compito: un arbitraggista avvia pubblicità con 15 account Facebook Ads. Ogni account utilizza il proprio proxy residenziale dagli Stati Uniti.
Problema senza health check: Facebook controlla rigorosamente la stabilità dell'IP. Se il proxy "salta" (cambia IP o ci sono interruzioni nella connessione), l'account viene sottoposto a verifica o bloccato immediatamente. Costo della perdita di un account: $200-500 (ripristino + inattività delle campagne).
Soluzione con health check: verifica ogni 15 minuti: disponibilità, velocità (la latency deve essere stabile), anonimato (livello elite). Se un proxy mostra instabilità (variazione della latency superiore al 30%), viene escluso dalla rotazione fino a chiarimenti. Per gli account critici vengono utilizzati solo proxy con uptime > 99.5% nelle ultime 24 ore.
Risultato: il numero di blocchi a causa di problemi con i proxy è diminuito da 2-3 al mese a 0. ROI aumentato del 15% grazie al funzionamento stabile delle campagne.
💡 Consiglio:
Per compiti critici (multi-accounting, arbitraggio) utilizza proxy residenziali con alto uptime. Costano di più rispetto ai data center, ma la stabilità e il basso rischio di blocchi ripagano la differenza di prezzo.
Errori comuni nella configurazione dell'health check
Esaminiamo errori tipici che riducono l'efficacia dell'health check o creano nuovi problemi.
Errore 1: Verifica troppo frequente
Problema: controllare ogni 1-5 minuti crea un enorme carico sui proxy e sui servizi di test. I servizi pubblici (httpbin.org, ip-api.com) possono bloccare il tuo IP per spam. Inoltre, verifiche frequenti consumano traffico — se hai 100 proxy e controlli ogni minuto, sono 144.000 richieste al giorno.
Soluzione: per proxy stabili è sufficiente una verifica ogni 30-60 minuti. Per compiti critici — ogni 15 minuti. Utilizza il tuo server di test invece di servizi pubblici, se hai bisogno di controlli frequenti.
Errore 2: Verifica solo della disponibilità
Problema: un proxy può rispondere alle richieste (stato 200 OK), ma essere lento (latency di 10 secondi) o avere una geolocalizzazione errata. Per attività aziendali, tale proxy è inutile o addirittura pericoloso.
Soluzione: verifica in modo complessivo — disponibilità + velocità + geolocalizzazione + anonimato. Per il multi-accounting la geolocalizzazione è critica, per lo scraping la velocità, per l'arbitraggio tutto insieme.
Errore 3: Mancanza di quarantena
Problema: un proxy può "cadere" temporaneamente a causa di un riavvio del server o di problemi con il provider, ma può riprendere a funzionare dopo 1-2 ore. Se si rimuovono immediatamente tali proxy dal pool, si perdono IP funzionanti.
Soluzione: utilizza un sistema di quarantena — i proxy non funzionanti non vengono rimossi, ma esclusi per 2-4 ore. Dopo questo tempo vengono verificati nuovamente e, se funzionano, vengono restituiti al pool.
Errore 4: Ignorare le metriche di stabilità
Problema: un proxy può funzionare, ma in modo instabile — la latency oscilla da 500 ms a 5000 ms, il periodo...