Clash 지연 시간 측정 수치의 의미: 60ms 노드인데도 동영상이 끊기는 이유

지연 시간 수치는 정확히 무엇을 측정할까

Clash, Clash Meta（mihomo） 및 그래픽 클라이언트에서 지연 시간 측정을 실행하면, 일반적으로 코어가 지정한 프록시 노드로 테스트 URL에 접속한 뒤 요청 시작부터 유효한 응답을 받을 때까지 걸린 시간을 기록합니다. 흔히 HTTP 204를 반환하는 경량 주소를 사용하며, 예를 들면 https://www.gstatic.com/generate_204가 있습니다. 화면에 표시되는 60ms는 이 짧은 요청이 빠르게 완료됐다는 뜻이지, 노드가 초당 얼마나 많은 데이터를 전송하는지를 나타내는 수치는 아닙니다.

한 번의 측정에는 프록시 연결 수립, 대상 도메인 조회, 대상 서버와의 TCP 연결, TLS 핸드셰이크, HTTP 요청 및 응답이 포함될 수 있습니다. 어느 단계까지 측정하는지는 코어 버전, 프로토콜 구현, 연결 재사용 여부와 테스트 진입점에 따라 달라집니다. 일부 클라이언트는 mihomo 외부 컨트롤 인터페이스로 단일 노드를 검사하고, 설정의 url-test 그룹과 프록시 제공자 상태 점검은 코어가 주기적으로 실행합니다. 모두 밀리초 단위 결과를 내지만 실행 시점과 연결 상태가 완전히 같지는 않습니다.

순수한 네트워크 왕복 시간과 동일한 값은 아니다

시스템의 ping은 보통 ICMP 에코 패킷으로 네트워크 계층의 왕복 시간을 측정하지만, Clash 지연 시간 측정은 프록시 프로토콜과 HTTP 요청 경로를 사용합니다. 노드가 ICMP를 차단해도 HTTPS 프록시는 정상 작동할 수 있고, 반대로 ICMP는 빠르지만 프록시 서버의 부하가 높아 인증과 암호화 처리가 느릴 수도 있습니다. 따라서 명령줄 ping에서 35ms가 나오고 클라이언트에 68ms가 표시되어도 서로 모순되지 않습니다.

내 컴퓨터에서 노드까지: 가정용 인터넷, Wi-Fi, 통신사 출구 구간에서 첫 번째 지연이 발생합니다.
프록시 핸드셰이크: Trojan, VLESS, Shadowsocks, Hysteria2 등은 전송 방식과 핸드셰이크 과정이 서로 다릅니다.
노드에서 테스트 서버까지: 출구 회선이 두 번째 경로를 결정하며, 우회 경로는 수치를 바로 끌어올립니다.
테스트 서버 응답: 대상 서버의 위치와 부하, 속도 제한, CDN 라우팅도 결과에 반영됩니다.
순간적인 상태: 패킷 손실 재전송, CPU 스케줄링, 무선 간섭은 특정 요청 하나에만 영향을 줄 수 있습니다.

60ms 노드인데도 동영상이 끊기는 이유

동영상 재생에는 지속적인 처리량이 필요합니다. 일반적인 비트레이트를 기준으로 1080p 동영상은 안정적인 5~10Mbps, 4K 콘텐츠는 20~40Mbps가 필요할 수 있으며 순간 최고치는 더 높을 수 있습니다. 지연 시간 측정은 아주 작은 응답만 내려받아 수십 밀리초 안에 끝나므로, 수십 MB를 전송한 뒤 노드가 속도 제한이나 패킷 손실, 혼잡을 보이는지는 확인할 수 없습니다.

대역폭 부족: 첫 응답은 빠르지만 이후 데이터가 밀린다

어떤 노드는 60ms 안에 핸드셰이크를 완료해도, 공유 출구의 사용 가능한 대역폭이 저녁 시간대에 2Mbps뿐일 수 있습니다. 웹 페이지는 수백 KB만 전송하면 되므로 빠르게 반응하는 것처럼 보이지만, 동영상 버퍼가 데이터를 계속 소비하면 다운로드 속도가 재생 속도를 따라가지 못해 자주 멈춥니다. 전형적인 ‘낮은 지연 시간, 낮은 처리량’ 상황입니다.

