Fermare un ciclo di rotazione dei proxy che non finisce mai
Dare a un pool di proxy Python un budget finito di tentativi e distinguere gli errori di connessione dalle risposte della destinazione.
Un pool di proxy può trasformare un semplice disservizio in un ciclo intenso. Scegli un indirizzo, fallisci, scegline un altro, fallisci ancora. Se ogni endpoint è irraggiungibile perché la tua rete è giù, cambiare indirizzo non risolve mai la causa.
Dai all'operazione un budget prima di scegliere il primo proxy dal pool o dalla lista di proxy gratuiti: un numero finito di tentativi, attese di connessione e lettura limitate e una scadenza per l'intera attività. Un timeout di Requests controlla il suo comportamento documentato di connessione o lettura; da solo non limita un ciclo che continua a emettere nuove richieste.
Decidere cosa merita un altro tentativo
- Una connessione proxy rifiutata può giustificare la prova di un altro endpoint.
- Una risposta della destinazione richiede una propria interpretazione. Ricevere un errore HTTP dimostra che un percorso di richiesta è stato completato.
- Un errore di autenticazione del proxy richiede di controllare endpoint e account invece di martellare le stesse credenziali su una lista crescente.
Conserva l'eccezione o lo stato originale con il record del tentativo. Un messaggio finale che contiene solo «tutti i proxy hanno fallito» nasconde se i fallimenti avessero persino la stessa causa.
Controllare la salute di ogni proxy prima di ogni richiesta reale aggiunge un'altra richiesta e comunque non garantisce che la successiva riesca. Riusa le informazioni di salute recenti quando si adattano all'attività, poi lascia che l'operazione reale riporti il proprio risultato.
Un nuovo tentativo può ripetere il lavoro
Per un recupero in sola lettura, passare a un altro proxy è di solito più semplice che ripetere un invio. Se una connessione cade dopo aver inviato un acquisto o un modulo, la destinazione potrebbe averlo già elaborato. Segui il meccanismo di idempotenza del servizio e le regole di nuovo tentativo HTTP prima di ripetere il lavoro.
Quando il budget è esaurito, restituisci un errore utile. Un lavoro che si ferma con le prove è più facile da riparare di uno che continua a girare in silenzio finché qualcuno non se ne accorge.