Clash 지연 테스트 원리: URL Test 수치와 실제 인터넷 속도가 다른 이유

URL Test는 작은 요청의 응답 시간을 측정하며 다운로드 속도는 측정하지 않습니다

먼저 결론부터 말하면, Clash 클라이언트의 지연 시간은 보통 코어가 지정된 프록시를 통해 테스트 URL에 요청을 보내고 응답을 받기까지 걸린 시간입니다. 단순한 ICMP Ping도, 노드 대역폭도 아니며 동영상 화질로 환산할 수도 없습니다. 현재 작업에 적합한 노드인지 판단하려면 지연 시간의 변동, 지속 전송 성능, 대상 사이트 접속 여부, 실제로 적용된 규칙을 함께 확인해야 합니다.

클라이언트는 테스트를 실행하고 결과를 표시하며, 코어는 프록시 연결을 맺어 대상에 접속합니다. 화면의 ‘지연 테스트’와 ‘연결 테스트’는 서로 다른 API를 사용할 수 있습니다. 통합 지연 시간을 적용하는지, 두 번째 요청 결과를 사용하는지도 코어와 클라이언트 설정에 따라 달라집니다. 두 결과를 비교하기 전에 테스트 URL과 방식을 먼저 확인하세요.

URL Test: 작은 HTTP 요청의 성공 여부와 테스트 완료까지 걸린 시간을 확인하며, 보통 밀리초(ms)로 표시합니다.
다운로드 테스트: 일정 시간 동안 전송한 데이터양을 확인하며, 보통 MB/s 또는 Mbps로 표시합니다. 실제 데이터 사용량이 발생합니다.
실제 사용: DNS, 연결 재사용, 페이지 리소스 동시 로드, 서버 처리 시간, 앱 자체의 대기 시간도 영향을 줍니다.

지연 테스트는 어떤 과정을 거칠까

테스트 경로는 ‘내 기기 → 프록시 입구 → 프록시 출구 → 테스트 사이트’로 간단히 나타낼 수 있습니다. 실제 구성에는 중계 서버와 여러 단계의 프록시가 포함될 수 있고, 입구와 출구가 같은 지역에 있다는 보장도 없습니다. 각 단계가 요청에 영향을 주지만, 어떤 과정이 표시된 수치에 포함되는지는 코어 구현, 캐시 상태, 연결 재사용 여부에 따라 다릅니다.

연결에 필요한 도메인을 조회합니다. 프록시 서버 도메인을 조회해야 합니다. 테스트 대상의 도메인을 어디서 조회하는지는 프록시 프로토콜, DNS 설정, 코어 동작에 따라 달라지므로 모두 로컬에서 처리된다고 단정할 수 없습니다.
프록시에 연결합니다. 프로토콜에 따라 TCP, TLS 또는 UDP 기반 전송의 핸드셰이크가 필요할 수 있습니다. 기존 연결을 재사용할 때보다 최초 연결이 대체로 더 오래 걸립니다.
프록시를 통해 테스트 대상에 접속합니다. 프록시 출구에서 테스트 사이트까지는 라우팅, 혼잡 대기열, 대상 사이트의 처리 과정이 추가로 영향을 줍니다.
HTTP 응답을 받습니다. HTTPS를 사용하면 테스트 사이트와 TLS 세션도 맺어야 합니다. 응답 상태, 리디렉션, 시간 초과 처리 역시 테스트 결과에 영향을 줍니다.

두 번째 테스트가 훨씬 빨라질 수 있는 이유

DNS 캐시, 연결 재사용, TLS 세션 재개로 후속 요청 시간이 짧아질 수 있습니다. mihomo의 unified-delay 옵션은 프록시 프로토콜별 핸드셰이크 오버헤드가 지연 시간 비교에 미치는 영향을 줄입니다. 이 옵션을 켠 결과는 다른 측정 기준의 수치와 그대로 비교하면 안 됩니다. 문제를 확인할 때는 설정을 고정하고, 옵션을 바꾸기 전후의 차이를 회선 개선으로 오해하지 마세요.

