지연 시간이 짧은 프록시도 다운로드가 느릴 수 있는 이유

작은 페이지를 빠르게 반환하는 프록시도 파일을 다운로드할 때는 느릴 수 있습니다. 첫 요청은 주로 연결 설정과 응답 지연을 보여 줍니다. 대용량 전송은 해당 경로가 지속적으로 전달할 수 있는 데이터양에도 영향을 받습니다.

어떤 수치가 필요한가요?

ICMP ping은 다른 테스트입니다. 서버는 프록시 서비스를 사용할 수 없는 상태에서도 ping에 응답할 수 있고, 프록시가 작동하는 동안 ping을 차단할 수도 있습니다. 프록시 주소까지의 왕복 시간에는 프록시에서 목적지까지의 연결도 포함되지 않습니다.

실제 전송 측정하기

직접 관리하는 서버의 파일이나 이러한 테스트용 파일을 사용하세요. 다음 예제는 응답 본문을 버리고 전송 크기, 초당 평균 바이트, 총 시간을 출력합니다.

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin

예제의 프록시와 파일 URL을 모두 바꾸세요. 404 페이지나 접근 거부 응답은 빠르게 도착해도 유효한 다운로드 성능 측정이 아닙니다. 속도를 비교하기 전에 상태, 예상 파일 크기, 내용을 확인하세요.

평균 속도 필드의 단위는 초당 바이트입니다. 초당 비트로 광고하는 네트워크 요금제와는 단위가 다릅니다. 바이트를 비트로 대략 변환하려면 8을 곱하고, 비교 내내 같은 단위를 사용하세요.

비교 조건 맞추기

목적지, 파일, 클라이언트 네트워크, 시간 제한 설정을 동일하게 유지하세요. 가장 빠른 시도만 고르지 말고 적당한 규모의 여러 표본을 비교하세요. 전송이 멈추는 경우에는 연결 설정, 전체 시간, 저속 상태의 제한을 신중하게 선택하세요. 실패한 요청도 결과에 남겨 두세요. 가끔 빠르지만 자주 실패하는 프록시는 반드시 끝내야 하는 작업에 부적합할 수 있습니다.

캐시된 파일과 새 다운로드는 서비스 내부에서 서로 다른 경로를 거칠 수 있습니다. 연결 설정 후의 요청과 기존 연결을 재사용하는 요청도 마찬가지입니다. 애플리케이션에 필요한 동작을 정하고 해당 동작을 일관되게 측정하세요.

작업 부하에 맞게 선택하기

작은 API 응답에서는 최대 처리량보다 첫 바이트 전의 추가 1초가 더 중요할 수 있습니다. 대용량 다운로드에서는 핸드셰이크만 빠르고 본문이 매우 느린 것은 좋은 절충이 아닙니다. 두 작업 모두 실제로 사용할 목적지를 테스트하세요. 프록시를 통과하는 모든 경로를 설명하는 단일 속도 점수는 없습니다.

ProxyHub 프록시 목록은 IP별 독립적인 처리량 측정값을 제공하지 않습니다. 프로토콜이나 국가 필터는 속도 순위가 아닙니다.