Clash 노드 지연 시간 테스트 원리: 지연 시간(ms)이 실제 속도와 다른 이유

노드 목록의 밀리초 값은 한 번의 요청을 측정한 결과입니다

Clash 클라이언트의 ‘속도 테스트’는 보통 코어가 지정한 노드를 통해 테스트 주소에 접속하고, 탐색에 걸린 시간을 밀리초로 표시하는 기능입니다. 대용량 파일을 계속 다운로드해 대역폭을 측정하는 것과는 다릅니다. 노드 옆에 80ms라고 표시되어도 이번 탐색이 빠르게 끝났다는 뜻일 뿐, 초당 몇 MB를 다운로드할 수 있는지는 알 수 없습니다.

클라이언트는 버튼과 목록, 결과 표시를 담당하고 실제 연결은 Clash 또는 Clash Meta(현재는 보통 mihomo라고 부름) 코어가 처리합니다. 클라이언트와 코어 버전에 따라 테스트 방식, 시간 측정 범위, 결과 캐시가 다를 수 있으므로 화면에 표시된 숫자를 그대로 비교하기는 어렵습니다. 어느 노드가 더 빠른지 비교하려면 먼저 테스트 주소와 방식을 동일하게 맞춰야 합니다.

일반적인 테스트는 어떤 단계를 거칠까요?

1. 사용자가 노드의 지연 시간 테스트 버튼을 누르거나, 프록시 그룹이 설정된 일정에 따라 검사를 시작하면 코어가 테스트 작업을 받습니다.
2. 코어는 지정된 프록시 노드로 나가는 연결을 만듭니다. 먼저 노드 서버의 도메인을 확인해야 할 수도 있고, 프록시 프로토콜의 핸드셰이크가 필요할 수도 있습니다.
3. 트래픽은 프록시 서버를 거쳐 테스트 사이트에 도달합니다. HTTPS를 사용한다면 대상 사이트와 TLS 협상도 진행됩니다.
4. 코어는 구현 방식에 따라 응답의 유효성을 확인한 뒤, 소요 시간이나 실패 상태를 클라이언트에 반환합니다.

위 단계가 매번 모두 새로 실행되는 것은 아닙니다. DNS 캐시, 연결 재사용, 프로토콜 세션 재사용으로 후속 테스트 시간이 짧아질 수 있습니다. 구현에 따라 요청을 한 번 이상 보내기도 합니다. 따라서 화면의 ‘지연 시간’을 네트워크 패킷 하나가 왕복하는 시간으로 엄밀하게 해석해서는 안 되며, 시스템의 ping 명령 결과와도 다릅니다.

테스트 주소·시간 초과·자동 선택이 결과에 미치는 영향

테스트 주소가 ‘어디까지 측정할지’를 결정합니다

테스트 주소로는 소량의 데이터를 반환하거나 HTTP 204 상태를 보내는 페이지를 주로 사용합니다. 예를 들면 https://www.gstatic.com/generate_204가 있습니다. 응답 본문이 작아 데이터 다운로드 자체가 측정 시간에 미치는 영향을 줄일 수 있습니다. 다만 결과는 해당 서비스가 있는 네트워크까지의 접속 상태만 나타내며, 모든 웹사이트에서 같은 속도가 나온다는 뜻은 아닙니다.

노드 출구에서 테스트 서비스까지는 경로가 좋더라도 동영상 사이트나 업무 플랫폼으로 가는 경로는 다를 수 있습니다. CDN은 출구 위치, DNS 응답, 서버 부하에 따라 서로 다른 엣지 서버를 할당할 수도 있습니다. 테스트 주소를 HTTPS에서 HTTP로 바꾸면 연결 과정도 달라집니다. 두 방식의 결과를 한데 섞어 가장 낮은 값만 고르는 것은 적절하지 않습니다.

시간 초과는 테스트가 제한 시간 안에 끝나지 않았다는 뜻이지, 노드가 영구적으로 끊겼다는 뜻은 아닙니다

테스트 시간 초과가 5000ms라고 가정해 보겠습니다. 제한 시간 내에 유효한 탐색이 끝나지 않으면 코어가 실패를 반환할 수 있습니다. 프록시 연결 실패, 대상 사이트 접속 불가, TLS 오류, 당시의 네트워크 혼잡 등 원인은 다양하며 ‘노드 오프라인’만이 이유는 아닙니다. 반대로 시간 초과를 10000ms로 늘려도 기다리는 시간만 길어질 뿐 회선 속도가 빨라지지는 않습니다.

화면에 표시되는 Timeout, Error, 빈 칸, 0 ms는 클라이언트마다 실패나 미테스트 상태를 다르게 표현한 것일 수 있습니다. 이런 상태가 나타나면 연결 로그에서 구체적인 오류를 확인하세요. 모든 문제를 패킷 손실로 단정해서는 안 됩니다.