여러 노드를 한꺼번에 테스트하면 연결도 동시에 여러 개 생성됩니다. 성능이 제한된 라우터나 모바일 네트워크, 동시 연결 수가 제한된 노드에서는 측정 작업 자체가 경합을 일으킬 수 있습니다. ‘전체 테스트’를 연속으로 여러 번 눌러도 노드 순위가 더 정확해지는 것은 아닙니다.

테스트 URL에 따라 노드 순위가 달라지는 이유

테스트 URL은 결과에 영향을 주는 중요한 설정입니다. 도메인마다 연결되는 CDN이 다를 수 있으며, 같은 도메인도 프록시 출구와 DNS 조회 결과에 따라 다른 데이터센터에 연결될 수 있습니다. 테스트 사이트까지 경로가 짧은 노드가 동영상 플랫폼, 코드 호스팅 서비스, 업무 사이트까지 빠르게 연결된다는 뜻은 아닙니다.

테스트 URL을 고를 때 확인할 세 가지

응답 본문이 작아야 합니다. HTTP 204를 반환하는 연결 확인 주소처럼 작고 안정적인 응답 엔드포인트를 우선 사용해 본문 전송으로 인한 영향을 줄입니다.
접속 조건이 안정적이어야 합니다. 로그인, CAPTCHA, 지역 인증이 필요하거나 리디렉션이 잦은 페이지는 피하세요.
같은 기준으로 측정해야 합니다. 같은 노드 묶음을 비교할 때는 URL, 시간 초과 설정, 네트워크 환경을 통일하고 서로 다른 사이트의 결과를 섞지 마세요.

https://www.gstatic.com/generate_204는 흔히 쓰이는 예시이며 HTTPS 기본 포트인 443을 사용합니다. 작은 요청을 보내 확인하기에 적합하지만 인터넷 서비스 전체를 대표하지는 않습니다. 로컬 네트워크나 특정 출구에서 이 주소에 접속할 수 없다면, 테스트 실패만으로 노드를 전혀 사용할 수 없다고 판단해서는 안 됩니다.

테스트 결과	우선 판단할 수 있는 내용	추가로 확인할 내용
작은 요청의 지연 시간이 짧음	현재 탐색 경로의 응답이 빠름	지속 처리량과 대상 서비스에서의 성능
모든 URL에서 시간 초과	테스트 대상이나 공용 경로에 문제가 있을 수 있음	다른 신뢰할 수 있는 대상으로 바꿔도 실패하는지
특정 노드 하나만 시간 초과	해당 노드의 현재 경로를 점검할 필요가 있음	입구 연결, 프로토콜 설정, 출구 상태
수치가 자주 크게 변동함	연결 경로나 측정 조건이 불안정함	로컬 Wi-Fi, 동시 연결, 혼잡 시간대의 트래픽

테스트 URL을 바꿨다면 노드 전체를 다시 테스트하고 변경 시각을 기록하세요. 노드 하나만 새로 측정한 뒤 다른 노드의 이전 캐시 값과 비교하지 마세요.

지연 시간이 짧은데도 노드가 끊기는 이유

작은 요청은 빠르지만 지속 전송은 느릴 수 있습니다

아주 작은 응답은 혼잡이 심해지기 전에 도착할 수 있습니다. 대용량 파일을 내려받거나 고화질 동영상을 재생하면 지속 전송이 필요해 대역폭 제한, 패킷 손실과 재전송, 저녁 시간대의 혼잡, 연결 재설정 같은 문제가 드러납니다. 지연 시간은 응답 시간, 처리량은 전송 능력을 나타냅니다. 서로 연관은 있지만 같은 지표는 아닙니다.

단위 환산을 예로 들면 20Mbps의 이론상 전송 속도는 약 2.5MB/s이며, 실제 앱에서는 프로토콜 오버헤드만큼 낮아집니다. 단순 환산 예시일 뿐 노드의 실측값은 아닙니다. 지연 시간이 60ms인 노드가 150ms인 노드보다 다운로드 속도가 느릴 수도 있습니다.

실제 트래픽이 측정한 노드를 거치지 않을 수 있습니다

