Clash 지연 테스트 결과 보는 법: url-test 원리와 실제 속도 차이

지연 시간: 한 번의 테스트에 걸린 시간이지 다운로드 속도가 아닙니다

클라이언트에 표시되는 80 ms, 230 ms는 보통 코어가 지정된 노드를 통해 테스트 URL에 HTTP 또는 HTTPS 요청을 한 번 보내 측정한 값입니다. 이 값은 “요청을 보내고 테스트 조건에 맞는 응답을 받기까지 걸린 시간”을 나타내며, “회선이 초당 얼마나 많은 데이터를 전송하는지”를 알려주지는 않습니다. 메뉴에 ‘속도 테스트’라고 표시되어도 대용량 파일을 다운로드하는 테스트는 아닐 수 있습니다.

먼저 세 가지 지표를 구분하세요. 지연 시간은 한 번 요청했을 때 응답을 기다리는 시간, 처리량은 지속적인 전송 능력, 안정성은 여러 요청의 편차와 실패 여부를 나타냅니다. 지연 시간이 낮으면 작은 요청을 자주 주고받을 때 유리하지만, 그것만으로 동영상 로딩이나 대용량 다운로드, 장시간 연결 품질이 더 좋다고 단정할 수는 없습니다.

url-test 원리: 후보 노드를 통해 테스트 URL에 접속

url-test는 프록시 그룹 유형입니다. 코어는 그룹에 포함된 후보 노드로 URL 테스트를 수행한 뒤, 연결 가능 여부와 지연 시간, 전환 허용 오차를 기준으로 노드를 선택합니다. 클라이언트의 수동 지연 테스트와 그룹의 주기적 테스트는 URL, 시간 제한, 실행 방식이 다를 수 있습니다. 화면에 표시된 숫자만 보고 자동 선택에 문제가 있다고 판단해서는 안 됩니다.

테스트 경로에 포함되는 과정

1. 이름 확인 및 연결 준비: 노드 서버의 도메인을 확인해야 합니다. 대상 도메인을 로컬에서 확인할지 원격에서 확인할지는 프로토콜, DNS 설정, 구현 방식에 따라 달라집니다.
2. 프록시 연결 설정: 노드에 연결해 해당 프로토콜의 핸드셰이크를 완료한 다음, 노드에서 테스트 대상에 접속합니다. 중계 서버가 있다면 중계 구간도 거칩니다.
3. 테스트 리소스 요청: HTTPS 주소라면 보통 TLS 핸드셰이크를 거친 뒤 HTTP 요청을 보내고 응답을 기다립니다.
4. 결과 기록: 테스트가 성공하면 소요 시간을 기록합니다. 연결 실패, 시간 초과 또는 응답이 테스트 조건을 충족하지 않으면 실패·사용 불가·시간 초과로 표시될 수 있습니다.

위 내용은 요청이 거치는 과정을 설명한 것이며, 모든 코어가 각 과정을 하나의 수치에 전부 반영한다는 뜻은 아닙니다. DNS 캐시, 연결 재사용, 프로토콜 구현, 측정 시작·종료 시점이 결과에 영향을 줍니다. 따라서 Clash, Clash Meta(mihomo), 각 클라이언트 화면의 수치는 같은 조건에서 비교해야 하며, 서로 다른 조건의 값을 단순히 나란히 비교해서는 안 됩니다.

이 테스트는 기존의 ICMP ping과도 다릅니다. 서버에서 ICMP를 차단해도 HTTP 테스트는 성공할 수 있고, 서버에 ping이 된다고 해서 프록시 인증과 프로토콜 핸드셰이크, 대상 사이트 접속까지 정상이라는 뜻은 아닙니다.

테스트 결과가 실제 트래픽 규칙을 대신하지는 않습니다

프록시 그룹 테스트는 후보 노드별로 요청을 보내 확인합니다. 테스트 URL을 일반 브라우저 요청처럼 전체 rules에 먼저 넘겨 노드를 정하는 방식이 아닙니다. 실제 브라우저 연결은 계속 실행 모드, 규칙 일치 결과, 프록시 그룹 선택의 영향을 받습니다. 테스트는 노드 A로 했더라도 웹 요청이 최종적으로 DIRECT나 다른 그룹에 연결되면 체감이 달라질 수 있습니다.

