Clash 노드 지연 시간 테스트 원리: 패널의 밀리초가 실제 속도와 다른 이유

패널의 밀리초는 무엇을 측정할까

Clash, Clash Meta(현재는 주로 mihomo라고 부름)와 제어 인터페이스를 호출하는 그래픽 클라이언트는 일반적으로 노드 테스트 결과를 밀리초 단위로 표시합니다. 이 수치는 흔히 ‘지연 시간’ 또는 ‘속도 테스트’라고 불리지만, 기존 명령줄 도구가 서버에 수행하는 ICMP Ping도 아니고 노드의 가용 대역폭을 종합적으로 측정한 값도 아닙니다. 지정한 프록시 노드를 통해 HTTP 요청 하나를 완료하는 데 걸린 시간에 가깝습니다.

테스트가 시작되면 클라이언트 또는 커널은 선택한 프록시 노드를 사용해 테스트 URL에 접속합니다. 이 과정에는 프록시 서버 연결, 프로토콜 핸드셰이크, 대상 사이트로의 외부 연결, TLS 핸드셰이크, HTTP 요청 전송과 응답 헤더 수신이 포함될 수 있습니다. 커널 버전, 테스트 주소의 프로토콜, 연결 재사용 여부에 따라 측정 범위가 달라지므로 같은 노드를 테스트해도 두 클라이언트가 완전히 같은 결과를 표시한다고 보장할 수 없습니다.

일반적인 지연 시간 테스트의 요청 경로

1. 클라이언트가 mihomo 제어 인터페이스에 노드 지연 시간 테스트를 요청합니다.
2. 커널이 로컬에서 노드 서버에 연결합니다. 예를 들어 서버의 TCP 또는 UDP 수신 포트에 연결합니다.
3. 커널이 Shadowsocks, Trojan, VLESS, Hysteria2 또는 기타 프록시 프로토콜에 필요한 핸드셰이크를 완료합니다.
4. 노드 서버가 외부 네트워크를 통해 테스트 URL에 해당하는 대상 서버에 연결합니다.
5. URL이 HTTPS를 사용하면 TLS 핸드셰이크를 수행하고 인증서도 확인합니다.
6. 대상 서버가 HTTP 응답을 반환하면 커널이 측정을 중지하고 밀리초 값을 클라이언트에 전달합니다.

따라서 패널에 표시된 80ms를 ‘내 컴퓨터와 노드 사이의 물리적 왕복 지연 시간이 80ms’라고 바로 해석할 수는 없습니다. 노드에서 테스트 사이트까지의 경로와 애플리케이션 계층 핸드셰이크가 포함될 수 있기 때문입니다. 반대로 220ms가 표시되더라도 다운로드 속도가 반드시 느리다는 뜻은 아닙니다. 회선 대역폭이 충분하고 패킷 손실이 적으며 혼잡 제어가 안정적이라면 단일 연결 다운로드에서도 높은 처리량을 낼 수 있습니다.

시스템 Ping과의 차이

ping은 일반적으로 ICMP Echo 패킷을 보내 대상 호스트가 응답하기까지 걸리는 왕복 시간을 측정합니다. 많은 프록시 서버는 ICMP를 제한하거나 전혀 응답하지 않지만, 프록시 포트는 TCP 또는 UDP 트래픽을 정상적으로 받을 수 있습니다. 서버에 따라 ICMP 경로에 다른 라우팅이나 우선순위가 적용되기도 하므로 명령줄 Ping이 45ms이고 Clash 패널이 110ms로 표시되어도 모순이 아닙니다.

HTTP 지연 시간 테스트는 일상적인 웹 요청에 더 가깝지만 여전히 매우 작은 표본일 뿐입니다. 테스트 응답은 대개 본문이 없거나 매우 짧아 회선을 거의 지속적으로 점유하지 않습니다. ‘연결을 수립하는 데 얼마나 걸리는가’는 보여 주지만, 연결이 수립된 뒤 초당 얼마나 많은 데이터를 전송할 수 있는지는 알려 주지 못합니다.

