Stoppa en proxyroteringsloop som kör för evigt

En proxypool kan förvandla ett enkelt avbrott till en upptagen loop. Välj en adress, misslyckas, välj en annan, misslyckas igen. Om varje endpoint är onåbar eftersom ditt eget nätverk är nere, löser byte av adresser aldrig orsaken.

Ge operationen en budget innan du väljer den första proxyn från poolen eller listan med gratis proxyservrar: ett ändligt antal försök, begränsade anslutnings- och lästider samt en deadline för hela uppgiften. En Requests-timeout styr sitt dokumenterade anslutnings- eller läsbeteende; den begränsar inte i sig en loop som fortsätter att skicka nya förfrågningar.

Bestäm vad som förtjänar ett nytt försök

• En nekad proxyanslutning kan motivera att prova en annan endpoint.
• Ett svar från målet kräver sin egen tolkning. Att få ett HTTP-fel bevisar att någon förfrågningsväg slutfördes.
• Ett proxyautentiseringsfel kräver att endpointen och kontot kontrolleras i stället för att hamra samma uppgifter genom en växande lista.

Behåll det ursprungliga undantaget eller statusen med försöksposten. Ett slutligt meddelande som bara säger ”alla proxyservrar misslyckades” döljer om felen ens hade samma orsak.

Hälsokontroll av varje proxy före varje verklig förfrågan lägger till ytterligare en förfrågan och kan fortfarande inte garantera att nästa lyckas. Återanvänd färsk hälsoinformation där den passar uppgiften och låt sedan den verkliga operationen rapportera sitt eget resultat.

Ett nytt försök kan upprepa arbetet

För en skrivskyddad hämtning är det vanligtvis enklare att byta till en annan proxy än att spela upp en inskickning. Om anslutningen bryts efter att ett köp eller formulär skickats kan målet redan ha behandlat det. Följ tjänstens idempotensmekanism och HTTP-reglerna för nya försök innan arbetet spelas upp.

När budgeten är slut, returnera ett användbart fel. Ett jobb som stannar med bevis är lättare att reparera än ett som tyst fortsätter rotera tills någon märker det.