Clash 지연 시간 테스트 원리: url-test의 응답 시간이 실제 다운로드 속도와 다른 이유

지연 시간 수치의 의미: 소규모 요청이 완료되는 데 걸리는 시간

Clash 노드 목록에 표시되는 밀리초 수치는 대개 지정한 프록시를 통해 전송한 HTTP 또는 HTTPS 탐색 요청에서 나온 값이며, 노드 서버에 ICMP ping을 보낸 결과가 아닙니다. url-test 정책 그룹은 이러한 탐색으로 후보 노드의 연결 가능 여부와 응답 속도를 확인한 뒤, 코어의 선택 로직과 허용 오차 등을 고려해 사용할 노드를 결정합니다. 수동으로 ‘지연 시간 테스트’를 실행하는 기능과 정책 그룹의 백그라운드 검사는 관련 기능을 공유할 수 있지만, 테스트 URL과 시간 초과 설정, 검사 범위는 다를 수 있습니다.

지연 시간은 응답에 걸리는 시간이고, 다운로드 속도는 단위 시간 동안 전송된 데이터의 양입니다. 소량의 데이터만 반환하는 탐색 요청은 연결 실패나 우회 경로, 느린 응답을 파악하는 데 유용하지만 지속적인 다운로드 처리량을 예측하기에는 부족합니다. 따라서 지연 시간이 80ms인 노드의 다운로드 속도가 2MB/s이고, 180ms인 노드가 15MB/s를 기록하는 일은 기술적으로 충분히 가능합니다.

url-test 요청은 어떤 과정을 거칠까

HTTPS 테스트 URL을 예로 들면, 코어는 보통 테스트할 프록시를 통해 대상 URL에 접속하고 필요한 연결을 설정한 뒤 HTTP 응답을 기다립니다. 측정되는 것은 특정 탐색 구현에서 걸린 시간이지, 네트워크 회선 일부의 순수 전파 지연이 아닙니다.

아웃바운드 준비: 노드 설정을 읽고 필요한 경우 프록시 서버의 도메인을 조회합니다. DNS 조회 결과가 캐시에 있는지에 따라 이번 작업량이 달라질 수 있습니다.
프록시 연결 설정: 노드의 진입점에 연결한 다음 해당 프로토콜에 필요한 전송·보안·프록시 핸드셰이크를 수행합니다. 프로토콜에 따라 TCP나 UDP를 사용하거나 연결 다중화 방식이 다를 수 있습니다.
테스트 대상에 접속: 프록시 경로를 통해 테스트 사이트에 연결합니다. 대상 도메인을 어디에서 조회하는지는 사용 프로토콜과 DNS 설정에 따라 달라지므로, 항상 로컬에서 조회한다고 단정할 수 없습니다.
응답 수신 및 시간 측정: HTTPS 접속에는 대상 사이트와의 TLS 통신도 포함됩니다. 이후 코어가 구현 방식에 따라 결과를 기록해 클라이언트에 전달합니다.

위 단계는 연결 과정을 이해하기 위한 모델입니다. 매번 모든 단계를 처음부터 수행한다거나 모든 코어가 준비 시간을 전부 표시값에 포함한다는 뜻은 아닙니다. DNS 캐시, 이미 설정된 터널, 세션 재개, 연결 재사용에 따라 이후 탐색이 첫 탐색보다 빨라질 수 있습니다. 서로 다른 클라이언트의 수치를 비교하기 전에 테스트 URL과 측정 방식이 같은지 확인하세요.

시스템 ping은 낮은데 Clash 지연 시간은 높은 이유

터미널에서 노드 진입점에 ping을 실행하면 로컬 기기와 진입점 사이의 ICMP 왕복 시간만 확인할 수 있습니다. ICMP는 속도 제한을 받거나 차단될 수도 있습니다. Clash의 URL 탐색은 테스트 사이트에 접속하는 과정까지 포함하며, 노드에서 대상 사이트로 나가는 경로도 결과에 영향을 줍니다. 측정 대상이 서로 다르므로 두 값을 빼서 ‘프로토콜 추가 지연’을 계산할 수는 없습니다.

지연 시간·대역폭·혼잡: 각각 무엇을 봐야 할까