반대로 180ms의 원거리 노드라도 안정적으로 50Mbps를 제공한다면, 재생 버튼을 누른 직후의 응답은 조금 느려도 버퍼링이 끝난 뒤 끊김 없이 재생될 수 있습니다. 지연 시간은 상호작용 대기 시간에 영향을 주고, 처리량은 대용량 파일과 동영상 데이터를 지속적으로 공급할 수 있는지를 결정합니다. 서로 다른 지표입니다.

지터와 패킷 손실: 평균값이 숨기는 순간적인 급등

연속 다섯 번의 결과가 58ms, 61ms, 63ms, 420ms, 시간 초과로 나와도 클라이언트는 마지막 값이나 필터링된 값만 표시할 수 있습니다. 사용자는 61ms를 보지만 실제 경로에는 뚜렷한 지터가 존재할 수 있습니다. TCP는 패킷 손실이 발생하면 재전송하고 혼잡 윈도우를 줄이며, UDP 기반 전송도 회선 품질이 나빠지면 복구 비용이 증가합니다. 동영상 조각을 내려받을 때는 속도가 크게 오르내리는 현상으로 나타납니다.

지터를 판단할 때 최저값만 보지 마세요. 10회 연속 측정에서 대부분이 55~70ms이고 한 번만 90ms가 나온 노드는 ‘최저 42ms, 최고 680ms, 두 번 시간 초과’인 노드보다 일반적으로 예측 가능성이 높습니다. 게임, 음성 통화, 원격 데스크톱은 순간적인 급등에 특히 민감합니다.

테스트 서버와 동영상 서버는 같은 출구 경로를 사용하지 않는다

테스트 URL은 노드와 가까운 CDN에 연결될 수 있지만, 실제 동영상 서비스는 다른 지역으로 라우팅될 수 있습니다. 노드에서 테스트 서버까지는 6홉이면 충분해도 동영상 CDN에는 대륙을 가로지르는 우회 경로가 필요할 수 있습니다. 두 대상이 모두 443 포트를 사용하더라도 자율 시스템, 피어링, 혼잡 지점은 완전히 다를 수 있습니다.

지역 차단 해제 여부에 따라 콘텐츠 노드도 달라집니다. 미국으로 표시된 출구가 Google 테스트 주소에는 빠르게 접속해도, 동영상 서비스가 이를 데이터센터 네트워크로 식별해 부하가 높은 CDN으로 보낼 수 있습니다. 반대로 지연 시간이 조금 더 긴 주거용 출구가 더 적절한 콘텐츠 엣지 노드를 할당받을 수도 있습니다. 초록색 수치만으로 정렬하면 이 차이를 놓치게 됩니다.

로컬 회선과 클라이언트 모드도 영향을 준다

혼잡한 채널의 2.4GHz Wi-Fi에서는 재전송이 쉽게 발생합니다. 노드 측정은 가끔 정상이어도 대용량 전송에서는 문제가 커질 수 있습니다.
TUN 모드가 시스템 트래픽을 가로챈 뒤 MTU 설정이 적절하지 않으면 단편화와 패킷 손실이 발생하거나 일부 사이트 로딩이 멈출 수 있습니다.
브라우저는 QUIC를 사용하지만 현재 노드나 회선의 UDP 지원이 좋지 않으면 동영상 연결이 자주 다른 방식으로 전환될 수 있습니다.
규칙이 테스트 URL은 프록시로 보내면서 동영상 도메인은 다른 정책 그룹에 배정할 수 있습니다. 이 경우 두 결과를 직접 비교할 수 없습니다.
로컬 CPU가 과부하 상태이거나 플레이어의 하드웨어 디코딩이 작동하지 않아도 ‘동영상 끊김’이 발생할 수 있습니다. 이때 프록시 다운로드 속도는 정상일 수 있습니다.

테스트 URL, 캐시와 연결 재사용이 결과를 바꾸는 방식

테스트 주소는 충분히 작고 응답이 명확하며 장기간 접근 가능해야 합니다. 204 응답 주소는 본문을 포함하지 않아 다운로드량이 결과에 미치는 영향을 줄일 수 있습니다. 다만 ‘간섭이 적다’고 해서 ‘모든 웹사이트를 대표한다’는 뜻은 아닙니다. 서로 다른 지역의 URL을 사용하면 같은 노드에서도 결과가 수십에서 수백 밀리초까지 달라질 수 있습니다.

같은 테스트 주소로 비교해야 가로 비교가 가능하다

