Clash 지연 시간 테스트 수치 해석: 80ms 노드가 오히려 더 느린 이유

Clash 지연 시간 테스트는 실제로 무엇을 측정할까

Clash 화면에 표시되는 80ms, 150ms, 500ms 등의 수치는 일반적인 ICMP Ping이 아닌 경우가 많습니다. Clash Premium, Clash for Windows 0.20.39, mihomo 코어를 사용하는 Clash Verge Rev 2.3.x를 예로 들면, 클라이언트는 보통 코어를 통해 지정한 프록시 노드로 테스트 URL에 접속한 뒤 요청 완료까지 걸린 시간을 기록합니다. 자주 사용하는 주소로는 https://www.gstatic.com/generate_204와 https://cp.cloudflare.com/generate_204가 있습니다. 서버가 본문 없이 HTTP 204를 반환하므로 연결 상태 확인에 적합합니다.

이 요청은 로컬 Clash 코어, 노드 진입점, 프록시 전송 경로, 노드 출구, 테스트 사이트를 차례로 거칩니다. 측정값에는 TCP 연결 설정, TLS 핸드셰이크, 프록시 프로토콜 핸드셰이크, HTTP 응답 대기 시간이 포함될 수 있으며, 정확한 범위는 코어 버전, 연결 재사용 여부, 테스트 URL, 클라이언트 구현에 따라 달라집니다. 따라서 이 수치는 ‘아주 작은 웹 요청 하나를 처리하는 데 걸린 시간’에 가깝고, 내 컴퓨터와 노드 서버 사이의 물리적 왕복 지연 시간과 동일하게 볼 수 없습니다.

테스트 방식	주요 측정 대상	확인할 수 있는 내용
Clash URL Test	프록시를 통해 지정한 HTTP 또는 HTTPS 주소에 접속하는 데 걸린 시간	현재 해당 노드가 작은 요청을 얼마나 빠르게 처리할 수 있는지
`ping`	ICMP 왕복 시간과 패킷 손실	대상이 ICMP에 응답하는지, 기본 경로가 얼마나 안정적인지
다운로드 테스트	지속 전송 중 처리량	대용량 파일, 동영상, 업데이트 작업을 어느 속도로 처리할 수 있는지
실제 웹페이지 로딩	DNS, 연결 설정, 리소스 수, 대상 사이트 처리 시간	웹 탐색 환경이 안정적인지

테스트 URL에 따라 결과가 달라진다

테스트 대상은 절대적인 기준이 아닙니다. 노드 출구가 도쿄에 있다고 가정하면, 아시아에 있고 상호 연결이 좋은 테스트 사이트에 접속할 때는 75ms가 나올 수 있습니다. 경로가 더 멀거나 연결 정책이 다른 사이트로 주소를 바꾸면 같은 노드가 160ms로 측정될 수도 있습니다. 테스트 사이트가 특정 출구 IP의 속도를 제한하거나 연결을 거부하거나 TLS 오류를 일으키면 Clash에 시간 초과가 표시될 수 있지만, 그렇다고 모든 웹사이트를 사용할 수 없다는 뜻은 아닙니다.

왜 80ms 노드가 150ms보다 오히려 더 느릴까

80ms라는 수치는 특정 시점에 작은 요청 하나가 빠르게 처리됐다는 의미일 뿐입니다. 웹 탐색, 동영상 재생, 코드 다운로드, 클라우드 드라이브 다운로드는 여러 연결을 만들고 데이터를 계속 전송하며, 실제 체감 속도는 패킷 손실, 지터, 대역폭, 혼잡, 출구 품질의 영향도 받습니다. 지연 시간이 낮더라도 몇 초마다 재전송이 발생하는 노드는 지연 시간이 조금 높아도 안정적인 노드보다 사용감이 나쁠 수 있습니다.

패킷 손실은 재전송과 혼잡 제어를 유발한다

TCP는 데이터가 순서대로 도착하도록 보장해야 합니다. 특정 데이터 세그먼트가 손실되면 뒤의 데이터가 이미 도착했더라도 재전송을 기다려야 할 수 있습니다. 한 번의 URL Test는 소량의 데이터만 전송하므로 패킷 손실을 만나지 않으면 80ms로 표시됩니다. 하지만 수십 개 리소스가 포함된 웹페이지를 열면 연결 수와 데이터 양이 늘어나 패킷 손실이 드러날 가능성도 커집니다.