지연 시간은 낮은데 버벅이는 이유: 경로별 차이 네 가지

작은 응답은 빠르지만 지속 전송은 느린 경우

일반적인 generate_204 주소는 응답이 매우 작아 가벼운 연결 확인에 적합합니다. 지속적인 데이터 처리량을 거의 측정하지는 않습니다. 노드 대역폭이 혼잡하거나 단일 연결 속도 제한이 걸렸거나 출구 부하가 높은 경우, 작은 요청은 빠르게 처리돼도 대용량 파일은 제대로 전송되지 않을 수 있습니다.

예를 들어, 아래는 지표를 설명하기 위한 가상 기록이며 이 사이트에서 직접 측정한 결과가 아닙니다. A 노드는 테스트 지연 시간 65 ms, 다운로드 속도 1.2 MB/s이고 B 노드는 테스트 지연 시간 140 ms, 다운로드 속도 8 MB/s라고 가정해 보겠습니다. A는 짧은 요청에 더 빨리 응답하지만, 같은 파일을 다운로드하면 B가 더 먼저 완료할 수 있습니다.

테스트 서버는 가깝지만 실제 서비스 서버는 먼 경우

테스트 URL은 CDN에서 제공되는 경우가 많습니다. 출구 지역에 따라 연결되는 데이터센터가 달라질 수 있으므로, 테스트 결과가 좋다는 것은 해당 대상까지의 경로가 양호하다는 뜻일 뿐입니다. 다른 지역의 코드 저장소, 동영상 서비스, 사내 시스템에 접속하면 출구 이후의 경로와 상호 접속 품질, 서버 부하가 모두 달라질 수 있습니다.

한 번은 낮은 수치가 나와도 연속 요청이 불안정한 경우

같은 노드에서 70, 75, 620, 시간 초과, 82 ms처럼 결과가 이어진다면 마지막 82 ms만 봐서는 큰 편차를 놓치게 됩니다. 패킷 손실은 재전송을 유발할 수 있으며 TLS 연결 설정, 웹 리소스 동시 로딩, 장시간 데이터 전송에 특히 영향을 줍니다. 여기서 ‘시간 초과’는 애플리케이션 계층 테스트 실패를 뜻하며 ICMP 패킷 손실률로 봐서는 안 됩니다.

실제 서비스가 UDP나 다른 연결 방식을 사용하는 경우

HTTP 테스트 성공만으로 UDP 전달이 가능하다고 단정할 수는 없습니다. 음성 통화, 게임, QUIC을 사용하는 서비스는 UDP 지원 여부, 서버 설정, 클라이언트의 트래픽 처리 방식, 방화벽의 영향을 받습니다. TUN을 켠다고 노드 대역폭이 늘어나는 것도 아닙니다. TUN은 주로 트래픽이 클라이언트로 들어오는 방식을 바꾸며, 모든 서비스가 HTTP 테스트와 같은 경로를 사용하도록 보장하지는 않습니다.

url-test 설정: 테스트 URL과 주기부터 고정하기

아래는 mihomo용 프록시 그룹 설정 일부이며, 단독으로 실행할 수 있는 전체 설정 파일은 아닙니다. 기존 proxies에 “홍콩-A”와 “홍콩-B”라는 이름의 노드가 정의되어 있어야 합니다. 설정을 합칠 때는 실제 노드 이름을 사용하세요. 파일 끝에 같은 이름의 최상위 proxy-groups 필드를 추가하지 마세요.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩-A
      - 홍콩-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• type: url-test: URL 테스트 결과에 따라 후보 노드를 선택합니다. 대역폭 측정용 그룹은 아닙니다.
