En proxypulje kan gøre et simpelt udfald til en travl løkke. Vælg en adresse, fejl, vælg en anden, fejl igen. Hvis hvert endepunkt er utilgængeligt, fordi dit eget netværk er nede, løser skift af adresser aldrig årsagen.

Giv operationen et budget, før du vælger den første proxy fra din pulje eller listen over gratis proxyer: et endeligt antal forsøg, begrænsede ventetider på forbindelse og læsning samt en deadline for hele opgaven. En Requests-timeout styrer sin dokumenterede forbindelses- eller læseadfærd; den begrænser ikke i sig selv en løkke, der bliver ved med at sende nye anmodninger.

Afgør, hvad der fortjener et nyt forsøg

  • En afvist proxyforbindelse kan begrunde, at man prøver et andet endepunkt.
  • Et svar fra destinationen skal fortolkes for sig. At modtage en HTTP-fejl beviser, at en anmodningsvej blev gennemført.
  • En proxygodkendelsesfejl kalder på at kontrollere endepunktet og kontoen i stedet for at hamre de samme legitimationsoplysninger gennem en voksende liste.

Gem den oprindelige undtagelse eller status sammen med forsøgsregistreringen. En afsluttende besked med kun »alle proxyer fejlede« skjuler, om fejlene overhovedet havde samme årsag.

Sundhedstjek af hver proxy før hver rigtig anmodning tilføjer endnu en anmodning og kan stadig ikke garantere, at den næste lykkes. Genbrug nylig sundhedsinformation, hvor det passer til opgaven, og lad derefter den rigtige operation rapportere sit eget resultat.

Et nyt forsøg kan gentage arbejdet

Ved en skrivebeskyttet hentning er det normalt enklere at skifte til en anden proxy end at genafspille en indsendelse. Hvis en forbindelse falder, efter at et køb eller en formularindsendelse er sendt, kan destinationen allerede have behandlet den. Følg tjenestens idempotensmekanisme og HTTP-reglerne for nye forsøg, før arbejdet genafspilles.

Når budgettet er opbrugt, returner en brugbar fejl. Et job, der stopper med beviser, er lettere at reparere end et, der stille bliver ved med at rotere, indtil nogen bemærker det.

Relaterede artikler