노드 A는 Google 204에서 70ms, 노드 B는 다른 국내 CDN에서 25ms가 나왔다면 두 수치를 직접 순위 매길 수 없습니다. 대상 서버가 다르므로 경로의 종점도 다릅니다. 여러 노드를 일괄 측정할 때는 모든 후보가 같은 URL에 접속하도록 하고, 동일한 시간 제한을 적용하며, 가능한 한 같은 시간대에 실행해야 합니다.

주된 용도가 해외 개발 서비스 이용이라면 안정적인 HTTPS 204 주소 하나를 유지해 1차 선별에 사용할 수 있습니다. 특정 동영상 플랫폼이 주된 용도라면 실제 재생이나 해당 플랫폼의 정적 리소스 테스트도 추가해야 합니다. 로그인이 필요하거나 큰 페이지를 반환하거나 자주 리디렉션되는 URL은 상태 점검에 넣지 마세요. 인증, 리디렉션, 페이지 크기가 데이터를 오염시킬 수 있습니다.

캐시가 대역폭을 늘려 주는 것은 아니다

DNS 캐시는 조회 한 번을 생략할 수 있고, TLS 세션 재개는 핸드셰이크 비용을 줄이며, HTTP 연결 재사용은 새로운 연결 수립을 건너뛸 수 있습니다. 연속으로 측정하면 뒤의 결과가 첫 번째보다 낮아지는 일도 드물지 않습니다. 이는 짧은 연결을 준비하는 비용이 줄었다는 뜻이지 노드 출구의 용량이 확장됐다는 의미는 아닙니다.

클라이언트와 코어 버전에 따라 연결 풀, 상태 점검, 동시 측정 처리 방식이 달라질 수 있습니다. 한 번에 수십 개 노드를 일괄 측정하면 로컬 스레드 스케줄링, DNS 조회, 라우터 NAT 테이블도 추가적인 변동을 만듭니다. 재확인이 필요하다면 2~5초 간격으로 대상 노드를 하나씩 측정하는 편이 전체 측정을 반복해서 실행하는 것보다 참고 가치가 높습니다.

시간 초과는 ‘무한대 지연 시간’이 아니다

시간 제한을 5000ms로 설정했을 때 결과가 timeout으로 표시되면 요청이 5초 안에 완료되지 않았다는 뜻일 뿐입니다. 원인은 노드 장애, 테스트 URL 차단, DNS 실패, TLS 오류, 일시적인 패킷 손실 등일 수 있습니다. 먼저 접근 가능한 것으로 확인된 테스트 URL로 바꾼 뒤 노드 자체가 오프라인인지 판단하세요.

mihomo의 url-test와 상태 점검 결과 읽는 법

url-test 정책 그룹은 그룹 내 노드를 주기적으로 검사하고, 현재 지연 시간이 낮으면서 사용 가능한 항목을 우선 선택합니다. 자동 선택에는 적합하지만 실시간 대역폭 조정기는 아닙니다. 상태 점검에서 55ms를 반환한 노드가 이후 저녁 시간대 혼잡에 빠져도, 동영상 속도가 떨어졌다고 해서 코어가 처리량 저하를 즉시 감지하는 것은 아닙니다.

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

proxy-providers:
  airport-main:
    type: http
    path: ./providers/airport-main.yaml
    url: https://example.net/subscription.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: true
      expected-status: 204

여기서 interval: 300은 300초마다 한 번 검사한다는 뜻이고, timeout: 5000은 단일 상태 점검의 시간 제한을 5000ms로 설정합니다. tolerance: 50은 지연 시간이 비슷할 때 잦은 전환을 줄이는 옵션입니다. 현재 노드와 후보 노드의 차이가 수십 밀리초에 불과하다면 연결을 유지하는 편이 계속 전환하는 것보다 안정적입니다. lazy: true는 정책 그룹이 실제로 사용되지 않을 때 불필요한 검사를 줄입니다.

간격을 5초까지 줄이지 마세요. 제공자에 80개 노드가 있다고 가정하면 5초마다 전부 탐색하는 작업이 지속적인 소규모 요청을 만들고 서버의 요청 빈도 제한을 유발할 수도 있습니다. 데스크톱에서 평소 사용할 때는 300초부터 시작하는 것이 좋습니다. 회선 변화가 빠르다면 60~120초를 시도한 뒤 로그와 리소스 사용량을 확인하세요.

외부 컨트롤 인터페이스로 단일 노드 재확인하기

