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 요청을 solvethree API로 보냅니다. 프록시 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 연결의 프록시가 실패 원인이라고 가정하지 마세요.