Clash 노드 지연 시간 테스트 원리: 측정값과 실제 다운로드 속도가 다른 이유

지연 시간은 한 번의 요청에 걸리는 시간이지 다운로드 대역폭이 아닙니다

Clash 클라이언트의 노드 목록에서 ‘속도 테스트’는 일반적으로 지정된 프록시를 통해 테스트 URL에 접속하고, 코어가 보고한 소요 시간을 표시하는 기능입니다. 결과는 밀리초(ms) 단위로 나타납니다. 지속적인 다운로드 속도를 측정하거나 프록시 서버에 ICMP Ping을 한 번 보내는 테스트가 아닙니다. 클라이언트 화면에 ‘지연 시간’이라고 표시되더라도 실제 측정 기준은 코어와 테스트 설정에 따라 달라질 수 있습니다.

흔히 볼 수 있는 상황으로, 한 노드는 80ms로 표시되지만 파일 다운로드 속도는 500KB/s에 그치고, 다른 노드는 180ms인데도 10MB/s를 안정적으로 유지하기도 합니다. 앞의 노드는 짧은 요청에 빠르게 응답하고, 뒤의 노드는 지속적인 전송 처리량이 더 높습니다. 두 지표는 서로 다른 구간을 나타내므로 반드시 비례하지 않습니다.

단위도 혼동하기 쉽습니다. 네트워크 대역폭은 보통 Mbps, 다운로드 도구는 MB/s를 사용합니다. 10진수 기준으로 100Mbps의 이론상 최대 다운로드 속도는 약 12.5MB/s이며, 실제 전송에서는 프로토콜 오버헤드가 빠집니다. 지연 시간의 100ms와 대역폭의 100Mbps는 서로 환산할 수 없습니다.

URL Test의 연결 및 핸드셰이크 과정

HTTPS 테스트 주소를 예로 들면 접속 과정을 몇 단계로 나눠 볼 수 있습니다. 각 단계는 문제 발생 지점을 이해하는 데 도움이 되지만, 모든 코어 버전이 단계별 시간을 각각 측정하고 표시하는 것은 아닙니다. 화면에 표시된 값을 각 단계의 시간을 단순히 더한 정확한 결과로 봐서도 안 됩니다.

1. 노드 주소 확인. 프록시 서버에서 도메인을 사용하는 경우 연결 전에 해당 주소를 확인해야 합니다. 캐시된 결과를 사용할 수도 있고 새 DNS 조회가 발생할 수도 있습니다.
2. 프록시 서버에 연결. 클라이언트는 노드 프로토콜에 따라 전송 연결을 설정합니다. TCP, UDP 기반 전송, 암호화 프로토콜에 따라 준비 과정은 서로 다릅니다.
3. 테스트 대상까지 연결 경로 설정. 프록시 출구에서 대상 사이트에 접속할 수 있어야 합니다. 대상 도메인을 어느 쪽에서 조회하는지는 프로토콜과 관련 설정에 따라 달라집니다.
4. 대상 사이트와 HTTPS 통신 완료. 일반적으로 대상 사이트와의 TLS 핸드셰이크 및 HTTP 요청이 포함되며, 코어가 정한 응답 조건을 충족하면 측정이 끝납니다.

실제 측정 구간과 연결 재사용 여부, 재시도 방식, HTTP 요청 메서드는 코어 버전에 따라 달라질 수 있습니다. 한 클라이언트에 표시된 ‘연결 지연 시간’을 다른 클라이언트가 같은 공식으로 계산한 결과라고 단정하지 마세요. 노드를 비교하려면 클라이언트, 코어, 테스트 URL, 네트워크 환경을 동일하게 맞춰야 합니다.

시스템 Ping은 낮은데 Clash 지연 시간은 높은 이유

노드 서버에 Ping을 보내면 내 기기와 해당 서버 사이의 ICMP 왕복 시간만 확인할 수 있습니다. URL Test 결과에는 프록시 프로토콜 처리, 출구에서 대상 사이트까지의 경로, 대상 서버의 응답도 영향을 줍니다. 서버가 ICMP를 제한해 Ping은 손실되더라도 프록시 요청은 정상일 수 있습니다. 두 테스트는 각각 기록해야 하며 서로 대체할 수 없습니다.

테스트 주소에 따라 측정하는 네트워크 구간이 달라집니다

흔히 사용하는 테스트 URL에는 https://www.gstatic.com/generate_204처럼 HTTP 204 응답을 반환하는 작은 응답용 주소가 있습니다. 204 응답에는 본문이 없어 전송량이 적기 때문에 연결 상태를 자주 확인하기에 적합합니다. 반면 대용량 파일 전송 능력은 거의 보여 주지 못합니다.

같은 출구를 사용해도 도메인에 따라 서로 다른 CDN이나 다른 지역의 접속 지점에 연결될 수 있습니다. 한 노드에서 테스트 서버까지의 경로가 짧다고 해서 동영상 사이트, 코드 저장소, 업무 서비스까지의 경로도 짧다는 뜻은 아닙니다. 테스트 대상을 다른 사이트로 바꾼 뒤 노드 순위가 달라지는 것은 자연스러운 일입니다.