mihomo에서 흔히 사용하는 외부 컨트롤 수신 주소는 127.0.0.1:9090입니다. 접근 키를 설정했다면 특정 노드에 지연 시간 측정을 요청할 수 있습니다. 노드 이름과 테스트 URL은 먼저 URL 인코딩해야 합니다.

curl -H "Authorization: Bearer local-secret" "http://127.0.0.1:9090/proxies/HK-A-01/delay?timeout=5000&url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204"

원격 확인을 위해 9090 포트를 인터넷에 직접 노출하지 마세요. 데스크톱에서는 루프백 수신만 유지하면 됩니다. LAN에서 제어해야 한다면 접근 키를 설정하고 시스템 방화벽으로 허용된 출발지 주소를 제한하세요. 프록시 포트도 구분해야 합니다. 일반적으로 7890은 mixed-port이고 9090은 컨트롤 인터페이스이므로 역할이 다릅니다.

실제 체감에 가까운 노드 판단 방법

신뢰할 수 있는 선택 과정은 최저 수치를 찾는 것이 아니라 단계적으로 선별하는 것입니다. 먼저 지연 시간과 가용성으로 명백한 장애 노드를 제외하고, 그다음 지속 처리량과 지터, 대상 서비스를 측정한 뒤 배율과 지역을 함께 고려해 결정하세요. 모든 노드를 끝까지 포화시킬 필요 없이 실제 용도를 반영하는 지표만 확인하면 됩니다.

1단계: 연속 측정으로 우연한 최저값을 피하기

동일한 HTTPS 테스트 URL을 고정하고 시간 제한은 5000ms로 설정합니다.
후보 노드를 5~10회 연속 측정하고, 각 측정 사이에 2초 이상 간격을 둡니다.
최저값만 기록하지 말고 중앙값, 최고값, 시간 초과 횟수를 기록합니다.
연속으로 시간 초과가 발생하거나 수백 밀리초 이상 크게 흔들리거나 자주 끊기는 노드는 제외합니다.

예를 들어 노드 A의 결과가 75~88ms에 집중되고, 노드 B는 최저값이 48ms지만 나머지 결과가 60~530ms 사이라면 웹 브라우징에서는 둘 다 쓸 수 있어도 회의와 게임에는 A가 우선입니다. 중앙값이 안정적이고 극단값이 적은 노드가 우연히 기록된 최저값보다 대체로 의미가 큽니다.

2단계: 20~30초 동안 지속 다운로드하기

신뢰할 수 있는 속도 측정 사이트나 대용량 파일 소스를 선택해 현재 정책 그룹으로 20~30초 동안 다운로드합니다. 순간 최고 속도가 아니라 속도가 안정적으로 유지되는지 확인하세요. 어떤 노드가 시작할 때 18MB/s까지 올라갔다가 5초 후 700KB/s로 떨어진다면 순간 대역폭은 좋지만 지속 성능이 부족하다는 뜻입니다. 다른 노드가 6MB/s를 안정적으로 유지한다면 실제 고화질 동영상 시청은 오히려 더 편할 수 있습니다.

측정에는 구독 트래픽이 사용됩니다. 배율이 2.0인 노드로 500MB를 다운로드하면 1GB로 계산될 수 있습니다. 트래픽이 제한적이라면 측정 시간을 줄이거나 파일 크기를 낮추고, 수십 개 노드를 모두 끝까지 측정할 필요는 없습니다.

3단계: 실제 사용 서비스를 직접 측정하기

동영상: 1080p 또는 4K 콘텐츠를 5분간 재생하며 버퍼링 속도와 자동 화질 저하 여부를 확인합니다.
개발: Git 가져오기, 패키지 인덱스, 컨테이너 이미지를 테스트해 대상 저장소로 가는 경로가 정상인지 확인합니다.
게임: 웹 속도 측정으로 대신하지 말고 실제 게임 내 지연 시간, 패킷 손실, 저녁 시간대 안정성을 확인합니다.
회의: 10분간 통화를 유지하며 음성 끊김과 업로드 품질을 확인합니다. 다운로드가 빠르다고 업로드가 안정적인 것은 아닙니다.
원격 데스크톱: 창을 빠르게 끌고 텍스트를 입력해 봅니다. 순간 최고 대역폭보다 상호작용 지터가 더 중요합니다.

4단계: Clash 규칙이 같은 노드를 선택했는지 확인하기

