Clash 지연 테스트 수치 보는 법: 표시 지연 시간과 실제 체감이 다른 이유

Clash에 표시되는 지연 시간은 실제로 무엇을 측정할까

클라이언트 노드 목록에 표시되는 45ms, 168ms 또는 timeout은 보통 아주 작은 HTTP 또는 HTTPS 요청에서 나온 결과입니다. Clash 또는 mihomo는 테스트 요청을 지정한 프록시 노드를 통해 보내고, 클라이언트 기본값이나 설정 파일에 지정된 테스트 주소에 접속한 뒤 요청을 시작해 유효한 응답을 받을 때까지 걸린 시간을 기록합니다. 이 수치는 노드가 연결을 수립할 수 있는지와 핸드셰이크가 빠른지를 판단하는 데 유용하지만, 전체 다운로드 속도를 측정한 결과는 아닙니다.

HTTPS 지연 테스트는 대략 로컬 애플리케이션, Clash 인바운드 포트, 프록시 노드, 대상 웹사이트의 네 단계를 거칩니다. 대상 도메인이 아직 해석되지 않았다면 먼저 DNS 조회가 수행됩니다. 새 연결에는 보통 프록시 서버와의 TCP 연결 수립, 프록시 프로토콜 핸드셰이크, 테스트 사이트 접속 시 TCP 및 TLS 핸드셰이크도 포함됩니다. 클라이언트가 연결을 재사용하는지와 DNS 캐시를 활용하는지에 따라 최종 수치가 달라집니다.

1. 클라이언트는 테스트 요청을 현재 자동으로 선택된 다른 노드가 아니라 지정한 노드로 전달합니다.
2. Clash는 Shadowsocks, Trojan, VLESS 또는 커널이 지원하는 다른 프로토콜로 연결을 수립합니다.
3. 프록시 노드는 테스트 URL에 해당하는 서버에 계속 연결합니다.
4. 대상 서버가 HTTP 응답을 반환하면 클라이언트가 이를 바탕으로 소요 시간을 계산합니다.

단순한 네트워크 Ping이 아닙니다

시스템 명령 ping은 ICMP 에코 패킷을 사용하지만 Clash의 URL Test는 일반적으로 실제 HTTP 또는 HTTPS 요청을 사용합니다. 일부 서버는 ICMP를 제한하면서도 프록시 프로토콜과 웹 트래픽은 허용할 수 있고, Ping은 낮지만 프록시 핸드셰이크는 느린 경우도 있습니다. 따라서 서버 Ping 수치를 Clash에 표시될 지연 시간으로 그대로 볼 수는 없습니다.

같은 노드가 두 클라이언트에서 70ms와 130ms로 표시되더라도 반드시 커널 문제인 것은 아닙니다. 먼저 테스트 URL, 타임아웃, HTTPS 사용 여부, 연결 재사용 여부, 테스트 당시 로컬 네트워크가 같은지 확인해야 합니다. 휴대폰은 5G, 컴퓨터는 유선 인터넷을 사용했다면 두 결과를 직접 비교하기 어렵습니다.

URL Test 경로와 자동 선택 로직

url-test는 Clash 프록시 그룹 유형 중 하나입니다. 그룹에 포함된 노드를 주기적으로 테스트하고, 그중 현재 측정값이 낮으면서 사용 가능한 노드를 선택합니다. 흔히 204 상태를 빠르게 반환하는 주소를 사용해 응답 본문이 측정에 미치는 영향을 줄입니다. 다음은 읽기 쉬운 예시입니다.

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

interval: 300은 테스트 간격이 300초, 즉 5분이라는 뜻입니다. 간격을 짧게 설정한다고 항상 좋은 것은 아닙니다. 10초로 설정하면 불필요한 연결과 로그가 늘고 순간적인 변동 때문에 노드가 자주 바뀔 수 있습니다. 일반적인 사용 환경에서는 300~600초부터 시작하고, 모바일 네트워크처럼 변화가 큰 경우에만 적절히 줄이는 것이 좋습니다.