테스트 URL을 고를 때 확인할 세 가지

• 응답이 작고 안정적이어야 합니다. 연결 확인 용도로 명시된 주소를 우선 사용하고, 이미지가 포함된 홈페이지나 로그인 리디렉션, 내용이 계속 바뀌는 페이지는 피하세요.
• 프로토콜을 통일하세요. 노드를 비교할 때는 같은 HTTPS URL을 사용하세요. HTTP와 HTTPS는 통신 과정이 다르므로 같은 순위표에 섞어서는 안 됩니다.
• 실제 서비스도 따로 확인하세요. 동일한 테스트 주소로 노드를 먼저 추린 다음 실제 앱에서 성능을 확인하세요. 로그인 정보나 민감한 쿼리 매개변수가 포함된 링크를 반복해서 요청하지 마세요.

테스트 경로는 세 가지로 구분해야 합니다. 노드 옆의 수동 테스트, url-test 정책 그룹의 자동 테스트, proxy-providers의 상태 확인입니다. 각 경로에 서로 다른 URL, 간격, 시간 제한이 설정될 수 있습니다. 한 곳의 설정만 바꿔도 다른 화면의 테스트 조건은 바뀌지 않을 수 있습니다.

mihomo의 url-test 설정과 자동 노드 선택

url-test 정책 그룹은 테스트 결과에 따라 구성원 중 하나를 자동으로 선택합니다. 아래는 그룹 설정 예시이며, ‘홍콩-01’과 ‘일본-01’은 예시에서 이미 정의된 노드 이름입니다. 실제 설정에 적용할 때는 구성원 이름이 자신의 proxies 정의와 일치해야 올바르게 참조할 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩-01
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300: 자동 테스트 간격은 300초이며, 300밀리초가 아닙니다.
• tolerance: 50: 밀리초 단위의 전환 허용값으로, 지연 시간의 작은 차이 때문에 노드가 자주 바뀌는 것을 줄여 줍니다. 시간 제한을 뜻하지는 않습니다.
• lazy: true: 해당 그룹을 사용하지 않을 때 주기적인 테스트를 건너뛰어 백그라운드 요청을 줄일 수 있습니다. 따라서 오랫동안 사용하지 않은 그룹의 지연 시간은 최신 값이 아닐 수 있습니다.

설정 항목은 현재 코어의 지원 범위를 기준으로 확인해야 합니다. 클래식 Clash와 mihomo는 모든 필드가 동일하지 않습니다. 클라이언트가 설정 덮어쓰기나 구독 변환을 통해 최종 내용을 변경할 수도 있으므로, 구독 원문만 볼 것이 아니라 실제 실행 중인 설정을 확인하세요. 설정 및 설치 방법은 전 플랫폼 가이드를 참고하세요.

지연 시간은 낮지만 다운로드가 느린 흔한 이유

출구 대역폭 제한과 공유 회선 혼잡

작은 HTTP 응답은 전송 데이터가 적기 때문에 회선 속도가 5Mbps로 제한되어 있어도 빠르게 돌아올 수 있습니다. 반면 1GB 파일을 다운로드하려면 대역폭을 지속적으로 사용해야 하므로 출구 속도 제한, 공유 회선 혼잡, 서버 측 속도 제한이 드러납니다. 저녁 시간대에 ‘지연 시간은 비슷한데 다운로드가 눈에 띄게 느려지는’ 경우에는 지연 테스트를 반복하기보다 지속 전송 처리량을 확인하세요.

패킷 손실과 재전송이 장시간 연결에 미치는 영향

간헐적인 패킷 손실은 짧은 테스트에서는 나타나지 않더라도 장시간 전송 중 재전송과 혼잡 제어를 유발할 수 있습니다. 속도가 크게 오르내리거나, 처음에는 정상이다가 이후 떨어지는 현상으로 나타날 수 있습니다. 여러 차례의 요청 성공률과 실제 다운로드 과정을 함께 확인해야 합니다. 한 번 측정한 최저 지연 시간만으로 안정성을 판단할 수는 없습니다.

실제 트래픽이 테스트한 노드를 거치지 않는 경우

노드를 수동으로 테스트했다고 해서 브라우저도 해당 노드를 사용 중인 것은 아닙니다. 규칙에 따라 대상 도메인이 다른 정책 그룹이나 DIRECT로 전달될 수 있습니다. 시스템 프록시는 해당 설정을 따르는 앱에만 적용되며, TUN 모드의 적용 범위도 라우팅, 제외 항목, 클라이언트 설정에 따라 달라집니다. 클라이언트 연결 목록에서 대상 도메인, 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요.

다운로드 서버나 기기 환경이 병목인 경우

원격 사이트는 연결, 계정, 지역에 따라 속도를 제한할 수 있습니다. 기기의 Wi-Fi 간섭, 백그라운드 동기화, 디스크 쓰기도 측정 결과에 영향을 줍니다. 같은 다운로드 작업에서 노드를 계속 바꾸기보다 서로 다른 출처 두 곳에서 반복 테스트하는 편이 원인을 파악하는 데 도움이 됩니다.

