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

1. 노드 지연 시간(ms)은 다운로드 속도가 아닙니다

Clash 클라이언트에서 말하는 ‘속도 측정’은 대부분 대용량 파일을 내려받아 대역폭을 재는 것이 아니라, 코어가 URL에 요청을 보내 지연 시간을 측정하는 기능입니다. 화면에 표시된 120 ms는 한 번의 짧은 요청에 걸린 시간으로, 초당 다운로드할 수 있는 데이터양으로 환산할 수 없습니다. 주로 연결을 맺고 응답을 받기까지 기다린 시간을 나타내며, 지속적인 전송 성능은 측정하지 않습니다.

이해하기 쉽게 ‘핸드셰이크 시간’이라고 부를 수는 있지만, 기술적으로는 정확한 표현이 아닙니다. 코어 구현 방식, 프록시 프로토콜, 연결 재사용 여부, HTTP 또는 HTTPS 테스트 URL에 따라 측정 범위가 달라집니다. 이 값은 순수한 TCP 핸드셰이크 시간도, 시스템의 ping 명령으로 확인하는 ICMP 왕복 시간도 아닙니다.

예를 들어 노드 A의 지연 시간은 80 ms이고 다운로드 속도는 2 MB/s인 반면, 노드 B는 지연 시간이 160 ms지만 다운로드 속도는 15 MB/s일 수 있습니다. 이는 설명을 위한 예시이며 이 사이트에서 직접 측정한 결과가 아닙니다. A는 짧은 요청에 빠르게 응답할 수 있고, B는 대용량 파일 전송에 더 적합할 수 있습니다. 대역폭, 혼잡도, 단일 연결 제한은 짧은 요청 한 번으로 확인할 수 없으므로 두 결과는 모순되지 않습니다.

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

url-test는 정책 그룹 유형 중 하나입니다. 코어는 그룹에 포함된 후보 노드를 통해 지정된 URL에 접속하고 테스트 결과를 확인한 뒤, 연결 가능 여부와 지연 시간, 허용 오차 등을 기준으로 노드를 선택합니다. 그래픽 인터페이스의 ‘전체 속도 측정’ 기능도 코어의 지연 시간 테스트 인터페이스를 호출할 수 있지만, 정책 그룹과 같은 URL·시간 제한·실행 방식을 사용한다고 단정할 수는 없습니다.

일반적인 HTTPS 테스트 과정

1. 테스트 대상 확인: https://www.gstatic.com/generate_204와 같은 테스트 URL을 확인합니다. 이 경로는 일반적으로 다운로드할 본문 없이 HTTP 204 응답을 반환합니다.
2. 프록시 연결 구성: 기기가 후보 노드에 연결하고 해당 프록시 프로토콜에 필요한 연결 절차를 완료합니다. 노드 주소 확인, 전송 계층 연결, 프로토콜 핸드셰이크에 시간이 걸릴 수 있습니다.
3. 테스트 사이트 접속: 프록시 출구를 통해 대상 사이트에 연결합니다. HTTPS라면 대상 사이트와의 TLS 협상도 진행됩니다. 대상 도메인을 어느 쪽에서 조회하는지는 프로토콜과 실제 설정에 따라 다르므로, 항상 기기에서 조회한다고 단정할 수 없습니다.
4. 응답을 받고 기록: 코어는 구현 방식에 따라 요청에 걸린 시간을 기록하고 결과 또는 오류를 반환합니다. 클라이언트에 따라 실패 상태가 ‘시간 초과’, 빨간색 표시, 연결 불가 등으로 다르게 나타날 수 있습니다.

노드 테스트는 일반적으로 지정된 프록시 출구를 대상으로 합니다. 브라우저로 테스트 URL에 접속해 평소 사용하는 규칙 분기를 모두 거치는 것과는 다릅니다. 실제 앱 트래픽은 규칙에 따라 직접 연결되거나 다른 정책 그룹 또는 노드로 전달될 수 있습니다. 따라서 ‘테스트는 빠른데 웹 페이지는 느리다’면 테스트 URL을 바꾸기보다 먼저 연결 패널에서 웹 트래픽이 실제로 어떤 출구를 사용하는지 확인하세요.

3. 테스트 URL·시간 제한·간격 설정 방법

아래는 해당 필드를 지원하는 mihomo 코어에서 사용할 수 있는 설정 예시입니다. mihomo는 이후 Clash Meta 프로젝트에서 사용하는 이름입니다. 이전 버전의 Clash나 일부 클라이언트의 그래픽 설정에서는 모든 필드를 지원하지 않을 수 있습니다. 먼저 클라이언트에 표시된 코어 유형을 확인한 뒤 해당 코어 문서를 참고하세요. 이 설정을 완전한 구독 파일로 간주해 그대로 덮어쓰면 안 됩니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩-01
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

여기서 홍콩-01, 일본-01은 기존 proxies에 정의된 이름과 정확히 일치해야 합니다. 프록시 컬렉션을 사용하는 경우 코어에서 지원하는 방식으로 use를 참조할 수도 있습니다. 노드가 아직 정의되지 않은 파일에 이 부분만 붙여 넣어도 연결되지 않습니다.