한 번의 결과만 보지 말고 요청을 100회 연속으로 관찰해 보세요. 예를 들어 노드 A의 중앙값은 82ms지만 95백분위수가 780ms이고 요청의 3%가 실패할 수 있습니다. 노드 B는 중앙값이 148ms, 95백분위수가 190ms이며 실패율은 0%일 수 있습니다. 웹페이지와 회의 연결에서는 노드 B가 대체로 더 안정적입니다. 한 번 측정한 최저값만으로 전체 사용 시간 동안의 품질을 판단할 수는 없습니다.

지연 시간이 낮아도 가용 대역폭이 높은 것은 아니다

URL Test의 응답 본문은 보통 비어 있어 지속적인 처리량을 거의 측정하지 않습니다. 속도가 5Mbps로 제한된 노드도 70ms 안에 204 응답을 반환할 수 있지만, 500MB 파일을 다운로드할 때는 이론상 데이터 전송만 약 800초가 걸립니다. 반면 160ms이더라도 80Mbps를 안정적으로 제공하는 노드는 같은 데이터를 훨씬 빠르게 전송합니다. 동영상이 고화질 구간으로 전환된 뒤 대역폭이 부족하면 화질이 자주 낮아지거나 버퍼링이 발생합니다.

저녁 시간대 혼잡과 큐 지연

가정용 회선의 업로드, 통신사의 국제 회선, 노드 진입점에서는 모두 대기열이 발생할 수 있습니다. 유휴 상태에서는 80ms였지만 다운로드를 시작하자 지연 시간이 600ms로 올라간다면 전형적인 부하 지연 증가입니다. 이때 속도 측정 프로그램에는 높은 처리량이 표시되더라도 페이지 클릭 반응은 느려질 수 있습니다. 노드를 판단할 때는 유휴 상태와 전송 중의 지연 시간을 각각 관찰해야 하며, 새벽에 측정한 수치 하나만 기록해서는 안 됩니다.

유휴 지연 시간: 눈에 띄는 업로드나 다운로드 작업이 없을 때 측정하며, 기본 경로의 상태를 보여줍니다.
부하 지연 시간: 다운로드나 업로드를 지속하는 동안 측정하며, 큐 관리와 혼잡 상태를 보여줍니다.
지터: 여러 측정값 사이의 변동입니다. 예를 들어 80, 83, 79ms는 안정적이지만 80, 420, 95ms는 불안정합니다.
실패율: 시간 초과 횟수를 전체 테스트 횟수로 나눈 값이며, 지속적인 사용에서는 한 번의 최저값보다 중요합니다.

URL Test, 상태 확인, 자동 선택의 차이

수동으로 ‘지연 시간 테스트’를 실행하면 보통 화면에 표시되는 현재 결과만 갱신됩니다. 설정 파일의 url-test 프록시 그룹은 구성원 노드를 주기적으로 테스트하고 결과에 따라 자동으로 선택합니다. 프록시 제공자의 health-check는 노드 사용 가능 여부를 확인합니다. 세 기능은 비슷한 요청 방식을 사용할 수 있지만 실행 시점과 목적은 서로 다릅니다.

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

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

이 예시에서 interval: 300은 자동 선택 그룹이 설정된 주기마다 테스트한다는 뜻이며, tolerance: 80은 지연 시간이 비슷한 노드 사이의 잦은 전환을 줄이는 데 사용됩니다. 현재 노드가 허용 범위 안에 있다면 코어는 몇 ms 차이만으로 연결을 즉시 옮길 필요가 없습니다. lazy: true는 프록시 그룹을 실제로 사용하지 않을 때 불필요한 능동 테스트를 줄일 수 있다는 의미입니다. 지원되는 필드는 Clash 파생 버전에 따라 다르므로 사용 전 현재 mihomo 또는 클라이언트 코어 문서를 확인해야 합니다.

자동 선택이 이미 연결된 모든 연결을 옮기는 것은 아니다

프록시 그룹이 노드 A에서 노드 B로 전환되면 일반적으로 새 연결부터 새 선택을 사용합니다. 이미 만들어진 TCP 연결이나 장시간 연결은 즉시 전환되지 않을 수 있습니다. 재생 중인 동영상, SSH 세션, 다운로드 작업은 앱이 다시 연결할 때까지 기존 연결을 계속 사용할 수 있습니다. 테스트 수치는 낮아졌는데 현재 페이지가 여전히 느리다면 시크릿 창을 새로 열거나 해당 연결을 완전히 종료한 뒤 다시 테스트해 보세요.

네 가지 지표로 노드 품질 판단하기

