Scrapy कुकी जार एका सत्राची असते, आपोआप प्रॉक्सीची नाही

प्रॉक्सी बदलल्याने स्पायडरच्या कुकीज आपोआप बदलत नाहीत. चालू असलेल्या एका सत्रासाठी ते उपयुक्त ठरू शकते आणि अनेक स्वतंत्र सत्रे एकच स्पायडर सामायिक करत असतील तर ते आश्चर्यकारक वाटते.

Scrapy चे कुकी मिडलवेअर विनंतीच्या cookiejar मेटाडेटाने निवडल्या जाणाऱ्या वेगळ्या जारना समर्थन देते. त्या कीला तुम्हाला खरोखर जपायची असलेली ओळख द्या:

yield scrapy.Request(
    'https://example.com/start',
    meta={'proxy': selected_proxy, 'cookiejar': 'workflow-17'},
)

एंडपॉइंट आणि जार-की हे दोन स्वतंत्र पर्याय आहेत. अनधिकृत सार्वजनिक क्रॉल त्याचा निवडलेला HTTP एंडपॉइंट HTTP प्रॉक्सी यादीमधून घेऊ शकतो जिथे तो मार्ग अनुमत आहे; वर्कफ्लो तरीही जार-कीचा मालक असतो. या सत्रात राहिलेल्या पुढील विनंतीला तीच जार-की लागते; तुम्ही तयार करता त्या प्रत्येक नवीन विनंतीला मेटाडेटा आपोआप चिकटत नाही. सर्व मिडलवेअर मेटाडेटा डोळे झाकून कॉपी करण्याऐवजी वर्कफ्लोला आवश्यक असलेली विशिष्ट फील्ड्स पुढे पाठवा.

प्रॉक्सी पत्ता जार-की म्हणून वापरणे हे फक्त एक धोरण आहे

तो शॉर्टकट स्थिती एंडपॉइंटनुसार गटबद्ध करतो. तो ती व्यक्ती, खाते किंवा सार्वजनिक एक्झिटनुसार गटबद्ध करतोच असे नाही. एकच प्रदाता एंडपॉइंट एक्झिट फिरवू शकतो आणि अनेक खाती एकच एंडपॉइंट वापरू शकतात.

स्थिर स्थिती आवश्यक असलेल्या अधिकृत वर्कफ्लोसाठी खाते/सत्र ओळखकर्ता, जार ओळखकर्ता आणि निवडलेला मार्ग वेगळे नोंदवा. जर तुम्ही अर्ध्या वाटेत मार्ग बदलण्याचे ठरवले तर अॅप्लिकेशन सत्राचे काय व्हावे हेही ठरवा.

वेगळ्या जार तुम्ही ठरवलेल्या गटांमध्ये कुकीज अपघाताने सामायिक होण्यास प्रतिबंध करतात. पण कोणतेही गंतव्य खाते किंवा इतर अॅप्लिकेशन डेटाद्वारे दोन विनंत्या जोडू शकणार नाही याची त्या हमी देत नाहीत.

IP बदलल्यानंतरही चुकीचे पान राहिले तर सर्व कुकीज हटवण्यापूर्वी किंवा संपूर्ण प्रॉक्सी पूल बदलण्यापूर्वी कोणत्या जारने विनंती पाठवली ते तपासा. ठेवलेली स्थिती पानाचे पूर्णपणे स्पष्टीकरण देऊ शकते.