테스트 URL이 결과를 바꾸는 방식

테스트 URL은 단순한 장식 항목이 아닙니다. 노드 지연 시간은 대상 사이트의 위치, DNS 해석, HTTP 또는 HTTPS 프로토콜, 대상 서버 부하, CDN 라우팅, 통신사 경로의 영향을 함께 받습니다. 같은 노드라도 도쿄에 있는 테스트 사이트와 프랑크푸르트에 있는 테스트 사이트에 접속하면 외부 구간의 경로가 크게 달라져 결과가 수십에서 수백 밀리초까지 차이 날 수 있습니다.

연결성 테스트에 204 주소를 자주 쓰는 이유

일반적인 주소로는 http://www.gstatic.com/generate_204, https://www.gstatic.com/generate_204, https://cp.cloudflare.com/generate_204가 있습니다. 이러한 엔드포인트는 정상일 때 HTTP 204를 반환하며 본문이 없고 전송량도 적어 연결성과 지연 시간을 자주 확인하기에 적합합니다.

HTTP 주소는 TLS 핸드셰이크를 생략하므로 수치가 연결 및 첫 HTTP 응답까지의 시간에 더 가깝습니다. HTTPS 주소는 인증서 협상과 암호화 핸드셰이크가 추가되어 일반적인 HTTPS 웹사이트 환경에 더 가깝지만, 최초 연결의 수치는 더 높을 수 있습니다. 클라이언트가 기존 연결을 재사용하면 이후 테스트 결과가 최초 결과보다 낮아질 수도 있습니다. 노드를 비교할 때는 URL, 제한 시간, 클라이언트 버전, 네트워크 환경을 동일하게 유지해야 합니다.

설정의 URL과 제한 시간

mihomo 설정에서 url-test 유형의 프록시 그룹은 테스트 주소, 검사 주기, 허용 오차를 지정할 수 있습니다. 아래 설정은 300초마다 후보 노드를 확인하며, 새 노드가 현재 노드보다 조금만 빠를 때는 tolerance가 잦은 전환을 줄여 줍니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 도쿄-01
      - 싱가포르-01
      - 로스앤젤레스-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval: 300은 주기적인 검사 간격이 300초라는 뜻이며, 사용자 요청마다 다시 속도를 측정한다는 의미는 아닙니다. tolerance: 80의 단위는 밀리초이며 노드 전환에 필요한 차이를 확보합니다. lazy: true는 프록시 그룹을 사용하지 않을 때 능동적인 검사를 줄일 수 있다는 뜻입니다. 구체적인 지원 여부는 사용 중인 mihomo 커널 버전과 클라이언트가 생성한 설정을 기준으로 확인해야 합니다.

제어 인터페이스로 단일 노드를 테스트할 수도 있습니다. 일반적인 요청 형식은 GET /proxies/노드명/delay이며 timeout과 url 쿼리 매개변수를 함께 전달합니다. 그래픽 클라이언트의 ‘지연 시간 테스트’ 버튼은 보통 내부적으로 이 작업을 수행합니다. 컨트롤러가 127.0.0.1:9090에서 수신 대기한다면 요청은 로컬의 신뢰할 수 있는 프로그램만 접근해야 합니다. LAN 제어를 활성화할 때는 접근 키를 설정하고 방화벽에서 허용할 출발지를 제한해야 합니다.

지연 시간이 짧은 노드가 왜 여전히 버벅일까

지연 시간이 짧다는 것은 테스트 시점에 짧은 요청이 빠르게 반환되었다는 뜻일 뿐입니다. 웹페이지 열기, 영상 재생, 클라우드 드라이브 다운로드, 온라인 회의에는 처리량, 지터, 패킷 손실, 동시 연결 수, DNS 결과, 대상 사이트의 외부 경로도 영향을 줍니다. 어느 한 단계에서 병목이 생겨도 ‘패널은 60ms인데 실제 로딩은 느린’ 상황이 발생할 수 있습니다.

대역폭 제한과 공유 혼잡

