Clash 노드 지연 시간 측정 원리:url-test 수치와 실제 다운로드 속도가 다른 이유

지연 시간은 요청에 걸린 시간이며, 다운로드 속도가 아닙니다

Clash for Windows의 Proxies 페이지에서 테스트 버튼을 누르면 노드 옆에 보통 밀리초 단위의 수치가 표시됩니다. 이 수치로 알 수 있는 것은 “이 프록시를 통해 테스트 주소에 접속하는 데 얼마나 걸리는가”이지, “파일을 초당 얼마나 다운로드할 수 있는가”가 아닙니다. 패널에 표시된 80 ms와 다운로드 프로그램의 8 MB/s는 서로 다른 지표입니다.

Clash에서 흔히 사용하는 지연 시간 측정은 프록시를 통한 HTTP 요청 테스트이며, 명령줄의 ICMP ping과는 다릅니다. 지정한 프록시를 거쳐 테스트 URL에 요청을 보내고 걸린 시간을 기록합니다. 코어 버전, 프로토콜, 연결 재사용 방식, 테스트 구현에 따라 측정에 포함되는 단계가 다를 수 있으므로 모든 클라이언트의 수치를 같은 기준으로 보면 안 됩니다.

예를 들어 첫 번째 소규모 요청은 빠르지만 대용량 파일을 전송할 때 속도 제한이 걸리는 회선이 있습니다. 반면 대륙 간 왕복 시간은 길어도 지속 대역폭이 충분한 회선도 있습니다. 전자는 지연 시간이 더 짧게 표시될 수 있지만, 실제 다운로드는 후자가 더 빠를 수 있습니다. 모순되는 결과가 아닙니다.

url-test 요청은 어떤 단계를 거칠까요?

내 기기의 코어에서 테스트 사이트까지

일반적인 경로는 “내 기기의 Clash 코어 → 프록시 서버 또는 프록시 체인 → 테스트 사이트 → 내 기기”입니다. 테스트 과정에서 프록시 연결을 새로 설정하거나 기존 연결을 이용해 지정된 URL에 접속합니다. HTTPS 주소라면 대상 사이트와의 TLS 과정도 포함됩니다. 도메인 이름을 어디서 조회하는지는 프록시 프로토콜, DNS 설정, 실제 연결 경로에 따라 달라집니다.

1. 테스트할 프록시 선택: 코어는 지정된 노드를 대상으로 테스트합니다. 정책 그룹을 테스트한다면 해당 그룹이 실제 출구 노드를 선택하는 방식도 확인해야 합니다.
2. 연결을 설정하고 요청 전송: 내 기기의 네트워크 상태, 프록시 핸드셰이크, 출구에서 대상 사이트까지의 경로가 모두 소요 시간에 영향을 줄 수 있습니다.
3. 요청 결과 확인: 요청이 성공하면 지연 시간이 반환됩니다. 실패하거나 상태 코드가 조건에 맞지 않거나 제한 시간 내에 완료되지 않으면 화면에 시간 초과 또는 오류가 표시될 수 있습니다.

테스트 주소에는 HTTP 204를 반환하는 경량 엔드포인트가 자주 사용됩니다. 204 응답에는 본문이 없어 대용량 데이터 전송이 측정에 끼치는 영향을 줄일 수 있습니다. 하지만 본문을 거의 전송하지 않는다는 점 때문에 지속 대역폭을 측정하기는 어렵습니다. 이 테스트를 “다운로드 속도까지 확인했다”고 해석하면 안 됩니다.

테스트 버튼과 자동 선택 그룹은 별개의 기능입니다

패널에서 속도 측정을 실행하면 일반적으로 클라이언트가 코어의 지연 시간 API를 호출합니다. 반면 설정의 type: url-test는 테스트 결과를 바탕으로 프록시를 자동 선택하는 정책 그룹을 정의합니다. 두 기능은 테스트 URL, 시간 제한, 실행 시점이 다를 수 있습니다. 그룹 설정의 url을 바꿔도 패널의 테스트 버튼이 같은 주소를 사용한다고 보장할 수 없습니다.

url-test 설정: 주소, 간격, 전환 허용 범위

