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

노드 지연 시간: 먼저 연결 가능 여부를 확인하고 속도를 비교하세요

지연 시간이 짧다고 다운로드가 빠른 것은 아니며, 시간 초과가 표시된다고 노드가 완전히 작동하지 않는 것도 아닙니다.Clash 클라이언트의 ‘속도 측정’은 대개 작은 HTTP 요청을 보내는 테스트이지, 지속적인 다운로드 테스트가 아닙니다. 요청을 완료할 수 없는 노드를 걸러내거나 자동 선택 프록시 그룹의 판단 근거로 쓰기에는 적합합니다. 동영상, 다운로드, 화상 회의 품질을 판단하려면 지속 전송 속도와 안정성, 실제 접속할 사이트도 확인해야 합니다.

예를 들어 한 노드는 80ms, 다른 노드는 180ms로 표시되더라도 앞의 노드가 대용량 파일 다운로드에 더 적합하다고 단정할 수는 없습니다. 응답은 빠르지만 대역폭이 제한적일 수도 있고, 연결 수립은 조금 느려도 데이터를 안정적으로 많이 전송하는 노드일 수도 있습니다. 여기의 숫자는 상황을 설명하기 위한 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다.

단위도 헷갈리기 쉽습니다. 100Mbps는 이론상 12.5MB/s에 해당하지만, 실제 다운로드 속도는 프로토콜 오버헤드와 서버 제한, 네트워크 상태에도 영향을 받습니다. 노드 목록의 100ms를 다운로드 속도 등급으로 해석하면 안 됩니다.

url-test 원리: 한 번의 프록시 HTTP 요청에 걸리는 시간을 측정

url-test는 프록시 그룹 유형입니다. 코어가 후보 프록시를 통해 지정된 테스트 URL에 접속하고 걸린 시간을 기록한 뒤, 그 결과를 바탕으로 노드를 선택합니다. 클라이언트의 수동 지연 시간 측정 버튼도 코어 제어 API를 통해 비슷한 테스트를 실행하는 경우가 많습니다. 다만 버튼과 프록시 그룹이 서로 다른 URL이나 시간 제한을 사용할 수 있어 측정값이 일치하지 않을 수 있습니다.

테스트는 어떤 단계로 진행될까요?

테스트 URL을 읽고 측정할 프록시 또는 프록시 그룹을 정합니다.
프록시 서버에 연결한 다음 해당 프록시 프로토콜에 필요한 연결 절차를 완료합니다.
프록시를 거쳐 대상 서버에 접속합니다. HTTPS라면 대상 서버와 TLS 협상도 진행합니다.
HTTP 테스트 요청을 보내고 코어가 정한 측정 시간 안에 응답을 받습니다.

코어 버전에 따라 연결 재사용 방식, 측정 시작 시점, 요청 구현이 다를 수 있습니다. 이 테스트는 ICMP ping과 완전히 같지 않으며, 엄밀한 의미의 단일 네트워크 왕복 지연 시간도 아닙니다. 해당 프록시를 통해 작은 HTTP 요청을 완료하는 데 걸린 시간으로 보는 것이 정확합니다. 연결과 핸드셰이크, 응답 대기 등의 비용이 포함됩니다.

대역폭을 측정할 수 없는 이유

흔히 쓰이는 generate_204 URL은 응답이 매우 작으며, 204는 응답 본문이 없다는 뜻입니다. 충분한 데이터를 지속해서 전송하지 않으므로 수십 초 동안 부하가 걸렸을 때의 처리량을 확인할 수 없습니다. 응답이 한 번 빨랐다는 것은 해당 테스트 경로가 그 순간 빠르게 완료됐다는 뜻일 뿐, 대용량 파일 전송에도 속도 제한이 없다는 의미는 아닙니다.

이 테스트는 일반적인 사용 규칙에 따라 사이트에 접속하는 것과도 다릅니다. 지정된 프록시를 확인하는 테스트만으로 브라우저 요청이 실제로 같은 노드를 사용했다고 볼 수는 없습니다. 실제 경로를 확인하려면 클라이언트의 연결 기록과 적용된 규칙, 최종 프록시 경로를 살펴보세요.

테스트 URL: URL에 따라 순위가 달라집니다