url-test는 지연 시간이 짧은 노드를 고르지만 최대 대역폭을 측정하지는 않습니다

아래는 mihomo 스타일의 프록시 그룹 예시입니다. 香港 01과 日本 01은 현재 설정에 정의된 노드 이름이어야 합니다. 아래 내용은 설정 일부일 뿐, 그대로 가져와 사용할 수 있는 전체 구독 설정이 아닙니다.

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

• interval: 300: 검사 간격은 초 단위이며, 여기서는 5분입니다. 웹페이지를 열 때마다 테스트하는 것은 아닙니다.
• tolerance: 50: 전환 허용 오차는 밀리초 단위입니다. 미세한 차이로 노드가 계속 바뀌는 것을 줄이기 위한 값이지, 대역폭 기준이 아닙니다.
• lazy: true: 그룹을 사용하지 않을 때는 주기 검사를 건너뛸 수 있으므로 목록에 표시된 결과가 방금 측정한 값이 아닐 수도 있습니다.

‘전체 속도 테스트’를 직접 실행하는 기능, 프록시 그룹의 자동 검사, 프록시 모음의 상태 확인은 테스트 진입점과 매개변수가 서로 다를 수 있습니다. 특정 그룹의 url만 바꿔도 클라이언트에서 직접 실행하는 테스트 주소까지 바뀐다고 보장할 수는 없습니다. 지원되는 필드는 현재 코어를 기준으로 확인하고, 관련 개념은 프로토콜 및 설정 참고서를 함께 살펴보세요.

지연 시간이 짧은데도 노드가 느리고 동영상이 끊기는 이유

응답이 작은 요청은 처리량을 거의 요구하지 않습니다. 회선의 지속 대역폭이 5Mbps뿐이어도 수십~수백 바이트의 응답은 빠르게 도착할 수 있습니다. 고화질 동영상이나 대용량 설치 파일을 다운로드하면 대역폭 제한이 뚜렷하게 드러납니다. 노드 지연 시간은 짧지만 다운로드 속도가 느린 상황은 서로 모순되지 않습니다.

패킷 손실은 문제를 더 알아차리기 어렵게 만들기도 합니다. 한 번의 탐색은 우연히 성공해 수치가 좋아 보일 수 있지만, 연속 전송에서는 TCP 재전송과 혼잡 제어로 실효 속도가 낮아질 수 있습니다. QUIC을 사용하는 서비스는 UDP 경로도 이용합니다. TCP 기반 HTTPS 탐색 한 번으로는 노드의 UDP 지원 여부나 UDP 품질을 확인할 수 없습니다.

반복 가능한 노드 테스트 절차

1단계: 실제 트래픽이 테스트 대상 노드를 통과하는지 확인

먼저 클라이언트에서 테스트할 노드를 선택한 다음 ‘연결’ 또는 ‘Connections’ 페이지에서 대상 도메인의 기록을 확인해 적용된 규칙과 프록시 체인을 살펴보세요. 페이지 이름은 클라이언트마다 다르지만 확인할 내용은 같습니다. 실제 연결이 최종적으로 어떤 출구를 사용했는지 확인해야 합니다. 테스트 중에는 자동 전환 그룹을 함께 사용하지 마세요. 대용량 파일 다운로드와 다음 웹페이지 요청이 서로 다른 노드를 사용할 수 있습니다.

시스템 프록시는 해당 설정을 따르는 앱에만 영향을 줍니다. 명령줄, 게임, 일부 다운로드 도구는 시스템 프록시를 사용하지 않을 수 있습니다. TUN 모드는 프록시 적용 범위를 넓힐 수 있지만 라우팅, 제외 규칙, 실제 연결 기록은 여전히 확인해야 합니다. TUN을 켠다고 속도가 빨라지는 것은 아니며, 대역폭이 낮은 회선이 더 빠른 회선으로 바뀌지도 않습니다.

2단계: 조건을 고정하고 한 번이 아닌 여러 차례 측정

1. 다른 대용량 트래픽을 중지하고 같은 네트워크, 테스트 주소, 시간 초과 설정을 유지합니다.
2. 노드마다 10회씩 테스트하고 약 5초 간격으로 실행해 성공한 요청의 소요 시간과 실패 횟수를 기록합니다.
3. 일반적인 대기 시간은 중앙값으로 비교하고 최댓값도 함께 기록해, 한 번의 낮은 결과가 변동을 가리지 않도록 합니다.
4. 저녁 20:00~22:00처럼 평소 자주 사용하는 시간대에 다시 측정해 혼잡 시간대의 변화를 확인합니다.