노드는 수십 바이트에 불과한 204 응답을 빠르게 완료할 수 있지만, 사용 가능한 대역폭은 5Mbps에 불과할 수 있습니다. 이상적으로 환산하면 5Mbps는 약 0.625MB/s이므로 500MB 파일을 다운로드하는 데 최소 약 800초가 걸리며, 프로토콜 오버헤드와 속도 변동은 계산하지 않은 값입니다. 노드의 인바운드 또는 아웃바운드 회선을 많은 사용자가 공유한다면 새벽에는 80Mbps가 나오다가 저녁에는 같은 경로가 8Mbps로 떨어질 수 있습니다. 짧은 지연 시간 테스트만으로는 이런 차이가 즉시 드러나지 않을 수 있습니다.

대역폭은 단일 연결 제한의 영향도 받을 수 있습니다. 어떤 회선은 여러 연결로 다운로드하면 빨라 보이지만 단일 연결 영상 재생은 안정적이지 않을 수 있습니다. 또 다른 회선은 총 대역폭은 충분해도 짧은 순간의 버스트 이후 속도가 제한될 수 있습니다. 평가할 때는 다운로드 시작 직후의 최고 속도만 보지 말고 30~60초 동안의 지속적인 속도 곡선을 기록해야 합니다.

패킷 손실, 지터와 TCP 재전송

평균 지연 시간만으로는 매 요청의 변동을 설명할 수 없습니다. 연속 다섯 번의 결과가 62, 65, 61, 64, 180ms라면 평균은 여전히 높지 않지만 다섯 번째 급증은 게임, 음성 통화, 원격 데스크톱에 영향을 줍니다. 회선에 2% 패킷 손실이 있으면 TCP는 데이터를 재전송하고 혼잡 윈도우를 조정합니다. 대용량 파일 다운로드의 처리량은 크게 떨어질 수 있지만, 한 번 성공한 204 응답 테스트는 여전히 녹색 수치를 표시할 수 있습니다.

UDP 기반 서비스는 지터를 더 쉽게 드러냅니다. 게임과 실시간 음성 통화는 보통 손실된 패킷의 재전송을 기다리지 않으므로 20~40ms의 연속적인 지연 변동만으로도 순간 이동, 음성 끊김, 불안정한 입력 반응이 나타날 수 있습니다. 이런 용도에서는 한 번의 최저 결과만 고르지 말고 일정 시간 동안의 최대 지연, 지터 범위, 패킷 손실률을 확인해야 합니다.

노드에서 대상 웹사이트로 나가는 경로가 다르다

테스트 URL의 응답이 빠르다고 해서 모든 웹사이트가 같은 외부 경로를 사용하는 것은 아닙니다. 노드에서 Cloudflare, Google, GitHub, 스트리밍 CDN, 기업 업무 서비스로 가는 경로는 서로 다를 수 있습니다. 싱가포르의 한 노드가 현지 CDN에는 45ms로 접속하더라도 미국 동부에 있는 업무 서버에는 230ms를 넘길 수 있습니다. 영상 사이트는 노드의 외부 IP를 기준으로 서로 다른 CDN 엣지 노드를 배정할 수도 있어 실제 경로가 지연 시간 테스트 경로와 완전히 달라집니다.

특정 웹사이트의 문제를 판단할 때는 전역 지연 시간 테스트를 반복해서 누르기보다 해당 노드를 통해 실제 업무 대상에 직접 접속해야 합니다. 브라우저 개발자 도구의 ‘네트워크’ 패널에서 DNS, 연결, TLS, 첫 바이트 대기, 콘텐츠 다운로드 단계별 시간을 확인할 수 있습니다. 첫 바이트 대기는 짧지만 콘텐츠 다운로드가 느리다면 처리량 문제에 가깝고, 연결 단계부터 오래 걸린다면 핸드셰이크, 라우팅 또는 패킷 손실을 점검해야 합니다.

로컬 처리, DNS와 TUN 모드

