החיבור ל-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.

השרת שלכם שולח בקשת HTTPS מאומתת ל-API של solvethree. כתובת ה-URL של הפרוקסי מועברת בתוך גוף ה-JSON; לאחר מכן solvethree משתמש בפרוקסי הזה לפתרון. בהמשך, האפליקציה או הדפדפן שלכם שולחים בקשה נפרדת ליעד. לא שדה המשימה ולא קריאה ל-SDK מגדירים אוטומטית את החיבור האחרון הזה.

יש להחליף את שם המארח, הפעולה ופרטי ההזדהות של הפרוקסי שבדוגמה בערכים שלכם. לאתר נדרש פרופיל פעיל שזמין לסביבת העבודה שלכם; שליחת שם המארח שלו אינה יוצרת פרופיל. ראו הגדרת פרופיל אתר.

יש לשמור את מפתח ה-API של סביבת העבודה בשרת שלכם. יש לשלוח את כותרת ההרשאה מסוג Bearer שלו רק למארח ה-API, גם בעת אחזור סטטוס המשימה. אין להעתיק את הכותרת הזו לבקשה ליעד או להשתמש בה לאימות מול הפרוקסי.

יש להגדיר בנפרד את לקוח ה-HTTP או הדפדפן ששולח את הפתרון. יש להשתמש בפרוקסי שהצליח יחד עם זהות הדפדפן שהוחזרה בשדות userAgent ו-secChUa. אין לשלב את הפתרון עם זהות דפדפן, פרוקסי או כתובת URL של יעד שאינם קשורים אליו.

אותה כתובת URL של פרוקסי אינה מספיקה אם הספק מחליף את כתובת ה-IP ביציאה בין חיבורים. יש להשתמש בתכונת הסשן או הקיבוע של הספק, כך שהפתרון והשליחה ליעד ישתמשו באותה נקודת יציאה. תיוג כפרוקסי ביתי או סלולרי אינו מעיד שהיעד יקבל אותו.

אם משתמשים ב-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 לא הצליח ליצור את המשימה.

כדאי לנסות: יש לאחזר את המשימה אם המזהה שלה ברשותכם. אם סיפקתם requestId, יש לשחזר אותה באמצעות שליחה חוזרת של אותה בקשת משימה עם המזהה הזה לפני יצירת משימה לוגית חדשה.

המשימה מגיעה לסטטוס failed.

יש לקרוא את errorCode ואת error שלה; מצב זה שונה משגיאת תעבורת HTTP.

כדאי לנסות: יש להפסיק לתשאל את המשימה הזו ולטפל בגורם שדווח. אין לנסות שוב עם קלט לא תקין שלא השתנה או להניח שהפרוקסי של החיבור ל-API גרם לכשל.