Clash 지연 시간 테스트 원리: 측정값이 웹·동영상 체감 속도와 다른 이유

Clash 클라이언트에서 노드를 고를 때 가장 먼저 눈에 들어오는 값은 대개 지연 시간입니다. 두 노드가 각각 68ms와 126ms로 표시되면 전자가 두 배 빠르다고 생각하기 쉽습니다. 하지만 이 값은 당시 조건에서 특정 탐색 요청을 완료하는 데 걸린 시간일 뿐입니다. 다운로드 속도와 같지 않으며 웹 페이지 로딩, 동영상 버퍼링, 게임 접속, 대용량 파일 전송의 실제 체감을 온전히 나타내지도 않습니다.

지연 시간 테스트를 이해하려면 네트워크 요청을 여러 단계로 나눠 봐야 합니다. 도메인 이름 확인, 프록시 노드 연결, 프록시 프로토콜 핸드셰이크, 노드를 통한 테스트 대상 연결, 암호화 연결 설정, 요청 전송, 응답 대기, 이후 데이터 전송 단계가 있습니다. Clash 클라이언트와 코어 버전, 테스트 메뉴에 따라 측정 범위가 다를 수 있으므로 같은 노드가 두 클라이언트에서 서로 다른 값을 보이는 것은 이상한 일이 아닙니다.

Clash 지연 시간 값이 측정하는 범위

많은 GUI 클라이언트가 이 기능을 “지연 시간 테스트” 또는 “속도 테스트”라고 표시하지만, 내부에서는 일반적인 ICMP Ping을 사용하지 않는 경우가 많습니다. Clash 또는 Mihomo는 보통 지정한 프록시 노드를 통해 테스트 URL에 접속한 뒤 요청 성공까지 걸린 시간을 기록합니다. 테스트 대상은 상태 코드 204처럼 매우 작은 HTTP 응답을 반환할 수 있습니다. 전송 데이터가 적기 때문에 결과는 주로 왕복 시간과 연결 설정 비용을 반영합니다.

테스트 URL이 HTTPS라면 한 번의 탐색 과정에 TCP 연결, 프록시 프로토콜 처리, TLS 핸드셰이크, HTTP 응답 대기가 포함될 수 있습니다. 연결 재사용 여부, DNS 캐시 유무, 테스트 대상의 응답 속도도 결과에 영향을 줍니다. 클라이언트 화면에는 대개 각 단계가 따로 표시되지 않고 합산된 밀리초 값만 나타납니다.

따라서 화면에 표시된 80ms는 “이 노드를 통해 지정된 요청을 한 번 완료하는 데 약 80밀리초가 걸렸다”는 뜻에 가깝습니다. 노드 서버와 로컬 기기 사이의 순수한 물리적 거리도 아니고, 모든 사이트에서 동일하게 나오는 고정값도 아닙니다. 테스트 주소를 바꾸면 노드 출구에서 대상 서버까지의 경로가 달라지므로 노드 순위도 바뀔 수 있습니다.

지연 시간이 낮아도 웹과 동영상이 항상 빠르지는 않은 이유

지연 시간과 대역폭은 서로 다른 지표입니다. 지연 시간은 요청이 왕복하는 데 걸리는 시간을, 대역폭은 단위 시간에 전송할 수 있는 데이터양을 나타냅니다. 어떤 노드는 소량 요청에 빠르게 응답하더라도 출구 대역폭 부족, 저녁 혼잡 시간대, 다수 사용자 공유 때문에 지속적인 다운로드 처리량이 낮을 수 있습니다. 반대로 첫 응답은 조금 느려도 가용 대역폭이 더 안정적인 노드도 있습니다.

웹 페이지 로딩은 여러 단계로 이루어짐