테스트 결과에는 ‘내 기기에서 프록시 입구까지’와 ‘프록시 출구에서 테스트 사이트까지’의 연결 상태가 모두 반영됩니다. 테스트 사이트의 위치와 CDN 사용 여부, 대상 도메인의 DNS 확인 방식에 따라 결과가 달라질 수 있습니다. 어떤 노드는 테스트 사이트에 빠르게 연결되지만 실제 업무용 서버에는 느리게 접속할 수도 있습니다.

테스트 대상	확인할 수 있는 항목	한계
`https://www.gstatic.com/generate_204`	작은 HTTPS 요청의 완료 여부	해당 사이트로 가는 경로만 나타내며 모든 사이트에 적용되는 결과는 아닙니다
`https://cp.cloudflare.com/generate_204`	다른 대상 경로의 응답 상태	엣지 노드 위치가 달라 순위도 바뀔 수 있습니다
실제로 이용하는 서비스 페이지 또는 파일	대상 서비스의 실제 사용 경험	로그인, 리디렉션, 캐시, 속도 제한의 영향을 받습니다

HTTP와 HTTPS 결과를 섞어 비교하지 마세요

HTTP 테스트에는 대개 대상 서버와의 TLS 협상이 빠져 있어 측정값이 더 낮을 수 있지만, 이는 HTTP 테스트 결과만 보여줍니다. HTTPS는 평소 암호화된 웹사이트에 접속하는 방식에 더 가깝고, 인증서나 시스템 시간 문제를 드러낼 수도 있습니다. 노드를 비교할 때는 URL과 프로토콜, 시간 제한을 동일하게 설정하세요. HTTP 결과와 HTTPS 결과를 그대로 비교해 순위를 매기면 안 됩니다.

응답이 작고 장기간 안정적이며 로그인이 필요 없는 URL을 우선 선택하세요.
모든 노드에서 시간 초과가 발생하면 두 번째 테스트 URL로 교차 확인하세요.
접속 제한이 엄격한 업무용 API를 많은 노드의 자동 테스트 대상으로 지정하지 마세요.
URL을 바꾸기 전에 기존 주소를 기록해 두세요. 주소 변경으로 네트워크가 갑자기 좋아지거나 나빠졌다고 오해하지 않도록 주의해야 합니다.

자동 선택 설정: interval과 tolerance의 역할

아래는 include-all을 지원하는 mihomo 코어용 프록시 그룹 설정 예시이며, 완성된 구독 설정이 아닙니다. 전체 설정에 등록된 프록시 노드와 프록시 제공자를 후보로 불러옵니다. 실제 프록시 설정이 먼저 있어야 합니다. 기존 Clash나 구버전 코어에서는 이 항목을 지원하지 않을 수 있으므로, 해당 코어 문서에 따라 proxies 또는 use로 기존 객체를 지정하세요.

proxy-groups:
  - name: 자동 선택
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 프록시 출구
    type: select
    proxies:
      - 자동 선택
      - DIRECT

자동 선택과 프록시 출구는 예시 설정에 정의되어 있지만 모든 트래픽을 자동으로 처리하지는 않습니다. 전체 설정의 규칙에서도 해당 프록시 그룹을 지정해야 합니다. 구독에 포함된 기존 규칙 구조를 유지하면서 먼저 대상 요청이 어느 그룹으로 전달되는지 확인한 다음 교체 여부를 결정하세요. 테스트하려고 전체 규칙을 전역 프록시로 바꾸지는 마세요.

설정 항목	예시 값	설명
`interval`	300	주기적인 테스트 간격(초). 요청 시간 제한이 아닙니다.
`tolerance`	50	전환 허용 오차(밀리초). 미세한 차이로 인한 전환을 줄입니다.
`lazy`	true	그룹을 사용하지 않을 때 주기 테스트를 건너뛸 수 있습니다. 항상 최신 결과가 있다는 뜻은 아닙니다.

허용 오차는 ‘50ms보다 낮아야 사용 가능’이라는 기준이 아니며 모든 결과에 50ms를 더하는 설정도 아닙니다. 자동 선택 시 노드를 전환할지 판단하는 데 영향을 줍니다. 예를 들어 현재 노드가 약 130ms이고 다른 노드가 약 110ms라면, 20ms 개선만으로는 전환되지 않을 수 있습니다. 실제 동작은 코어 구현 방식과 노드 상태에 따라서도 달라집니다.

