네트워크 예상 읽기 시간 12분

Clash 노드 지연 시간 측정 원리: 표시되는 밀리초가 실제 속도와 다른 이유

측정 URL, 핸드셰이크 과정과 측정 기준으로 클라이언트에 표시되는 지연 시간의 의미를 설명하고, 지연 시간이 짧아도 웹이 느리거나 길어도 영상이 원활한 일반적인 원인과 실제 체감에 가까운 자가 측정법을 소개합니다.

지연 시간 수치가 실제로 측정하는 것

Clash 클라이언트에 표시되는 38ms, 126ms, 480ms는 일반적인 ICMP Ping도 아니고 다운로드 속도도 아닙니다. 클라이언트는 보통 Clash 또는 mihomo 코어에 지정한 프록시 노드를 통해 HTTP나 HTTPS 측정 URL에 접속하도록 요청한 뒤, 요청을 시작하고 유효한 응답을 받을 때까지 걸린 시간을 기록합니다. 클라이언트마다 버튼 이름은 ‘지연 시간 측정’, ‘속도 테스트’, ‘상태 확인’ 등으로 다를 수 있지만 핵심 목적은 비슷합니다. 노드 연결 가능 여부를 확인하고 짧은 요청의 왕복 시간을 추정하는 것입니다.

일반적인 측정 주소는 HTTP 204 응답을 반환합니다. 204 응답에는 본문이 없어 전송량이 매우 적고 반복 확인에 적합합니다. 예를 들어 https://www.gstatic.com/generate_204와 https://cp.cloudflare.com/generate_204가 여기에 해당합니다. 응답 본문이 거의 없기 때문에 측정 결과는 주로 연결 설정과 요청 응답 속도를 반영하며, 노드가 100MB 파일을 계속 전송할 때 몇 MB/s를 낼 수 있는지는 보여 주지 못합니다.

한 번의 HTTPS 지연 시간 측정에 포함될 수 있는 단계

  1. Clash가 클라이언트에서 보낸 측정 명령을 받고 프록시 노드를 선택합니다.
  2. 코어가 노드 서버 주소를 해석하고 노드 진입점까지 TCP 또는 다른 전송 연결을 설정합니다.
  3. Shadowsocks, VMess, VLESS, Trojan 또는 기타 프로토콜에 필요한 핸드셰이크를 완료합니다.
  4. 노드를 통해 측정 사이트에 연결하고 대상 사이트와 TCP 및 TLS 핸드셰이크를 완료합니다.
  5. HTTP 요청을 보내고 상태 코드와 응답 헤더가 돌아오기를 기다립니다.
  6. 클라이언트가 전체 소요 시간을 밀리초로 환산해 표시합니다.

구체적인 측정 시작·종료 지점은 클라이언트와 코어 버전에 따라 다릅니다. 매번 새 연결을 만드는 구현도 있고, 상태 확인에서 일부 리소스를 재사용하는 경우도 있습니다. DNS 조회 시간을 포함하는 구현이 있는 반면 DNS 캐시를 사용하는 경우도 있습니다. 따라서 두 클라이언트가 같은 노드를 동시에 측정해도 20~80ms 정도 차이가 나는 것은 드문 일이 아닙니다. 노드 상태를 판단할 때는 같은 기기, 같은 클라이언트, 같은 측정 URL에서 얻은 결과를 우선 비교해야 합니다.

지연 시간이 짧은 노드도 느린 이유

지연 시간이 짧다는 것은 짧은 연결 확인이 빠르다는 뜻일 뿐입니다. 웹 페이지 로딩, 소프트웨어 다운로드, 영상 재생에는 처리량, 패킷 손실, 목적지까지의 경로와 서버 부하도 영향을 줍니다. 측정 요청은 응답 헤더 몇 개만 받으므로 노드 출구 속도가 5Mbps로 제한되어도 50ms 안에 204 요청을 완료할 수 있습니다. 실제 파일을 다운로드하면 5Mbps의 이론상 한도는 약 0.625MB/s이며, 이때 속도 차이가 지속적으로 드러납니다.

노드 대역폭 또는 공유 진입점의 혼잡

프록시 진입점은 보통 여러 사용자가 공유합니다. 저녁 20:00~23:00에는 오전보다 동시 트래픽이 크게 늘 수 있습니다. 노드 지연 시간이 한산할 때 45ms, 혼잡할 때도 58ms 정도로 유지되더라도 다운로드 속도는 18MB/s에서 2.4MB/s로 떨어질 수 있습니다. 작은 요청은 빠르게 대기열을 통과하지만 대용량 트래픽은 출구 대역폭을 계속 나눠 써야 하기 때문입니다.

