Clash 노드 지연 시간 확인법: 측정값과 실제 속도가 다른 이유

먼저 지연 시간, 처리량, 안정성을 구분하세요

먼저 지연 시간으로 사용하기 어려운 노드를 걸러낸 뒤, 실제 사용 환경에서 속도를 판단하세요. Clash 목록의 80 ms는 보통 한 번의 탐지에 걸린 시간을 뜻하며, 다운로드 대역폭을 나타내거나 동영상이 끊김 없이 재생된다는 보장은 아닙니다. 노드 A가 80 ms, 노드 B가 160 ms라고 해서 A의 다운로드 속도가 B의 두 배라고 볼 수는 없습니다.

‘빠르다’는 기준을 세 가지로 나누면 원인을 더 쉽게 찾을 수 있습니다. 웹페이지는 연결 수립과 첫 바이트 수신 속도를, 파일 다운로드는 지속 처리량을 확인하세요. 영상 통화와 게임에서는 패킷 손실과 지터, 실제로 사용하는 UDP 경로도 중요합니다. 한 번의 HTTP 탐지로 확인할 수 있는 것은 이 중 일부뿐입니다.

항목	의미	판단에 적합한 항목
지연 시간(ms)	지정한 탐지를 완료하는 데 걸리는 시간	연결 가능 여부 및 짧은 요청의 응답 속도
처리량(MB/s)	단위 시간 동안 실제로 전송되는 데이터 양	다운로드, 업데이트, 동영상 버퍼링
지터(ms)	여러 차례 측정한 지연 시간의 변동 폭	실시간 통화 및 상호작용의 안정성
실패율	정해진 횟수의 탐지 중 실패한 비율	연결이 간헐적으로 끊기는지 여부

예를 들어 10 MiB/s로 계속 다운로드하면 약 83.9 Mbit/s에 해당합니다. 여기서 MiB는 1024²바이트로 계산합니다. 통신사는 보통 회선 대역폭을 Mbit/s로 표시하고, 다운로드 프로그램은 MB/s 또는 MiB/s를 사용할 수 있습니다. 약 8배 차이 나는 단위를 회선 문제로 오해하지 않도록 먼저 단위를 확인한 뒤 수치를 비교하세요.

Clash 지연 시간 테스트의 요청 경로 이해하기

먼저 클라이언트가 어떤 테스트를 실행하는지 확인하세요. 많은 Clash 클라이언트는 코어의 URL 지연 시간 테스트를 사용합니다. 지정한 노드를 통해 테스트 주소에 접속하고 요청 완료까지 걸린 시간을 기록하는 방식입니다. 노드 서버에 ICMP ping만 보내는 것도, 대용량 파일을 계속 다운로드하는 것도 아닙니다.

URL 테스트는 어떤 과정을 거치나요?

코어가 노드 연결을 준비하고, 필요한 경우 노드 서버 도메인을 조회합니다.
프록시 서버에 연결한 뒤 해당 프록시 프로토콜의 핸드셰이크를 완료합니다.
프록시를 통해 테스트 사이트에 접속합니다. HTTPS를 사용하면 TLS 핸드셰이크도 진행됩니다.
테스트 응답을 받은 뒤 코어 또는 클라이언트가 결과를 표시합니다.

측정 시간의 시작과 종료 지점, 연결 재사용 방식, 결과 표시는 코어와 클라이언트 버전에 따라 다릅니다. 모든 클라이언트에 표시되는 밀리초 수치를 전체 웹페이지 로딩 시간으로 해석하지 마세요. 테스트 중 캐시나 기존 연결을 사용했는지, 테스트 대상에 추가 도메인 조회가 필요한지도 결과에 영향을 줍니다.

클라이언트에서 연결 로그를 먼저 열고 대상 웹페이지를 새로고침하세요. 대상 도메인, 일치한 규칙, 정책 경로를 확인해 실제 출구를 파악한 다음 지연 시간을 비교하세요. TUN을 켜면 트래픽을 가로채는 방식만 바뀝니다. 노드 대역폭이 늘어나거나 HTTP 테스트가 UDP 성능 테스트로 바뀌지는 않습니다.

테스트 주소와 시간 제한 조건 통일하기