최신 웹 페이지는 대개 HTML, 스크립트, 스타일시트, 이미지, API 데이터, 외부 리소스를 불러옵니다. 처음 열 때는 DNS 조회, TLS 핸드셰이크, 여러 차례의 연결 설정도 거칠 수 있습니다. 낮은 지연 시간은 소량 요청 사이의 대기를 줄여 주지만, 전체 로딩 시간에는 리소스 수, 서버 처리 시간, 브라우저 캐시, HTTP 연결 재사용, 대상 사이트의 부하도 영향을 미칩니다.

특정 노드가 지연 시간 테스트 서버에 빠르게 연결된다고 해서 실제 웹 페이지의 콘텐츠 전송 서버까지 빠른 것은 아닙니다. 테스트 대상과 실제 사이트는 서로 다른 국가, 통신사 또는 자율 시스템에 있을 수 있으며 노드 출구에서 각 대상까지의 라우팅 품질도 완전히 다를 수 있습니다.

동영상 체감 품질은 지속 처리량과 안정성이 더 중요함

동영상 플레이어는 보통 콘텐츠를 구간별로 내려받고 최근 다운로드 속도에 맞춰 화질을 조절합니다. 노드가 동영상 비트레이트보다 높은 처리량을 꾸준히 제공한다면 기본 지연 시간이 조금 높아도 체감 차이는 크지 않을 수 있습니다. 반대로 지연 시간은 매우 낮지만 처리량이 자주 떨어지는 노드에서는 화질 저하, 버퍼링 증가, 재생 중단이 발생할 수 있습니다.

탐색 요청은 데이터양이 매우 적어 전송이 안정 구간에 들어가기 어렵고, 수십 초 이상 이어지는 혼잡도 확인하기 어렵습니다. 동영상 재생에서는 한 번 측정한 최저 지연 시간보다 지속 가용 대역폭, 지터, 패킷 손실이 더 유용한 지표인 경우가 많습니다.

대화형 애플리케이션은 지터와 패킷 손실도 중요함

원격 터미널, 음성 통화, 일부 실시간 애플리케이션은 지연 시간에 민감하지만 평균값만으로는 체감 품질을 설명하기 어렵습니다. 연속 측정값이 70, 72, 75ms인 노드는 45, 180, 60, 260ms 사이를 오가는 노드보다 대체로 안정적입니다. 후자는 가끔 더 낮은 값이 나오더라도 지터와 재전송 때문에 눈에 띄는 끊김이 생길 수 있습니다.

같은 노드의 지연 시간이 계속 달라지는 이유

지연 시간은 노드의 영구적인 속성이 아니라 특정 시점, 접속 구간, 출구, 대상이 함께 만든 측정 결과입니다. 짧은 시간에 연속으로 테스트했을 때 수십 밀리초 차이가 나는 것은 흔합니다. 변동 폭이 크다면 로컬 네트워크, 프록시 회선, 테스트 대상 중 어느 부분이 불안정한지 추가로 확인해야 합니다.

1. 로컬 접속망의 변동. Wi-Fi 전파 간섭, 모바일 네트워크 전환, 공유기의 대기열, 다른 기기의 업로드 사용량 때문에 탐색 요청이 더 오래 대기할 수 있습니다. 안정적인 네트워크에서 반복 측정해야 LAN 문제를 노드 문제로 잘못 판단하지 않을 수 있습니다.
2. 통신사 라우팅 변경. 로컬 네트워크에서 노드까지의 경로는 항상 같지 않습니다. 시간대에 따라 다른 중계 구간을 거칠 수 있으며, 저녁 혼잡 시간대에는 대기 지연과 패킷 손실이 발생할 수도 있습니다.
3. 프록시 서버 부하 변화. 노드는 연결, 프로토콜 핸드셰이크, 트래픽 전달을 처리해야 합니다. CPU 사용률, 연결 수, 출구 대역폭, 시스템 스케줄링이 모두 응답 시간에 영향을 줍니다.
4. 테스트 대상의 상태 차이. 테스트 서버가 속도를 제한하거나 요청을 서로 다른 주소로 배정할 수 있고, 노드 출구별로 다른 경로를 반환할 수도 있습니다. 대상 서버가 일시적으로 바쁘면 모든 노드가 동시에 느려질 수 있습니다.
5. DNS 캐시와 연결 재사용 여부. 첫 탐색에는 DNS 조회와 새 연결 설정이 포함될 수 있지만, 다음 탐색부터는 캐시나 기존 연결을 활용할 수 있습니다. 클라이언트와 코어의 테스트 방식에 따라 이전 결과와 이후 결과를 직접 비교할 수 있는지가 달라집니다.
6. 동시 테스트로 인한 추가 경합. 수십 개 노드에 동시에 요청하면 로컬 연결, 업로드 대역폭, 시스템 자원을 함께 사용하게 됩니다. 일괄 결과는 1차 선별에 적합하며, 최종 판단에는 소수 노드를 연속으로 다시 테스트하는 편이 좋습니다.