TUN 모드는 더 많은 시스템 트래픽을 인계받고 설정에 따라 DNS 가로채기, 라우팅 판단, 프로토콜 스택 처리를 수행합니다. 성능이 정상인 장치에서는 이러한 오버헤드가 보통 주요 병목이 아닙니다. 하지만 오래된 장치, 높은 CPU 사용률, 서드파티 보안 소프트웨어의 필터링, 여러 가상 네트워크 어댑터의 중첩이 있으면 실제 사용 경험이 떨어질 수 있습니다. 이때 패널의 지연 시간 테스트는 커널이 직접 수행하므로 브라우저나 게임과 완전히 같은 시스템 경로를 거치지 않을 수 있습니다.

DNS 설정 때문에 ‘노드 지연 시간은 정상인데 웹사이트가 느린’ 상황이 생길 수도 있습니다. 예를 들어 도메인이 노드의 외부 출구에서 멀리 떨어진 CDN 주소로 해석되면 연결은 성공해도 적절하지 않은 지역을 우회하게 됩니다. fake-ip 모드를 사용할 때는 실제 IP가 필요한 LAN 장치, 기업 도메인, 특수 애플리케이션이 필터 규칙에 포함되어 있는지도 확인해야 합니다. DNS 설정을 변경한 뒤에는 설정을 다시 불러오고 운영체제 또는 브라우저의 DNS 캐시를 삭제한 다음 재테스트하세요.

더 정확한 노드 평가 방법

노드 선택은 연결성, 응답성, 안정성, 처리량, 대상 서비스라는 다섯 가지 관점으로 나누어야 합니다. 먼저 패널의 지연 시간으로 사용할 수 없거나 명백히 우회하는 노드를 제외한 뒤 지속적인 테스트를 진행하세요. 단순히 밀리초가 낮은 순서로 정렬하는 것보다 실제 사용 요구에 훨씬 가깝습니다.

1단계: 조건을 고정하고 반복 측정

1. 진행 중인 다운로드, 클라우드 드라이브 동기화, 시스템 업데이트를 일시 중지합니다.
2. 유선 네트워크 또는 동일한 Wi-Fi 대역을 고정하고 테스트 중 모바일 네트워크로 전환하지 않습니다.
3. 모든 후보 노드에 동일한 HTTPS 204 주소를 사용합니다.
4. 5회 연속 테스트하고 매번 3~5초 간격을 두며 최솟값, 최댓값, 실패 횟수를 기록합니다.
5. 평소 사용 시간대와 저녁 피크 시간대에 각각 테스트하여 최소 두 그룹의 결과를 남깁니다.

예를 들어 노드 A의 다섯 번 결과가 78, 81, 79, 83, 80ms이고 노드 B가 55, 210, 62, 시간 초과, 58ms라고 해 보겠습니다. 노드 B의 최저값은 더 낮지만 변동과 실패가 더 뚜렷합니다. 웹페이지가 가끔 빠르게 열린다고 해서 시간 초과 위험이 상쇄되지는 않으며, 장기간 사용에서는 노드 A가 대체로 더 안정적입니다.

2단계: 통제된 다운로드 테스트 수행

출처가 안정적이고 테스트를 허용하는 HTTPS 파일을 선택해 30~60초 동안 계속 다운로드합니다. 각 노드에서 동일한 파일, 같은 다운로드 도구, 비슷한 시간대를 사용하여 테스트 사이트 자체의 속도 제한을 노드 제한으로 잘못 판단하지 않도록 합니다. 안정 구간의 속도를 기록하고 다운로드 시작 후 1~2초 동안 나타나는 캐시 최고 속도는 사용하지 않습니다.

속도 단위도 통일해야 합니다. 클라이언트에 40Mbps로 표시되면 이론적으로 약 5MB/s에 해당합니다. 1바이트가 8비트이기 때문입니다. TCP, TLS, 프록시 프로토콜 오버헤드를 고려하면 실제 파일 기록 속도는 보통 조금 더 낮습니다. 시스템 모니터가 MB/s를 표시하고 속도 테스트 페이지가 Mbps를 표시한다면 숫자를 그대로 비교할 경우 8배의 오차가 생깁니다.

