API कनेक्शन और CAPTCHA प्रॉक्सी अलग हैं

Application server
  -> HTTPS api.solvethree.com/v1/tasks
     Authorization: Bearer <workspace API key>
     JSON: { "site": "accounts.example.com", "action": "login", "proxy": "http://USER:PASS@PROXY:PORT" }

solvethree solves through the proxy supplied in that JSON.

Application or browser
  -> the SAME successful proxy and pinned exit
  -> intended target, with the returned token/headers/cookie and browser identity

The API key belongs on the API request, never the target request.
Putting a proxy URL in task JSON does not configure the application's HTTP client.

आपका सर्वर solvethree API को एक प्रमाणित HTTPS अनुरोध भेजता है। प्रॉक्सी URL JSON बॉडी के अंदर जाता है; फिर solvethree समाधान के लिए उस प्रॉक्सी का उपयोग करता है। इसके बाद, आपका ऐप्लिकेशन या ब्राउज़र लक्ष्य को अलग अनुरोध भेजता है। न टास्क फ़ील्ड और न ही SDK कॉल उस अंतिम कनेक्शन को अपने आप कॉन्फ़िगर करती है।

उदाहरण के होस्टनेम, ऐक्शन और प्रॉक्सी क्रेडेंशियल की जगह अपने मान रखें। साइट के लिए आपके वर्कस्पेस में उपलब्ध एक सक्रिय प्रोफ़ाइल चाहिए; उसका होस्टनेम भेजने से प्रोफ़ाइल नहीं बनती। साइट प्रोफ़ाइल सेटअप देखें।

वर्कस्पेस की API कुंजी अपने सर्वर पर रखें। उसका Bearer ऑथराइज़ेशन हेडर केवल API होस्ट को भेजें, टास्क स्टेटस प्राप्त करते समय भी। उस हेडर को लक्ष्य के अनुरोध में कॉपी न करें और न ही प्रॉक्सी प्रमाणीकरण के लिए उपयोग करें।

समाधान सबमिट करने वाले HTTP क्लाइंट या ब्राउज़र को अलग से कॉन्फ़िगर करें। सफल प्रॉक्सी के साथ लौटाई गई userAgent और secChUa ब्राउज़र पहचान का उपयोग करें। समाधान के साथ असंबंधित ब्राउज़र पहचान, प्रॉक्सी या लक्ष्य URL न मिलाएँ।

यदि प्रदाता कनेक्शन के बीच एग्ज़िट IP बदलता है, तो एक ही प्रॉक्सी URL पर्याप्त नहीं है। प्रदाता की सेशन या पिनिंग सुविधा का उपयोग करें, ताकि समाधान और लक्ष्य पर सबमिशन का एग्ज़िट एक ही रहे। रेज़िडेंशियल या मोबाइल लेबल यह साबित नहीं करता कि लक्ष्य उसे स्वीकार करेगा।

यदि आप proxyCandidates उपयोग करते हैं, तो सूची की किसी मनमानी एंट्री के बजाय वास्तव में सफल हुई प्रॉक्सी से सबमिट करें। उम्मीदवार solvethree को वैकल्पिक एग्रेस आज़माने देते हैं; वे आपके ब्राउज़र को कॉन्फ़िगर नहीं करते और न ही स्वीकृति की गारंटी देते हैं।

ready टास्क का मतलब है कि समाधान उपलब्ध है। स्वीकृति एक अलग परिणाम है: समाधान ले जाने वाले अनुरोध पर लक्ष्य के रिस्पॉन्स की जाँच करें।

यदि आपका HTTP क्लाइंट HTTP_PROXY या अन्य प्रॉक्सी एनवायरनमेंट सेटिंग पढ़ता है, तो जाँचें कि क्या वे सेटिंग api.solvethree.com के अनुरोधों को भी रूट करती हैं। इससे API कनेक्शन उस प्रॉक्सी से जा सकता है जिसे आपने केवल लक्ष्य के ट्रैफ़िक के लिए रखा था। यह मानने के बजाय कि वह टास्क JSON से मेल खाता है, क्लाइंट के प्रभावी ट्रांसपोर्ट कॉन्फ़िगरेशन की जाँच करें।

API ट्रांसपोर्ट और लक्ष्य ट्रांसपोर्ट को अलग-अलग कॉन्फ़िगर करें। एनवायरनमेंट की प्रॉक्सी सेटिंग आवश्यक टास्क फ़ील्ड का विकल्प नहीं है: reCAPTCHA अनुरोध में अब भी proxy या proxyCandidates में से ठीक एक चाहिए।

टास्क मिलने से पहले API अनुरोध विफल हो जाता है।

HTTP रिस्पॉन्स और आपके API क्लाइंट द्वारा उपयोग किए गए रूट की जाँच करें, जिसमें प्रॉक्सी की सभी एनवायरनमेंट सेटिंग भी शामिल हैं।

यह आज़माएँ: सफलता वाला पेलोड पढ़ने से पहले HTTP त्रुटि संभालें। टास्क प्रॉक्सी को बिना जाँच के बदलने के बजाय API की अनचाही रूटिंग ठीक करें।

आपको HTTP 407 मिलता है।

पहचानें कि प्रॉक्सी प्रमाणीकरण की विफलता किस कनेक्शन पर हुई: API कनेक्शन पर या टास्क प्रॉक्सी उपयोग करने वाले कनेक्शन पर।

यह आज़माएँ: उस प्रॉक्सी के क्रेडेंशियल ठीक करें। उपयोगकर्ता नाम और पासवर्ड वाले हिस्सों के अंदर आरक्षित वर्णों को प्रतिशत-एन्कोड करें, पूरे URL को नहीं।

टास्क बनाने का अनुरोध टाइम आउट हो जाता है।

टाइमआउट यह साबित नहीं करता कि API टास्क बनाने में विफल रही।

यह आज़माएँ: यदि आपके पास टास्क का ID है, तो उसे प्राप्त करें। यदि आपने requestId दिया था, तो नया तार्किक टास्क बनाने से पहले उसी ID के साथ वही टास्क अनुरोध दोहराकर उसे रिकवर करें।

टास्क की स्थिति failed हो जाती है।

उसके errorCode और error पढ़ें; यह HTTP ट्रांसपोर्ट त्रुटि से अलग है।

यह आज़माएँ: उस टास्क की पोलिंग बंद करें और बताए गए कारण को दूर करें। अपरिवर्तित अमान्य इनपुट के साथ दोबारा प्रयास न करें और यह न मानें कि API कनेक्शन की प्रॉक्सी से विफलता हुई।