Clash 속도 측정값과 실제 체감이 다른 이유: url-test 지연 시간 측정 원리

Clash 지연 시간: 한 번의 요청을 측정할 뿐, 다운로드 속도는 아닙니다

노드 옆에 표시되는 ‘80 ms’는 보통 해당 프록시를 거쳐 HTTP 또는 HTTPS 요청을 한 번 보낸 뒤 응답을 받기까지 걸린 시간입니다. ms는 밀리초로 요청 한 번의 소요 시간을 나타내고, MB/s는 초당 전송하는 메가바이트 수로 지속적인 전송 성능을 나타냅니다. 둘 사이에 연관성은 있지만 서로 환산할 수는 없습니다. 80 ms라는 수치만 보고 다운로드 속도가 8 MB/s라고 추측할 수는 없습니다.

Clash 설정의 url-test는 프록시 그룹을 자동으로 선택하는 방식 중 하나입니다. 후보 프록시로 지정된 테스트 주소에 요청을 보내고, 결과에 따라 프록시를 선택합니다. 클라이언트 화면의 ‘속도 측정’ 버튼도 코어의 지연 시간 측정 기능을 호출할 수 있지만, 버튼에서 사용하는 주소와 시간 제한은 자동 선택 그룹의 설정과 다를 수 있습니다.

아래 내용은 Clash Meta와 이후 mihomo라는 이름으로 이어진 버전에도 적용됩니다. 클라이언트마다 화면 구성, 코어 버전, 테스트 매개변수가 다를 수 있습니다. 여러 노드를 비교하기 전에 테스트 주소와 네트워크 환경, 측정 시간을 통일하세요.

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

시스템 명령어 ping과는 다릅니다

시스템의 ping은 보통 ICMP 에코 패킷을 보냅니다. 반면 Clash의 URL 테스트는 프록시를 통해 웹 주소에 접속합니다. 프록시 서버가 ICMP에는 응답하지 않아도 웹 요청은 전달할 수 있습니다. 반대로 서버의 ping 값이 매우 낮더라도 프록시 출구에서 대상 웹사이트까지 빠르다는 뜻은 아닙니다.

새 HTTPS 테스트는 로컬에서 프록시 진입점까지 연결하고, 프록시 프로토콜 핸드셰이크를 수행한 뒤, 출구에서 테스트 사이트에 연결하고 TLS 핸드셰이크를 하는 과정이 포함될 수 있습니다. TLS는 HTTPS에서 암호화 통신을 설정하는 프로토콜입니다. DNS 조회, 연결 재사용, 프로토콜 구현도 결과에 영향을 줍니다. 표시된 값을 단순히 ‘내 컴퓨터와 노드 서버 사이의 왕복 지연 시간’으로 해석하면 안 됩니다.

1. 프록시 진입점에 연결: 가정용 인터넷, Wi-Fi 간섭, 통신사 라우팅, 진입점 혼잡이 모두 이 구간에 영향을 줄 수 있습니다.
2. 프록시 연결 설정: 프로토콜과 전송 계층, 기존 연결을 재사용할 수 있는지에 따라 연결 설정에 드는 시간이 달라집니다.
3. 테스트 주소에 접속: 프록시 출구에서 테스트 사이트까지의 경로, 사이트의 응답 속도, 도메인 조회 결과가 모두 최종 결과에 영향을 줄 수 있습니다.
4. 테스트 결과 반환: 코어는 요청 한 번에 걸린 시간을 기록합니다. 구체적인 측정 구간은 구현 방식에 따라 달라지므로, 수치를 정해진 몇 단계의 핸드셰이크 시간으로 나누어 해석하는 것은 적절하지 않습니다.

204 응답 주소를 자주 사용하는 이유

HTTP 상태 코드 204는 요청이 성공했지만 응답 본문은 없다는 뜻입니다. 전송량이 적어 프록시가 작동하는지 자주 확인하기에 적합합니다. 다만 대용량 파일 전송이 거의 없으므로 회선의 지속 처리량을 측정할 수 없고, 동영상을 10분 동안 재생했을 때 안정적인지도 알 수 없습니다.

첫 테스트와 이후 테스트는 DNS 캐시, 연결 재사용, 서버 캐시 상태의 영향을 받을 수도 있습니다. 한 번 측정한 최저값만 기록하지 마세요. 여러 차례 연속으로 측정한 뒤 값의 변동 폭과 실패 횟수를 함께 확인해야 실제 사용 환경에 더 가까운 결과를 얻을 수 있습니다.

지연 시간은 낮은데 느린 이유: 흔한 원인 5가지

1. 짧은 요청은 빠르지만 지속 대역폭이 부족한 경우

한 회선이 짧은 요청에는 약 60 ms 만에 응답해도 실제 처리량은 2 Mbps에 불과할 수 있습니다. 십진법으로 대략 계산하면 3 MB 파일을 다운로드하는 데 추가 오버헤드를 제외하고도 약 12초가 걸립니다. 반면 지연 시간이 160 ms인 다른 회선이 50 Mbps를 지속적으로 전송할 수 있다면 큰 이미지나 동영상은 오히려 더 원활하게 이용할 수 있습니다.