• url: 응답이 작고 경로가 안정적이며 평소 접속 환경을 잘 반영하는 주소를 선택하세요. HTTP와 HTTPS는 핸드셰이크 과정이 다르므로 프로토콜을 바꾼 뒤 기존 수치와 그대로 비교해 순위를 매기면 안 됩니다.
• interval: 300: 자동 검사 간격은 300초, 즉 5분입니다. 연결 시간 제한이 아니며 300밀리초마다 테스트한다는 뜻도 아닙니다.
• timeout: 5000: 한 번의 테스트에 적용되는 시간 제한은 최대 5000밀리초입니다. 제한이 너무 짧으면 일시적인 혼잡을 연결 불가로 판단할 수 있고, 제한을 늘려도 작동하지 않는 노드가 복구되지는 않습니다.
• tolerance: 50: 전환 허용 오차는 50밀리초입니다. 지연 시간이 조금 변할 때 노드가 자주 바뀌는 것을 줄이기 위한 값으로, 대역폭 기준이 아니며 표시된 지연 시간에서 50을 빼지도 않습니다.
• lazy: true: 지연 검사를 활성화하면 그룹을 사용하지 않을 때 주기적인 테스트를 건너뛸 수 있습니다. 따라서 모든 노드의 결과가 시계 기준으로 정확히 5분마다 갱신된다고 볼 수는 없습니다.

더 낮은 수치만 바라며 테스트 주소를 바꾸지 마세요

테스트 사이트의 위치, CDN 연결 경로, 출구 간 연동에 따라 결과가 달라집니다. 출구와 매우 가까운 주소로 바꾸면 수치는 낮아질 수 있지만, 자주 사용하는 사이트로 가는 경로는 나아지지 않을 수 있습니다. 노드를 비교할 때는 URL, 네트워크 환경, 테스트 방식을 동일하게 유지하세요. 특정 사이트의 문제를 확인할 때는 해당 사이트에서 접근할 수 있는 작은 리소스를 추가해 참고할 수 있습니다.

수백 개 노드의 테스트 간격을 일괄적으로 10초로 줄이는 것도 권장하지 않습니다. 잦은 테스트는 연결 수와 트래픽, 기기 부하를 늘리고 원격 서비스의 요청 제한을 유발할 수 있습니다. 평소에는 300초 간격으로 살펴보고, 문제가 생겼을 때 몇 차례 수동으로 다시 테스트하는 편이 계속 빠르게 새로고침하는 것보다 원인을 파악하기 쉽습니다.

4. 지연 시간은 낮은데 웹 페이지나 동영상이 느린 이유

짧은 요청에 성공해도 혼잡 시간대의 대역폭이 충분한 것은 아닙니다

204 요청은 아주 적은 양의 데이터만 주고받습니다. 출구 대역폭이 혼잡해도 요청은 빠르게 끝날 수 있지만, 동영상 조각이나 대용량 파일은 연결을 계속 사용합니다. 서버 속도 제한, 공유 출구의 부하, 네트워크 간 연결 상태, 로컬 Wi-Fi 패킷 손실 때문에 실제 전송 속도가 낮아질 수 있습니다.

실제 사이트와 테스트 사이트는 서로 다른 경로를 거칠 수 있습니다

기기에서 프록시 노드까지는 전체 경로의 전반부에 불과합니다. 노드에서 테스트 사이트로 가는 경로와 동영상 사이트로 가는 경로는 완전히 다를 수 있습니다. 한 테스트 주소의 속도가 빠르다고 다른 CDN도 빠르다고 볼 수 없습니다. 대상 사이트의 지역별 정책과 부하, 출구 IP 제한도 접속 가능 여부에 직접 영향을 줄 수 있습니다.

브라우저가 테스트에 사용한 노드를 거치지 않을 수 있습니다

• 규칙 모드에서는 도메인이 DIRECT로 연결되거나 다른 정책 그룹에 포함될 수 있습니다. 연결 기록을 열어 대상 도메인, 적용된 규칙, 최종 프록시 경로를 확인하세요.
• 시스템 프록시는 해당 설정을 따르는 앱에만 적용되는 경우가 많습니다. 게임, 자체 네트워크 스택을 사용하는 앱, 일부 명령줄 프로그램은 시스템 프록시를 사용하지 않을 수 있습니다.
• TUN은 가상 네트워크 어댑터를 통해 해당 트래픽을 처리하지만, 실제로 처리되는 범위는 라우팅, 제외 설정, DNS 설정의 영향을 받습니다. TUN을 켠다고 노드 대역폭이 자동으로 높아지는 것은 아닙니다.
• 브라우저가 재사용 중인 장기 연결은 정책을 바꿔도 바로 다시 연결되지 않을 수 있습니다. 전환 효과를 확인하려면 대상 앱을 다시 열고, 필요한 경우 관련 연결만 종료하세요. 진행 중인 다운로드가 중단되지 않도록 주의해야 합니다.