시간 제한 설정: 5000ms는 대기 상한이지 속도 기준이 아닙니다

시간 초과는 정해진 시간 안에 테스트를 완료하지 못했다는 뜻입니다. 시간 제한을 5000ms로 설정하면 최대 약 5초까지 기다립니다. 10000ms로 늘리면 느린 요청 일부에서 결과를 얻을 수 있지만 노드 대역폭이 늘어나는 것은 아닙니다. 또한 어떤 프록시 그룹에든 timeout을 바로 추가하지 마세요. 해당 코어가 지원하는 필드인지, 어디에 설정해야 하는지 구성 문서에서 확인해야 합니다.

제어 API로 시간 제한 매개변수 이해하기

Clash 스타일 제어 API를 지원하는 코어는 보통 프록시 지연 시간 측정 API를 제공합니다. 아래 명령은 로컬 진단용입니다. 제어 API가 127.0.0.1:9090에서 활성화되어 있고 이 예시에서는 인증이 필요하지 않다고 가정합니다. 테스트 대상은 내장 DIRECT이며, 특정 구독 노드가 아니라 직접 연결의 기준값을 확인하는 용도입니다.

curl --get "http://127.0.0.1:9090/proxies/DIRECT/delay" \
  --data-urlencode "url=https://www.gstatic.com/generate_204" \
  --data-urlencode "timeout=5000"

성공하면 {"delay":186}과 같은 결과가 반환될 수 있습니다. 이번 측정값이 186ms라는 의미이며, 형식만 보여주는 예시입니다. 특정 노드를 테스트하려면 경로의 DIRECT를 실제 프록시 이름으로 바꾸고, 이름을 URL 경로에 맞게 인코딩해야 합니다. 한글이나 공백, 슬래시를 그대로 이어 붙이면 안 됩니다.

API에서 secret을 활성화했다면 요청에 해당 Bearer 인증 헤더를 포함해야 합니다. 권한이 없어 발생한 401 오류는 노드 시간 초과가 아닙니다. 편의상 제어 API를 공용 인터넷에 노출하지 마세요. 포트 9090도 필수값이 아니므로 클라이언트의 현재 실행 설정을 확인해야 합니다.

모든 노드가 시간 초과될 때 확인할 순서

코어가 실행 중이고 구독에 포함된 노드가 불러와졌는지 확인하세요. 예전 목록만 보고 있는 것은 아닌지 살펴보세요.
두 번째 테스트 URL로 바꿔 보세요. 한 주소에서만 실패한다면 먼저 대상 서버에 접속할 수 있는지 확인하세요.
로그에서 DNS, 연결 거부, TLS, 시간 초과 정보를 확인해 어느 단계에서 실패했는지 구분하세요.
시스템 날짜와 시간이 올바른지 확인해 HTTPS 인증서의 시간 오류를 배제하세요.
같은 시간 제한으로 서로 다른 노드 두 개를 테스트하고, 필요하면 직접 연결 기준값과 비교하세요.

실제 속도 측정: 노드와 대상은 고정하고 여러 번 확인

두 노드를 비교하려면 자동 선택을 수동으로 고정된 후보 노드에 연결하거나 기존 수동 선택 그룹을 사용하세요. 테스트 중 출구를 자주 바꾸면 결과의 원인을 파악하기 어렵습니다. 브라우저의 연결 재사용과 서버 캐시, 백그라운드 다운로드도 비교 결과에 영향을 줄 수 있습니다.

재현 가능한 테스트 방법

조건 고정: 같은 기기와 같은 Wi-Fi 또는 유선 네트워크를 사용하고, 데이터 사용량이 큰 다른 작업은 일시 중지하세요.
라우팅 확인: 연결 기록에서 대상 도메인과 적용된 규칙, 최종 노드를 확인하세요. 다운로드가 실제로는 DIRECT를 사용하지 않는지 살펴보세요.
소규모 요청 반복: 노드마다 5회씩 측정하고 최저값만이 아니라 모든 결과를 기록하세요.
지속 전송 확인: 접근 권한이 있는 동일한 대용량 파일을 사용해 30~60초 동안 관찰하세요. 시작 직후의 순간 속도와 안정적으로 유지되는 속도를 구분해야 합니다.
시간을 바꿔 재측정: 예를 들어 10:00와 21:00에 각각 한 번씩 측정하고, 저녁에 처리량이 떨어지거나 시간 초과가 늘어나는지 기록하세요.