• url: 그룹에서 테스트할 대상입니다. 위 예시는 가벼운 테스트에 자주 쓰이는 HTTPS 엔드포인트지만, 현재 네트워크에서 접속 가능한지 확인해야 합니다.
• interval: 300: 테스트 주기는 300초, 즉 5분입니다. 300밀리초가 아닙니다.
• tolerance: 80: 전환 허용 오차는 80밀리초입니다. 작은 지연 시간 차이로 노드가 바뀌는 일을 줄입니다.
• lazy: true: mihomo의 지연 테스트 방식에 따라 사용하지 않는 그룹은 주기적인 테스트를 계속 실행하지 않을 수 있습니다. 확인할 때 백그라운드에서 늘 새로고침되고 있다고 가정하지 마세요.

구독 제공자가 proxy-providers의 health-check 설정을 통해 상태 확인을 수행할 수도 있습니다. 제공자 상태 확인 주기, 프록시 그룹의 interval, 클라이언트 화면의 수동 테스트는 서로 다른 설정 항목입니다. 하나만 바꿔도 모든 표시와 테스트 동작이 함께 바뀌는 것은 아닙니다.

tolerance 설정법: 작은 차이로 인한 전환 줄이기

tolerance는 ‘허용되는 최대 지연 시간’이나 ‘이 값보다 낮으면 통과’라는 뜻이 아닙니다. 현재 선택된 노드와 더 빠른 후보 노드 사이의 전환 허용 오차를 정합니다. 후보가 조금 더 빠를 뿐이라면 현재 사용 가능한 노드를 유지하고, 설정한 차이보다 훨씬 빨라졌을 때 전환하는 것으로 이해하면 됩니다.

일반적인 mihomo 선택 방식을 예로 들어 보겠습니다. 현재 노드가 150 ms, 후보 노드가 110 ms라면 차이는 40 ms입니다. tolerance: 80으로 설정한 경우 이 정도 차이만으로는 보통 전환되지 않습니다. 후보 노드가 60 ms가 되어 차이가 90 ms로 벌어지면 설정된 허용 오차를 넘습니다. 실제 선택은 현재 노드의 사용 가능 여부, 유효한 테스트 결과, 코어 구현에도 영향을 받습니다.

단일 수치보다 조정 순서가 중요합니다

1. 먼저 테스트 URL과 네트워크 환경을 고정하고, 노드 테스트가 반복해서 실패하지 않는지 확인하세요.
2. 먼저 50~100밀리초 범위의 허용 오차로 살펴볼 수 있습니다. 이는 설정을 시작하기 위한 기준일 뿐 모든 회선에 맞는 표준은 아닙니다.
3. 후보 노드의 지연 시간이 비슷한데도 자주 전환된다면 허용 오차를 조금 높이세요. 눈에 띄게 빠른 노드가 계속 선택되지 않는다면 지연 시간 차이와 현재 유효한 테스트 결과를 확인하세요.
4. 현재 노드를 사용할 수 없다면 상태 확인과 실패 감지를 우선 점검하세요. 허용 오차는 문제가 있는 노드를 유지하기 위한 설정이 아닙니다.

전환 정책은 보통 새로 생성되는 연결에 적용되며, 기존 TCP 연결이 다른 노드로 끊김 없이 옮겨가지는 않습니다. 한 번 전환한 뒤 기존 다운로드는 느린데 새 웹페이지는 빨라질 수 있으며, 이는 모순이 아닙니다. interval을 1초로 바꿔 계속 테스트하는 것도 권장하지 않습니다. 테스트 자체가 연결과 트래픽을 발생시키며, 너무 잦은 확인은 부하만 늘릴 뿐 실제 회선의 변동을 없애지는 못합니다.

테스트 URL 선택법: 가볍고 안정적이며 용도에 맞는 주소

테스트 URL은 오랫동안 접속할 수 있어야 하고, 응답 본문이 작으며, 로그인이나 단기 서명에 의존하지 않고, 여러 번 리디렉션되지 않는 것이 좋습니다. 전체 동영상 페이지나 대용량 파일, CAPTCHA가 있는 페이지를 상태 확인에 사용하면 페이지 동작을 네트워크 문제로 오인하기 쉽습니다.