요청 10회 중 2회가 실패했다면 정확한 표현은 ‘이번 애플리케이션 계층 탐색의 실패율은 20%’입니다. 이를 곧바로 ‘네트워크 패킷 손실률 20%’라고 해서는 안 됩니다. 요청 하나에 여러 패킷이 포함될 수 있고 DNS, TLS, 대상 서비스 문제로 실패할 수도 있습니다. 10회 연속 성공하더라도 장시간 연결의 안정성을 입증하기에는 표본이 부족합니다.

3단계: 실제 사용으로 대역폭과 안정성 확인

접근 권한이 있고 크기를 알고 있는 파일이나 같은 구간의 동영상을 골라 출처를 고정한 뒤 노드별로 비교하세요. 다운로드는 연결 후 속도가 올라가는 약 10초간의 과정과 이후 30~60초간의 지속 속도를 관찰합니다. 동영상은 버퍼링 횟수와 시간, 플레이어가 표시하는 연결 속도를 확인합니다. 두 방식 모두 노드 목록의 숫자만 보는 것보다 실제 사용 경험에 가깝습니다.

단위도 맞춰야 합니다. 8Mbps는 십진법 기준 약 1MB/s이고, 80Mbps는 약 10MB/s입니다. 실제 유효 속도는 프로토콜 오버헤드의 영향을 받습니다. 도구가 MiB/s로 표시한다면 이진 단위를 사용하므로 수치가 조금 달라집니다. 지속 대역폭 테스트는 구독 데이터 사용량을 늘리므로, 특히 모바일 네트워크에서는 테스트 횟수를 조절하세요.

curl로 연결 시간과 첫 바이트 수신 시간 나눠 보기

시간이 어디에서 걸리는지 자세히 알아보려면 curl이 로컬 HTTP 프록시를 사용하도록 지정하고 단계별 시간을 출력하면 됩니다. 아래 예시는 클라이언트의 HTTP 또는 혼합 리스닝 포트가 7890이라고 가정합니다. 흔히 쓰이는 설정이지만 모든 클라이언트의 기본값은 아니므로 실행 전에 클라이언트의 포트 설정을 확인하세요.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  --output /dev/null \
  --silent --show-error \
  --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

이 명령은 macOS, Linux 등 일반적인 셸에서 사용할 수 있습니다. Windows PowerShell에서는 curl.exe를 실행하고 명령을 한 줄로 합친 뒤 --output /dev/null을 --output NUL로 바꾸세요. 프록시를 명시하면 명령줄이 시스템 프록시를 사용하는지 추측할 필요가 없습니다. 단, 먼저 클라이언트에서 현재 선택한 출구를 확인해야 합니다.

• time_connect: 로컬 HTTP 프록시를 사용하는 이 상황에서는 주로 127.0.0.1:7890까지의 연결 시간을 나타냅니다. 원격 노드까지의 지연 시간으로 볼 수는 없습니다.
• time_appconnect: HTTPS의 TLS 핸드셰이크가 완료될 때까지 걸린 시간입니다. HTTP 프록시를 통하면 그 전에 프록시 터널을 설정하는 과정도 포함됩니다.
• time_starttransfer: 응답의 첫 바이트를 받기까지 걸린 누적 시간으로, 앞선 연결 과정과 대상 서비스의 응답 대기도 포함합니다.
• time_total: 이번 요청에 걸린 전체 시간입니다. 테스트 페이지의 응답 본문은 거의 없으므로 대용량 파일 처리량을 보여 주지는 않습니다.

이 시간 값은 모두 요청 시작부터 계산한 누적값이므로 서로 더하면 안 됩니다. 테스트 방식과 연결 재사용 방법이 다를 수 있어 클라이언트 코어의 속도 테스트 수치와 일치한다고 보장할 수도 없습니다. 이 명령은 문제를 비교하고 확인하는 데 유용합니다. 같은 노드, 대상, 매개변수로 반복 실행해 연결 단계와 첫 바이트 수신 전 단계 중 어디에서 느려지는지 살펴보세요.

자주 묻는 질문: 시간 초과·패킷 손실·자동 선택

노드를 고를 때는 지연 시간으로 먼저 추린 다음 지속 처리량, 실패 빈도, 대상 앱에서의 실제 성능을 확인하세요. 문제가 생기면 한 번에 조건 하나만 바꾸세요. 먼저 출구를 고정하고, 다음으로 테스트 대상을 고정한 뒤 네트워크나 시간대를 비교합니다. 이렇게 하면 ‘전체 속도 테스트’를 계속 누르는 것보다 결과를 재현하기 쉽고 문제를 찾는 데도 도움이 됩니다.