로그는 프록시를 돌립니다. 요청은 여전히 예전 것을 씁니다.
새 값을 출력하면 요청 구성이 바뀐다고 가정하지 말고, 선택된 엔드포인트를 실제 HTTP 전송 호출까지 추적하세요.
선택기는 프록시 A를 출력하고, 다음으로 프록시 B를 출력합니다. 그런데 요청 로그는 계속 프록시 A를 보여 줍니다. 이 모순을 설명하는 데 네트워크 서비스는 필요 없습니다. 호출하는 쪽이 선택기의 반환 값을 버렸을 수 있습니다.
그 값을 요청을 보내는 호출까지 추적하세요:
endpoint = choose_proxy()
routes = {'http': endpoint, 'https': endpoint}
response = session.get(target_url, proxies=routes, timeout=15)
이 조각은 기존 Requests 세션과 검증된 프록시 URL을 전제로 합니다. 공개 중개자를 통해 허용되는 공개 요청의 경우 무료 프록시 목록이 같은 선택과 전송 경로를 거치는 후보 URL을 제공합니다. 지원되는 키워드는 proxies입니다. 매핑을 출력만 하거나 아무도 대입하지 않는 매핑을 반환하는 헬퍼는 여기서 넘기는 매핑을 대신할 수 없습니다.
선택한 경로는 그 작업 안에 국소적으로 두세요. 동시성 코드에서는 공유 current_proxy 필드가 기록과 전송 사이에 바뀔 수 있습니다. 그러면 다른 워커의 선택이 잘못된 결과 옆에 나타날 수 있습니다.
선택, 전송 구성, 결과를 연결하려면 시도 식별자를 사용하세요. 자격 증명이 들어 있을 때는 전체 URL 대신 안전한 엔드포인트 식별자를 기록하세요.
그 값들이 일치하는데 관측된 공인 IP가 바뀌지 않는다면 다른 질문에 도달한 것입니다. 선택한 엔드포인트가 서로 다른 출구를 제공하는지, 아니면 회전 게이트웨이가 연결을 유지하는지입니다. 먼저 애플리케이션이 선택했다고 주장하는 경로를 실제로 보냈는지 확정하세요. 그렇지 않으면 공급자 측 추측이 단순한 오래된 변수를 몇 시간씩 가릴 수 있습니다.