https://www.gstatic.com/generate_204는 테스트를 시작할 때 사용할 수 있지만, 모든 네트워크에 적합한 유일한 답은 아닙니다. 특정 출구에서 이 주소에 문제가 생기면 로그와 대상 접속 여부, 응답 상태를 확인한 뒤 다른 안정적인 소용량 응답 엔드포인트로 다시 테스트하세요. 주소 하나에서 실패했다고 모든 서비스가 사용할 수 없다고 단정할 수는 없습니다.

HTTP와 HTTPS 테스트 결과도 한데 섞어 순위를 매기면 안 됩니다. HTTPS에는 보통 TLS 관련 오버헤드가 추가됩니다. 주소를 HTTP로 바꿔 수치가 낮아졌다고 노드 회선이 개선된 것은 아닙니다. 특정 서비스에 가까운 결과가 필요하다면 해당 서비스의 첫 응답을 추가로 확인하되, 로그인 정보가 필요한 서비스 페이지를 전체 그룹의 상시 상태 확인에 직접 사용하지 마세요.

실제 체감 비교: 같은 경로에서 다시 테스트하기

‘지연 시간은 낮은데 웹페이지가 느린’ 문제를 확인할 때는 먼저 테스트 결과와 실제 요청이 같은 출구 노드를 사용하는지 확인한 다음 DNS, 처리량, 대상 서비스 문제를 살펴보세요. 클라이언트 메뉴 이름은 버전에 따라 달라질 수 있으므로, 아래 단계는 특정 버전의 화면 배치가 아닌 기능을 기준으로 안내합니다.

1. 실행 모드 확인: 규칙에 따라 트래픽을 분기해야 한다면 mode: rule인지 확인하고, 다른 프로필이 아니라 방금 수정한 설정이 활성화되어 있는지 확인하세요.
2. 연결 경로 확인: 클라이언트의 연결 목록을 열고 대상 사이트에 접속한 다음 해당 연결에 적용된 규칙, 프록시 그룹, 실제 출구 노드를 확인하세요. 필요하면 로그도 함께 살펴보세요.
3. 노드를 임시로 고정: 직접 선택할 수 있는 프록시 그룹에서 A 노드를 고정해 비교 중 자동 전환을 막으세요. 테스트가 끝나면 기존 정책으로 되돌리세요.
4. 연속 테스트 기록: 같은 네트워크에서 같은 주소를 10회 테스트하고 중앙값, 최댓값, 실패 횟수를 기록하세요. 실패는 별도로 집계하고 0 ms로 간주해 평균에 포함하지 마세요.
5. 실제 서비스 테스트 추가: 같은 사이트에서 같은 파일을 30초간 다운로드하고 속도가 안정된 구간을 기록하세요. 동영상 서비스라면 버퍼링, 탐색 후 재생 재개, 연속 재생 상태를 살펴보세요.
6. 트래픽 처리 방식 별도 확인: TUN에서만 문제가 생긴다면 DNS, 라우팅, UDP 지원 여부를 확인하세요. 시스템 프록시에서 서비스 요청이 연결 목록에 나타나지 않는다면 해당 앱이 시스템 프록시를 따르는지 먼저 확인하세요.

로컬 프록시 포트도 확인해야 합니다. 예를 들어 설정에 mixed-port: 7890이 있다면 테스트 도구는 현재 클라이언트가 실제로 수신 대기 중인 127.0.0.1:7890에 연결해야 합니다. 다른 클라이언트에서 사용하던 7897이나 1080을 일반 포트로 간주하지 마세요. 포트 사용 가능 여부는 적용된 설정과 실제 수신 대기 상태를 기준으로 판단하세요.

비교를 마쳤다면 문제 유형에 따라 대응하세요. 테스트는 안정적인데 대용량 파일이 느리다면 처리량과 혼잡을 먼저 확인하고, 특정 사이트만 느리다면 대상까지의 경로와 규칙을 살펴보세요. 주기적으로 실패한다면 네트워크 변동과 노드 상태를 확인하세요. 지연 시간은 후보를 추리는 데 유용하고, 최종 선택은 실제 서비스 테스트로 판단해야 합니다.

자주 묻는 질문: 시간 초과, 수동 테스트, 자동 선택