3단계: 용도별 대상 서비스 테스트

• 웹과 개발: 자주 사용하는 검색 서비스, 코드 저장소, 패키지 저장소, 문서 사이트를 테스트하고 첫 화면과 작은 파일 요청을 확인합니다.
• 영상: 10분 동안 연속 재생하며 화질 전환, 버퍼링 횟수, 피크 시간대의 안정성을 확인합니다.
• 원격 업무: 화상 회의, 원격 데스크톱, 회사 서비스를 테스트하고 지터와 짧은 연결 끊김을 중점적으로 기록합니다.
• 게임: 해당 서버 지역을 우선 테스트하고 일반적인 204 주소만 측정하지 말고 UDP 사용 가능 여부, 패킷 손실, 게임 내 지연 시간을 확인합니다.
• 대용량 파일: 단일 연결과 다중 연결의 속도를 최소 60초 동안 관찰하고 주기적으로 속도가 0으로 떨어지는지도 확인합니다.

4단계: 간단한 점수표 만들기

평균 지연, 최대 지연, 실패 횟수, 지속 다운로드 속도, 대상 서비스 성능을 각각 기록할 수 있습니다. 웹 사용에서는 지연과 안정성에 더 높은 가중치를 둘 수 있고, 대용량 파일 다운로드에서는 처리량의 비중을 높이는 것이 좋습니다. 게임과 통화에서는 평균 다운로드 속도보다 패킷 손실, 지터, 최대 지연이 대체로 더 중요합니다.

지연 시간 이상 발생 시 점검 순서

모든 노드가 갑자기 시간 초과로 표시되면 먼저 로컬 환경과 구독 상태를 점검하세요. 특정 지역이나 한 노드만 이상할 때 서버와 회선을 의심하면 됩니다. 처음부터 DNS, TUN 프로토콜 스택, 규칙 세트를 계속 바꾸면 문제의 범위가 오히려 더 모호해집니다.

모든 노드가 시간 초과로 표시됨

1. 현재 설정이 정상적으로 로드되었고 프록시 목록에 선택 가능한 노드가 있는지 확인합니다.
2. 현재 네트워크에서 테스트 URL을 해석할 수 있는지 확인하고, 다른 신뢰할 수 있는 HTTPS 204 주소로 바꿔 봅니다.
3. 시스템 시간이 정확한지 확인합니다. 시간 오차로 TLS 인증서 검증이 실패할 수 있습니다.
4. 클라이언트 로그를 확인하고 timeout, connection refused, TLS handshake, DNS 오류를 중점적으로 찾습니다.
5. 시스템 프록시 또는 TUN 모드를 잠시 껐다가 다시 켜서 이전 프로세스와 가상 네트워크 어댑터 상태가 해제되었는지 확인합니다.
6. 구독을 업데이트하고 노드 주소, 포트, 인증 정보가 변경되었는지 확인합니다.

많은 그래픽 클라이언트에서 ‘설정’ → ‘로그’ 또는 ‘커널’ → ‘로그’ 메뉴로 이동할 수 있지만 정확한 메뉴 이름은 클라이언트 버전에 따라 달라집니다. mihomo 로그 수준을 info로 설정하면 일반적으로 연결 단계를 확인하기에 충분합니다. 핸드셰이크 세부 정보를 확인해야 할 때만 잠시 debug를 사용하고 점검이 끝나면 되돌려 로그가 계속 빠르게 쌓이지 않도록 하세요.

특정 노드 하나만 시간 초과됨

먼저 프록시 그룹에서 같은 지역의 다른 노드로 전환합니다. 다른 노드가 정상이라면 문제는 대개 해당 노드의 서버, 포트, 프로토콜 매개변수, 진입 회선에 집중됩니다. 같은 서버가 여러 포트를 제공한다면 각각 테스트할 수 있지만, 프로토콜, SNI, 전송 계층, 테스트 URL을 동시에 바꾸지 마세요. 무엇이 연결을 복구했는지 알 수 없게 됩니다.