지표	주로 나타내는 내용	직접 알 수 없는 내용
URL 지연 시간(ms)	현재 경로에서 소규모 요청의 응답에 걸린 시간	지속 다운로드 대역폭, 모든 사이트의 속도
전송 처리량(MB/s)	일정 시간 동안 실제 데이터를 전송하는 능력	반응성이 좋은지, 다른 시간대에도 안정적인지
여러 차례 탐색 결과의 변동	응답 시간이 안정적인지	적은 표본만으로 패킷 손실이 발생한 위치
시간 초과 또는 실패 횟수	지정한 탐색 조건에서의 사용 가능 여부	모든 대상에 연결할 수 없는 노드

예를 들어 노드 A의 응답 시간이 5회 측정에서 70, 74, 71, 520, 76ms이고, 노드 B는 145, 149, 146, 152, 148ms라고 해 보겠습니다. 설명을 위한 예시이며 이 사이트에서 직접 측정한 값은 아닙니다. A는 대부분 더 낮은 값을 기록했지만 한 번 크게 튀었습니다. 원격 터미널에 사용할 경우 B가 더 일관된 조작 경험을 제공할 수도 있습니다. 최솟값만 보면 이런 차이를 놓치게 됩니다.

지속 다운로드 속도는 서버 측 속도 제한, 노드 대역폭 공유, 네트워크 간 혼잡, 전송 프로토콜의 혼잡 제어, 로컬 네트워크의 영향을 받습니다. 접속 대역폭이 100Mbps라면 오버헤드를 제외한 이론상 속도는 약 12.5MB/s지만, 단일 연결이 그 속도를 보장하지는 않습니다. 204 응답을 빠르게 받았더라도 대용량 파일을 전송하는 동안 몇 초 뒤 대기열이 쌓이거나 공유 출구 대역폭 경쟁이 발생해 속도가 떨어질 수 있습니다.

저녁 시간대에 ‘지연 시간은 정상인데 영상이 끊기는’ 이유

소규모 요청은 전송 데이터가 적어 회선의 처리량이 제한적이어도 탐색을 빠르게 완료할 수 있습니다. 반면 동영상은 재생 구간을 지속적으로 내려받아야 합니다. 현재 화질에 필요한 비트레이트보다 가용 대역폭이 낮으면 버퍼가 점차 줄어듭니다. 이럴 때는 지연 시간 테스트를 반복하기보다 플레이어의 버퍼 상태와 실제 구간 다운로드 속도, 연결 로그를 확인하세요.

테스트 URL에 따라 결과를 적용할 수 있는 범위가 달라집니다

흔히 사용하는 테스트 URL은 본문이 없는 성공 응답인 HTTP 204를 반환합니다. 예를 들어 https://www.gstatic.com/generate_204는 이러한 탐색에 사용할 수 있습니다. 테스트 URL은 장기간 접속 가능하고, 응답 본문이 작으며, 동작이 안정적이어야 합니다. 대용량 파일이나 로그인이 필요한 페이지, 인증 문자가 자주 표시되는 API는 피하세요.

프로토콜 차이: HTTP와 HTTPS는 연결 과정이 다르므로 두 URL의 측정 시간을 한데 놓고 비교할 수 없습니다. HTTPS 테스트는 대상과의 TLS 연결이 정상적으로 이루어지는지도 확인할 수 있습니다.
대상 위치 차이: 같은 도메인도 CDN 설정에 따라 서로 다른 지역으로 연결될 수 있습니다. 노드의 출구 위치가 바뀌면 실제 접속하는 서버도 달라질 수 있습니다.
사이트 정책 차이: 테스트 사이트가 특정 출구를 제한하거나 일시적으로 장애를 겪을 수 있습니다. 한 번 실패했다면 해당 탐색 경로가 예상대로 완료되지 않았다는 뜻일 뿐입니다.
사용 목적의 차이: 공용 테스트 사이트에 접속된다고 해서 동영상 플랫폼, 코드 저장소, 게임 서버에도 같은 경로로 접속할 수 있거나 동일한 권한이 있다는 뜻은 아닙니다.

일상적인 자동 선택에는 안정적인 기본 탐색 URL을 하나 사용하고, 실제 서비스 접속 결과는 별도로 확인하세요. 코드 저장소를 자주 이용한다면 저장소 페이지와 실제 가져오기 속도를 비교하고, 동영상을 주로 시청한다면 해당 플랫폼의 재생 통계를 확인하세요. 자동 탐색에 대용량 파일 URL을 넣고 이를 종합적인 대역폭 테스트로 오해하지 마세요.