노드를 비교하기 전에 테스트 URL, 네트워크 환경, 측정 시간을 통일하세요. 흔히 쓰이는 테스트 주소 https://www.gstatic.com/generate_204는 크기가 매우 작은 HTTP 204 응답을 반환하므로 짧은 요청의 연결 상태를 확인하기에 적합합니다. 응답 본문이 작기 때문에 대용량 파일 전송 능력을 확인할 수는 없습니다.

테스트 주소가 ‘인터넷 전체의 속도 기준’인 것은 아닙니다. 대상 서비스의 서버 위치와 CDN 라우팅, 출구 네트워크 간 연결, 접속 제한에 따라 결과가 달라집니다. 어떤 회선에서는 이 주소에 90 ms 만에 접속해도 실제 서비스 사이트에는 300 ms가 걸릴 수 있습니다. 두 결과는 서로 모순되지 않습니다.

같은 조건으로 한 차례 비교하기

같은 Wi-Fi 또는 유선 네트워크를 사용하고 시스템 업데이트와 클라우드 동기화를 일시 중지합니다.
비교할 노드 두 개를 선택하고 같은 HTTPS 테스트 주소를 사용합니다.
노드마다 약 5초 간격으로 10회씩 측정하고 성공 횟수와 지연 시간 중앙값을 기록합니다.
수동 테스트 시간 제한을 5000 ms로 통일합니다. 클라이언트에서 변경할 수 없다면 실제 기본값을 기록하세요.
그다음 실제 웹사이트에서도 확인합니다. 테스트 주소를 바꾼 결과를 기존 기록에 섞지 마세요.

시간 제한은 대기할 수 있는 최대 시간이지 목표 속도가 아닙니다. timeout이 표시되면 해당 요청이 제한 시간 안에 완료되지 않았거나 연결, 이름 조회, TLS 등의 과정에서 오류가 발생했다는 뜻입니다. 3000 ms를 10000 ms로 바꾼 뒤 수치가 표시되어도 더 오래 기다리면 성공할 수 있다는 뜻일 뿐, 회선이 빨라졌다는 의미는 아닙니다.

‘모든 노드에서 시간 초과가 발생하지만 웹페이지는 열린다’면 로그에 표시된 구체적인 오류부터 확인한 뒤 테스트 주소와 클라이언트가 예상한 코어를 실제로 사용하는지 살펴보세요. ‘테스트는 정상인데 특정 웹사이트가 열리지 않는다’면 테스트 시간 제한을 늘리기보다 해당 사이트의 규칙, DNS, 출구 제한, 로그인 상태를 확인해야 합니다.

지연 시간은 낮은데 다운로드가 느린 원인 찾기

대역폭 제한과 공유 회선 혼잡 확인하기

작은 응답은 전송 데이터가 적기 때문에 노드가 5 Mbit/s로 제한되어 있어도 지연 시간은 양호하게 나올 수 있습니다. 하지만 5 Mbit/s의 이론상 최대 속도는 약 0.625 MB/s이며 프로토콜 오버헤드를 제외하면 실제 속도는 더 낮습니다. 이런 상황에서 지연 시간이 10여 ms 낮은 노드를 계속 찾아도 대용량 파일 다운로드 문제는 해결되지 않는 경우가 많습니다.

저녁 시간대에도 비슷한 현상이 나타납니다. 공유 출구가 작은 요청에는 빠르게 응답하면서도 충분한 대역폭을 계속 제공하지 못할 수 있습니다. 09:00와 21:00에 같은 파일을 다운로드해 보세요. 저녁에만 지속 속도가 크게 낮아지고 일반 연결 테스트는 정상이라면 프록시 경로나 출구 혼잡을 먼저 의심할 수 있습니다.

패킷 손실과 재전송 확인하기

소량의 패킷 손실은 특정 지연 시간 측정에 나타나지 않을 수 있지만, 장시간 연결에서는 재전송이 반복되고 전송 윈도우가 줄어들 수 있습니다. 짧은 요청 10회가 모두 성공해도 장시간 전송이 안정적이라는 증거는 아닙니다. 다운로드 속도 그래프가 반복해서 0에 가까워지는지, 연결이 다시 설정되는지, 시스템 네트워크 도구에서 TCP 재전송이 증가하는지도 함께 살펴보세요.

