multi-cURL 전송은 각자의 순서로 완료됩니다. 각 핸들에 서로 다른 프록시를 할당했다면, 가장 먼저 완료된 결과가 입력 목록의 첫 번째 프록시의 것이라고 단정할 수 없습니다.

각 핸들을 구성할 때 안정적인 전송 식별자를 붙이세요. 선택 가능한 공개 엔드포인트를 시험하고 있다면 HTTP 프록시 목록이 HTTP 후보를 제공합니다. PHP는 libcurl의 비공개 데이터 메커니즘을 노출합니다:

$id = 'job-17';
curl_setopt($handle, CURLOPT_PROXY, 'http://203.0.113.10:8080');
curl_setopt($handle, CURLOPT_PRIVATE, $id);

curl_multi_info_read() 이 완료된 전송을 보고하면, 반환된 핸들을 사용해 식별자를 되찾으세요:

$id = curl_getinfo($message['handle'], CURLINFO_PRIVATE);

그 식별자를 키로 하는 응용 프로그램 레코드를 유지하며, 대상, 구성된 프록시, 시도 번호를 담습니다. 다른 프록시를 통한 재시도는 같은 전체 작업에 속하더라도 새로운 시도 레코드를 받을 자격이 있습니다.

세 가지 주소를 분리해 두세요

구성된 프록시 엔드포인트는 cURL에 제공된 주소입니다. 연결의 피어 주소는 cURL이 연 네트워크 연결을 설명합니다. 대상이 관찰한 출구 IP는 반대편에서 보고된 정보입니다. 이들은 다를 수 있으며, 특히 체인 프록시나 공급자 관리 프록시에서 그렇습니다.

비공개 메타데이터는 의도한 구성을 기록하지만, 대상이 어떤 IP를 보았는지 증명할 수는 없습니다. 반대로 대상의 IP 응답은 프로그램의 어느 핸들이 그것을 생성했는지 자동으로 알려 주지 않습니다.

일상 로그에는 안전한 프록시 식별자를 저장하세요. 전체 엔드포인트에 자격 증명이 포함되어 있다면, 실패한 전송마다 그 URL을 기록하는 것은 비밀번호를 오류 수집 전체에 퍼뜨립니다.

이 작은 기록 단계는 혼합된 결과를 더 읽기 쉽게 만듭니다. 하나의 작업, 하나의 시도, 하나의 선택된 프록시, 하나의 실제 결과입니다. 또한 PHP의 리소스 기반 cURL API와 객체 기반 cURL API 사이에서 바뀐 우연한 핸들 표현에 의존하는 일도 피합니다.

관련 글