단위를 잘못 비교하는 경우도 흔합니다. 이론적으로 8 Mbps는 약 1 MB/s에 해당하며, 실제 속도에서는 프로토콜 오버헤드를 고려해야 합니다. 통신사가 안내하는 대역폭, 속도 측정 사이트의 단위, 다운로드 프로그램의 단위가 다르면 먼저 단위를 환산한 뒤 속도에 문제가 있는지 판단하세요.

5. 지연 시간·대역폭·안정성으로 노드 선택하기

노드를 선택할 때는 먼저 연결할 수 없는 노드를 제외하고, 다음으로 안정성을 확인한 뒤 용도에 맞춰 전송 속도를 비교하세요. 목록 순위만 믿지 말고, 자동 전환을 켠 채 고정 노드의 속도를 비교하려고 하지도 마세요. 측정 도중 대상 노드가 바뀔 수 있습니다.

1. 조건 고정: 같은 기기와 네트워크에서 테스트하고 백그라운드 다운로드를 일시 중지하세요. 후보 노드를 수동 선택 그룹에서 지정해 고정한 다음, 실제 서비스 연결도 해당 노드를 사용하는지 확인합니다.
2. 여러 차례 지연 시간 확인: 약 10초 간격으로 수동 테스트를 5회 진행해 결과와 실패 횟수를 기록하세요. 이는 단기 문제를 확인하기 위한 방법이지, 자동 테스트를 장기간 10초 간격으로 설정하라는 뜻은 아닙니다.
3. 지속 전송 속도 테스트: 신뢰할 수 있는 동일한 다운로드 소스를 대상으로 30~60초간 테스트하고, 첫 1초의 최고 속도가 아니라 안정된 뒤의 속도를 기록하세요. 속도 테스트에는 데이터가 사용되므로 종량제 네트워크라면 먼저 남은 용량을 확인하세요.
4. 실제 용도 확인: 동영상은 버퍼링과 탐색 후 재생 복구를, 원격 터미널은 입력 응답을, 회의는 연결 끊김과 오디오 연속성을 확인하세요. URL 테스트는 UDP 서비스 테스트를 대신할 수 없습니다.

표는 기록 방법을 보여 주기 위한 예시이며 특정 서비스 제공업체에서 측정한 결과가 아닙니다. A의 지연 시간 중앙값은 83 ms, B는 153 ms입니다. C는 5회 중 1회 실패해 표본 실패율이 20%입니다. 표본이 적어 장기적인 장애율을 추정할 수는 없지만, C의 최저 기록이 70 ms라는 이유만으로 우선 선택하기보다 더 관찰해야 한다는 점은 알 수 있습니다.

6. 시간 초과·결과 불일치·자동 전환 문제 해결 순서

모든 노드에서 시간 초과가 발생하는 경우

먼저 기기의 기본 네트워크가 정상인지, 구독 노드가 아직 유효한지, 시스템 날짜와 시간이 정확한지 확인하세요. 그런 다음 코어 로그를 확인합니다. timeout은 제한 시간 안에 요청이 완료되지 않았다는 뜻이고, connection refused는 일반적으로 연결이 거부되었다는 뜻입니다. 인증서 관련 오류가 있으면 시간, 대상 인증서, 네트워크 간섭을 추가로 확인해야 합니다. 모든 실패를 ‘노드가 느려서’라고 단정하지 마세요.

접속할 수 있는 것으로 확인된 다른 소형 테스트 주소를 사용해 비교하세요. 기존 테스트 URL에서만 실패한다면 대상 서비스나 출구에서 해당 주소까지의 경로를 확인하고, 여러 주소에서 모두 실패한다면 노드 설정과 로컬 네트워크, 방화벽을 살펴보세요. 인증서 오류를 없애려고 인증서 검증을 바로 끄면 실제 원인을 가릴 수 있습니다.

앱의 속도 측정과 자동 선택 그룹의 결과가 다른 경우

양쪽에서 사용하는 URL, 시간 제한, 마지막 갱신 시각을 확인하세요. 앱의 수동 테스트, url-test 정책 그룹, proxy-providers 아래의 health-check는 각각 설정 위치가 다르므로 한 곳을 수정해도 다른 설정에 반영된다고 볼 수 없습니다. 구독을 업데이트하면 로컬 수정 사항이 덮어써질 수 있으니, 지속적으로 적용할 설정은 클라이언트가 지원하는 재정의 또는 병합 설정에 두세요.

가장 빠른 노드가 바로 선택되지 않는 경우

현재 사용하는 서비스가 실제로 url-test 그룹을 이용하는지 먼저 확인하세요. 수동 선택 그룹이나 fallback 그룹일 수도 있습니다. fallback은 일반적으로 후보 순서에 따라 연결 가능한 노드를 선택하며, 단순히 지연 시간이 가장 낮은 노드를 찾는 방식이 아닙니다. url-test에서도 허용 오차와 테스트 갱신 시점, 지연 검사, 기존 연결을 고려해야 합니다. 몇 밀리초 차이 때문에 노드를 자주 바꿀 필요는 없습니다.