Scrapy 쿠키 항아리는 프록시가 아니라 세션에 속합니다
여러 프록시 워크플로가 하나의 스파이더를 공유할 때는 명시적인 쿠키 항아리 정체성을 선택하고 그 정체성을 후속 요청까지 이어가세요.
프록시를 바꾼다고 스파이더의 쿠키가 자동으로 바뀌지는 않습니다. 하나의 이어지는 세션에는 유용할 수 있지만, 여러 독립 세션이 같은 스파이더를 공유할 때는 예상 밖의 결과가 됩니다.
Scrapy의 쿠키 미들웨어는 요청의 cookiejar 메타데이터로 선택되는 별도 항아리를 지원합니다. 그 키에는 실제로 유지하려는 정체성을 지정하세요:
yield scrapy.Request(
'https://example.com/start',
meta={'proxy': selected_proxy, 'cookiejar': 'workflow-17'},
)
엔드포인트와 항아리 키는 독립적인 선택입니다. 인증되지 않은 공개 크롤은 해당 경로가 허용된 곳에서 HTTP 프록시 목록에서 선택한 HTTP 엔드포인트를 쓸 수 있지만, 항아리 키는 여전히 워크플로가 소유합니다. 이 세션에 남아야 하는 후속 요청에는 같은 항아리 키가 필요합니다. 메타데이터는 새로 만드는 모든 요청에 자동으로 붙지 않습니다. 미들웨어 메타데이터를 전부 무턱대고 복사하지 말고 워크플로가 요구하는 특정 필드만 전달하세요.
프록시 주소를 항아리 키로 쓰는 것은 하나의 정책일 뿐입니다
그 지름길은 상태를 엔드포인트별로 묶을 뿐입니다. 사람, 계정, 공개 출구별로 묶는다고 보장하지는 않습니다. 하나의 공급자 엔드포인트가 출구를 회전할 수 있고, 여러 계정이 같은 엔드포인트를 쓸 수 있습니다.
안정적인 상태가 필요한 승인된 워크플로에서는 계정/세션 식별자, 항아리 식별자, 선택한 경로를 따로 기록하세요. 도중에 경로를 바꾸기로 했다면 애플리케이션 세션은 어떻게 할지도 함께 정하세요.
별도 항아리는 정의한 그룹 사이에서 쿠키가 우연히 공유되는 것을 막습니다. 다만 목적지가 계정이나 다른 애플리케이션 데이터를 통해 두 요청을 연결할 수 없다고 약속하지는 않습니다.
IP를 바꾼 뒤에도 잘못된 페이지가 계속 나오면 모든 쿠키를 지우거나 전체 프록시 풀을 교체하기 전에 어느 항아리가 요청을 보냈는지 확인하세요. 남아 있는 상태가 그 페이지를 충분히 설명할 수 있습니다.