url-test 프록시 그룹이 지연 시간 결과를 사용하는 방식

Clash와 Mihomo 설정에서 url-test는 자동 선택 프록시 그룹의 한 유형입니다. 코어는 설정된 URL을 기준으로 그룹 내 프록시를 확인하고, 사용 가능하면서 지연 시간이 낮은 노드를 우선 선택합니다. 용도가 비슷한 노드 중 하나를 자동으로 고를 때 유용하지만, 자동 선택 결과도 테스트 대상의 영향을 받습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval은 정기 검사 주기를 지정합니다. 예시의 300은 300초마다 한 번 검사한다는 뜻입니다. 주기가 너무 짧으면 탐색 요청과 노드 연결 횟수가 늘어나고, 너무 길면 회선 상태 변화를 제때 감지하지 못할 수 있습니다. 가정용 네트워크와 일반적인 웹 이용에서는 몇 초마다 새로 검사할 필요가 없습니다.

tolerance는 전환 허용 범위를 설정합니다. 현재 노드와 후보 노드의 지연 시간 차이가 설정 범위를 넘지 않으면 작은 수치 변동 때문에 프록시 그룹이 자주 전환되는 것을 막을 수 있습니다. 출구가 빈번하게 바뀌면 기존 연결에 영향을 줄 수 있고 로그인 서비스에서 접속 IP 변경을 감지할 수도 있습니다. 몇 밀리초의 최저값을 계속 좇는 것보다 적절한 허용 범위를 두는 편이 대체로 안정적입니다.

lazy의 구체적인 동작은 사용하는 코어 버전을 기준으로 확인해야 합니다. 일반적으로 프록시 그룹에 실제 트래픽 요청이 없을 때 능동 검사를 줄이는 데 사용됩니다. 구독으로 받은 설정이라면 매개변수 이름만 보고 임의로 수정하지 않는 것이 좋습니다. 구독 업데이트로 로컬 변경 사항이 덮어써질 수 있으며, 클라이언트가 오버라이드 기능으로 프록시 그룹을 관리할 수도 있습니다.

테스트 URL은 안정적이고 응답 본문이 작아야 하며, 주된 이용 환경과 라우팅 측면에서도 어느 정도 관련성이 있어야 합니다. 주로 접속하는 대상과 테스트 사이트의 네트워크 위치가 크게 다르면 자동 선택된 최저 지연 시간 노드가 실제 작업에서는 가장 좋은 성능을 내지 못할 수 있습니다. 또한 HTTP와 HTTPS는 결과가 다를 수 있습니다. HTTPS 테스트에는 암호화 연결 설정 과정도 포함되기 때문입니다.

규칙 모드·TUN 모드와 지연 시간 테스트의 관계