아래는 설정 항목을 설명하기 위한 정책 그룹 예시이며, mihomo 기준입니다. 완성된 구독 설정이 아닙니다. proxies에 지정하는 노드 이름은 현재 설정에 이미 있어야 합니다. 이전 버전의 Clash 코어와 각 파생 버전은 지원하는 항목이 다를 수 있으므로 복사하기 전에 해당 코어의 설정 문서를 확인하세요.

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

• url: 테스트 대상입니다. 예시에서는 가벼운 HTTPS 엔드포인트를 사용합니다. 대상 사이트의 가용성과 연결 경로에 따라 결과가 달라지며, 모든 네트워크에서 사용할 수 있는 것은 아닙니다.
• interval: 300: 주기 테스트 간격은 300초입니다. 각 요청에 허용되는 대기 시간이 300초라는 뜻도, 노드가 멈추면 즉시 전환된다는 뜻도 아닙니다.
• tolerance: 50: 전환 허용 범위는 50밀리초입니다. 작은 지연 시간 차이로 잦은 전환이 발생하는 것을 줄이기 위한 값이며, 대역폭 기준이 아닙니다.
• lazy: true: 그룹의 사용 여부 등 조건에 따라 주기 검사를 실행할지 결정합니다. 구체적인 동작은 코어 구현에 따라 다릅니다. 따라서 그룹을 사용하지 않는 동안에는 패널에 표시된 이전 측정값이 갱신되지 않을 수 있습니다.

자동 선택 그룹은 주로 지연 시간과 사용 가능 여부를 기준으로 판단합니다. 다운로드 속도가 더 빠르다는 이유만으로 특정 회선의 순위를 높이지는 않습니다. 선택 결과가 기존 연결을 모두 새 노드로 옮긴다는 뜻도 아닙니다. 장시간 연결은 기존 경로를 계속 사용할 수 있으므로, 전환 효과를 확인하려면 웹페이지를 새로고침하거나 새 연결을 만들어 보세요.

시간 제한과 테스트 간격은 구분해서 확인하세요

호환되는 코어 제어 API를 예로 들면, 단일 노드의 지연 시간 측정 요청은 다음과 같이 보낼 수 있습니다. 여기서 timeout=5000은 최대 대기 시간이 5000밀리초라는 뜻이며 정책 그룹의 주기 설정과는 별개입니다. 포트 9090은 제어 포트 예시이지 프록시 포트가 아닙니다.

GET /proxies/홍콩입구/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

실제로 호출할 때는 노드 이름을 URL 인코딩하고, 로컬 설정에 맞게 제어 인터페이스 인증 정보도 포함해야 합니다. 문제를 확인할 때는 보통 클라이언트 화면만으로 충분합니다. 속도 측정을 위해 제어 포트를 로컬 네트워크에 공개하지 마세요. 설정 항목은 설정 참고에서 확인하고, 제어 포트와 HTTP 프록시 포트, SOCKS 포트를 혼동하지 않도록 주의하세요.

지연 시간이 짧아도 버벅이는 5가지 이유

1. 테스트 사이트는 가깝지만 실제 서비스까지의 경로는 다릅니다

같은 출구에서 가벼운 테스트 엔드포인트에 접속하면 가까운 CDN 서버로 연결될 수 있습니다. 하지만 동영상 서비스, 코드 저장소, 파일 사이트에 접속할 때는 다른 지역의 서버가 배정될 수 있습니다. 작은 요청이 원활하다고 해서 실제 서비스에서도 같은 경로를 이용하는 것은 아닙니다. 지역 간 접속에서는 응답 경로 차이, 인터넷 연동 구간의 혼잡, 서버 측 제한이 발생할 수도 있습니다.

2. 작은 요청은 빠르지만 지속 대역폭이 부족합니다

연결 핸드셰이크에는 소량의 데이터만 필요하므로, 회선에 속도 제한이 있어도 빠르게 완료될 수 있습니다. 다운로드를 시작해야 대역폭 제한, 공유 출구의 혼잡, 서버 부하가 두드러집니다. 처리량을 비교하려면 같은 출처의 파일을 비슷한 시간대에 같은 방식으로 다운로드하세요. 서로 다른 파일 사이트의 속도를 그대로 비교해 노드의 우열을 판단하면 안 됩니다.