Mbps는 초당 메가비트, MB/s는 초당 메가바이트를 뜻하며, 수치상 약 8배 차이가 납니다. 예를 들어 40 Mbps는 이론상 약 5 MB/s입니다. 클라이언트와 브라우저, 속도 측정 사이트의 결과를 비교할 때는 먼저 단위를 확인하세요.

2. 테스트 주소는 빠르지만 대상 웹사이트로 가는 경로가 다른 경우

테스트 사이트는 CDN을 통해 제공될 수 있습니다. CDN은 요청을 특정 엣지 서버로 전달하는 콘텐츠 전송 네트워크입니다. 프록시가 해당 엣지 서버에는 빠르게 접속하더라도 다른 지역의 동영상 사이트, 코드 저장소, 게임 서버까지 빠르다는 보장은 없습니다.

따라서 ‘노드 A는 70 ms, 노드 B는 130 ms’라는 결과는 측정 당시 해당 테스트 주소에 접속했을 때의 성능만 보여줍니다. 주로 코드를 다운로드한다면 실제 저장소를 추가로 테스트하고, 동영상을 주로 본다면 대상 플랫폼에서 버퍼링 속도와 해상도, 프레임 드롭을 확인하세요.

3. 간헐적인 패킷 손실과 저녁 시간대 혼잡

단 한 번의 테스트가 마침 혼잡을 피하면 보기 좋은 수치가 나올 수 있습니다. 하지만 장시간 연결 중 패킷 손실이 발생하면 재전송이나 속도 저하가 생기고, 연결을 다시 설정해야 할 수도 있습니다. 연속 측정 결과가 65, 68, 72, 980 ms에 시간 초과 1회라면 문제는 ‘평균 지연 시간이 약간 높다’가 아니라 안정성이 부족하다는 것입니다.

오후 8시의 회선 사용량은 오전 10시와 완전히 다를 수 있습니다. 실제로 사용하는 시간대에 비교하고, 이른 아침에 한 번 측정한 결과를 저녁 시간대의 체감 성능 대신으로 삼지 마세요.

4. 실제 트래픽이 테스트한 노드를 통과하지 않는 경우

규칙 모드는 규칙과 정책 그룹에 따라 출구를 결정합니다. ‘자동 선택’ 그룹을 테스트했더라도 대상 도메인이 다른 그룹에 매칭되거나 DIRECT, 즉 직결로 연결될 수 있습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 영향을 줍니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하지만, 실제로 적용되는 범위는 라우팅과 제외 설정에 따라 달라집니다.

클라이언트의 ‘연결’ 페이지에서 대상 도메인을 찾아 매칭된 규칙과 정책 체인, 최종 노드를 확인하세요. 노드를 바꿨는데도 달라지지 않는 이유를 파악하는 데 속도 측정 버튼을 계속 누르는 것보다 효과적입니다. 요청 기록이 보이지 않는다면 앱이 프록시를 사용하는지, 연결 기록의 필터 조건이 적절한지도 확인하세요.

5. DNS, 앱 또는 기기 때문에 페이지가 느린 경우

웹페이지는 도메인 하나만 요청하는 것이 아니라 이미지와 스크립트, 로그인 API도 불러올 수 있습니다. 특정 도메인의 DNS 조회가 느리거나 확장 프로그램이 간섭하거나 기기의 CPU 사용량이 지나치게 높으면 페이지가 버벅일 수 있습니다. 짧은 URL 테스트로는 이런 문제를 확인할 수 없습니다. 동영상 버퍼가 충분한데도 계속 끊긴다면 노드만 바꾸지 말고 하드웨어 디코딩과 기기 부하도 점검하세요.

url-test 설정: 주소, 간격, 허용 오차의 의미

다음은 mihomo 프록시 그룹 설정 예시이며, 설정에 ‘홍콩01’과 ‘일본01’이라는 프록시가 이미 정의되어 있다고 가정합니다. 기존 YAML에 합칠 때는 원래 노드 정의와 다른 정책 그룹을 유지하고, 규칙에서 이 그룹을 실제로 참조하도록 설정하세요. YAML은 들여쓰기로 계층을 표현하므로 공백 대신 Tab을 사용하지 마세요.

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

tolerance: 50은 테스트 결과에 50 ms를 더하거나 빼는 설정도, 지연 시간이 50 ms 이하임을 보장하는 설정도 아닙니다. 자동 선택에서 노드를 전환할지 판단하는 데 영향을 줍니다. 실제 동작은 현재 프록시 상태와 테스트 성공 여부, 코어 구현에 따라서도 달라지므로 고정된 두 수치만으로 매번 어떤 노드가 선택될지 예측할 수는 없습니다.