지연 시간 테스트는 대개 Clash 코어가 지정된 프록시를 통해 직접 실행합니다. 브라우저 트래픽이 시스템 프록시 또는 TUN을 거치는 전체 과정의 성능과 같지는 않습니다. 클라이언트에서 노드를 사용할 수 있다고 표시되는 것은 코어가 테스트 대상을 성공적으로 탐색했다는 의미일 뿐입니다. 브라우저에서 웹 페이지가 열리지 않는다면 시스템 프록시, 규칙 매칭, DNS, 애플리케이션의 프록시 우회 여부도 확인해야 합니다.

규칙 모드에서는 실제 요청이 위에서 아래로 규칙과 대조되며, 처음 일치한 규칙의 정책에 따라 경로가 결정됩니다. 노드 테스트에서는 특정 프록시를 직접 지정할 수 있지만 실제 웹 요청은 다른 프록시 그룹, 직접 연결 규칙 또는 차단 규칙과 일치할 수 있습니다. 문제를 확인할 때는 프록시 그룹 화면의 지연 시간만으로 추정하지 말고 연결 기록이나 로그에서 대상 도메인에 실제로 적용된 정책을 확인해야 합니다.

TUN 모드는 시스템 프록시 설정을 따르지 않는 트래픽까지 더 폭넓게 처리하지만, 프록시 노드의 물리적인 회선 품질을 자동으로 높여 주지는 않습니다. TUN을 켜면 DNS 처리, 라우팅 테이블, 네트워크 스택, 방화벽 권한이 실제 연결에 관여합니다. 노드 지연 시간은 정상인데 애플리케이션을 사용할 수 없다면 TUN 실행 여부, DNS 응답의 유효성, 올바른 규칙 매칭 여부, 대상 애플리케이션의 특수 네트워크 프로토콜 사용 여부를 각각 확인해야 합니다.

노드 선택에 지연 시간 데이터를 올바르게 활용하는 방법

노드를 비교할 때는 지연 시간을 먼저 선별 기준으로 활용한 뒤 안정성과 실제 작업 결과를 함께 확인하는 것이 좋습니다. 72ms와 79ms 사이에서 계속 전환할 필요는 없습니다. 이 정도 차이는 한 번의 네트워크 변동만으로도 쉽게 뒤집힙니다. 노드가 계속 사용 가능한지, 연속 테스트 결과가 안정적인지, 실제 대상에 접속할 때 눈에 띄는 끊김이 없는지를 더 중요하게 봐야 합니다.

1. 먼저 일괄 테스트로 후보를 추립니다. 계속 시간 초과되거나 지연 시간이 눈에 띄게 높은 노드를 제외합니다. 시간 초과가 반드시 노드를 전혀 사용할 수 없다는 뜻은 아니지만, 현재 조건에서는 해당 테스트를 완료하지 못했다는 의미이므로 이후에 별도로 확인해야 합니다.
2. 후보 노드를 연속으로 다시 테스트합니다. 후보 노드 3~5개를 고르고 일정한 간격으로 반복 측정합니다. 가장 낮았던 한 번의 값만 기록하지 말고 전체 결과 범위를 살펴봅니다.
3. 실제 이용 대상으로 검증합니다. 자주 이용하는 사이트를 둘러보고 평소 화질의 동영상을 재생하거나, 실제 업무에서 사용하는 다운로드와 연결 작업을 수행합니다. 몇 분 동안 테스트하면 혼잡과 처리량 변동이 더 잘 드러납니다.
4. 용도별로 그룹을 나눕니다. 웹 탐색, 동영상, 저지연 상호작용은 중요하게 보는 네트워크 지표가 서로 다릅니다. 프록시 그룹과 규칙을 이용해 대상별로 다른 노드를 사용하면 되므로 하나의 노드로 모든 상황을 처리할 필요는 없습니다.
5. 안정적인 노드를 대체 경로로 남겨 둡니다. 최저 지연 시간 노드가 불안정해졌을 때는 새 노드를 급히 찾는 것보다 안정적인 후보 노드로 전환하는 편이 실용적입니다. fallback 프록시 그룹에서는 단순히 최저 지연 시간을 고르는 것이 아니라 가용성 검사와 장애 시 전환이 핵심입니다.

