Clash 지연 테스트 원리 분석: 패널에 80ms로 표시되는데 왜 실제 이용 시 여전히 느릴까

지연 수치는 실제로 무엇을 측정하는가

Clash 커널 클라이언트의 프록시 페이지를 열면 각 노드 뒤에 밀리초 단위 숫자가 붙어 있고, 초록색은 빠름, 노란색은 보통, 빨간색은 타임아웃이나 사용 불가를 뜻합니다. 이 숫자는 클라이언트가 주기적으로 실행하는 속도 측정에서 나오며, 업계에서는 흔히 이를 URL Test라 부릅니다. 동작 방식은 단순합니다. 클라이언트가 해당 노드를 통해 고정된 주소로 HTTP 요청을 한 번 보내고, 요청을 보낸 시점부터 응답 헤더를 받는 시점까지의 시간을 기록하는데, 이 시간이 바로 패널에 표시되는 숫자입니다.

핵심은 이 측정이 "짧은 요청 한 번의 왕복 시간"만 측정할 뿐, 본문 콘텐츠를 내려받지도 않고 웹페이지 열람 시 발생하는 여러 동시 연결도 시뮬레이션하지 않는다는 점입니다. 이는 네트워크 공학에서 말하는 RTT(Round-Trip Time, 왕복 지연 시간)에 더 가깝습니다. "패킷을 보내고 확인 응답을 받기까지" 걸리는 시간을 측정하는 것이지, "웹페이지를 열어 모든 리소스를 다 불러오기까지" 걸리는 시간이 아닙니다. 이 둘은 관련은 있어 보이지만 실제 격차는 매우 커질 수 있습니다.

참고: 지연 수치는 경로의 응답 속도 상한선을 반영할 뿐, 사용 체감의 하한선을 보장하지 않습니다. 낮은 지연은 필요조건이지 충분조건이 아닙니다.

URL Test는 핸드셰이크 시간을 측정할 뿐, 페이지 로딩 시간이 아니다

격차가 어디서 오는지 이해하려면 먼저 실제 웹페이지 로딩 과정을 살펴봐야 합니다. 일반적인 웹페이지를 열 때 브라우저는 최소한 다음 작업들을 수행합니다.

DNS로 도메인을 해석해 대상 서버의 IP 주소를 확인
서버와 TCP 연결을 수립(3방향 핸드셰이크)
HTTPS라면 암호화 파라미터를 협상하는 TLS 핸드셰이크를 추가로 수행
HTTP 요청을 보내고 서버가 응답 헤더와 본문을 반환할 때까지 대기
HTML을 파싱한 뒤 페이지 내 이미지, 스크립트, 스타일시트 등 리소스를 동시에 요청
브라우저가 렌더링을 완료해 페이지가 상호작용 가능한 상태가 될 때까지 대기

URL Test는 2~4번 과정 중 짧은 일부만 다루며, 측정 대상도 보통 용량이 작고 응답이 빠른 고정 주소(예: 전용 속도 측정 인터페이스)라서 서버 부하가 거의 무시할 수준입니다. 반면 평소 접속하는 사이트, 동영상 사이트, 게임 서버는 부하 상황, 지리적 위치, CDN 노드 분포가 모두 다릅니다. 같은 프록시 경로라도 측정 주소 접속 시 80ms, 다른 대상 접속 시 200ms가 나올 수 있는데, 이는 지연 수치가 "잘못 측정된" 것이 아니라 원래부터 하나의 샘플 지점만 대표하는 것이지 모든 대상을 대표하지 않기 때문입니다.

또한 대부분 클라이언트의 자동 측정에는 스로틀링 메커니즘이 있어서, 리소스를 요청할 때마다 실시간으로 측정하지 않습니다. 패널에 표시되는 숫자는 흔히 수십 초에서 몇 분 전의 스냅숏입니다. 경로 상태 자체도 변동하는데, 특히 트래픽이 몰리는 시간대의 중계 노드는 5분 전 80ms였다가 지금은 300ms까지 오를 수 있으며, 패널이 그 정도로 실시간 갱신되지는 않습니다.