tolerance: 50은 전환 민감도를 조절합니다. 현재 노드가 120ms이고 다른 노드가 92ms라면 차이는 28ms에 불과하므로 즉시 바꿀 필요가 보통 없습니다. 새 노드가 60ms까지 낮아져 차이가 60ms가 되면 전환의 실익이 커집니다. 허용 오차를 두면 80ms, 95ms, 110ms 사이를 반복적으로 오가며 연결이 끊기는 현상을 줄일 수 있습니다.

테스트 URL에 따라 결과가 달라집니다

테스트 대상이 프록시 출구에서 멀수록 결과는 대체로 높아집니다. 도쿄 출구에서 도쿄 인근 테스트 서버에 접속하면 35ms 정도일 수 있지만, 유럽 대상에 접속하면 220ms를 넘을 수도 있습니다. 일상적으로 주로 사용하는 서비스가 있다면 안정적이고 응답 본문이 작으며 실제 경로를 어느 정도 대표하는 HTTPS 주소를 선택할 수 있습니다. 단, 해당 주소가 장기간 정상적으로 접근 가능한지 확인해야 합니다.

• 테스트 주소 안정성: 대상 사이트에 속도 제한이 걸리거나 장애가 발생하면 모든 노드가 timeout으로 표시될 수 있습니다.
• HTTP와 HTTPS: HTTPS는 TLS 연결 수립 비용까지 반영하므로 일반적인 웹 접속에 더 가깝습니다.
• DNS 해석 경로: nameserver, fake-ip 또는 redir-host 설정이 다르면 최초 테스트 시간도 달라질 수 있습니다.
• 출구 위치: 같은 프록시 노드라도 지역이 다른 대상에 접속하면 경로 길이와 혼잡도가 달라집니다.
• 캐시 상태: 첫 테스트에는 DNS와 핸드셰이크 비용이 포함될 수 있지만, 바로 이어지는 두 번째 테스트는 더 낮게 측정될 수 있습니다.

수십 ms 노드에서도 영상이 끊기는 이유

영상 재생은 지속적인 처리량에 의존하지만 지연 테스트는 아주 적은 데이터만 전송합니다. 노드가 45ms 안에 작은 요청을 처리하더라도 지속 대역폭은 2Mbps에 그칠 수 있습니다. 약 15Mbps 비트레이트가 필요한 4K 영상을 재생하면 버퍼가 소모되는 속도가 다운로드 속도보다 빨라져 자주 멈춥니다. 반대로 180ms이지만 80Mbps를 안정적으로 전송하는 노드는 페이지를 처음 여는 속도는 느려도 대용량 파일이나 영상에는 더 적합할 수 있습니다.

지연 시간·대역폭·패킷 손실·지터는 서로 다른 네 가지 지표입니다

예를 들어 어떤 노드의 연속 5회 테스트 결과가 48, 52, 51, 49, 55ms라면 평균은 약 51ms이고 변동도 작습니다. 다른 노드의 결과가 35, 280, 62, 410, 44ms라면 최저값은 35ms지만 지터가 매우 큽니다. 노드 목록에 최근 측정값 35ms만 표시되면 이후 요청이 자주 느려지는 문제를 가릴 수 있습니다.

패킷 손실은 특히 TCP 전송에서 뚜렷하게 나타납니다. TCP는 데이터가 도착하지 않은 것을 확인하면 재전송하고 혼잡 윈도 크기를 줄일 수 있습니다. 기본 왕복 지연이 60ms에 불과해도 2~5%의 패킷 손실이 지속되면 다운로드 속도 그래프가 톱니 모양으로 출렁일 수 있습니다. UDP 음성이나 게임 트래픽은 일반적으로 완전한 재전송을 기다리지 않으므로 음성이 끊기거나 위치 업데이트가 늦어지고 화면이 갑자기 튀는 식으로 나타납니다.

서버 부하와 시간대별 회선 상태도 중요합니다

프록시 서버의 CPU, 메모리, 연결 수 또는 상위 회선 대역폭이 한계에 가까워져도 작은 탐색 요청은 빠르게 반환될 수 있지만 대용량 전송은 제한됩니다. 저녁 20:00~23:00에는 통신사 간 혼잡도 흔합니다. 낮에는 70ms였던 결과가 저녁에는 90~400ms 사이에서 오르내릴 수 있습니다. 오전에 한 번 측정한 결과만으로 저녁의 실제 체감 품질을 판단할 수는 없습니다.