지연 시간 이상을 단계별로 점검하는 순서

모든 노드의 지연 시간이 갑자기 높아지거나 시간 초과된다면 각 노드 설정을 수정하기 전에 공통 경로부터 확인해야 합니다. 모든 노드는 로컬 기기, LAN, DNS 환경, 테스트 대상, 클라이언트 코어를 공유합니다. 이 중 어느 한 단계에 문제가 생겨도 전체 목록에서 동시에 결과가 사라질 수 있습니다.

1단계: 로컬 네트워크

기기에서 자주 이용하는 사이트에 직접 연결할 수 있는지 확인하고 Wi-Fi 신호, 모바일 네트워크 상태, 공유기 부하를 점검합니다. 대용량 파일 업로드, 클라우드 동기화, LAN에서 많은 대역폭을 사용하는 작업을 멈춘 뒤 다시 테스트합니다. 다른 접속망으로 바꿨을 때 정상화된다면 기존 LAN이나 통신사 경로에 문제가 있을 가능성이 큽니다.

2단계: 클라이언트와 코어

설정이 정상적으로 로드되었는지, 프록시 노드에 프로토콜 또는 매개변수 오류가 표시되는지, 제어 포트와 코어 프로세스가 정상인지 확인합니다. 구독 업데이트 후 모든 노드에 문제가 생겼다면 이전에 정상 실행되던 설정 사본으로 되돌려 구독 구조, 프록시 그룹 참조, 오버라이드 설정의 변경이 원인인지 비교해 봅니다.

3단계: 테스트 주소

노드로 실제 웹 페이지에는 접속할 수 있지만 모든 지연 시간 테스트가 시간 초과된다면 탐색 주소 자체를 의심해야 합니다. 작고 빠른 응답을 안정적으로 반환하는 테스트 URL로 바꾼 뒤 다시 비교합니다. 여러 조건을 한꺼번에 바꾸지 마십시오. 한 번에 한 가지 조건만 조정해야 테스트 대상과 노드 회선 중 어디에서 문제가 발생했는지 확인할 수 있습니다.

4단계: 노드와 회선

일부 노드에서만 지연 시간이 높다면 해당 노드들이 같은 지역에 있거나 같은 접속 지점 또는 동일한 회선을 사용하는지 확인합니다. 낮에는 안정적이지만 저녁마다 계속 상승한다면 장시간 측정 결과를 바탕으로 시간대별 혼잡 여부를 판단해야 합니다. 한 번 낮은 값으로 돌아왔다고 해서 문제가 해결된 것은 아닙니다.

밀리초 값을 올바른 판단 기준으로 활용하기

Clash 지연 시간 테스트는 가볍고 빠르며 서로 비교할 수 있는 네트워크 탐색 결과를 제공합니다. 접속할 수 없는 노드를 제외하고 지연 시간이 눈에 띄게 높은 회선을 찾아내며, url-test 자동 선택의 기준으로 활용할 수 있습니다. 하지만 웹 체감 품질에는 DNS, 규칙 매칭, 대상 사이트 라우팅, 리소스 로딩 방식도 영향을 미칩니다. 동영상과 다운로드는 지속 처리량, 혼잡도, 패킷 손실의 영향을 더 많이 받습니다.

더 안정적인 방법은 지연 시간으로 1차 선별하고, 연속 테스트로 지터를 관찰한 다음, 실제 접속으로 대역폭과 안정성을 검증하는 것입니다. 비슷한 값이 여러 개라면 무조건 가장 낮은 수치를 고집할 필요가 없습니다. 연결이 안정적이고 실제 대상에 접속할 수 있으며 정책 전환이 지나치게 잦지 않은지가 일시적으로 10여 밀리초 앞서는 것보다 대체로 더 중요합니다.