3. 한 번의 지연 시간은 짧아도 변동이 큽니다

한 번 측정한 65 ms만으로 회선의 안정성을 알 수는 없습니다. 연속 요청 결과가 70, 75, 820 ms로 크게 달라지고 실패까지 섞이면 웹페이지가 간헐적으로 멈출 수 있습니다. TCP 재전송은 대기 시간을 늘리고, 지속적인 데이터 전송은 패킷 손실과 지터에도 민감합니다. 최저 수치를 계속 찾기보다 여러 번 측정한 결과를 함께 살펴보세요.

4. 실제 앱이 측정한 노드를 사용하지 않습니다

Clash for Windows에서 먼저 General → System Proxy가 켜져 있는지 확인한 다음, Proxies → Rule에서 규칙 모드와 대상 정책 그룹을 확인하세요. Windows 시스템 프록시를 따르는 프로그램은 보통 이 경로를 이용하지만, 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 무시할 수 있습니다.

Connections를 열고 대상 도메인으로 연결을 찾아 적용된 규칙과 프록시 체인을 확인하세요. 수동으로 측정한 노드는 “일본 입구”인데 실제 연결에는 DIRECT가 적용됐다면 두 결과가 다를 수밖에 없습니다. 자동 선택 그룹, 수동 선택 그룹, 규칙 분류가 여러 단계로 중첩될 수도 있으므로 카드에 표시된 이름 하나만 보고 판단하지 마세요.

5. UDP, DNS 또는 앱의 동작 방식이 테스트와 다릅니다

HTTPS 테스트 한 번으로 UDP 중계까지 사용할 수 있다고 단정할 수는 없습니다. 게임, 음성 통화, QUIC을 사용하는 앱은 다른 프로토콜 경로를 거칠 수 있습니다. 브라우저 캐시, 연결 재사용, DNS 캐시, 웹사이트 자체의 응답 속도도 체감에 영향을 줍니다. TUN은 시스템 프록시를 따르지 않는 연결을 더 많이 가로챌 수 있지만 출구 대역폭을 늘려 주지는 않으며, 모든 트래픽이 프록시를 거친다고 보장하지도 않습니다. 실제 경로는 라우팅, 규칙, 제외 설정에 따라 달라집니다.

노드에 timeout이 표시될 때: 범위를 좁혀 확인하기

timeout은 이번 테스트가 지정된 조건과 시간 내에 성공하지 못했다는 뜻일 뿐, “노드가 영구적으로 작동하지 않는다”는 의미는 아닙니다. 먼저 문제가 노드 하나에만 있는지, 테스트 주소 하나에만 있는지, 전체 네트워크에 영향을 주는지 확인하세요.

1. 모든 노드에서 동시에 실패: 먼저 로컬 네트워크가 정상이고 코어가 실행 중인지 확인하세요. 알려진 정상 경로로 테스트 URL에 접속할 수 있는지 확인한 뒤, 로그에 DNS 오류나 연결 오류가 있는지 살펴보세요.
2. 노드 하나에서만 실패: 구독이 최신 상태인지, 노드 인증 정보가 만료되지 않았는지, 해당 프로토콜을 현재 코어가 지원하는지 확인하세요. 구독을 업데이트한 다음 실제 노드를 다시 선택해 보세요.
3. 테스트 주소를 바꾸면 성공: 기존 테스트 대상, 인증서, DNS 조회 또는 연결 경로에 문제가 있을 가능성이 큽니다. 공정하게 비교하려면 모든 노드에 같은 새 주소를 사용하세요.
4. 대기 시간이 너무 짧음: 설정을 바꿀 수 있다면 3000밀리초를 5000밀리초로 늘려 다시 테스트해 보세요. 대기 시간을 늘리면 응답이 느린지 확인하는 데 도움이 될 뿐, 혼잡을 해결하거나 회선을 빠르게 만들지는 않습니다.
5. 속도 측정은 성공했지만 웹페이지는 실패: 같은 테스트 버튼을 반복해서 누르지 말고 대상 사이트, 적용된 규칙, 앱의 연결 경로를 확인하세요.