노드 하나를 지정해 테스트하는 것은 해당 프록시로 탐색 요청을 보내는 것일 뿐, 브라우저 요청도 같은 규칙과 정책 그룹을 거친다는 뜻은 아닙니다. 앱 트래픽에 DIRECT가 적용되거나 다른 정책 그룹으로 전달될 수 있습니다. 노드를 직접 선택했더라도 대상 도메인에 최종 적용된 규칙과 전체 프록시 경로를 확인해야 합니다.

클라이언트의 ‘연결’ 또는 ‘연결 로그’ 화면에서 대상 도메인을 찾아 적용된 규칙, 정책 그룹, 출구 프록시를 확인하세요.
현재 규칙 모드를 사용 중인지 확인하고, 실수로 직접 연결 모드로 바뀌지 않았는지 살펴보세요. 전역 모드라면 GLOBAL에서 선택한 항목을 확인해야 합니다.
앱이 시스템 프록시를 따르지 않는다면 TUN 모드가 필요한지, 해당 앱이 라우팅 대상에서 제외되어 있는지 확인하세요.

HTTP 테스트로는 UDP나 서비스 접근 권한을 확인할 수 없습니다

일반적인 HTTPS 테스트는 해당 HTTP 요청 경로를 주로 확인합니다. 게임, 음성 통화, 일부 QUIC 트래픽은 UDP를 사용하므로 노드 프로토콜 지원 여부, 서버 설정, 로컬 라우팅이 다를 수 있습니다. 테스트에 성공해도 UDP까지 사용할 수 있다는 보장은 없습니다. TUN을 켠다고 모든 도메인 조회와 UDP 전달 문제가 자동으로 해결되는 것도 아닙니다.

대상 서비스에서 출구 IP, 계정 지역, 요청 빈도를 제한할 수도 있습니다. 지역 제한, 403, CAPTCHA가 표시되면 지연 수치만 보고 노드를 반복해서 바꾸기보다 서비스 응답을 확인하세요.

url-test 정책 그룹: interval과 tolerance 설정 방법

url-test는 탐색 결과를 자동 비교하는 정책 그룹이지 다운로드 속도 측정 도구가 아닙니다. 아래 예시는 해당 필드를 지원하는 mihomo 코어용입니다. 노드-A와 노드-B는 기존 proxies에 정의된 이름으로 바꿔야 합니다. 이 설정 조각으로 구독 파일 전체를 덮어쓰지 마세요.

proxy-groups:
  - name: 자동 지연
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 아웃바운드 선택
    type: select
    proxies:
      - 자동 지연
      - 노드-A
      - 노드-B

rules:
  - MATCH,아웃바운드 선택

여기서 MATCH는 트래픽이 정책 그룹으로 전달되는 방식을 보여주는 예시일 뿐입니다. 기존 설정의 LAN, 직접 연결, 서비스별 분기 규칙은 그대로 두고 기본 트래픽이나 지정한 서비스가 해당 그룹을 사용하도록 설정하세요. 이미 proxy-groups나 rules가 있다면 항목을 합치고 최상위 키를 중복해서 추가하지 마세요. 전체 필드 구조는 YAML 매뉴얼에서 확인할 수 있습니다.

필드	예시 값	의미와 설정 기준
`interval`	300초	주기적으로 테스트하는 간격입니다. 단일 요청의 시간 초과 값이나 시간이 되면 노드를 강제로 바꾸는 설정이 아닙니다.
`tolerance`	50ms	전환 허용 오차입니다. 지연 시간에 작은 차이만 있어도 현재 노드가 자주 바뀌는 일을 방지합니다.
`lazy`	`true`	그룹을 사용하지 않을 때 주기 테스트를 건너뛰어 탐색 부하를 줄입니다.
`url`	HTTPS 소용량 응답 URL	탐색 대상을 지정합니다. URL을 바꾸면 비교 기준도 달라집니다.

우선 300초와 50ms로 설정한 뒤 변동에 따라 조정하세요