패킷 손실과 지터는 직접 표시되지 않습니다

클라이언트는 최근에 성공한 측정 결과만 표시하거나 여러 번의 결과 중 하나만 보여 주는 경우가 많습니다. 연속 10회 결과가 52, 54, 55, 53, 410, 시간 초과, 61, 58, 390, 57ms였다고 가정해 보겠습니다. 화면에 마지막 57ms만 남는다면 상당한 지터와 패킷 손실이 숨겨집니다. 웹 페이지에서 동시에 많은 요청을 보내면 재전송이 반복되어 이미지가 나눠서 나타나거나 페이지가 간헐적으로 멈추는 현상으로 이어질 수 있습니다.

측정 사이트와 실제 목적지의 경로가 다릅니다

노드에서 측정 URL까지의 경로가 짧다고 해서 코드 저장소, 동영상 플랫폼, 클라우드 드라이브까지의 경로도 좋다는 뜻은 아닙니다. 측정 사이트에는 로컬 피어링으로 접속해 지연 시간이 35ms에 불과해도, 실제 목적지에는 다른 지역을 우회해 첫 바이트 시간이 900ms에 이를 수 있습니다. 측정 URL은 해당 URL의 상태만 보여 줄 뿐 실제 서비스 검증을 대신할 수 없습니다.

로컬 회선과 기기 부하

지연 시간이 긴 노드도 영상 재생이 원활한 이유

영상 재생은 지속적인 처리량과 버퍼에 의존하며 모든 데이터 조각이 수십 밀리초 안에 돌아오기를 요구하지 않습니다. 지연 시간이 180ms이고 안정적인 속도가 25MB/s인 노드는 지연 시간 45ms, 속도 2MB/s에 불과한 노드보다 버퍼를 더 빠르게 채우는 경우가 많습니다. 재생이 시작된 뒤 다운로드 속도가 영상 비트레이트보다 계속 높다면 지연 시간이 다소 길어도 연속 재생에는 미치는 영향이 제한적입니다.

4K 영상을 예로 들면 평균 비트레이트가 25Mbps일 때 약 3.125MB/s입니다. 노드가 12MB/s를 안정적으로 제공한다면 지연 시간이 220ms에 달해도 재생을 유지할 여유가 충분합니다. 반대로 지연 시간이 30ms여도 저녁 시간대 속도가 1.5~4MB/s 사이에서 오르내리면 버퍼가 자주 소진될 수 있습니다.

인터랙티브 작업과 대용량 작업은 서로 다른 지표를 봅니다

사용 시나리오 더 중요한 지표 일반적인 결과
웹 페이지, 온라인 문서 열기 지연 시간, 첫 바이트 시간, 패킷 손실 지연 시간이 짧으면 여러 작은 요청을 빠르게 완료하는 데 유리합니다
영상 재생 지속 처리량, 지터, 가용 대역폭 지연 시간이 다소 높아도 버퍼링으로 원활한 재생이 가능합니다
대용량 파일 다운로드 지속 속도, 출구 속도 제한, 회선 안정성 시작 후 몇 초간의 최고 속도만으로 평균 속도를 판단할 수 없습니다
원격 터미널, 클라우드 데스크톱 왕복 지연 시간, 지터, 패킷 손실 80ms와 250ms는 조작 반응에서 차이가 뚜렷합니다
음성 통화와 실시간 통신 지연 시간, 지터, UDP 사용 가능 여부 대역폭이 충분해도 지터 때문에 음성이 끊길 수 있습니다

측정 URL이 결과를 바꾸는 방식

측정 주소의 위치, 프로토콜, 응답 상태가 수치에 모두 영향을 줍니다. HTTPS 주소를 선택하면 일반적으로 TLS 연결 설정이 포함되고, HTTP 주소를 선택하면 TLS 단계가 빠집니다. 측정 사이트가 노드 출구와 가까우면 결과가 낮게 나오고, 대륙을 가로지르거나 응답이 혼잡하면 높게 나옵니다. 측정 사이트가 현재 네트워크에서 제한되면 노드 자체가 정상이어도 시간 초과가 표시될 수 있습니다.

측정 URL을 고르는 세 가지 기준

서로 다른 URL에서 얻은 밀리초 수치를 바로 정렬하지 마세요. 예를 들어 노드 A는 아시아 측정 사이트에서 48ms, 노드 B는 유럽 측정 사이트에서 130ms가 나왔다면 공정하게 비교할 수 없습니다. 여러 노드를 일괄 측정할 때는 같은 URL, 같은 시간 초과 설정, 비슷한 측정 시각을 사용해야 합니다.

