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

1. URL Test는 요청에 걸린 시간을 측정하며 다운로드 대역폭을 측정하지 않습니다

Clash Nyanpasu 같은 클라이언트에서 노드 옆에 표시되는 밀리초 값은 보통 코어의 URL Test 결과입니다. 지정한 테스트 URL에 프록시로 접속해 탐색이 완료될 때까지 걸린 시간을 기록합니다. 일반 ICMP Ping으로 노드 서버를 검사하는 것도, 대용량 파일을 내려받아 전송량을 계산하는 것도 아닙니다. 노드가 빠른지 판단하기 전에 화면에 표시된 값이 어떤 테스트 결과인지 확인하세요.

일반적인 경량 HTTPS 탐색 요청에는 프록시 연결 설정, 프록시 프로토콜 핸드셰이크, 대상 사이트 연결, TLS 핸드셰이크, HTTP 응답이 포함될 수 있습니다. 도메인 조회가 어느 쪽에서 이뤄지는지, 연결을 재사용할 수 있는지, 코어 버전과 지연 시간 집계 설정이 무엇인지에 따라 최종 값이 달라집니다. 따라서 화면의 180ms를 단순히 내 기기와 노드 서버 사이의 왕복 지연 시간으로 볼 수는 없습니다.

먼저 단위를 확인하세요: ms는 시간을, MB/s와 Mbps는 전송 속도를 나타냅니다. 짧은 요청은 데이터가 조금만 오가므로, 이 결과만으로 회선이 지속적으로 처리할 수 있는 트래픽을 추정할 수 없습니다.

세 가지 속도 테스트가 답하는 서로 다른 질문

서버가 ICMP를 차단해도 프록시 서비스는 정상적으로 제공할 수 있습니다. 반대로 서버에 Ping이 되더라도 프록시 포트는 사용할 수 없을 수 있습니다. Clash 노드 문제를 해결할 때는 Ping만 보는 것보다 URL Test로 프록시 경로를 확인하는 편이 실제 접속에 더 가깝지만, 실제 서비스 테스트도 함께 해야 합니다.

2. 지연 시간은 낮은데 다운로드가 느린 이유: 핸드셰이크·대역폭·혼잡의 차이

지연 시간은 한 번의 요청과 응답을 기다리는 시간이고, 대역폭은 단위 시간에 전송할 수 있는 데이터 양입니다. 작은 탐색 요청은 응답 헤더만 받아도 되므로 회선 대역폭이 낮아도 빠르게 완료될 수 있습니다. 수백 MB 파일을 내려받을 때는 회선 속도 제한, 공유 출구의 부하, 대상 서버의 속도 제한이 본격적으로 드러납니다.

예시 데이터로 차이 살펴보기

아래 데이터는 판단 방법을 설명하기 위한 예시이며, 특정 서비스의 실측 결과를 보장하지 않습니다. 같은 기기에서 동일한 테스트 URL로 같은 시간대에 측정했다고 가정해 보겠습니다.

대용량 파일을 내려받는다면 노드 B를 먼저 써볼 만합니다. 짧은 요청이 적은 환경에서는 부하가 낮을 때 노드 A의 응답이 더 빠를 수 있지만, 최댓값을 보면 안정성을 더 살펴봐야 합니다. 1.2MB/s는 약 9.6Mbps, 9.0MB/s는 약 72Mbps입니다. 비교하기 전에 바이트와 비트 단위를 통일하세요.

• 웹 페이지 첫 로딩: DNS, 연결 핸드셰이크, 첫 바이트 수신, 여러 리소스 요청의 영향을 받으므로 지연 시간이 중요합니다.
• 대용량 파일 다운로드: 지속 처리량, 패킷 손실 후 재전송, 서버 측 제한이 더 중요합니다.
• 동영상 재생: 충분하고 안정적인 처리량이 필요합니다. 순간 속도가 높더라도 버퍼가 계속 채워진다는 뜻은 아닙니다.
• 실시간 상호작용: 평균 지연 시간뿐 아니라 지터, 패킷 손실, 실제로 사용하는 UDP 경로도 확인해야 합니다.