신뢰할 수 있는 판단에는 최소한 지연 시간 분포, 패킷 손실과 실패율, 지속 처리량, 출구와 대상 사이트의 위치라는 네 가지 정보가 필요합니다. 테스트할 때는 로컬 네트워크를 고정하고 시스템 업데이트와 클라우드 드라이브 동기화를 일시 중지하며 Wi-Fi와 유선 네트워크를 동시에 바꾸지 않아야 합니다. 후보 노드마다 5~10분씩 관찰하는 편이 버튼을 열 번 연속 눌러 가장 낮은 수치를 고르는 것보다 효과적입니다.

첫째: 중앙값과 높은 지연 구간을 기록하세요

평균값은 소수의 극단적인 결과에 따라 크게 올라가거나 내려갈 수 있습니다. 20~100회 측정값을 기록하고 중앙값, 최댓값, 95백분위수를 중점적으로 확인하세요. 통계 도구가 없다면 결과가 일정한 범위에 집중되는지라도 살펴봐야 합니다. 다음 두 데이터 그룹은 평균값이 비슷하지만 안정성은 완전히 다릅니다.

노드	대표 결과	판단
노드 A	78、81、79、84、690 ms	기본 지연 시간은 낮지만 뚜렷한 급등이 있음
노드 B	142、149、151、146、155 ms	지연 시간은 높지만 변동 폭이 작음

둘째: 프록시 요청 실패율을 확인하세요

시스템의 ping 명령은 노드 진입점의 방화벽에 의해 차단될 수 있고, 서버 진입점까지만 측정할 수도 있습니다. 실제 프록시 트래픽은 출구까지 이동해야 하므로 ICMP 패킷 손실은 참고 자료로만 활용해야 합니다. Clash 사용 환경에 더 가까운 방법은 로컬 프록시 포트를 통해 같은 테스트 주소에 반복 요청하는 것입니다.

curl -x http://127.0.0.1:7890 \
  -o /dev/null -s \
  -w "connect=%{time_connect} total=%{time_total} code=%{http_code}\n" \
  https://www.gstatic.com/generate_204

이 예시에서는 Clash의 HTTP 또는 Mixed 포트가 7890이라고 가정합니다. 클라이언트가 7897 또는 다른 포트로 설정되어 있다면 ‘설정’ → ‘매개변수 설정’에 표시된 실제 포트를 사용하세요. 연속 실행할 때는 total의 변동, HTTP 상태 코드, 시간 초과 발생 여부를 확인해야 합니다. 같은 노드에 50회 요청해 2회 시간 초과가 발생했다면 실패율은 4%입니다. 이런 노드는 지속적이고 안정적인 연결이 필요한 기본 노드로 적합하지 않습니다.

셋째: 시간대별로 지속 처리량을 테스트하세요

출처를 신뢰할 수 있고 용량이 충분한 고정 파일을 선택해 30~60초 동안 계속 다운로드하고, 시작 직후의 순간 최고값이 아니라 안정 구간의 속도를 기록하세요. 평일 오전과 20:00~23:00 저녁 시간대에 각각 테스트하는 것이 좋습니다. 낮에는 70Mbps였던 노드가 저녁에 8Mbps로 떨어지고 다른 노드는 계속 35Mbps를 유지한다면, 후자가 장기 기본 노드로 더 적합합니다.

속도 테스트는 실제 구독 트래픽을 사용하고 노드 부하도 높이므로 수 GB 파일을 자주 다운로드할 필요는 없습니다. 웹페이지와 1080p 동영상을 확인할 때는 보통 100~300MB 샘플만으로도 뚜렷한 속도 제한을 발견할 수 있습니다. 4K 고비트레이트 영상, 시스템 이미지, 대형 저장소 다운로드는 더 긴 안정 전송을 관찰해야 합니다.

넷째: 진입점, 출구, 대상 위치를 확인하세요

노드 이름에 있는 ‘홍콩’이나 ‘일본’이 진입 서버, 실제 출구, 전체 경로를 모두 의미하는 것은 아닙니다. 중계 노드는 먼저 중국 본토의 진입점에 연결한 뒤 전용 회선을 통해 해외 출구로 이동할 수 있고, 공용 인터넷 직결 노드는 로컬 기기에서 해외 서버로 직접 연결할 수도 있습니다. 두 노드의 URL Test 수치가 비슷해도 저녁 시간대 안정성과 대역폭 상한은 다를 수 있습니다.

대상 웹사이트의 위치도 선택에 영향을 줍니다. 도쿄 서버에 접속할 때는 일본 출구가 보통 더 짧은 경로를 제공합니다. 유럽에 직접 구축된 서버에 접속한다면 유럽 출구가 출구에서 대상 사이트까지의 추가 대륙 간 전송을 줄일 수 있습니다. ‘현지에서 가장 가까운 곳’만 기준으로 정렬하고 출구에서 대상 사이트까지의 후반 경로를 무시하면, 테스트 지연 시간은 낮지만 실제 업무 속도는 느린 결과를 고르기 쉽습니다.

