En proxypool kan gjøre en enkel svikt om til en travel løkke. Velg en adresse, feil, velg en annen, feil igjen. Hvis hvert endepunkt er utilgjengelig fordi ditt eget nettverk er nede, løser bytte av adresser aldri årsaken.

Gi operasjonen et budsjett før du velger den første proxyen fra poolen eller listen over gratis proxyer: et begrenset antall forsøk, begrensede ventetider for tilkobling og lesing, og en frist for hele oppgaven. En Requests-timeout styrer sin dokumenterte tilkoblings- eller leseatferd; den begrenser ikke i seg selv en løkke som fortsetter å sende nye forespørsler.

Avgjør hva som fortjener et nytt forsøk

  • En avvist proxyforbindelse kan begrunne å prøve et annet endepunkt.
  • Et svar fra destinasjonen trenger sin egen tolkning. Å motta en HTTP-feil beviser at en forespørselsvei ble fullført.
  • En proxyautentiseringsfeil krever at endepunktet og kontoen sjekkes, i stedet for å hamre de samme påloggingsdetaljene gjennom en voksende liste.

Ta vare på den opprinnelige unntaket eller statusen sammen med forsøksregistreringen. En avsluttende melding som bare sier «alle proxyer feilet», skjuler om feilene i det hele tatt hadde samme årsak.

Å helsesjekke hver proxy før hver ekte forespørsel legger til nok en forespørsel og kan fortsatt ikke garantere at den neste lykkes. Gjenbruk fersk helseinformasjon der det passer til oppgaven, og la deretter den ekte operasjonen rapportere sitt eget resultat.

Et nytt forsøk kan gjenta arbeidet

For en skrivebeskyttet henting er det vanligvis enklere å bytte til en annen proxy enn å spille av en innsending på nytt. Hvis en tilkobling faller etter at et kjøp eller en skjemainnsending er sendt, kan destinasjonen allerede ha behandlet den. Følg tjenestens idempotensmekanisme og HTTP-reglene for nye forsøk før arbeidet spilles av på nytt.

Når budsjettet er brukt opp, returner en nyttig feil. En jobb som stopper med bevis, er lettere å reparere enn en som stille fortsetter å rotere til noen legger merke til det.

Relaterte artikler