지연 시간 측정은 노드나 정책 그룹을 대상으로 하지만, 실제 웹사이트 트래픽은 먼저 규칙 매칭을 거칩니다. 설정에서 DOMAIN-SUFFIX,example-video.com,MEDIA가 MEDIA 그룹에 매칭되는데 수동 테스트는 PROXY 그룹으로 했다면, 수치가 아무리 좋아도 동영상 성능을 설명할 수 없습니다.

rules:
  - DOMAIN-SUFFIX,example-video.com,MEDIA
  - DOMAIN-SUFFIX,example-cdn.net,MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

문제를 확인할 때는 클라이언트의 연결 화면을 열고, 재생을 시작한 뒤 도메인으로 필터링하여 매칭된 규칙, 정책 그룹, 최종 노드를 확인하세요. 일반적인 데스크톱 클라이언트라면 경로는 보통 ‘연결’ → ‘도메인 검색’ → ‘연결 세부 정보 펼치기’입니다. 설정을 수정할 때는 ‘설정’ → ‘현재 설정 편집’으로 들어갑니다. 클라이언트마다 메뉴 이름은 조금씩 다르지만 대상 도메인, 매칭 규칙, 실제 출구라는 세 항목은 동일하게 확인해야 합니다.

지연 시간이 비정상일 때 점검 순서

문제를 기기, 로컬 네트워크, 노드, 대상 서버의 네 단계로 나눠 보세요. 빨간 수치가 보인다고 바로 클라이언트를 재설치하지 마세요. 다음 순서로 점검하면 원인을 빠르게 좁힐 수 있습니다.

로컬 네트워크 확인: 유선 연결과 5GHz Wi-Fi에서 각각 측정해 무선 혼잡을 배제합니다.
테스트 URL 변경: 기존 주소가 모두 시간 초과되면 안정적인 다른 204 주소로 교차 확인합니다.
DIRECT 비교: 테스트 서버에 직접 접속해도 느리다면 로컬 통신사나 대상 서버에 문제가 있을 수 있습니다.
코어 로그 확인: timeout, DNS, TLS, connection reset 등의 오류를 검색합니다.
시스템 시간 확인: 시간 오차로 TLS 인증서 검증이 실패하면 노드를 사용할 수 없는 것처럼 보일 수 있습니다.
동시 다운로드 일시 중지: 클라우드 드라이브, 시스템 업데이트, 클라우드 동기화가 업로드나 다운로드 대역폭을 모두 차지할 수 있습니다.
TUN 매개변수 확인: TUN 모드에서만 문제가 발생할 때 시스템 프록시 모드로 테스트해 결과를 비교합니다.

모든 노드가 동시에 80ms에서 800ms로 상승했다면 먼저 로컬 네트워크와 구독 서비스 진입점을 확인하세요. 특정 지역만 비정상이라면 해당 지역의 회선이나 출구 문제일 가능성이 큽니다. 지연 시간은 정상인데 특정 웹사이트만 느리다면 규칙, DNS, 대상 CDN, 지역 차단 해제 문제를 점검해야 합니다.

결론: 지연 시간은 본래 역할에 맞게 해석하자

Clash 지연 시간 측정은 두 가지 질문에 답하는 데 가장 적합합니다. 해당 시점에 노드가 프록시를 통해 테스트 URL에 접속할 수 있는지, 그리고 짧은 요청이 대략 어느 정도 속도로 완료되는지입니다. 가용성 확인과 1차 순위 선정에는 유용하지만, 대역폭·동영상 화질·게임 패킷 손실·저녁 시간대 안정성을 단독으로 예측하는 데는 적합하지 않습니다.

60ms가 표시되면 ‘짧은 요청의 응답이 빠르다’고 이해하세요. ‘노드가 반드시 빠르다’고 해석해서는 안 됩니다. 여러 번 측정한 변동, 20~30초간의 지속 처리량, 실제 서비스 성능, 규칙의 실제 매칭 결과를 함께 확인하세요. 지연 시간, 대역폭, 지터, 패킷 손실, 지역, 배율, 프로토콜이 모두 체감 품질을 결정하므로 어떤 하나의 수치도 전체 결론을 대신할 수 없습니다.

Clash 노드 계속 점검하기

현재 플랫폼에 맞는 클라이언트를 설치한 뒤 안내에 따라 구독을 가져오고, 규칙 매칭과 DNS 설정을 확인하세요.

다운로드 페이지 사용법 보기