대상 서비스가 출구 주소별로 트래픽을 분배하는 방식도 속도에 영향을 줍니다. 같은 노드에서 테스트 URL은 빠르게 열리지만 영상 서비스에서는 멀리 있는 CDN으로 연결될 수 있고, 일부 출구는 대상 사이트의 속도 제한을 받을 수도 있습니다. 이 경우 문제는 사용자 기기와 프록시 서버 사이가 아니라 프록시 출구와 대상 서비스 사이에서 발생했을 가능성이 있습니다.

재현 가능한 단계로 실제 체감 품질 판단하기

더 신뢰할 수 있는 방법은 절대적으로 가장 낮은 수치를 찾는 것이 아니라 같은 기기, 같은 네트워크, 같은 시간대에 여러 차례 결과를 비교하는 것입니다. 테스트 전에는 클라우드 동기화, 시스템 업데이트, 대용량 다운로드를 일시 중지해 백그라운드 트래픽이 대역폭을 차지하지 않게 하세요. 휴대폰으로 테스트할 때는 Wi-Fi 또는 모바일 네트워크 중 하나를 고정하고 자동 전환을 피해야 합니다.

1단계: 지연 시간을 연속 5회 측정

1. 클라이언트의 프록시 또는 노드 페이지를 열고 비교할 프록시 그룹을 찾습니다.
2. 테스트 URL을 그대로 유지한 채 약 10초 간격으로 5회 연속 실행합니다.
3. 최저값, 최고값, 대략적인 평균을 기록하고 마지막 결과만 보지 않습니다.
4. 5회 결과가 각각 82, 87, 79, 91, 84ms라면 비교적 안정적이라고 볼 수 있습니다. 반면 60, 320, 75, timeout, 180ms라면 지터와 패킷 손실을 먼저 점검해야 합니다.

그래픽 클라이언트마다 메뉴 이름은 다르지만 보통 「프록시」→「프록시 그룹」→「지연 시간 테스트」에서 테스트 메뉴를 찾을 수 있습니다. 일부 클라이언트는 「설정」→「매개변수 설정」에서 테스트 URL과 타임아웃을 제공합니다. 변경하기 전에 기존 값을 기록해 두어야 접근할 수 없는 주소 때문에 모든 노드가 실패로 표시되는 일을 피할 수 있습니다.

2단계: 지속 처리량 테스트

지연 시간이 안정적인 노드 2~3개를 선택해 각각 최소 30초 동안 실제 다운로드 또는 영상 재생을 진행합니다. 처음의 일시적인 최고 속도가 아니라 안정적으로 유지되는 속도를 관찰해야 합니다. 예를 들어 다운로드 속도가 처음에는 18MB/s까지 치솟았다가 5초 후 장시간 1.2MB/s에 머문다면 이 노드의 지속 처리량은 1.2MB/s에 가깝습니다. 비교할 때는 같은 파일과 같은 시간대를 사용하고, 여러 스레드 작업이 서로 대역폭을 빼앗지 않도록 해야 합니다.

영상이 주된 용도라면 고정된 해상도의 콘텐츠를 각각 재생하고 60초 동안 버퍼가 계속 늘어나는지 확인하세요. 1080p 영상의 필요한 비트레이트는 인코딩 방식과 콘텐츠에 따라 달라지므로 단순히 ‘재생된다’는 사실만으로 판단할 수 없습니다. 4K 콘텐츠는 지속 처리량과 회선 안정성을 더 많이 요구합니다. 테스트 중 노드를 자주 수동 전환하면 기존 연결이 끊기므로 매 라운드를 독립적으로 완료해야 합니다.

3단계: 사용 목적에 따라 선택