url-test 설정: 검사 주기·허용 오차·필요할 때만 검사

아래는 관련 필드를 지원하는 mihomo 코어용 정책 그룹 예시이며, 기존 설정에 병합해야 합니다. 예시에서는 필드 구조를 보여 주기 위해 내장 멤버인 DIRECT를 사용합니다. 그대로 적용하면 직접 연결만 검사하며 프록시 노드가 자동으로 추가되지는 않습니다. 실제로 사용할 때는 현재 설정에 이미 존재하는 노드 이름으로 멤버를 바꾸거나 코어 문서에 따라 프록시 제공자를 사용하세요.

config.yaml · 정책 그룹 예시

proxy-groups:
  - name: 자동 지연 시간 선택
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300은 자동 검사 주기가 300초, 즉 5분이라는 뜻입니다. 요청 시간 초과가 아니며 300밀리초마다 검사한다는 의미도 아닙니다.
tolerance: 50은 밀리초 단위의 전환 허용 오차입니다. 작은 지연 시간 차이로 노드가 자주 바뀌는 것을 줄이기 위한 값이지, 노드 지연 시간을 50ms 미만으로 강제하는 설정은 아닙니다.
lazy: true를 설정하면 사용하지 않는 정책 그룹의 검사를 사용 상황에 따라 줄일 수 있습니다. 백그라운드에서 새 수치가 계속 표시되지 않는다고 해서 반드시 검사가 중단된 것은 아닙니다.
proxies는 이미 존재하는 노드 또는 지원되는 정책 멤버를 참조하는 목록입니다. 멤버가 하나뿐이면 비교할 다른 후보가 없습니다.

현재 멤버의 지연 시간이 약 120ms이고 다른 멤버가 약 105ms라고 가정해 보겠습니다. 50ms 허용 오차는 이처럼 작은 차이로 경로가 계속 바뀌는 일을 줄이기 위한 설정입니다. 실제 선택은 멤버의 사용 가능 여부, 검사 주기, 코어 구현에 따라서도 달라지므로 허용 오차를 정확한 전환 보장으로 이해해서는 안 됩니다. 정책 그룹의 멤버가 바뀌더라도 기존 TCP 연결이 끊김 없이 이동하는 것은 아닙니다. 일반적으로 새 연결부터 변경된 선택을 따릅니다.

시간 초과·실패·‘0ms’ 문제 해결

시간 초과는 요청이 정해진 시간 안에 예상대로 완료되지 않았다는 뜻이지, 지연 시간이 그 제한값과 같다는 의미가 아닙니다. 테스트 시간 초과가 5000ms라고 가정했을 때 시간 초과로 표시되면 이번 탐색이 5초 안에 성공적으로 응답하지 못했다는 뜻입니다. 노드 연결 실패, 대상 사이트 접속 불가, DNS 오류, 핸드셰이크 정체 등이 원인일 수 있습니다.

클라이언트의 수동 속도 측정, 코어 제어 인터페이스, 정책 그룹의 자동 검사, 프록시 제공자의 상태 확인에는 각각 별도의 시간 초과 설정이 있을 수 있습니다. 특정 API의 timeout 매개변수를 모든 YAML 계층에 그대로 붙여 넣지 마세요. 현재 코어에서 사용하는 필드를 문서로 확인하고, 로그에서 수정한 매개변수가 실제 검사에 적용됐는지 확인하세요.

먼저 오류 유형 확인: 연결 거부, 도메인 조회 실패, TLS 오류, 요청 시간 초과는 각각 다른 단계를 가리킵니다. 단순히 ‘빨간색’이라고 기록하기보다 전체 오류와 발생 시간을 남기는 편이 효과적입니다.
그다음 비교 테스트: 같은 노드에서 안정적인 다른 테스트 URL을 사용하고, 같은 URL에서 다른 노드를 사용해 보세요. 한 번에 하나의 변수만 바꾸면 문제가 노드와 대상 중 어디에 가까운지 파악할 수 있습니다.
트래픽이 올바른 멤버를 거치는지 확인: 특정 노드를 테스트했다고 해서 브라우저도 그 노드를 사용하고 있다는 뜻은 아닙니다. ‘연결’ 페이지에서 실제로 적용된 규칙과 정책 그룹, 아웃바운드 멤버를 확인하세요.
로컬 트래픽 처리 방식 확인: 브라우저는 시스템 프록시를 따를 수 있지만 터미널에는 프록시가 설정되지 않았을 수 있으며, TUN은 별도의 트래픽 처리 범위를 가집니다. 속도 측정에 성공한 것과 모든 앱의 트래픽이 프록시를 거치는 것은 별개의 문제입니다.

