Verification

वास्तविक ट्रैफ़िक के साथ भरोसा करने से पहले एक मुफ्त प्रॉक्सी को सत्यापित करना

3 min read Published Updated 470 words

फ्री प्रॉक्सी अक्सर काम करने की बजाय फेल हो जाते हैं। एक सार्वजनिक सूची में हजारों उम्मीदवार घूमते रहते हैं और आपका काम उस छोटे उपसमूह को ढूंढना है जो वर्तमान में जीवित है, पर्याप्त तेज़ है, और सक्रिय रूप से दुर्भावनापूर्ण नहीं है। पाँच परीक्षण, प्रत्येक सस्ता, क्रम में चलाए जाते हैं।

परीक्षण 1: TCP पहुँच क्षमता

curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
     -s -o /dev/null -w "%{http_code}\n" \
     https://api.ipify.org

गैर-शून्य एग्जिट कोड या खाली प्रतिक्रिया का मतलब है कि प्रॉक्सी मृत है। किसी भी फ्री सूची का लगभग 60–80% किसी भी समय इस परीक्षण में असफल होगा। तुरंत छोड़ें और पुनः प्रयास न करें।

परीक्षण 2: एग्रेस IP सत्यापन

वही कॉल वह सार्वजनिक IP लौटाता है जहाँ से अनुरोध निकला है। यदि यह 1.2.3.4 — प्रॉक्सी का पता — के बराबर है, तो प्रॉक्सी ट्रैफ़िक को सही ढंग से अग्रेषित कर रहा है। यदि यह आपके स्थानीय IP के बराबर है, तो प्रॉक्सी टूटा हुआ या पारदर्शी है: इसने कनेक्शन स्वीकार किया लेकिन वास्तव में स्वयं के माध्यम से रिले नहीं किया। इसे विफलता मानें, भले ही TCP सफल रहा हो।

परीक्षण 3: हेडर पारदर्शिता

curl --proxy http://1.2.3.4:8080 https://httpbin.org/headers

प्रतिक्रिया उन हेडरों को प्रतिध्वनित करती है जो गंतव्य को प्राप्त हुए। अपने वास्तविक IP के साथ X-Forwarded-For, Via, या Forwarded देखें। यदि आप उन्हें पाते हैं, तो प्रॉक्सी एलीट के बजाय पारदर्शी या अनाम मोड में है। CONNECT के माध्यम से HTTPS के लिए यह अप्रासंगिक है — गंतव्य केवल TLS हैंडशेक देखता है, कोई एप्लिकेशन हेडर नहीं — लेकिन सादे टेक्स्ट HTTP के लिए यह निर्धारित करता है कि प्रॉक्सी उद्देश्य के लिए उपयुक्त है या नहीं।

परीक्षण 4: लोड के तहत विलंबता

एकल-शॉट टाइमिंग शोरगुल वाली होती है। प्रॉक्सी के माध्यम से दस सीरियल अनुरोध चलाएँ और मीडियन लें। दो सेकंड से ऊपर कुछ भी इंटरैक्टिव कार्य के लिए अनुपयोगी है। 500 मिलीसेकंड से नीचे बिना किसी प्रॉक्सी के प्रतिस्पर्धी है। इन संख्याओं के बीच, प्रॉक्सी बैच स्क्रैपिंग के लिए उपयुक्त है लेकिन ब्राउज़िंग के लिए नहीं।

परीक्षण 5: TLS फिंगरप्रिंट अखंडता

प्रॉक्सी के माध्यम से एक ज्ञात TLS एंडपॉइंट से कनेक्ट करें और सत्यापित करें कि सर्टिफिकेट चेन बिना प्रॉक्सी के मिलने वाली चेन से मेल खाती है। बेमेल का मतलब है कि प्रॉक्सी TLS को इंटरसेप्ट कर रहा है — मैन-इन-द-मिडिल चला रहा है और आपका "एन्क्रिप्टेड" ट्रैफ़िक वास्तव में प्रॉक्सी से आगे एन्क्रिप्टेड नहीं है। यह सही ढंग से कॉन्फ़िगर किए गए SOCKS प्रॉक्सी पर दुर्लभ है (वे TLS नहीं देख सकते) लेकिन गलत कॉन्फ़िगर किए गए कॉर्पोरेट HTTPS प्रॉक्सी और कभी-कभी दुर्भावनापूर्ण सार्वजनिक नोड पर दिखाई देता है। openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 चेन प्रिंट करता है।

एक व्यावहारिक कार्यप्रवाह

सूची खींचें, देश और प्रोटोकॉल के अनुसार फ़िल्टर करें, पाँच परीक्षणों को लगभग 50 वर्कर्स के समानांतर पूल में फैलाएँ, और बचे हुए को रखें। 100 कच्चे उम्मीदवारों में से एक सामान्य रन में 5–15 उपयोगी प्रविष्टियाँ मिलती हैं। HTTP और HTTPS के लिए क्षय दर लगभग 30–60 मिनट है, SOCKS के लिए थोड़ी अधिक — उस अंतराल पर रिफ्रेश शेड्यूल करें और बचे हुए सेट को अपने स्क्रैपर या ब्राउज़र कॉन्फ़िगरेशन में फीड करें। एक बैच के जीवनकाल के लिए परीक्षण परिणामों को कैश करें और अगले पर पुनः परीक्षण करें।