일반적인 웹 브라우징이라면 interval: 300, tolerance: 50부터 시작해 볼 수 있습니다. 모든 환경에 최적인 값은 아닙니다. 노드가 많거나 모바일 데이터를 사용한다면 간격을 600초로 늘려 보세요. 네트워크 전환이 잦아 더 빠른 결과가 필요하다면 부하를 확인한 뒤 120초를 시험할 수 있습니다. 그룹을 사용하지 않거나 기기가 절전 상태인 경우 실제 탐색 시점이 달라질 수 있습니다.

tolerance는 안정성과 전환 빈도 사이의 균형을 조절합니다. 현재 노드가 120ms이고 다른 노드가 100ms라면 20ms만 더 빠릅니다. tolerance를 50ms로 설정하면 사용 가능한 현재 노드를 유지하는 쪽으로 동작하는 경우가 많습니다. 다른 노드가 60ms라면 60ms 개선되므로 전환될 가능성이 더 높습니다. 이는 매개변수 설명을 위한 예시이며, 실제 동작은 사용 가능 여부, 이전 탐색 결과, 코어 구현에 따라 달라집니다.

구독을 업데이트할 때 직접 수정한 설정이 덮어써진다면 클라이언트가 지원하는 오버라이드나 병합 기능을 사용하세요. 클라이언트마다 메뉴 이름이 다르므로 저장 후 편집기 내용뿐 아니라 코어에 실제로 로드된 실행 설정도 확인해야 합니다.

실제 사용 경험을 반복해서 확인하는 방법

‘Clash 속도 테스트는 빠른데 웹페이지는 느림’ 문제를 확인할 때는 탐색 테스트와 실제 서비스 테스트를 나눠 기록하세요. 한 번에 조건 하나만 바꿔야 개선 원인이 노드인지, 규칙인지, 로컬 네트워크인지 판단할 수 있습니다.

테스트 조건을 고정합니다. 같은 Wi-Fi 또는 유선 네트워크, 같은 테스트 URL, 같은 지연 설정을 유지하고 업로드나 다운로드 대역폭을 많이 쓰는 작업은 일시 중지하세요.
연속 측정 결과를 기록합니다. 후보 노드 2~3개를 골라 각 노드를 5회씩, 약 10초 간격으로 테스트합니다. 가장 좋은 값만 남기지 말고 중간값, 최댓값, 실패 횟수를 기록하세요.
후보 노드를 직접 고정합니다. select 그룹에서 노드 하나를 선택해 실제 서비스 테스트 중 자동 그룹이 출구를 바꾸지 않도록 합니다.
서비스 연결을 새로 시작합니다. 대상 페이지를 다시 열거나 전송을 새로 시작한 뒤, 연결 화면에서 도메인, 적용 규칙, 프록시 경로가 일치하는지 확인하세요.
지속 성능을 확인합니다. 합법적으로 접근할 수 있는 같은 파일이나 동일한 동영상 구간을 60~120초 동안 재생하고, 로딩 대기 시간, 버퍼링 횟수, 안정적인 전송 속도를 각각 기록하세요.
로컬 환경을 점검합니다. 모든 노드에서 변동이 나타나면 먼저 유선과 Wi-Fi를 비교하고 백그라운드 업로드와 DNS를 확인하세요. 그다음 프록시 매개변수를 하나씩 조정합니다.

기록표에는 ‘시간, 노드, 테스트 URL, 지연 시간 5회, 실패 횟수, 대상 서비스 성능’의 6개 항목만 있어도 됩니다. 특정 시간대에만 문제가 생긴다면 비슷한 시간에 다시 측정하세요. 새벽과 저녁 혼잡 시간대의 단일 측정값은 직접 비교하기 어렵습니다.

노드 선택은 작업에 맞춰야 합니다. 웹페이지 상호작용에는 응답 속도와 안정성, 파일 전송에는 지속 처리량, 게임과 음성 통화에는 해당 UDP 경로와 지터가 중요합니다. url-test는 통일된 소용량 요청 지표로 노드를 자동 선별하는 기능이며 실제 서비스 테스트를 대신하지 않습니다. 테스트 간격을 계속 줄이는 것보다 수동 선택 경로를 하나 남겨 두는 편이 문제를 찾기 쉽습니다.