패킷 손실, 대역폭 한계, 경로 혼잡이 실제 체감을 어떻게 저하시키는가

지연 수치 외에도 "실제로 느린가"를 좌우하는 세 가지 변수가 더 있으며, 이들은 대부분 그 밀리초 숫자에 드러나지 않습니다.

패킷 손실률

TCP 프로토콜은 확인 응답과 재전송으로 데이터 완전성을 보장합니다. 경로상에서 패킷 하나가 손실되면 송신 측은 타임아웃을 기다린 뒤 재전송해야 하며, 이 대기 시간은 보통 수백 밀리초부터 시작합니다. 지연은 낮지만 손실률이 높은 경로는 "웹페이지는 잘 열리지만 동영상은 계속 끊김", "게임 지연 수치는 정상인데 갑자기 프레임이 튀는" 형태로 나타납니다. URL Test의 단발성 짧은 요청은 샘플이 너무 적어 마침 손실이 발생한 순간을 놓치기 쉬워서 손실 문제를 드러내기 어렵습니다.

대역폭 한계

지연은 "응답이 빠른가"를 측정하고, 대역폭은 "통로가 넓은가"를 측정합니다. 지연이 50ms에 불과해도 대역폭이 2Mbps뿐인 경로는 웹페이지는 금세 반응하지만, 파일 다운로드나 고화질 동영상 재생 시 진행률이 눈에 띄게 느려집니다. 이 둘은 완전히 독립된 지표이며, 패널의 지연 수치는 대역폭 한계에 전혀 반응하지 않습니다.

경로 혼잡

프록시 경로는 대개 여러 단계의 중계를 거치며, 어느 한 중계 서버의 부하가 과도하거나 상위 대역폭을 다수 사용자가 나눠 쓰면 혼잡이 발생합니다. 혼잡의 대표적 증상은 지연이 시간에 따라 크게 변동하고 트래픽 몰리는 시간대에 나빠지며 새벽 시간대에 좋아지는 것입니다. 클라이언트를 켰을 때 딱 한 번 측정한 지연만 본다면 경로 품질을 오판하기 쉽습니다.

증상	지연 수치 표시	실제 원인
동영상 버퍼링이 계속 돌아감	여전히 "초록색" 저지연으로 표시될 수 있음	패킷 손실로 인한 TCP 재전송, 또는 비트레이트를 감당하지 못하는 대역폭
웹페이지는 바로 열리는데 파일 다운로드가 느림	지연 정상	대역폭 한계, 지연과는 무관
낮에는 괜찮다가 새벽에 갑자기 빨라짐	시간대별로 측정 수치가 다름	경로 혼잡이 부하에 따라 변동
패널에 타임아웃/빨간색 표시	수치 이상 또는 누락	노드 장애 또는 측정 대상 자체에 접근 불가

실제 체감에 더 가까운 자가 진단 방법

패널의 지연 수치만으로는 부족하므로, 실제 사용 상황에 더 가까운 진단 방식을 몇 가지 더해 경로가 정말 쓸 만한지 종합적으로 판단할 수 있습니다.

1. 자동 측정만 믿지 말고 여러 실제 대상을 직접 측정하기

대부분의 Clash 클라이언트는 개별 노드나 그룹을 수동으로 다시 측정할 수 있고, 설정에서 측정 주소를 직접 지정할 수도 있습니다. 기본 측정 주소를 실제로 자주 쓰는 서비스(예: 자주 방문하는 사이트의 메인 페이지)로 바꾸면 측정값이 실제 접속 시간에 더 가까워집니다. 같은 노드로 일반적인 측정 주소와 실제 목적지 주소를 각각 측정해 그 차이를 비교하면, 해당 경로가 "전반적으로 빠른지" 아니면 "측정 대상에만 빠른지" 판단할 수 있습니다.

