प्रॉक्सी रोटेशन लूप को हमेशा के लिए चलने से रोकें

एक प्रॉक्सी पूल साधारण बाधा को व्यस्त लूप में बदल सकता है। पता चुनें, विफल हों, दूसरा चुनें, फिर विफल हों। यदि हर एंडपॉइंट अगम्य है क्योंकि आपका अपना नेटवर्क ठप है, तो पते बदलने से कारण कभी नहीं सुधरता।

अपने पूल या मुफ़्त प्रॉक्सी सूची से पहला प्रॉक्सी चुनने से पहले संचालन को बजट दें: सीमित संख्या में प्रयास, सीमित कनेक्शन और पढ़ने की प्रतीक्षा, और पूरे कार्य के लिए एक समय-सीमा। Requests टाइमआउट अपने प्रलेखित कनेक्शन या पढ़ने के व्यवहार को नियंत्रित करता है; अकेले वह उस लूप को सीमित नहीं करता जो लगातार नई अनुरोध भेजता रहता है।

तय करें कि दूसरा प्रयास किसका हक़ है

• अस्वीकृत प्रॉक्सी कनेक्शन दूसरा एंडपॉइंट आज़माने को उचित ठहरा सकता है।
• गंतव्य के उत्तर की अपनी व्याख्या चाहिए। HTTP त्रुटि मिलना सिद्ध करता है कि कोई अनुरोध पथ पूरा हुआ।
• प्रॉक्सी प्रमाणीकरण विफलता एंडपॉइंट और खाते की जाँच माँगती है, बढ़ती सूची में वही क्रेडेंशियल पीटना नहीं।

प्रयास रिकॉर्ड के साथ मूल अपवाद या स्थिति रखें। केवल «सभी प्रॉक्सी विफल रहे» वाला अंतिम संदेश छिपाता है कि विफलताओं का कारण भी एक ही था या नहीं।

हर वास्तविक अनुरोध से पहले हर प्रॉक्सी की स्वास्थ्य जाँच एक और अनुरोध जोड़ती है और फिर भी गारंटी नहीं देती कि अगला सफल होगा। जहाँ कार्य में फिट हो वहाँ ताज़ा स्वास्थ्य जानकारी दोबारा इस्तेमाल करें, और वास्तविक संचालन को अपना परिणाम बताने दें।

पुनः प्रयास काम दोहरा सकता है

केवल पढ़ने वाले फ़ेच के लिए, दूसरे प्रॉक्सी पर जाना आमतौर पर सबमिशन दोहराने से आसान है। यदि खरीद या फ़ॉर्म भेजने के बाद कनेक्शन टूट जाए, तो गंतव्य उसे पहले ही संसाधित कर चुका हो सकता है। काम दोहराने से पहले सेवा की idempotency व्यवस्था और HTTP पुनः प्रयास नियमों का पालन करें।

बजट खत्म होने पर उपयोगी विफलता लौटाएँ। साक्ष्य के साथ रुकने वाला काम चुपचाप घूमते रहने वाले काम की तुलना में ठीक करना आसान है जब तक किसी को ध्यान न आए।