url-test와 상태 확인 설정 방법

Clash와 mihomo 설정의 url-test 정책 그룹은 후보 노드를 주기적으로 측정하고 현재 지연 시간이 낮은 노드를 선택합니다. 자동 선택에 적합하지만 지속적인 다운로드 속도 측정과는 다릅니다. interval은 확인 주기를 제어하며 단위는 보통 초입니다. tolerance는 지연 시간이 비슷할 때 잦은 전환을 줄이는 데 사용합니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - 구독 서비스
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

이 설정은 300초마다 한 번씩 확인합니다. ‘자동 선택’ 그룹은 새 노드가 10ms만 더 빠르다고 즉시 전환하지 않습니다. tolerance: 80으로 설정하면 차이가 작을 때 현재 노드를 우선 유지해 연결 끊김을 줄일 수 있습니다. 웹 브라우징에서는 밀리초 단위의 추격보다 50~100ms 정도의 허용 오차가 더 실용적인 경우가 많습니다. 실시간 회의 중에는 주기를 10초로 설정하는 것도 권장하지 않습니다. 잦은 측정과 전환으로 불필요한 연결 변화가 생길 수 있기 때문입니다.

프록시 제공자는 상태 확인을 별도로 설정할 수도 있습니다. 다음 조각은 구독 내 노드에 접근할 수 있는지 600초마다 확인합니다:

proxy-providers:
  구독 서비스:
    type: http
    path: ./providers/airport.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

lazy: true는 관련 프록시 제공자를 사용하지 않을 때 능동적인 확인을 줄인다는 뜻이며, 구체적인 동작은 사용하는 코어 버전에 따라 다릅니다. 클라이언트가 그래픽 인터페이스로 설정을 관리하고 있다면 실행 중 생성된 YAML을 직접 편집해도 구독 업데이트 후 덮어써질 수 있습니다. 클라이언트의 오버라이드 또는 병합 설정 기능에서 규칙을 추가하는 것이 좋습니다. 예를 들어 Clash Verge Rev 2.x에서는 일반적으로 ‘설정’ → ‘구독 설정’ → 설정 선택 → ‘전역 확장 설정 편집’ 순서로 진행한 뒤 구독을 다시 불러오고 실행 중인 설정을 확인합니다.

실제 체감에 가까운 측정 방법

노드를 선택할 때는 번개 버튼을 한 번 누르는 대신 측정을 ‘응답 속도’, ‘지속 처리량’, ‘안정성’ 세 그룹으로 나누는 것이 좋습니다. 모든 비교에서 기기, 네트워크, 시간대, 프록시 모드를 고정해야 합니다. Wi-Fi와 유선 네트워크를 섞거나 시스템 프록시와 TUN 모드를 섞어 측정하면 결론을 비교하기 어려워집니다.

첫 단계: 지연 시간을 반복 측정하고 중앙값 확인

  1. Clash Verge Rev 2.x에서 ‘프록시’ → 대상 정책 그룹으로 이동합니다.
  2. 정책 그룹 오른쪽 위의 속도 테스트 버튼을 누르고 그룹 전체의 측정이 끝날 때까지 기다립니다.
  3. 후보 노드를 5~10회 반복 측정하고 매번 약 10초 간격을 둡니다.
  4. 최저값만 기록하지 말고 중앙값, 최고값, 시간 초과 횟수를 기록합니다.

한 그룹의 결과가 68, 71, 69, 74, 70ms라면 중앙값은 70ms이고 변동도 작습니다. 다른 그룹이 42, 45, 310, 시간 초과, 53ms라면 최저값은 더 좋지만 안정성은 떨어집니다. 웹 브라우징과 원격 조작에는 일반적으로 첫 번째 그룹이 더 적합합니다.

두 번째 단계: 순간 최고 속도가 아닌 지속 다운로드 측정

출처가 안정적이고 실제 용도와 거리가 비슷한 100~500MB 테스트 파일을 선택해 최소 30초 동안 계속 다운로드합니다. 시작 후 2~3초의 최고 속도는 제외하고 10초, 20초, 30초 시점의 속도를 기록합니다. 예를 들어 노드 A의 지연 시간은 46ms이고 세 번의 측정값이 8.2, 7.9, 7.8MB/s인 반면, 노드 B는 지연 시간 128ms, 측정값 30.5, 31.4, 30.8MB/s라면 다운로드 작업에는 노드 B가 확실히 적합합니다.

