Python और Node में कैप्चा प्रॉक्सी रोटेशन कैसे सेट करें

कैप्चा प्रॉक्सी रोटेशन ऐसी चीज़ है जिसे आप अपने ही code में बनाते हैं। सॉल्वर हर job के लिए एक प्रॉक्सी लेता है और उसे सिर्फ़ उसी job के लिए इस्तेमाल करता है, इसलिए pool, rotation की नीति और retry logic सब आपकी तरफ़ रहते हैं। दो नियम ही ज़्यादातर काम कर देते हैं: हर call पर प्रॉक्सी बदलने के बजाय एक IP को एक session से बाँधें, और सिर्फ़ किसी failure के बाद ही बदलें। यह गाइड हर SDK में प्रॉक्सी का सटीक रूप, उसके पीछे की raw API जोड़ी, और वह एक कैप्चा प्रकार बताती है जहाँ प्रॉक्सी चुपचाप नज़रअंदाज़ कर दी जाती है।

प्रॉक्सी चार में से तीन कैप्चा परिवारों पर लागू होती हैं, सभी चार पर नहीं

शुरुआत इसी सीमा से करें, क्योंकि इससे डीबगिंग की एक पूरी दोपहर बच जाती है। CapSkip चार कैप्चा परिवारों को हल करता है, और प्रॉक्सी उनमें से तीन पर काम करती हैं: reCAPTCHA, Turnstile और GeeTest। image कैप्चा प्रॉक्सी लेते ही नहीं।

reCAPTCHA यहाँ एक ही बार गिना जाता है। v2 चेकबॉक्स, Invisible, Enterprise और v3 अलग-अलग प्रकार नहीं, बल्कि एक ही solve call के विकल्प हैं, इसलिए प्रॉक्सी के मामले में सब एक जैसा व्यवहार करते हैं।

किसी image job को प्रॉक्सी देना error नहीं है। उसे स्वीकार करके नज़रअंदाज़ कर दिया जाता है, जो और भी बुरा है, क्योंकि वहाँ rotation की कोई गड़बड़ी कोई संकेत ही नहीं देती। अगर आप image कैप्चा को बाक़ी सब की तरह उसी wrapper से भेजते हैं, तो उस रास्ते पर proxy argument छोड़ दें।

हर SDK में प्रॉक्सी का रूप

हर SDK वही दो-field वाला object लेता है: एक type और एक URI। URI या तो host और port होता है, या फिर credentials के बाद host और port।

# pip install capskip
from capskip import CapSkip

solver = CapSkip(host="127.0.0.1", port=8080)

# The proxy applies to this one solve, nothing is remembered.
result = solver.recaptcha(
    sitekey="YOUR_SITEKEY",
    url="https://example.com/page-with-recaptcha",
    proxy={"type": "HTTPS", "uri": "user:[email protected]:3128"},
)

print(result["code"])   # token, solved through that IP

Node उसी object को options argument के रूप में लेता है।

// npm install capskip
const { CapSkip } = require('capskip');

const solver = new CapSkip({ host: '127.0.0.1', port: 8080 });

const result = await solver.turnstile(
  'YOUR_SITEKEY',
  'https://example.com/page-with-turnstile',
  { proxy: { type: 'SOCKS5', uri: '1.2.3.4:1080' } },
);

console.log(result.code, result.userAgent);  // send both back

PHP इसे options array में proxy key के तौर पर रखता है, और .NET उन्हीं दो values से बना Proxy object पास करता है। चारों अनुमत type values हर जगह एक जैसी हैं: HTTP, HTTPS, SOCKS5 और SOCKS5H। SOCKS5H DNS को लोकल के बजाय प्रॉक्सी पर resolve करता है, और यही आपको तब चाहिए जब target क्षेत्र के हिसाब से अलग-अलग resolve होता हो।

हर request नहीं, हर session के लिए एक प्रॉक्सी बाँधें

मन तो यही कहता है कि हर हल के लिए नया IP लिया जाए। यह ग़लत डिफ़ॉल्ट है और यही sessions को flag कराता है।

कोई सुरक्षित page token को उसी context से बाँध देता है जिसमें वह जारी हुआ था। अगर आपका crawler page को एक IP से लोड करता है और token किसी दूसरे IP से हल होता है, तो site को browsing session और verification के बीच बेमेल दिखता है। कुछ sites इसे नज़रअंदाज़ कर देती हैं। Cloudflare और reCAPTCHA Enterprise नहीं करतीं, और token या तो कम गुणवत्ता का माना जाता है या सीधे फेल हो जाता है।

तो rotation की इकाई session है, call नहीं। एक ही प्रॉक्सी page लाती है, कैप्चा हल करती है, और form submit करती है। अगला session अगली प्रॉक्सी लेता है।

# pip install capskip
import itertools

# One entry per exit IP. Round-robin, not random:
# random picks repeat, and a repeat is what a rate limiter sees.
POOL = [
    {"type": "HTTPS", "uri": "user:[email protected]:3128"},
    {"type": "HTTPS", "uri": "user:[email protected]:3128"},
    {"type": "SOCKS5H", "uri": "user:[email protected]:1080"},
]

