Itigil ang paikot na proxy loop na tumatakbo nang walang hanggan

Ang isang proxy pool ay maaaring gawing abalang loop ang simpleng pagkawala. Pumili ng address, mabigo, pumili ng iba, mabigo muli. Kung lahat ng endpoint ay hindi maabot dahil down ang sarili mong network, hindi kailanman inaayos ng pagpapalit ng address ang dahilan.

Bigyan ang operasyon ng badyet bago pumili ng unang proxy mula sa iyong pool o sa listahan ng libreng proxy: may hanggang bilang ng pagtatangka, may hanggang paghihintay sa koneksyon at pagbasa, at takdang oras para sa buong gawain. Ang Requests timeout ay kumokontrol sa dokumentadong pag-uugali nito sa koneksyon o pagbasa; hindi nito mag-isa nililimitahan ang loop na patuloy na naglalabas ng bagong kahilingan.

Magpasya kung ano ang karapat-dapat sa isa pang pagtatangka

• Ang tinanggihang koneksyon sa proxy ay maaaring magbigay-katwiran sa pagsubok ng ibang endpoint.
• Ang tugon ng destinasyon ay nangangailangan ng sariling interpretasyon. Ang pagtanggap ng HTTP error ay nagpapatunay na may isang landas ng kahilingan na natapos.
• Ang pagkabigo sa pagpapatunay ng proxy ay nangangailangan ng pagsuri sa endpoint at account sa halip na paulit-ulit na hampasin ang parehong mga kredensyal sa lumalaking listahan.

Itago ang orihinal na exception o status kasama ng talaan ng pagtatangka. Ang pangwakas na mensaheng naglalaman lamang ng “lahat ng proxy ay nabigo” ay nagtatago kung ang mga pagkabigo ay may parehong dahilan.

Ang pagsuri sa kalusugan ng bawat proxy bago ang bawat tunay na kahilingan ay nagdaragdag ng isa pang kahilingan at hindi pa rin matitiyak na magtatagumpay ang susunod. Gamitin muli ang kamakailang impormasyon sa kalusugan kung angkop sa gawain, pagkatapos ay hayaang iulat ng tunay na operasyon ang sarili nitong resulta.

Ang muling pagtatangka ay maaaring ulitin ang gawain

Para sa read-only na pagkuha, ang paglipat sa ibang proxy ay karaniwang mas simple kaysa sa muling paglalaro ng isinumite. Kung maputol ang koneksyon pagkatapos ng pagpapadala ng pagbili o form, maaaring naproseso na ito ng destinasyon. Sundin ang mekanismong idempotency ng serbisyo at ang mga tuntunin ng HTTP retry bago ulitin ang gawain.

Kapag naubos ang badyet, magbalik ng kapaki-pakinabang na pagkabigo. Ang trabahong humihinto nang may ebidensya ay mas madaling ayusin kaysa sa tahimik na patuloy na umiikot hanggang may makapansin.