지연 시간 측정값이 82, 85, 87, 91, 680ms라고 가정하면 중앙값은 87ms이지만, 마지막 값이 크게 튄 점도 주의해서 살펴봐야 합니다. 이 숫자는 계산 예시이며 실제 측정 결과가 아닙니다. 소수의 HTTP 테스트에서 발생한 실패 비율을 곧바로 ‘네트워크 패킷 손실률’이라고 부를 수도 없습니다. DNS, TLS, 대상 서버 또는 연결 시간 초과가 원인일 수 있습니다.

지연 시간은 짧은데 다운로드가 느리다면 먼저 확인할 항목

프록시 출구 혼잡: 작은 요청은 빠르게 완료되더라도 이용자가 몰리는 시간대에는 대용량 트래픽이 대역폭을 나눠 씁니다.
대상 서버의 속도 제한: 파일 호스팅 사이트나 CDN에 따라 같은 출구 연결에도 서로 다른 제한을 둘 수 있습니다.
로컬 무선 네트워크: 불안정한 신호와 재전송은 지속 전송 속도를 떨어뜨립니다. 유선 연결을 사용해 결과를 비교해 보세요.
프로토콜과 기기 부하: 암호화 처리와 CPU 사용량, 클라이언트 리소스 제한이 처리량에 영향을 줄 수 있습니다.
서로 다른 연결 경로: 속도 측정 버튼과 실제 요청이 서로 다른 노드를 사용하거나, 앱이 시스템 프록시를 따르지 않을 수 있습니다.

마지막 경우는 특히 흔합니다. 브라우저에서 프록시를 정상적으로 사용할 수 있어도 모든 앱이 같은 경로를 이용하는 것은 아닙니다. 시스템 프록시를 따르지 않는 프로그램은 앱 자체 프록시 설정이나 TUN 연결이 필요할 수 있습니다. TUN은 트래픽이 코어에 전달되는 방식을 바꿀 뿐, 출구 대역폭을 늘려주지는 않습니다. 기본 설정은 시스템 프록시 설정 단계를, 개념 차이는 개념 빠른 안내를 참고하세요.

노드 선택 기준: 밀리초 순위만 보지 말고 사용 목적에 맞추세요

웹 브라우징에는 안정적인 응답과 대상 사이트 접속 가능 여부가 중요합니다. 대용량 파일 다운로드는 지속 처리량을, 동영상은 버퍼링 속도와 재생 중단 여부를 확인하세요. 음성 회의나 실시간 서비스는 지터와 연결 끊김, 해당 서비스의 UDP 경로도 살펴봐야 합니다. HTTP 지연 시간 테스트로 UDP 전달이 가능한지 확인할 수는 없으며, 앱 자체의 네트워크 진단을 대신하지도 않습니다.

일반적인 웹 브라우징: 안정적인 노드 하나를 유지하거나 적절한 허용 오차를 설정한 자동 선택 그룹을 사용하세요.
대용량 파일 작업: 실제 다운로드 속도를 비교하고, 다운로드가 시작된 뒤에는 출구 노드를 가능한 한 그대로 유지하세요.
특정 사이트에서 문제가 발생할 때: 먼저 적용된 규칙을 확인한 뒤 해당 사이트에 실제로 접속해 비교하세요.
저녁 시간대에 느려질 때: 같은 조건으로 다시 측정하세요. 오전에 저장한 지연 시간만 보고 판단하지 마세요.

실용적인 기록 항목은 몇 가지면 충분합니다. 테스트 시간과 URL, 시간 제한, 최종 노드, 반복 측정한 지연 시간, 지속 다운로드 속도입니다. 이 정보가 있어야 테스트 대상 문제인지, 노드 경로 문제인지, 로컬 설정 문제인지 구분할 수 있습니다. 클라이언트를 바꾸려면 먼저 클라이언트 비교를 확인하고 플랫폼에 맞춰 선택하세요. 더 낮은 지연 시간만을 위해 클라이언트를 반복해서 다시 설치할 필요는 없습니다.