저녁 시간대 혼잡은 지연 시간을 높이고 처리량을 낮추는 경우가 많지만, 지속 전송을 해야만 문제가 드러날 수도 있습니다. 한가한 시간에 측정한 80ms 한 번으로 앞으로 10분 동안의 회선 부하를 예측할 수는 없습니다.

3. 테스트 URL과 시간 제한에 따라 순위가 달라지는 이유

테스트 URL이 측정 대상 경로를 결정합니다

URL Test는 프록시 입구에 도달하는 것으로 끝나지 않고, 프록시 출구에서 테스트 대상까지의 경로도 측정합니다. 테스트 도메인을 바꾸면 CDN 접속 지점, DNS 조회 결과, TLS 동작, 출구 라우팅 경로가 달라질 수 있습니다. 한 노드가 테스트 사이트와 가깝다고 해서 코드 저장소, 동영상 스트리밍 서비스, 업무 시스템까지 가까운 것은 아닙니다.

일반적인 경량 테스트 URL은 응답 데이터가 결과에 미치는 영향을 줄이기 위해 HTTP 204를 반환합니다. 예를 들어 https://www.gstatic.com/generate_204를 테스트 대상으로 사용할 수 있지만, 모든 출구와 네트워크 환경에서 작동하는 것은 아닙니다. 로그인이나 CAPTCHA가 필요하거나 리디렉션이 잦은 페이지는 범용 테스트 대상으로 사용하지 마세요.

• 노드를 비교할 때는 URL, 프로토콜, 시간 제한을 동일하게 설정하세요.
• 특정 사이트의 문제를 확인할 때는 실제 요청도 테스트하고, 범용 테스트 결과만으로 판단하지 마세요.
• 여러 노드의 테스트가 동시에 실패하면 먼저 테스트 사이트에 접속할 수 있는지 확인하세요.
• 응답하기 쉬운 URL로 바꿔 실제 서비스 접속 실패를 노드 정상으로 오인하게 만들지 마세요.

시간 제한은 대기 상한이며 노드 지연 시간이 아닙니다

예를 들어 두 테스트의 대기 상한이 각각 3000ms와 10000ms이고, 어떤 노드의 탐색 완료에 4200ms가 걸린다면 전자에서는 실패하고 후자에서는 결과를 받을 수 있습니다. 대기 시간을 늘리는 것은 결과가 돌아올 기회를 주는 것일 뿐, 회선을 빠르게 만들지는 않습니다. 클라이언트에 시간 초과가 표시되어도 노드가 영구적으로 작동하지 않는다는 뜻은 아닙니다. 이번 탐색이 지정된 조건 안에 완료되지 않았다는 의미입니다.

실패 원인은 DNS 조회, TLS, 연결 거부, 테스트 대상의 제한일 수도 있으므로 코어 로그를 함께 확인해야 합니다. 클라이언트의 수동 테스트, 프록시 그룹 상태 확인, provider 상태 확인은 서로 다른 매개변수를 사용할 수 있습니다. 화면 옵션 하나를 바꾸면 모든 탐색에 적용된다고 단정하지 마세요.

4. mihomo에서 url-test 프록시 그룹 설정하기

url-test 프록시 그룹은 탐색 결과를 바탕으로 후보 프록시를 자동 선택하므로, 낮은 지연 시간을 우선하는 작업을 코어에 맡길 때 적합합니다. 아래는 설정 예시이며, 전체 설정의 proxies에 “홍콩 입구 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초이며 300밀리초가 아닙니다.
• tolerance: 50: 전환 허용 오차는 50밀리초입니다. 작은 지연 시간 차이로 잦은 전환이 발생하는 것을 줄이며, 시간 제한 설정은 아닙니다.
• lazy: true: 그룹을 사용하지 않을 때 주기적인 테스트를 중단할 수 있습니다. 이 설정을 사용하면 백그라운드에서 최신 탐색 값이 항상 유지될 것으로 기대해서는 안 됩니다.
• proxies: 이미 정의한 프록시 또는 그룹 이름을 참조하며, 설정에 적힌 이름과 정확히 일치해야 합니다.