구독을 업데이트하면 직접 수정한 프록시 그룹 설정이 덮어쓰여질 수 있습니다. 장기간 설정을 유지하려면 클라이언트에서 제공하는 덮어쓰기 또는 설정 병합 기능을 우선 사용하고, 최종 적용된 설정을 확인하세요. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있으므로 편집기에 저장된 내용만 확인해서는 안 됩니다.

10분 안에 비교 가능한 테스트 결과 만들기

한 번에 모든 노드를 테스트할 필요는 없습니다. 먼저 사용 지역에 적합한 후보 노드 2~3개를 선택한 다음, 동일한 절차로 비교하세요. 아래 수치는 판단 방법을 설명하기 위한 예시이며 이 사이트에서 직접 측정한 결과가 아닙니다.

1. 환경 통일: 같은 기기와 네트워크를 사용하고 대용량 파일 동기화는 일시 중지하세요. 현재 시스템 프록시와 TUN 중 어떤 모드인지, 실제로 어떤 정책 그룹을 사용하는지도 기록하세요.
2. 출구 확인: ‘연결’ 페이지에서 대상 요청을 열고 최종 노드를 확인하세요. 노드를 직접 선택할 때는 대상 규칙이 실제로 매칭되는 정책 그룹에서 선택해야 합니다.
3. 반복 측정: 같은 테스트 주소로 노드마다 5회씩, 약 5~10초 간격으로 측정하세요. 최저값만 기록하지 말고 중앙값과 최고값, 시간 초과 횟수도 적어 두세요.
4. 처리량 추가 확인: 같은 출처의 대용량 파일을 30~60초 동안 다운로드하고 속도가 안정된 구간을 확인하세요. 브라우저 캐시에서 파일을 바로 읽어 오지 않는지 확인하고 구독 데이터 사용량도 살펴보세요.
5. 실제 서비스로 검증: 평소 사용하는 웹사이트를 열거나 같은 해상도의 동영상을 3분간 재생하세요. 마지막으로 주로 사용하는 시간대에 한 번 더 측정하세요.

음성 통화나 원격 조작 같은 대화형 작업에서는 지연 시간과 지터가 중요합니다. 동영상과 대용량 파일은 지속 처리량에 더 크게 좌우됩니다. 게임은 UDP 경로를 별도로 확인해야 합니다. HTTP 테스트에 성공했다고 UDP를 사용할 수 있는 것은 아니며, 게임 내 지연 시간 측정을 대신할 수도 없습니다.

이상 수치와 자동 선택: 증상별 점검 방법

timeout, 음수 또는 빈 값이 표시되는 경우

대개 테스트 실패, 유효한 결과 미수신, 결과 미갱신을 의미하며 구체적인 표시는 클라이언트에 따라 다릅니다. 노드를 전혀 사용할 수 없다는 뜻은 아닙니다. 테스트 주소에 접속할 수 없거나 시간 제한이 너무 짧거나 프록시 프로토콜 설정이 맞지 않을 수도 있습니다. 먼저 실제로 사용하는 웹사이트를 직접 열어 보고, 클라이언트 로그에서 연결 오류를 확인하세요. 로그를 공유하기 전에는 구독 링크와 토큰, 노드 인증 정보를 가리세요.

0 ms로 표시되면 속도가 매우 빠르다는 뜻일까요?

그렇게 판단할 수 없습니다. 0은 반올림이나 화면의 초기값, 일시적인 이상 결과일 수 있으므로 클라이언트 구현에 따라 확인해야 합니다. 다시 측정하고 실제 요청이 어떤 출구를 거쳤는지, 얼마나 걸렸는지 살펴보세요. 지역 간 프록시에서 0 ms가 계속 고정되어 표시된다면 테스트가 실제로 실행되는지 특히 확인해야 합니다.

자동 선택이 늘 ‘수치는 가장 낮지만 사용하기 불편한’ 노드를 고르는 경우

url-test는 주로 측정된 지연 시간을 기준으로 작동하며, 동영상 버퍼링이나 대역폭 제한, 서비스 지역 제한, 트래픽 배율을 자동으로 파악하지는 않습니다. 먼저 후보를 좁혀 실제 서비스에서 검증을 마친 노드만 남긴 다음 자동 선택에 맡기세요. 출구 지역을 고정해야 하는 서비스는 여러 지역을 하나의 자동 그룹에 섞지 말고 별도의 정책 그룹으로 설정하세요.

전역 모드로 바꾸면 더 빨라질까요?

전역 모드는 트래픽을 선택하는 방식을 바꿀 뿐 회선 대역폭을 직접 늘리지는 않습니다. 분할 라우팅 규칙이 결과에 영향을 주는지 확인하려고 잠시 전환해 볼 수는 있지만, 테스트가 끝나면 원래 규칙 모드로 되돌리고 ‘연결’ 페이지에서 출구를 확인하세요. 시스템 프록시와 TUN도 단순한 ‘속도 설정’이 아닙니다. 앱의 트래픽을 가로채야 하는지에 따라 선택해야 합니다.