pool = itertools.cycle(POOL)

def new_session():
    """Hand the same proxy to the HTTP client and the solver."""
    return next(pool)

यहाँ round-robin random चुनाव से बेहतर है, एक वजह से: किसी छोटे pool से random sampling इतनी बार एक ही IP को लगातार दोहरा देती है कि फ़र्क़ पड़ने लगता है, और एक ही exit node से पीछे-पीछे आती requests ठीक वही pattern हैं जिस पर rate limiters नज़र रखते हैं।

टाइमर पर नहीं, failure पर प्रॉक्सी बदलें

दूसरा नियम यह है कि आगे कब बढ़ें। हर N requests पर प्रॉक्सी बदलने से काम कर रहे IPs बेकार चले जाते हैं और खराब IPs N calls तक चलन में बने रहते हैं। इसके बजाय सबूत मिलने पर बदलें।

# pip install capskip
from capskip import CapSkip
from capskip import ApiException, NetworkException, TimeoutException

solver = CapSkip(host="127.0.0.1", port=8080)

def solve_with_retry(sitekey, url, attempts=3):
    last = None
    for _ in range(attempts):
        proxy = new_session()
        try:
            return solver.recaptcha(sitekey=sitekey, url=url, proxy=proxy)
        except (ApiException, NetworkException, TimeoutException) as err:
            # Burn this IP for the run and take the next one.
            last = err
    raise last

ज़्यादातर pools के लिए तीन कोशिशें सही सीमा हैं। अगर कोई sitekey तीन अलग-अलग IPs पर फेल होता है, तो दिक़्क़त प्रॉक्सी की नहीं है: sitekey पुराना पड़ चुका है, page URL ग़लत है, या site ने अपना challenge बदल दिया है। चौथी बार कोशिश करना सिर्फ़ उसी बात की पुष्टि में हल करने की क्षमता खर्च करना है।

आप कौन-सा exception पकड़ते हैं, यही बताता है कि हुआ क्या। NetworkException का मतलब है कि सॉल्वर तक पहुँच नहीं बनी या job तैयार होने से पहले ही poll कर लिया गया। TimeoutException का मतलब है कि polling की अवधि ख़त्म हो गई। ApiException अपने साथ लौटाया गया error code लाता है, और यही वह है जिसे प्रॉक्सी के साथ लॉग करना फ़ायदेमंद है, क्योंकि चालीस के pool में एक मरा हुआ exit node आप इसी तरह ढूँढते हैं।

raw API: proxy और proxytype

SDK के बिना, यही चीज़ submit call पर दो अतिरिक्त form fields बन जाती है। SDK object सीधे उन्हीं पर मैप होता है।

# No install step. curl is already on your machine.
curl -X POST http://127.0.0.1:8080/in.php \
  -d "key=YOUR_API_KEY" \
  -d "method=userrecaptcha" \
  -d "googlekey=YOUR_SITEKEY" \
  -d "pageurl=https://example.com/page-with-recaptcha" \
  -d "proxy=user:[email protected]:3128" \
  -d "proxytype=HTTPS"

OK|2122988149   # submitted, and it will solve through that IP

proxytype का डिफ़ॉल्ट HTTP है, इसलिए इसके बिना भेजी गई कोई HTTPS या SOCKS5 प्रॉक्सी सादे HTTP की तरह डायल होगी और फेल हो जाएगी। डिफ़ॉल्ट के आपके pool से मेल खाने पर भरोसा करने के बजाय यह field हर बार भेजें।

host बदल दें और वही call किसी shared instance पर भी काम करता है। CapSkip डिफ़ॉल्ट रूप से Local mode में 127.0.0.1 पर सुनता है, और कनेक्शन सेटिंग्स में Server mode भी मिलता है, जहाँ यह आपके network या public IP पर सुनता है ताकि दूसरी मशीनें API तक पहुँच सकें। इसे किसी VPS पर रखें और एक ही सॉल्वर आपके crawl fleet के हर worker को सेवा देता है। प्रॉक्सी handling नहीं बदलती: प्रॉक्सी अब भी हर job पर लागू होती है, और pool अब भी आपके अपने code में रहता है।

आम errors और उनका मतलब

हर प्रकार के parameters का पूरा विवरण यहाँ है: API डॉक्युमेंटेशन.

FAQ

संक्षेप में

हर session के लिए एक प्रॉक्सी बाँधें, किसी तय समय पर नहीं बल्कि हल फेल होने पर बदलें, proxytype हमेशा भेजें, और image jobs पर प्रॉक्सी बिल्कुल छोड़ दें। चूँकि हल करने का काम खुद लोकल रूप से चलता है, एक असीमित कैप्चा सॉल्वर, इसलिए किसी retry में प्रॉक्सी bandwidth के अलावा कुछ खर्च नहीं होता, जो rotate-on-failure को इतना सस्ता बना देता है कि उसे डिफ़ॉल्ट रखा जा सके। यह जिस बड़े pipeline में बैठता है, उसके लिए देखें वेब स्क्रैपिंग के लिए कैप्चा हल करना, जो session handling को शुरू से आख़िर तक कवर करता है। Python एकीकरण गाइड में client-side setup दिया गया है।