Clash 지연 시간 숫자 제대로 읽기:
몇십 ms인데 왜 끊기나

지연 시간 숫자는 실제로 무엇을 측정하는가

Clash 클라이언트를 열면 노드 목록 우측에 표시되는 밀리초 숫자는 코어가 각 노드에 대해 실행한 네트워크 탐지 한 번의 결과입니다. 구체적으로는 클라이언트가 해당 노드를 통해 연결을 맺고, 설정에 지정된 test-url(기본값은 대부분 http://www.gstatic.com/generate_204 같은 가벼운 엔드포인트)로 HTTP 요청을 한 번 보낸 뒤, 요청을 보낸 시점부터 응답을 받은 시점까지의 시간을 기록합니다. 이것이 바로 지연 시간입니다.

이 과정은 세 가지만 거칩니다: DNS 조회(대상이 도메인일 경우), TCP/TLS 핸드셰이크, 그리고 아주 작은 HTTP 왕복 한 번. 실질적인 콘텐츠는 전혀 내려받지 않으며, 대상 엔드포인트는 보통 204 빈 응답이나 몇 바이트 텍스트만 반환하므로 전체 테스트는 대역폭을 거의 요구하지 않습니다. 즉 지연 시간 숫자가 보여주는 것은 "이 노드에 연결해서 한 번 왕복하는 데 걸리는 시간"이며, "이 노드가 영상 시청이나 대용량 다운로드를 버텨낼 수 있는가"와는 별개의 문제입니다.

지연 시간이 낮은데도 실제로는 왜 끊기나

30ms, 50ms 같은 숫자를 보고 곧바로 "빠른 노드"라고 단정하는 것이 가장 흔한 오판입니다. 실제 체감 끊김의 원인은 대개 지연 시간 테스트가 전혀 포착하지 못하는 다음 요소들에 있습니다:

• 패킷 손실과 지터(Jitter): 지연 시간 테스트는 단발성 탐지라, 한 번 성공했다고 해서 지속적으로 안정적이라는 뜻은 아닙니다. 노드가 특정 순간에는 빠르게 응답하더라도, 실제로 브라우징하거나 영상을 재생하는 수십 초 동안 간헐적인 패킷 손실이 발생해 화면이 멈추거나 로딩이 걸릴 수 있으며, 마침 지연 목록이 새로고침될 때는 또 정상 값이 측정되곤 합니다.
• 대역폭과 출구 혼잡: 지연 탐지 요청은 크기가 거의 0이라 속도 제한이나 혼잡을 유발하지 않지만, 영상을 재생하거나 파일을 다운로드하려면 지속적인 처리량이 필요합니다. 노드의 출구 대역폭이 제한적이거나 다수 사용자와 공유 중이라면 실제 속도는 지연 숫자가 암시하는 "빠름"에 크게 못 미칠 수 있습니다.
• 목적지 서버와 랜딩 품질: 테스트 URL은 대개 해외 대기업의 가벼운 엔드포인트로, 실제로 접속하려는 웹사이트나 앱 서버와는 네트워크 경로가 전혀 다를 수 있습니다. 테스트 경로가 원활하다고 해서 실제 방문하려는 대상 사이트의 경로도 원활하다는 뜻은 아닙니다.
• 프로토콜 계층 차이: 서로 다른 프록시 프로토콜은 소용량 테스트와 지속적인 대용량 트래픽에서 다르게 동작합니다. 일부 프로토콜은 저지연 상황에서 우세하지만, 불안정한 네트워크나 고동시성 상황에서는 오히려 끊김·재연결이 더 잦을 수 있습니다.

test-url, 타임아웃, 동시 측정 메커니즘이 숫자에 미치는 영향

지연 시간 숫자는 한 번 계산되면 영원히 고정되는 값이 아니라, 몇 가지 설정 가능한 메커니즘에 의해 결정됩니다. 이 메커니즘을 이해하면 눈앞의 숫자를 얼마나 믿을 수 있는지 판단할 수 있습니다.

test-url: 누구의 경로를 측정하는가

정책 그룹 설정의 url(일부 문서에서는 test-url) 필드가 탐지 대상을 결정합니다. 대다수 구독은 기본적으로 해외의 가벼운 감지 엔드포인트를 가리키며, 이런 엔드포인트는 전 세계 어디서나 응답이 좋아 측정값이 전반적으로 낮고 "보기 좋게" 나옵니다. 특정 지역, 특정 서비스의 사이트를 주로 이용한다면 기본 테스트 대상과 네트워크 경로가 전혀 다를 수 있으므로, 숫자가 좋다고 해서 실제 목적지도 똑같이 빠르다는 뜻은 아닙니다.

interval: 얼마나 자주 재측정하는가

정책 그룹의 interval(단위: 초)이 자동 속도 측정 간격을 결정하며, 흔히 300초 전후로 설정됩니다. 즉 목록에 표시된 숫자는 몇 분 전에 찍힌 스냅샷일 가능성이 크고, 네트워크 상태는 계속 변하므로 숫자에는 지연이 있어 "지금 이 순간"의 실제 상태를 뜻하지 않습니다.

tolerance: 허용 범위 내에서는 전환하지 않음

tolerance 필드(단위: 밀리초)는 자동 최적 선택 정책 그룹의 전환 허용치를 정의합니다. 새로 측정된 지연이 현재 노드보다 약간 나은 정도이고 그 차이가 허용 범위 안이라면 클라이언트는 노드를 전환하지 않아, 잦은 흔들림으로 연결이 반복적으로 재구성되는 것을 막습니다. 목록에는 분명 더 낮은 지연의 노드가 있는데 자동 선택이 "반응하지 않는" 것도 이 때문입니다. 못 측정한 게 아니라 허용치 규칙에 따라 동작하는 것입니다.

timeout과 동시 탐지

탐지 요청 자체에는 타임아웃 제한이 있어 임계값을 넘으면 곧바로 타임아웃으로 처리됩니다(보통 실패 또는 매우 높은 값으로 표시). 같은 배치의 노드는 대개 동시에 속도 측정을 하는데, 로컬 네트워크나 CPU, 동시 실행 수 설정이 적절하지 않으면 짧은 시간에 많은 동시 요청이 서로 자원을 다투게 되어 측정값 전체가 높거나 불안정해질 수 있습니다. 이런 경우 한 번의 측정 결과는 참고 가치가 크지 않으니 여러 번 측정해서 추세를 보는 것이 좋습니다.

지연 시간 숫자를 제대로 해석하는 세 가지 행동

1. 단일 값이 아닌 추세를 본다: 수동으로 여러 번 속도 측정을 실행해(대부분 클라이언트는 새로고침 클릭이나 개별 노드 우클릭 측정을 지원) 같은 노드가 시간대별로 얼마나 요동치는지 확인하세요. 변동이 작은 노드는 평균값이 조금 높더라도 실제 체감이 대체로 더 안정적입니다.
2. 실제 상황으로 검증한다: 지연 숫자가 통과 기준이라면, 실제로 자주 쓰는 웹사이트를 열거나 소용량 파일을 다운로드해 로딩 속도와 끊김 여부를 체감으로 확인하세요. 이 단계가 숫자를 보는 것보다 훨씬 직접적입니다.
3. "자동 최적화 그룹"과 "수동 선택"을 구분한다: 정책 그룹이 자동 최적 선택(url-test 유형)이라면 이미 interval과 tolerance에 따라 걸러내고 있는 상태입니다. 수동 그룹이라면 숫자는 참고용일 뿐, 최종적으로는 실제 사용 체감으로 노드 교체 여부를 결정해야 합니다.

숫자는 좋은데 체감이 나쁠 때 추가로 점검할 것

지연 숫자가 계속 낮게 나오는데도 웹페이지 로딩이 느리고 영상 버퍼링이 자주 발생하며 다운로드 속도가 오르지 않는다면, 다음 순서로 점검해보세요:

• 다른 노드로 바꿔 같은 유형의 비교 테스트를 해서, 특정 노드만의 문제인지 구독 전체 라인의 공통 문제인지 구분합니다.
• TUN 모드가 켜져 있는지, 규칙 분기가 대용량 트래픽 앱을 적절한 정책 그룹으로 올바르게 보내고 있는지(과부하 상태인 노드 하나로 몰리지 않는지) 확인합니다.
• 현재 시간대가 네트워크 혼잡 시간대인지 확인합니다. 일부 라인은 저녁 피크 시간대에 사용자가 집중돼 대역폭 경합이 생기는데, 이런 혼잡은 지연 탐지 같은 소용량 테스트에는 드러나지 않습니다.
• 로컬 네트워크 자체에 문제가 없는지 확인합니다. 프록시를 끈 상태로 로컬 인터넷 속도와 패킷 손실을 먼저 테스트해, 로컬 네트워크로 인한 착시 현상을 배제합니다.

노드를 고를 때 함께 봐야 할 지표 조합

지연 시간은 선별의 첫 번째 관문으로만 삼고 유일한 기준으로 쓰지 말며, 다음 항목들을 함께 살펴보면 판단이 훨씬 정확해집니다:

• 지연 시간의 안정성: 여러 번 측정한 변동 범위가 단일 수치보다 중요합니다.
• 프로토콜과 암호화 방식: 프로토콜마다 불안정한 네트워크와 고동시성 상황에서 견디는 능력이 다르므로, 같은 배치 안에서 프로토콜이 동일한 노드끼리 비교해야 의미가 있습니다.
• 랜딩 지역과 라인: 같은 노드라도 시간대나 대상 사이트에 따라 성능 차이가 뚜렷할 수 있으니, 한 번의 판단보다 장기적으로 관찰하는 것이 더 믿을 만합니다.
• 실제 처리량 테스트: 여건이 된다면 실제 다운로드나 속도 테스트를 한 번 진행해, 대역폭이 지연 숫자가 주는 "좋은 인상"과 실제로 맞아떨어지는지 직접 확인하세요.

지연 시간 테스트는 눈에 띄게 비정상적이거나 타임아웃되는 노드를 빠르게 걸러내는 도구일 뿐, 일상적인 사용 체감을 결정하는 것은 언제나 대역폭, 패킷 손실률, 라인 혼잡도를 종합한 결과입니다. 이 항목들을 따로 떼어 봐야 보기 좋은 밀리초 숫자에 속지 않을 수 있습니다.