0ms, 빈 값 또는 비정상적으로 낮은 값이 표시되어도 곧바로 ‘가장 빠른 노드’라고 판단하지 마세요. 아직 검사되지 않았거나, 캐시된 결과, 반올림, 클라이언트의 표시 방식 때문일 수 있습니다. 로그와 재검사로 의미를 확인하세요. 결과가 이상하면 먼저 기록을 보존한 뒤 설정을 변경하세요. DNS 초기화, 노드 변경, 모드 변경을 한꺼번에 하면 원인을 찾기 어려워집니다.

재현 가능한 노드 비교 절차

노드를 비교할 때는 테스트 조건을 일치시키는 것이 중요합니다. 설정 전체를 자주 바꾸지 않고도 다음 순서로 기록을 남길 수 있습니다.

환경 고정: 클라이언트와 코어 버전, 테스트 URL, 시간 초과 설정, 네트워크 유형을 기록하세요. 대용량 파일 동기화는 중지하고, Wi-Fi와 모바일 핫스팟을 오가며 테스트하지 않는 것이 좋습니다.
첫 실행 결과 기록: 첫 테스트는 DNS 조회와 최초 핸드셰이크의 영향을 더 많이 받을 수 있으므로 별도로 기록하세요. 이후의 연결이 준비된 상태에서 나온 결과와 섞어 해석하지 마세요.
반복 측정: 노드마다 약 10초 간격으로 5~10회 테스트하고 중앙값과 최댓값, 실패 횟수를 기록하세요. 여러 노드에 같은 간격을 적용하고, 동시에 너무 많은 탐색을 실행해 로컬 네트워크에 부하를 주지 마세요.
실제 서비스 확인: 대상 사이트에 한 번 접속한 뒤 약 30초 동안 다운로드하거나 영상을 재생해 보세요. 다운로드 테스트는 데이터를 사용하므로 파일 크기와 테스트 횟수를 조절해야 합니다.
다른 시간대에 재검사: 평소 사용하는 저녁 시간대에도 다시 테스트해 일시적인 혼잡과 장기적인 성능을 구분하세요. 한산한 시간대의 최고 기록만 남기지 마세요.

기록은 다음처럼 작성할 수 있습니다. “노드 A, HTTPS 204 탐색, 중앙값 92ms, 10회 중 1회 실패, 대상 다운로드 평균 3.2MB/s.” 수치는 기록 형식을 보여 주기 위한 예시입니다. 지연 시간과 실패율, 실제 서비스 처리량을 함께 보면 초록색 밀리초 수치 하나만 볼 때보다 더 유용한 판단을 내릴 수 있습니다.

최솟값만 정렬하지 말고 사용 목적에 맞춰 선택하세요

웹 브라우징과 원격 터미널: 안정적인 응답과 적은 지연 시간 급등, 낮은 실패율을 우선으로 살펴보세요.
동영상과 대용량 파일: 접속 가능 여부를 확인한 뒤 지속적인 전송 처리량과 버퍼 상태, 혼잡 시간대의 성능을 중점적으로 보세요.
게임과 음성 통화: 실제 UDP 경로와 패킷 손실, 지터를 확인하세요. HTTP 탐색은 게임 서버나 음성 통화 경로 테스트를 대신할 수 없습니다.

url-test는 후보 멤버 중 응답이 빠르고 사용 가능한 경로를 고르는 기능이지, 대역폭 순위를 매기는 기능이 아닙니다. 안정적인 탐색 조건을 유지하고 실제 서비스와 연결 로그를 함께 확인하면 ‘밀리초 수치는 낮은데 속도는 느린’ 이유를 파악하고, 근거 없는 잦은 전환도 줄일 수 있습니다.