• 웹 브라우징: 지연 시간이 안정적이고 핸드셰이크가 빠른 노드를 우선 선택하되, 대역폭은 평소 사용량을 충족하면 됩니다.
• 영상 및 다운로드: 지속 처리량과 저녁 피크 시간대의 안정성을 우선 비교하고, 최저 지연 시간에 집착할 필요는 없습니다.
• 음성 통화 및 게임: 패킷 손실, 지터, UDP 사용 가능 여부를 중점적으로 확인해야 하며 평균 지연 시간은 여러 지표 중 하나일 뿐입니다.
• 원격 터미널: 상호작용이 왕복 지연 시간에 민감하므로 연속 테스트에서 변동이 작은 회선을 선택해야 합니다.
• 모바일 네트워크: 엘리베이터, 지하철, 기지국 전환에 따라 결과가 크게 달라지므로 실제 사용할 장소에서 테스트해야 합니다.

TUN 모드, DNS, 로컬 네트워크가 결과에 미치는 영향

TUN 모드는 더 많은 시스템 트래픽을 가로채지만 프록시 서버의 대역폭을 자동으로 높여 주지는 않습니다. TUN을 활성화하면 애플리케이션 트래픽이 기존 시스템 프록시 경로에서 가상 네트워크 어댑터 경로로 바뀔 수 있고, DNS 하이재킹, 라우팅 테이블, MTU, 방화벽 규칙도 함께 작동합니다. 따라서 활성화 전후의 지연 차이는 로그와 실제 연결 경로를 함께 확인해 판단해야 하며, 단순히 커널 성능 탓으로 돌릴 수 없습니다.

먼저 로컬 Wi-Fi 지터를 배제하세요

로컬 라우터 자체가 불안정하면 모든 노드가 영향을 받습니다. 먼저 유선 연결과 Wi-Fi를 비교하거나 기기를 라우터 가까이 옮겨 테스트해 보세요. 2.4GHz 대역은 혼잡한 환경에서 간섭을 받기 쉽고, 5GHz는 일반적으로 가까운 거리에서 높은 처리량을 내기에 적합하지만 벽을 통과할 때 감쇠가 더 큽니다. 모든 노드가 동시에 80ms에서 500ms로 상승했다면 구독을 즉시 바꾸기보다 로컬 연결부터 확인해야 합니다.

느린 DNS는 최초 연결을 지연시킵니다

서버 주소나 테스트 주소로 도메인을 사용할 때 DNS 조회 속도는 최초 연결에 영향을 줍니다. 해석 결과가 비정상적이거나 상위 DNS가 타임아웃되면 클라이언트가 실제 프록시 핸드셰이크를 시작하기 전에 수 초 동안 대기할 수 있습니다. Clash의 fake-ip 모드는 도메인에 예약 주소를 할당하고 내부에서 실제 도메인과 매핑하지만, 최종적인 상위 DNS 해석과 프록시 출구 연결은 여전히 정상적으로 완료되어야 합니다.

문제를 점검할 때 mihomo 로그에 DNS timeout, connection refused 또는 i/o timeout이 반복해서 나타나는지 확인할 수 있습니다. 특정 테스트 도메인만 실패한다면 안정적인 소용량 응답 주소로 바꿔 비교하고, 모든 도메인이 실패한다면 nameserver, 네트워크 권한, 시스템 시간을 확인하세요. TLS 인증서 검증에는 정확한 시간이 필요하므로 시스템 날짜가 크게 어긋나면 HTTPS 테스트가 바로 실패할 수 있습니다.

MTU 문제는 대용량 트래픽에서만 드러날 수 있습니다

작은 지연 요청이 성공했다고 해서 큰 데이터 패킷도 반드시 정상이라는 뜻은 아닙니다. TUN, VPN 중첩 또는 특수한 인터넷 환경에서는 MTU 설정이 맞지 않아 조각화나 블랙홀 문제가 발생할 수 있습니다. 작은 웹 요청은 되지만 대용량 파일 전송은 멈추는 식입니다. TUN을 활성화한 뒤 대용량 트래픽에서만 문제가 생긴다면 TUN을 끈 시스템 프록시 모드와 비교하고, 클라이언트의 MTU 설정, 시스템에서 다른 VPN이 동시에 실행 중인지, 라우팅이 중복으로 트래픽을 가로채고 있지 않은지 확인하세요.

