무료 프록시는 작동하지 않는 경우가 더 많습니다. 공개 목록은 수만 개의 후보를 순환하며, 여러분의 작업은 현재 작동 중이며, 충분히 빠르고, 악의적이지 않은 작은 하위 집합을 찾는 것입니다. 다섯 가지 테스트는 각각 비용이 적게 들며 순서대로 실행됩니다.
테스트 1: TCP 도달 가능성
curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
-s -o /dev/null -w "%{http_code}\n" \
https://api.ipify.org0이 아닌 종료 코드 또는 빈 응답은 프록시가 작동하지 않음을 의미합니다. 주어진 시점에서 모든 무료 목록의 약 60~80%가 이 테스트를 실패합니다. 즉시 건너뛰고 재시도하지 마십시오.
테스트 2: Egress IP 확인
동일한 호출은 요청이 발생한 공인 IP를 반환합니다. 만약 그것이 1.2.3.4 — 프록시의 주소 — 와 같다면, 프록시가 트래픽을 올바르게 전달하고 있음을 의미합니다. 만약 그것이 로컬 IP와 같다면, 프록시가 고장났거나 투명 모드(transparent)입니다: 연결은 수락했지만 실제로 자신을 통해 중계하지 않았습니다. TCP가 성공했더라도 실패로 처리하십시오.
테스트 3: 헤더 투명성
curl --proxy http://1.2.3.4:8080 https://httpbin.org/headers응답은 대상이 수신한 헤더를 그대로 반환합니다. X-Forwarded-For, Via 또는 Forwarded에 자신의 실제 IP가 포함되어 있는지 확인하십시오. 발견된다면 프록시가 엘리트(Elite) 모드가 아닌 투명(Transparent) 또는 익명(Anonymous) 모드에 있는 것입니다. CONNECT를 통한 HTTPS의 경우 이는 의미가 없습니다. 대상은 TLS 핸드셰이크만 볼 뿐 애플리케이션 헤더는 보지 않습니다. 그러나 일반 텍스트 HTTP의 경우 프록시가 목적에 적합한지 여부를 결정합니다.
테스트 4: 부하 상태의 지연 시간
단일 측정의 타이밍은 노이즈가 많습니다. 프록시를 통해 10개의 직렬 요청을 실행하고 중앙값(median)을 사용하십시오. 2초 이상이면 대화형 작업에는 사용할 수 없습니다. 500밀리초 미만이면 프록시 없이도 경쟁력 있는 수준입니다. 그 사이의 값이라면 프록시가 배치 스크래핑에는 적합하지만 브라우징에는 적합하지 않습니다.
테스트 5: TLS 지문 무결성
프록시를 통해 알려진 TLS 엔드포인트에 연결하여 인증서 체인이 프록시 없이 얻은 것과 일치하는지 검증하십시오. 불일치가 있다면 프록시가 TLS를 가로채고 있음을 의미합니다 — 중간자 공격(MITM)을 수행하고 있으며, "암호화된" 트래픽이 프록시 이후로는 실제로 암호화되지 않습니다. 이는 올바르게 구성된 SOCKS 프록시에서는 드물지만(SOCKS는 TLS를 볼 수 없습니다), 잘못 구성된 기업 HTTPS 프록시와 가끔 악의적인 공용 노드에서 나타납니다. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443가 체인을 출력합니다.
실용적인 워크플로
목록을 가져온 후 국가 및 프로토콜별로 필터링하고, 다섯 가지 테스트를 약 50개의 워커로 구성된 병렬 풀에 분산(fan out)시킨 후, 살아남은 것들을 보관하십시오. 100개의 원시 후보에서 일반적인 실행은 5~15개의 사용 가능한 항목을 얻을 수 있습니다. HTTP 및 HTTPS의 경우 유효 기간(decay rate)은 대략 30~60분이며, SOCKS의 경우 약간 더 깁니다. 해당 주기로 새로고침(refresh)을 예약하고 살아남은 집합을 스크래퍼 또는 브라우저 설정에 공급하십시오. 테스트 결과를 한 배치의 수명 동안 캐시하고 다음 배치에서 다시 테스트하십시오.