실제 사용에 가까운 노드 비교 방법

비교할 후보 노드는 2~3개면 충분합니다. Windows 업데이트와 대용량 파일 동기화를 잠시 중지하고, 가능한 한 같은 네트워크 환경을 유지하세요. Wi-Fi를 사용한다면 테스트 중에 위치를 바꾸지 마세요. 비교 전후의 결과가 유효한지 확인할 수 있도록 클라이언트, 코어, 테스트 URL, 측정 시간대를 기록해 두세요.

1. 프록시 경로 고정: 수동 선택 그룹에서 노드를 하나 지정하고 대상 앱의 연결이 실제로 그 노드를 통과하는지 확인하세요. 자동 전환으로 인한 변수를 줄일 수 있습니다.
2. 가벼운 테스트 반복: 같은 주소를 몇 초 간격으로 5~10회 측정하고 중앙값, 최고값, 실패 횟수를 기록하세요. 최저값만 보지 마세요.
3. 실제 웹사이트 열기: 매일 사용하는 서비스 2~3곳에 접속해 처음 열 때와 새로고침할 때 모두 안정적인지 확인하세요. 브라우저 개발자 도구의 “네트워크” 패널로 요청 시간을 살펴볼 수 있지만, 캐시와 서버 처리 시간도 측정값에 포함됩니다.
4. 지속 전송은 따로 테스트: 다운로드가 허용된 고정 파일 출처를 골라 30~60초 동안 전송 상태를 확인하세요. 데이터 사용량에 주의하고 동시 연결 수를 동일하게 유지하세요. 기록 단위가 MB/s인지 Mbps인지도 명시해야 합니다.
5. 실제 사용할 시간대에 다시 측정: 평일 낮과 저녁의 혼잡도는 다를 수 있습니다. 한 번의 순위보다 두 시간대의 측정 기록을 비교하는 편이 더 정확합니다.

아래는 비교 방법을 설명하기 위한 가상 측정 결과이며, 이 사이트에서 직접 측정한 값이 아닙니다. 두 회선 모두 가벼운 요청 10회를 성공적으로 마쳤다고 가정해도, 적합한 회선은 작업에 따라 달라질 수 있습니다.

채팅, 원격 작업, 웹페이지 이용은 응답 속도와 안정성이 중요합니다. 다운로드에는 지속 처리량이 더 중요하며, 동영상 재생은 비트레이트, 적응형 버퍼링, CDN 배정에도 영향을 받습니다. 단위도 확인하세요. 이론상 8 Mbps는 약 1 MB/s이며, 실제 전송 속도는 프로토콜 오버헤드만큼 더 낮습니다.

구버전 Clash for Windows의 사용 범위

Clash for Windows는 더 이상 유지 관리되지 않습니다. 기존 환경을 계속 사용한다면 General, Proxies, Connections, Logs에서 실행 상태, 적용된 규칙, 오류 정보를 확인할 수 있습니다. 다만 구버전 코어가 새 구독에 포함된 모든 프로토콜이나 mihomo 설정 항목을 지원한다고 가정하지 마세요. 화면에서 구독을 가져올 수 있어도 모든 노드가 정상 작동한다는 뜻은 아닙니다.

새로 설치하는 경우 클라이언트 비교에서 Clash Verge Rev, FlClash 등 현재 유지 관리 중인 프로젝트의 상태, 지원 플랫폼, 코어 호환성을 먼저 확인하세요. 클라이언트를 바꾼 뒤에는 시스템 프록시, 수신 포트, 테스트 주소를 다시 확인해야 합니다. 이전 클라이언트에 남아 있는 측정값과 바로 비교하지 마세요.

최종 확인 순서: 먼저 연결이 올바른 노드를 통과하는지 확인하고, 측정 기준을 비교한 다음, 여러 요청의 안정성을 살펴보세요. 마지막으로 실제 작업을 통해 대역폭과 사용 경험을 검증하세요. url-test는 사용할 출구를 고르는 기능입니다. 측정 결과 하나를 제공할 뿐, 회선 전체를 종합 평가하지는 않습니다.