Trojan과 TLS를 사용하는 노드는 올바른 서버 이름과 인증서 일치가 필요합니다. WebSocket 노드는 Host와 경로에도 의존하며, Hysteria2, TUIC 같은 UDP 방식은 로컬 네트워크나 방화벽의 UDP 제한을 받을 수 있습니다. 이러한 매개변수는 구독에서 제공한 설정을 기준으로 해야 하며, 지연 시간 수치를 낮추기 위해 임의로 삭제해서는 안 됩니다.

지연 시간은 정상인데 브라우저가 여전히 느림

1. 브라우저 트래픽이 실제로 예상한 프록시 그룹을 통과하는지 확인합니다. 클라이언트의 연결 목록에서 대상 도메인, 규칙, 아웃바운드 노드를 확인할 수 있습니다.
2. 규칙 모드에서 대상 도메인이 DIRECT 또는 다른 프록시 그룹으로 잘못 분류되지 않았는지 확인합니다.
3. 브라우저 DNS 캐시를 삭제하고 독립적인 프록시 설정을 사용할 수 있는 확장 프로그램을 끈 다음 다시 테스트합니다.
4. 시스템 프록시와 TUN 모드를 비교합니다. 한 모드에서만 이상이 발생한다면 포트 충돌, 가상 네트워크 어댑터, 라우팅 테이블을 점검합니다.
5. 범용 지연 시간 주소가 아니라 실제 대상 웹사이트를 테스트하고 연결 단계와 콘텐츠 다운로드 단계에 각각 얼마나 걸리는지 확인합니다.

일반적인 로컬 포트로는 HTTP 프록시 7890, SOCKS5 프록시 7891, 혼합 포트 7890, 외부 컨트롤러 9090이 있지만 구독과 클라이언트에 따라 값이 다를 수 있습니다. 브라우저 수동 프록시, 시스템 프록시, 서드파티 네트워크 도구는 현재 실제 포트를 사용해야 합니다. 두 프로그램이 같은 포트를 동시에 수신하면 커널이 시작되지 않을 수 있으며, 로그에는 대개 주소가 이미 사용 중이라는 메시지가 나타납니다.

지연 시간 수치에서 실행 가능한 결론 얻기

Clash 패널의 지연 시간은 짧은 요청을 측정하는 지표입니다. 로컬 장치에서 노드까지의 경로, 프록시 프로토콜 처리, 노드의 외부 출구에서 테스트 사이트까지의 경로, 그리고 경우에 따라 TLS와 HTTP 상호작용을 하나의 숫자로 압축합니다. 연결성 점검과 동일 조건 비교에는 유용하지만 대역폭, 저녁 피크 혼잡, 패킷 손실, 지터, 대상 웹사이트의 라우팅, 로컬 네트워크 스택까지 모두 반영하지는 못합니다.

실제로 노드를 선택할 때는 한 번의 최저값을 좇기보다 테스트 조건을 일관되게 유지하는 것이 중요합니다. 90ms 안팎으로 다섯 번 안정적으로 측정된 노드가 50~300ms 사이를 오가며 가끔 시간 초과되는 노드보다 장기간 사용에 더 적합한 경우가 많습니다. 다운로드 용도라면 30~60초 처리량 테스트를 추가하고, 게임과 회의에는 패킷 손실과 지터 관찰을 더해야 용도에 맞는 결론을 얻을 수 있습니다.

클라이언트가 URL-Test 자동 선택을 지원한다면 비슷한 지역의 노드를 같은 그룹에 넣고 고정된 테스트 URL, 합리적인 300초 검사 간격, 일정한 허용 오차를 설정할 수 있습니다. 세션을 안정적으로 유지해야 하는 서비스에는 수동 노드 또는 상태 확인 기능이 있는 장애 조치 전략을 선택하여 작은 지연 변화 때문에 잦은 전환이 발생하지 않도록 하세요.