흔한 오판과 설정 권장 사항

오판 1: 지연 시간이 가장 낮은 노드가 반드시 가장 빠르다

최저 지연 시간은 특정 짧은 요청이 더 빨리 완료되었다는 뜻일 뿐입니다. 영상이나 다운로드용 노드를 선택할 때는 최소 한 번 30~60초 동안 지속 처리량을 테스트해야 합니다. 노드 간 지연 차이가 20ms여도 안정적인 속도가 40Mbps 차이 난다면 대용량 작업에서는 후자가 보통 더 중요합니다.

오판 2: 한 번의 timeout만으로 노드가 고장 났다고 판단한다

한 번의 타임아웃은 테스트 사이트 장애, DNS 조회 실패, 로컬 네트워크 전환 또는 순간적인 혼잡 때문에 발생할 수 있습니다. 3~5회 연속 테스트하고 다른 테스트 URL과 비교해야 노드 장애와 테스트 대상 장애를 구분할 수 있습니다. 특정 노드 하나만 계속 실패한다면 노드 주소, 포트, 프로토콜 매개변수, 구독 업데이트 시점을 확인하세요.

오판 3: 테스트 간격을 짧게 설정할수록 정확하다

간격이 지나치게 짧으면 요청량이 늘고 자동 그룹이 순간적인 변화에 과민하게 반응합니다. 일반 가정용 네트워크에서는 300초 간격과 30~100ms 허용 오차로 시작한 뒤 노드 수와 사용 환경에 맞게 조정할 수 있습니다. 실시간 서비스에서 안정적인 연결이 중요하다면 자동 그룹이 자주 전환되지 않도록 하세요. 기존 TCP 세션은 보통 새 노드로 자연스럽게 이전되지 않습니다.

오판 4: TUN을 켜면 모든 끊김 문제가 해결된다

TUN의 주된 역할은 트래픽 가로채기 범위를 넓히는 것으로, 시스템 프록시를 따르지 않는 애플리케이션에 적합합니다. 회선 가속 스위치는 아닙니다. 서버 혼잡, 출구 속도 제한, 원격 CDN 라우팅 문제는 TUN을 켠다고 자동으로 사라지지 않습니다. 먼저 트래픽이 Clash로 들어오지 않는 것인지, 이미 프록시를 통과하지만 전송 품질이 낮은 것인지 확인한 뒤 모드 조정 여부를 결정해야 합니다.

실제 체감에 가까운 결론

Clash 지연 수치를 볼 때는 ‘현재 노드가 지정된 URL의 작은 요청 하나를 완료하는 데 걸린 시간’으로 이해하면 됩니다. 연결할 수 없거나 핸드셰이크가明显하게 느린 노드를 빠르게 걸러내고 url-test 자동 선택의 근거로 삼을 수 있지만, 영상이 원활한지, 다운로드 속도가 얼마나 나오는지, 게임이 안정적인지까지 단독으로 판단할 수는 없습니다.

실제로 노드를 선택할 때는 먼저 5회 지연 테스트의 변동 폭을 보고, 다음으로 30~60초 지속 처리량을 확인한 뒤, 마지막으로 자주 사용하는 시간대에 대상 서비스로 검증하세요. 웹 브라우징과 원격 터미널은 안정적인 낮은 지연 시간을, 영상과 다운로드는 지속 대역폭을 더 중요하게 봅니다. 게임과 통화는 패킷 손실, 지터, UDP 경로도 확인해야 합니다. 항목을 나누어 측정해야 ‘수십 ms로 표시되는데도 끊기는’ 진짜 원인을 설명할 수 있습니다.

모든 노드가 동시에 느려졌다면 로컬 Wi-Fi, 테스트 URL, DNS, 시스템 시간, 저녁 피크 시간대 혼잡 순서로 확인하세요. 특정 노드만 이상하다면 해당 노드의 서버 부하, 출구 라우팅, 프로토콜 설정을 점검해야 합니다. 이 순서대로 확인하는 편이 지연 시간을 반복해서 새로 고치거나 무작정 모드를 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.