이 그룹은 규칙이나 상위 프록시 그룹에서 선택될 때만 해당 연결의 출구 선택에 참여합니다. 그룹을 만들었더라도 다른 곳에서 참조하지 않으면 브라우저 트래픽이 자동으로 이 그룹을 사용하지 않습니다. 이미 시작된 다운로드나 장시간 연결은 정책을 바꾸더라도 다른 노드로 원활하게 옮겨지지 않는 경우가 많습니다. 새 연결을 만든 뒤 결과를 확인하세요.

자동 선택은 대역폭 순위가 아닙니다: url-test는 탐색 지연 시간을 기준으로 경로를 선택할 뿐, 대용량 파일을 자동으로 내려받아 노드별 지속 대역폭을 측정하지 않습니다. 다운로드 작업에서는 수동 선택 그룹으로 노드를 고정한 뒤 처리량을 따로 비교할 수 있습니다.

후보 노드가 proxy-providers에서 제공된다면 provider의 health-check 설정도 확인하세요. 두 설정은 각각 역할과 매개변수가 다릅니다. 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다. 지속적으로 설정을 바꾸려면 현재 클라이언트가 지원하는 오버라이드 방식을 사용하고, 적용 후 실제 설정을 확인하세요.

5. 조건을 통일해 재현 가능한 노드 비교하기

1. 네트워크 환경을 통일합니다. 같은 기기에서 같은 Wi-Fi 또는 유선 네트워크를 사용하세요. 로컬 대역폭을 점유하지 않도록 시스템 업데이트, 클라우드 동기화, 다른 대용량 다운로드를 일시 중지합니다.
2. 트래픽 경로를 확인합니다. 연결 목록에서 대상 도메인에 어떤 규칙이 적용됐고 어떤 프록시가 최종 선택됐는지 확인하세요. 규칙 모드에서는 테스트 사이트가 직접 연결되는 반면 지연 탐색은 후보 노드를 통할 수 있어, 두 결과를 그대로 비교할 수 없습니다.
3. 후보 노드를 고정합니다. 테스트 중 자동 그룹이 노드를 바꾸지 않도록 잠시 수동 선택을 사용하세요. 노드를 바꾼 뒤에는 새 업무 연결을 만들고, 필요한 경우 기존 다운로드를 중지한 다음 다시 시작합니다.
4. 경량 탐색을 반복합니다. 노드마다 약 5초 간격으로 5회 테스트하고 성공 횟수, 중앙값, 최댓값을 기록하세요. 가장 낮은 값 하나만 남기지 마세요.
5. 실제 서비스 테스트를 추가합니다. 동일한 다운로드 URL에서 단일 연결 전송을 각각 약 30초 동안 진행하고 안정 구간을 관찰하세요. 다중 연결 결과는 따로 기록하고 단일 연결 결과와 합산하지 않습니다.
6. 시간대를 바꿔 다시 확인합니다. 낮과 저녁 혼잡 시간대에 각각 테스트하세요. 저녁에만 속도가 크게 떨어진다면 클라이언트를 반복해서 재설치하기보다 부하와 라우팅 혼잡을 먼저 살펴보세요.

curl로 지정한 로컬 HTTP 프록시 확인하기

아래 명령은 설정된 mixed-port가 7890이고 로컬 접속이 허용되며 추가 프록시 인증이 없다고 가정합니다. 포트가 다르면 현재 적용된 설정을 기준으로 바꾸세요. Windows PowerShell에서는 curl.exe를 사용하면 이전 환경에서 같은 이름으로 등록된 명령 별칭이 매개변수 해석에 영향을 주는 것을 방지할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --connect-timeout 5 --max-time 10 --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

위의 출력 파일 경로는 macOS와 Linux에서 사용할 수 있습니다. Windows에서는 /dev/null을 NUL로 바꾸세요. --connect-timeout 5는 연결 단계의 대기 시간을 제한하고, --max-time 10은 요청 전체를 최대 10초로 제한합니다. 출력되는 시간 단위는 초입니다. 이 명령은 curl이 로컬 프록시를 통해 보낸 요청의 동작을 측정하므로, 코어의 URL Test 결과인 밀리초 값과 완전히 같지는 않을 수 있습니다.

테스트 결과는 연결 목록과 함께 확인해야 합니다. 로컬 HTTP 프록시가 요청을 받아도 코어는 현재 모드와 규칙에 따라 출구를 선택합니다. --proxy를 지정했다고 해서 비교하려는 원격 노드가 반드시 사용된다는 뜻은 아닙니다.