TUN 모드에서 수치는 정상인데 앱이 여전히 느릴 때의 점검 순서

Clash 지연 시간 테스트는 코어가 직접 실행하므로 코어가 노드를 통해 테스트 주소에 접속할 수 있다는 사실만 보여줍니다. 앱 트래픽이 실제로 같은 프록시 그룹을 통과하는지는 시스템 프록시, TUN 인계, DNS, 규칙 적용, 앱 자체의 프록시 동작에 따라 달라집니다. 테스트 결과가 80ms인데 브라우저가 여전히 직접 연결되거나 다른 프록시 그룹을 사용하더라도 두 현상은 모순되지 않습니다.

현재 모드를 확인하세요. 클라이언트가 규칙 모드, 전역 모드, 직결 모드 중 어디에 있는지 확인합니다. 규칙 모드에서는 연결 목록을 열어 대상 도메인이 예상한 규칙과 프록시 그룹에 적용됐는지 살펴보세요.
시스템 프록시를 확인하세요. Clash Verge Rev 2.3.x와 같은 화면에서는 ‘설정’ → ‘시스템 설정’ 또는 홈 화면의 ‘시스템 프록시’ 스위치를 확인합니다. 코어만 켜고 시스템 프록시를 활성화하지 않으면 시스템 프록시 설정을 따르는 앱도 자동으로 Clash를 통과하지 않습니다.
TUN 상태를 확인하세요. 시스템 프록시를 따르지 않는 앱을 연결해야 할 때 TUN을 활성화합니다. 시작 직후 상태가 멈춘다면 노드 지연 시간을 반복 테스트하기보다 서비스 설치, 관리자 권한, 가상 네트워크 어댑터 충돌을 확인해야 합니다.
DNS를 확인하세요. 도메인 해석 실패, Fake-IP 매핑 오류, 로컬 네트워크 DNS 가로채기는 웹페이지가 오랫동안 대기하는 원인이 될 수 있습니다. 알려진 IP에 직접 접속하는 것만으로는 DNS 문제를 완전히 배제할 수 없습니다. HTTPS는 여전히 올바른 도메인과 인증서에 의존하기 때문입니다.
연결 세부 정보를 확인하세요. 연결 목록에는 대상 호스트, 규칙, 프록시 체인, 업로드 및 다운로드 바이트 수가 표시되어야 합니다. 테스트한 노드와 실제 연결에 사용된 노드가 다르다면 먼저 규칙이나 프록시 그룹 선택을 바로잡으세요.
연결을 다시 만드세요. 브라우저 탭을 닫고 다운로드를 일시 중지한 다음 다시 엽니다. HTTP/2, HTTP/3, WebSocket 장시간 연결은 전환 전 경로를 계속 사용할 수 있습니다.

사용 목적별로 우선 확인할 지표

사용 목적	우선 지표	보조 지표
일반 웹 탐색과 검색	중앙 지연 시간, 실패율, DNS 안정성	최대 대역폭
동영상 및 대용량 파일 다운로드	지속 처리량, 저녁 시간대 안정성	수십 ms의 지연 시간 차이
음성 통화, 원격 데스크톱	지터, 패킷 손실, 높은 지연 구간	대용량 파일 다운로드 속도
Git, 패키지, 미러 다운로드	대상 사이트 경로, 동시 연결 안정성	한 번의 URL Test 최저값
장기 자동 선택	실패율, 허용 오차, 전환 빈도	인접 노드의 미세한 순위 변화

일상적인 웹 탐색에서는 80ms와 110ms의 차이보다 실패율 0%와 3%의 차이가 보통 더 중요합니다. 고화질 동영상에서는 150ms이지만 60Mbps를 안정적으로 제공하는 노드가 70ms이지만 6Mbps만 유지하는 노드보다 대체로 낫습니다. 원격 데스크톱에서는 평균 90ms라도 500ms로 자주 튀는 노드가 안정적인 140ms 노드보다 조작하기 어렵습니다.

더 합리적인 노드 선택 방법은 먼저 시간 초과와 높은 실패율을 보이는 노드를 제외한 뒤, 사용 목적에 따라 안정성과 처리량을 비교하고 마지막으로 지연 시간으로 세부 순위를 정하는 것입니다. url-test는 품질이 비슷한 노드 그룹에서 자동으로 선택할 때 적합하며, 전체 경로 품질 평가를 대신할 수는 없습니다. 80ms가 표시되면 노드 성능의 총점이 아니라 한 번의 테스트 샘플로 이해해야 합니다.