I proxy gratuiti falliscono più spesso di quanto funzionino. Una lista pubblica scorre decine di migliaia di candidati e il tuo compito è trovare il piccolo sottoinsieme che è attualmente vivo, abbastanza veloce e non attivamente malevolo. Cinque test, ciascuno economico, eseguiti in ordine.
Test 1: Raggiungibilità TCP
curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
-s -o /dev/null -w "%{http_code}\n" \
https://api.ipify.orgUn codice di uscita diverso da zero o una risposta vuota significa che il proxy è morto. Circa il 60–80% di qualsiasi lista gratuita fallirà questo test in un dato momento. Salta immediatamente e non riprovare.
Test 2: Verifica dell'IP di uscita
La stessa chiamata restituisce l'IP pubblico da cui è emersa la richiesta. Se è uguale a 1.2.3.4 — l'indirizzo del proxy — il proxy sta inoltrando correttamente il traffico. Se è uguale al tuo IP locale, il proxy è rotto o trasparente: ha accettato la connessione ma non ha effettivamente inoltrato attraverso sé stesso. Consideralo un fallimento anche se TCP ha avuto successo.
Test 3: Trasparenza degli header
curl --proxy http://1.2.3.4:8080 https://httpbin.org/headersLa risposta restituisce gli header che la destinazione ha ricevuto. Cerca X-Forwarded-For, Via o Forwarded con il tuo IP reale. Se li trovi, il proxy è in modalità trasparente o anonima piuttosto che elite. Per HTTPS tramite CONNECT questo è irrilevante — la destinazione vede solo l'handshake TLS, nessun header applicativo — ma per HTTP in chiaro determina se il proxy è adatto allo scopo.
Test 4: Latenza sotto carico
La misurazione di un singolo colpo è rumorosa. Esegui dieci richieste seriali attraverso il proxy e prendi la mediana. Qualsiasi valore superiore a due secondi è inutilizzabile per lavoro interattivo. Sotto i 500 millisecondi è competitivo con nessun proxy. Tra questi numeri, il proxy è adatto per scraping batch ma non per navigazione.
Test 5: Integrità dell'impronta TLS
Connettiti tramite il proxy a un endpoint TLS noto e verifica che la catena di certificati corrisponda a quella che ottieni senza proxy. Una mancata corrispondenza significa che il proxy sta intercettando TLS — eseguendo un attacco man-in-the-middle e il tuo traffico "crittografato" non è effettivamente crittografato dal proxy in poi. Questo è raro su proxy SOCKS configurati correttamente (non possono vedere TLS) ma appare su proxy HTTPS aziendali mal configurati e su qualche nodo pubblico malevolo. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 stampa la catena.
Un flusso di lavoro pratico
Preleva la lista, filtra per paese e protocollo, distribuisci i cinque test su un pool parallelo di circa 50 worker e conserva i sopravvissuti. Da 100 candidati grezzi, un'esecuzione tipica produce 5–15 voci utilizzabili. Il tasso di decadimento è di circa 30–60 minuti per HTTP e HTTPS, leggermente più lungo per SOCKS — pianifica un aggiornamento a quella cadenza e alimenta l'insieme sopravvissuto nella configurazione del tuo scraper o browser. Memorizza nella cache i risultati dei test per la durata di un batch e riesegui il test sul successivo.