6. 자주 발생하는 문제: 시간 초과부터 동영상 끊김까지

모든 노드가 갑자기 시간 초과됨

먼저 현재 네트워크에서 기본 서비스에 정상적으로 접속할 수 있는지 확인하세요. 그런 다음 구독에 지정된 서버 주소가 DNS 조회에 성공하는지, 테스트 대상에 접속할 수 있는지, 로그에 연결 거부나 TLS 오류가 표시되는지 확인합니다. 다른 안정적인 경량 HTTPS 주소로 교차 검증할 수도 있습니다. 한 번에 여러 테스트가 실패했다고 모든 노드가 동시에 작동하지 않는다고 단정하거나 설정을 모두 삭제하지 마세요.

60ms로 표시되는데 웹 페이지를 여는 데 몇 초가 걸림

먼저 웹 페이지가 실제로 해당 노드를 통하는지 확인한 뒤 브라우저가 기존 연결을 재사용하는지도 살펴보세요. 웹 페이지는 수십 개의 외부 리소스를 불러올 수 있으며, 도메인 하나의 DNS 조회나 요청이 지연되기만 해도 전체 로딩이 느려질 수 있습니다. 브라우저 개발자 도구의 네트워크 패널에서 첫 바이트 대기 시간과 콘텐츠 다운로드 시간을 구분하면 핸드셰이크, 서버 응답, 전송 중 어디가 느린지 파악하는 데 도움이 됩니다.

속도 테스트는 정상이지만 동영상이 계속 버퍼링됨

Clash 지연 시간만 보지 말고 동영상 서비스 자체의 연결 속도나 버퍼 길이 통계를 확인하세요. 미디어 CDN과 테스트 사이트의 경로는 다를 수 있고, 출구에서 특정 서비스가 제한될 수도 있습니다. HTTP 탐색은 성공했더라도 실제 서비스가 UDP나 QUIC을 사용한다면 해당 경로가 지원되는지 별도로 확인해야 합니다. HTTPS 탐색 하나로 모든 프로토콜을 검증할 수는 없습니다.

TUN을 켠 뒤 측정값이나 사용 환경이 달라짐

TUN은 트래픽을 가로채는 방식을 바꿀 뿐 회선 대역폭을 늘리지는 않습니다. 전환 전후에 DNS 가로채기, 라우팅, 다른 프록시 소프트웨어와의 충돌을 확인하세요. 코어가 직접 실행하는 노드 탐색과 앱에서 TUN을 통해 코어로 전달되는 실제 트래픽은 로컬 경로가 완전히 같지 않을 수 있습니다. 차이는 실제 연결 기록을 기준으로 판단하세요.

7. 노드 선택: 접속 가능 여부, 안정성, 사용 목적 순으로 확인

일상적으로 사용할 노드는 세 단계로 고를 수 있습니다. 먼저 필요한 서비스에 접속되는지 확인하고, 반복 탐색 결과의 성공률과 변동 폭을 비교한 뒤, 웹 브라우징·다운로드·동영상 등 사용 목적에 맞춰 추가 테스트하세요. 간헐적으로 50ms가 나오지만 자주 시간 초과되는 노드보다 150ms로 안정적인 노드가 계속 사용하기에 나은 경우가 많습니다.

• 웹·업무: 여러 번 연속 측정한 요청 시간과 실제 서비스 성공률을 확인하세요.
• 다운로드·업데이트: 같은 출처와 연결 수에서 지속되는 전송 속도를 확인하세요.
• 동영상·회의: 버퍼링, 지터, 패킷 손실, 해당 프로토콜의 실제 성능을 확인하세요.

URL Test를 ‘지정된 대상에 대한 경량 연결 상태 및 지연 시간 탐색’으로 이해하면 하나의 숫자에 현혹되지 않습니다. 테스트 URL, 시간 제한, 프록시 그룹을 바꾸기 전에 기존 조건과 결과를 기록해 두세요. 한 번에 한 항목만 바꿔야 설정 변경으로 개선된 것인지, 우연히 회선 부하가 달라진 것인지 판단할 수 있습니다.