중간 라우터가 ICMP 응답을 제한하면 경로 탐지에서 패킷 손실이 있는 것처럼 보일 수 있습니다. 특정 홉의 ping 손실만으로 장애를 단정하지 말고 최종 대상의 응답, 실제 서비스 연결 실패, 지속 전송 상태를 함께 확인하세요. 특히 HTTP 탐지 실패율을 실제 회선의 패킷 손실률로 간주해서는 안 됩니다.

대상 사이트, 기기, 로컬 네트워크 확인하기

다운로드가 허용된 다른 대용량 파일 출처를 이용해 특정 사이트의 속도 제한과 CDN 캐시 차이를 배제합니다.
유선 네트워크로 다시 측정하거나 공유기 가까이에서 측정해 Wi-Fi 간섭을 배제합니다.
작업 관리자 또는 활성 상태 보기를 확인해 CPU 사용률이 계속 최대치에 가까운지 살펴봅니다.
다른 기기의 업로드를 일시 중지합니다. 업로드 대역폭이 가득 차면 확인 응답 패킷과 상호작용 요청도 대기할 수 있습니다.

동영상 재생이 늦게 시작되는 원인에는 재생 목록 요청, 세그먼트 서버, 계정 지역, 디코딩 과정도 포함될 수 있습니다. 클라이언트에 표시되는 지연 시간 하나로 전체 재생 경로를 확인할 수 없으며, 이런 단계가 모두 정상이라고 판단할 수도 없습니다.

정해진 절차로 실제 속도 기록하기

먼저 노드 하나를 수동으로 고정한 뒤 실제 서비스를 이용하세요. 측정 중 자동 선택 그룹이 출구를 바꾸거나 모든 노드의 속도를 동시에 측정하지 않도록 합니다. 노드나 규칙을 바꿨다면 기존 페이지를 닫고 새 연결을 만드세요. 이미 설정된 연결은 새 출구로 바로 전환되지 않을 수 있습니다.

curl로 요청 단계별 소요 시간 확인하기

아래 명령은 로컬의 HTTP 또는 mixed 프록시 포트인 127.0.0.1:7890을 통해 예시 사이트에 접속합니다. 먼저 클라이언트에서 실제 포트를 확인하세요. 포트가 7890이 아니라면 로컬 설정에 맞게 수정합니다. Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 같은 이름의 명령이 다르게 동작하는 문제를 피할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output response.html --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

time_connect는 여기서 주로 로컬 프록시에 연결하는 데 걸린 시간을 나타내며, 원격 노드의 지연 시간으로 볼 수 없습니다. time_appconnect와 time_starttransfer는 요청 시작부터 각 단계까지 누적된 시간입니다. 서로 독립된 시간처럼 더하면 안 됩니다. 이 명령은 같은 URL의 요청 단계를 비교할 때 적합하며 대역폭 측정용은 아닙니다.

시작 순간의 최고 속도보다 지속 다운로드 측정하기

접근 권한이 있고 파일 크기가 충분한 파일을 선택해 약 30초간 다운로드가 이어지도록 합니다.
단일 연결 또는 다중 연결 방식을 정하고, 두 노드를 비교할 때 같은 방식을 사용합니다.
처음 몇 초 동안의 속도 변화를 제외하고 안정 구간의 속도와 멈춤 횟수를 기록합니다.
노드마다 세 차례 반복하고 측정 사이에 간격을 둬 일시적인 캐시 효과를 장기 성능으로 오해하지 않도록 합니다.

아래는 판단 방법을 설명하기 위한 예시 기록입니다. 이 사이트에서 직접 측정한 결과가 아니며 특정 노드의 품질을 나타내지도 않습니다. 두 노드 모두 탐지를 10회 완료했으며 다운로드 방식과 파일은 동일하게 유지했습니다.

비교 노드	지연 시간 중앙값	탐지 성공 횟수	안정 구간 다운로드 속도
노드 A	82 ms	10 / 10	1.2 MiB/s
노드 B	156 ms	10 / 10	8.5 MiB/s