2. 숫자 하나만 보지 말고 로그 페이지로 연결 과정을 관찰하기

클라이언트의 로그 페이지(또는 연결 페이지)는 실제로 발생한 각 연결의 목적지 주소, 사용된 노드, 규칙 매칭 결과를 기록합니다. 버퍼링이 발생하는 웹페이지를 실제로 열어보면서 로그를 확인하면, 이번 접속이 어떤 노드를 거쳤는지, 재연결이 자주 발생했는지, 규칙 오판으로 느린 경로를 타게 된 연결이 있는지 확인할 수 있습니다. 이는 프록시 페이지의 지연 수치만 보는 것보다 문제 지점을 훨씬 정확히 짚어낼 수 있습니다.

3. 시스템 기본 도구로 기초 네트워크 진단하기

ping -c 20 목적지 도메인 또는 IP
tracert 목적지 도메인 또는 IP   # Windows는 tracert, macOS/Linux는 traceroute 사용

ping을 20회 연속 실행하면 패킷 손실률(출력의 packet loss)을 확인할 수 있어, 일회성 지연 수치보다 경로 안정성을 더 잘 반영합니다. 경로 추적은 데이터 패킷이 어느 구간에서부터 눈에 띄게 느려지거나 손실되는지 보여주어, 문제가 로컬 네트워크, 중계 노드, 목적지 서버 중 어느 쪽에 있는지 판단하는 데 도움이 됩니다.

4. 시간대를 바꿔 반복 측정하기

경로 혼잡이 의심된다면 같은 경로를 서로 다른 시간대(예: 밤 9시 트래픽 몰리는 시간과 새벽 2시)에 각각 측정해 보세요. 지연과 손실률 차이가 뚜렷하다면 문제가 경로 부하에 있을 뿐 설정 오류가 아니라는 것을 거의 확정할 수 있습니다.

5. 로컬 및 단말 기기의 간섭 요인 먼저 배제하기

결론을 내리기 전에 시스템 프록시가 제대로 켜져 있는지, 다른 프록시 소프트웨어와 충돌하지 않는지, TUN 모드가 트래픽을 정상적으로 인계받고 있는지 먼저 확인하세요. 이런 설정 단계의 문제도 겉보기에는 "느림"으로 나타나지만 경로 품질과는 무관하므로, 진단 순서상 먼저 배제해야 합니다.

주의: 여러 노드가 여러 시간대에서 모두 높은 지연이나 높은 손실률을 보인다면, 구독 자체의 경로 품질 문제일 가능성이 높습니다. 클라이언트 설정을 반복해서 조정하기보다 노드를 교체하거나 구독 제공처에 문의하는 편이 더 효과적입니다.

자주 묻는 질문

같은 노드를 두 클라이언트에서 측정했는데 왜 지연 수치가 다른가요?

측정 주소, 타임아웃 기준, 측정 빈도의 기본 설정이 서로 다르면 수치에 차이가 나는 것이 정상이며, 어느 클라이언트가 "더 정확하게 측정한다"는 뜻은 아닙니다.

지연이 계속 초록색인데 동영상은 자주 끊긴다면 어떻게 해야 하나요?

먼저 패킷 손실과 대역폭 한계를 의심하세요. ping을 여러 번 실행해 손실률을 확인하고, 해당 노드에 속도 제한이 있는지 살펴본 뒤, 필요하면 다른 노드 그룹으로 바꿔 다시 시도해 보세요.

자동 측정은 얼마나 자주 갱신되며, 더 자주 하도록 조정할 수 있나요?

대부분의 클라이언트는 설정에서 자동 측정 간격을 조정할 수 있습니다. 너무 자주 설정하면 불필요한 네트워크 요청이 늘어나므로, 일반적으로 기본값을 유지하거나 적절히 짧게 조정하는 것으로 충분하며 실시간 갱신을 추구할 필요는 없습니다.