timeout의 의미와 문제 확인 순서

timeout은 테스트가 정해진 시간 안에 완료되지 않았다는 뜻이지, 구독이 만료되었다는 확정 신호가 아닙니다. DNS 조회 실패, 서버 연결 불가, 프로토콜 매개변수 오류, 대상 사이트 제한, 현재 네트워크 속도 저하 등 다양한 이유로 테스트가 실패할 수 있습니다. 일부 클라이언트는 여러 오류를 모두 시간 초과로 표시하므로 구체적인 원인은 로그에서 확인해야 합니다.

1. 네트워크 조건을 통일하세요. 대용량 다운로드를 일시 중지하고 같은 Wi-Fi 또는 유선 네트워크에서 다시 테스트한 뒤 실패한 시각을 기록하세요.
2. 단일 노드 문제인지 전체 노드 문제인지 구분하세요. 한 노드만 실패하면 우선 해당 노드 정보를 확인하세요. 모든 노드가 동시에 실패하면 로컬 네트워크, DNS, 공용 테스트 대상부터 확인하세요.
3. 테스트 주소를 한 번 바꿔 보세요. 안정적인 다른 소형 응답 주소를 사용하세요. 기존 주소에서만 실패한다면 노드 전체를 사용할 수 없다고 판단해서는 안 됩니다.
4. 로그에서 오류 유형을 확인하세요. 이름 확인 오류, 연결 거부, TLS 오류, 응답 대기 시간 초과는 각각 해결 방법이 다릅니다. TLS 오류가 발생하면 시스템 날짜와 시간도 확인하세요.
5. 시간 초과 설정 위치를 확인하세요. 수동 테스트, 정책 그룹, 제공자 상태 확인은 서로 다른 제한 시간을 사용할 수 있습니다. 한 곳의 값을 늘려도 다른 테스트 경로에 반영된다는 보장은 없습니다.

예를 들어 테스트 제한 시간이 5초라면 6초가 걸린 요청은 실패로 처리됩니다. 제한 시간을 10초로 늘리면 성공으로 표시될 수는 있지만 회선 자체가 개선되는 것은 아닙니다. 시간 제한은 대기 시간을 정하는 값이지 속도를 높이는 설정이 아닙니다. 응답에 계속 몇 초씩 걸린다면 화면에 성공으로 표시되도록 설정만 바꾸지 말고 네트워크 경로를 점검하세요.

같은 조건으로 비교해 노드 품질 판단하기

아래는 반복해서 실행할 수 있는 노드 선별 절차입니다. 숫자는 기록 방법을 보여 주는 예시이며, 이 사이트에서 특정 노드를 직접 측정한 결과가 아닙니다. 비교할 때는 기기, 테스트 URL, 다운로드 출처, 시간대를 동일하게 유지하고 한 번에 노드 하나만 바꾸세요.

1. 먼저 짧은 요청을 테스트하세요. 노드별로 URL Test를 5회 실행하고, 약 10초 간격으로 모든 측정값과 실패 횟수를 기록하세요. 가장 좋은 결과만 남기지 마세요.
2. 다음으로 지속 전송을 테스트하세요. 속도 테스트가 허용된 고정 다운로드 출처를 선택해 30~60초 동안 관찰하고, 시작 직후와 속도가 안정된 뒤의 수치를 각각 기록하세요. 데이터 사용량에도 유의하세요.
3. 실제 출구 노드를 확인하세요. 연결 목록에서 해당 작업이 사용하는 노드를 확인하세요. 정책을 바꾼 뒤에는 작업을 다시 시작해야 합니다. 기존 연결은 즉시 새 노드로 전환되지 않을 수 있습니다.
4. 실제 사용 중인 앱에서 다시 확인하세요. 동영상은 재생 시작, 탐색, 버퍼링을 살펴보고, 웹페이지는 첫 화면 로딩과 연속 접속을 확인하세요. 원격 접속은 입력 반응과 연결 끊김 여부를 확인하세요.
5. 시간대를 바꿔 다시 확인하세요. 낮과 저녁 시간대의 결과를 각각 한 번 이상 비교해 특정 시점의 결과를 장기적인 품질로 오해하지 않도록 하세요.

이 예시에서는 노드 A가 짧은 요청에 더 빠르고, 노드 B는 대용량 파일 전송에 더 적합합니다. 5회 중 2회가 시간 초과라면 ‘성공 3/5’라고 별도로 기록하세요. 나머지 3회의 평균만 전체 결과인 것처럼 취급하면 안 됩니다. 상호작용이 중요한 앱에서는 낮고 안정적인 지연 시간이 더 중요하고, 대용량 파일이나 고화질 동영상에서는 지속 전송 처리량과 성공률도 중요합니다.

최종 선택은 실제 작업에 맞춰야 합니다. 먼저 URL Test로 접속할 수 없는 노드를 제외한 다음, 실제 앱에서 경로와 성능을 확인하세요. 지연 시간은 노드 선별 기준 중 하나일 뿐 다운로드 속도 점수도, 모든 사이트에서 사용할 수 있다는 보장도 아닙니다.