이 조건에서는 대용량 파일 다운로드에 노드 B를 우선 고려할 수 있습니다. 짧은 요청을 주로 사용한다면 실제 사이트의 첫 바이트 수신 시간과 실패 여부도 비교해야 합니다. 모든 서비스의 사용 경험을 한꺼번에 결정할 수 있는 지연 시간 기준은 없습니다.

url-test 자동 선택의 한계 이해하기

mihomo의 url-test 정책 그룹을 사용해도 자동 선택 기준은 지정한 URL의 탐지 결과이며, 대역폭 순위가 아닙니다. 아래 설정 일부는 기존 설정에 병합해야 합니다. 노드 A와 노드 B는 설정에 이미 등록된 실제 노드 이름과 일치해야 합니다.

proxy-groups:
  - name: 자동 지연 테스트
    type: url-test
    proxies:
      - 노드 A
      - 노드 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300은 300초 간격으로 확인한다는 뜻이며 테스트 시간 제한이 아닙니다.
tolerance: 50은 전환 허용 범위를 설정해 수십 ms 차이로 노드가 자주 바뀌는 것을 줄입니다. 다운로드 속도를 제한하는 설정은 아닙니다.
lazy: true를 설정하면 사용하지 않는 그룹은 주기적인 확인을 건너뛸 수 있습니다. 유휴 상태에서도 항상 최신 결과가 유지되는 것은 아닙니다.

이 설정은 해당 필드를 지원하는 mihomo 환경에서 사용할 수 있습니다. 클라이언트가 설정 덮어쓰기, 구독 설정 병합, 인터페이스 옵션을 통해 최종 설정을 바꿀 수 있으므로 실제로 불러온 설정과 로그를 확인하세요. 수정 전에 정상 작동하는 사본을 보관해 다음 구독 업데이트에서 로컬 변경 사항이 덮어쓰이지 않도록 합니다.

다운로드 작업에 안정적인 출구가 필요하다면 수동 선택 그룹에서 노드를 고정할 수 있습니다. 전환 빈도를 낮추면 동작을 예측하기 쉬워지지만 모든 장시간 연결이 끊기지 않는다고 보장할 수는 없습니다. 노드 상태, 클라이언트의 연결 처리 방식, 대상 사이트 상태도 중요합니다.

증상별로 마지막 점검하기

지연 시간은 낮은데 웹페이지가 계속 버벅임

먼저 브라우저 연결의 정책 경로를 확인한 다음 개발자 도구의 네트워크 패널을 살펴보세요. DNS 조회, 연결, 응답 대기, 콘텐츠 다운로드 단계를 구분합니다. 특정 리소스 도메인만 유난히 느리다면 다른 규칙에 따라 다른 출구로 연결되는지 확인하세요. 메인 페이지 도메인의 측정 결과로 모든 하위 리소스를 판단하지 마세요.

지연 시간은 높은데 다운로드는 빠름

먼저 테스트 대상까지 우회 경로를 거치는지 확인한 다음 지속 처리량을 살펴보세요. 장거리 경로는 왕복 시간이 길 수 있지만 사용 가능한 대역폭이 충분하고 패킷 손실이 적다면 다운로드는 여전히 빠를 수 있습니다. 대용량 파일 작업에서는 지연 시간 수치가 높다는 이유만으로 이런 노드를 제외할 필요가 없습니다.

지연 시간이 들쭉날쭉하고 간헐적으로 시간 초과 발생

같은 시간대에 유선 네트워크와 Wi-Fi를 비교한 뒤 업로드 작업을 중지하고 탐지를 10회 반복하세요. 로컬 네트워크는 안정적인데 모든 후보 노드에서 동시에 변동이 생기면 인터넷 회선을 확인합니다. 한 노드에서만 변동이 생기면 해당 프록시 경로를 점검하세요. 테스트 서비스 자체의 문제를 모든 노드의 장애로 오해하지 않도록 실제 사이트에서도 확인합니다.

실제 출구, 짧은 요청의 안정성, 지속 전송 속도 세 가지만 확인하면 됩니다.이 세 가지를 먼저 측정한 뒤 노드를 바꾸거나 규칙을 조정할지, 로컬 네트워크를 점검할지 결정하세요. 지연 시간은 원인 범위를 좁히는 데 활용하고 최종 선택은 실제 서비스 성능을 기준으로 하세요.