속도 측정은 실제 트래픽을 발생시킵니다. 모바일 네트워크나 종량제 회선에서는 파일 크기를 줄이고 다른 다운로드를 중지해야 합니다. 브라우저 개발자 도구의 ‘네트워크’ 패널에서 요청 소요 시간을 확인할 수 있습니다. Chromium 계열 브라우저에서는 F12를 누른 뒤 ‘네트워크’로 이동하고 대상 요청을 선택해 ‘타이밍’에서 ‘서버 응답 대기’와 ‘콘텐츠 다운로드’ 단계를 확인합니다.

세 번째 단계: 실제 서비스 확인

지연 시간이 비정상일 때 단계별 점검

모든 노드의 지연 시간이 동시에 높아진 경우

먼저 로컬 네트워크를 확인합니다. 실행 중인 클라우드 드라이브 동기화와 시스템 업데이트를 중지하고 유선 연결 또는 5GHz Wi-Fi로 다시 측정하세요. 직접 연결한 웹 페이지도 눈에 띄게 느리다면 문제는 로컬 광대역, 모바일 네트워크 또는 라우터에 있을 가능성이 큽니다. Clash를 재시작하면 프록시 연결을 다시 만들 수 있을 뿐 통신사 회선의 혼잡을 해결할 수는 없습니다.

한 지역의 노드만 높아진 경우

같은 지역의 여러 노드가 동시에 약 80ms에서 300ms로 상승했다면 국제 경로 조정이나 지역 진입점 혼잡일 수 있습니다. 일시적으로 다른 지역을 선택하고 낮 시간과 저녁 혼잡 시간대에 각각 측정해 보세요. 새벽에는 회복되고 저녁마다 다시 높아진다면 클라이언트 설정 오류보다 혼잡의 특징에 가깝습니다.

속도 측정은 시간 초과지만 웹 페이지는 열리는 경우

측정 URL을 바꿔 다시 확인하고 DNS 모드가 정상인지 확인하세요. Fake-IP를 사용하면 측정 도메인이 먼저 예약 주소를 받은 뒤 Clash가 연결 단계에서 도메인을 복원합니다. 규칙이 측정 도메인을 잘못 직접 연결 또는 거부 정책으로 분류하면 측정이 실패할 수 있습니다. 로그에서 대상 도메인, 적용된 규칙, 아웃바운드 노드를 확인하면 요청이 실제로 측정 대상 프록시를 거쳤는지 알 수 있습니다.

지연 시간은 정상인데 일부 웹사이트만 느린 경우

로그에서 해당 웹사이트가 예상한 정책 그룹에 매칭되었는지 확인합니다. Clash 규칙은 위에서 아래로 매칭되며 첫 번째로 일치한 규칙에서 중지됩니다. 대상 웹사이트가 더 앞에 있는 DOMAIN-SUFFIX, GEOSITE, IP-CIDR 규칙에 의해 다른 노드로 분류되었다면 정책 그룹에 표시된 낮은 지연 시간은 실제 연결과 관계가 없습니다. 브라우저에서 별도 프록시, HTTP/3 또는 보안 DNS를 사용 중인지도 확인해 트래픽 경로가 예상과 달라지지 않았는지 점검해야 합니다.

노드 정렬에서는 네 가지 수치를 함께 봐야 합니다

밀리초 하나만으로 사용 불가능한 노드를 빠르게 걸러낼 수는 있지만 모든 사용 시나리오를 결정하기에는 부족합니다. 더 안정적인 기록 방식은 지연 시간 중앙값, 최대 지터, 시간 초과율, 지속 다운로드 속도를 함께 기록하는 것입니다. 예를 들어 노드 A는 72ms, 지터 12ms, 시간 초과율 0%, 평균 14MB/s이고 노드 B는 41ms, 지터 280ms, 시간 초과율 20%, 평균 6MB/s라고 해 보겠습니다. 노드 B의 최저 지연 시간이 더 낮아도 기본 노드로는 대체로 노드 A가 더 적합합니다.

자동 정책 그룹에도 일정한 허용 오차를 두는 것이 좋습니다. 두 노드가 각각 64ms와 71ms라면 7ms 차이는 기존 연결을 전환하는 비용을 상쇄하기에 부족한 경우가 많습니다. 지연 시간 차이가 장기간 안정적으로 유지되거나 처리량과 실제 목적지 체감 품질도 더 좋을 때 전환해야 실질적인 의미가 있습니다. 측정 결과를 1차 필터로 활용하고 실제 작업으로 검증하면 한 번의 측정 결과만으로 정렬하는 것보다 훨씬 신뢰도 높은 노드 선택이 가능합니다.

Clash 클라이언트 다운로드 Windows, macOS 및 모바일 버전 확인