Clash 노드 지연 측정 원리: 패널 숫자와 실제 속도가 다른 이유

패널의 지연 숫자는 실제로 무엇을 측정하는가

Clash 제어 패널을 열면 노드마다 밀리초 단위의 숫자가 표시되고, 초록색은 빠르다는 뜻, 빨간색은 타임아웃을 의미합니다. 많은 사람이 이 숫자를 그대로 "이 노드가 얼마나 빠른가"의 답으로 받아들여 지연이 가장 낮은 노드를 선택하지만, 실제로 웹페이지가 끊기거나 다운로드 속도가 오르지 않는 경우가 흔합니다. 문제는 이 숫자에 대한 이해에 있습니다—이는 네트워크 속도가 아니라 한 번의 네트워크 요청에 걸린 왕복 시간이며, 이 요청의 대상과 방식은 클라이언트가 미리 정해 놓은 것이라 실제로 방문하려는 사이트와는 전혀 다를 수 있습니다.

이 메커니즘은 Clash와 Clash Meta(mihomo)에서 모두 URL 테스트(URL Test)라고 부릅니다. 원리는 단순합니다: 클라이언트가 특정 노드를 통해 고정된 주소로 HTTP 요청을 보내고, 요청을 보낸 시점부터 응답을 받은 시점까지의 시간을 기록하는데, 이 시간이 화면에 표시되는 지연입니다. 전체 과정은 단 한 번의 요청으로 끝나며 대용량 파일 다운로드나 처리량 측정은 포함되지 않습니다. 즉 이 숫자는 "연결 가능 여부와 링크 응답 속도"를 보여줄 뿐, "이 노드가 얼마나 빠른 다운로드 속도를 낼 수 있는가"를 보여주지는 않습니다.

설정 파일에서는 보통 다음과 같은 형태로 나타납니다:

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

url은 테스트 대상 주소, interval은 자동 재측정 간격(초), tolerance는 허용 오차입니다—새 지연이 현재 노드보다 이 값 이상 낮아야 실제로 전환이 일어나며, 몇 밀리초의 흔들림 때문에 노드가 계속 바뀌는 것을 막아줍니다. 이 몇 가지 필드가 패널 숫자의 동작 방식을 거의 결정합니다.

핸드셰이크 방식이 이 숫자에 미치는 영향

지연 측정에 걸리는 시간은 "네트워크 전송" 구간만이 아니라 프로토콜 자체의 연결 수립 비용도 포함합니다. 프로토콜마다 사용 가능한 연결을 맺기까지 필요한 단계 수가 다르며, 이 비용은 지연 숫자에 그대로 반영됩니다.

• TCP 3-way 핸드셰이크: TCP 기반 프로토콜은 모두 이 단계를 먼저 거치며, 보통 왕복 지연(RTT) 한 번 정도의 시간이 걸립니다.
• TLS 핸드셰이크: TLS 암호화를 사용하는 프로토콜(Trojan, 일부 VMess/VLESS 설정 등)은 TCP 이후 키 교환까지 마쳐야 하므로 보통 1~2 RTT가 추가되며, 첫 연결 시에는 더 두드러집니다.
• 프로토콜 자체의 인증/협상 단계: 예를 들어 Shadowsocks의 암호화 방식 협상, VMess의 타임스탬프 검증 등은 소량의 고정 비용을 더합니다.

즉 같은 서버, 같은 물리 회선이라도 프로토콜별로 노드를 구성하면 측정되는 지연 숫자에 차이가 생기는데, 이 차이는 회선 품질이 나빠진 게 아니라 프로토콜 자체의 오버헤드에서 나온 것입니다. 반대로 지연 숫자가 비슷한 두 노드라도 핸드셰이크 복잡도가 다르면 실제로 웹페이지를 열 때 "체감하는" 응답 속도가 다를 수 있습니다. 웹 브라우징은 대개 여러 연결을 새로 맺기 때문에 프로토콜 핸드셰이크 비용이 반복적으로 누적되기 때문입니다.

테스트 주소와 결과 캐시의 함정

패널의 숫자는 실시간으로 갱신되는 것이 아니라 interval에 설정된 간격마다 주기적으로 측정되며, 두 측정 사이의 결과는 캐시되어 그대로 표시됩니다. 그래서 흔히 오해가 생깁니다: 지금 보이는 "현재 지연"이 실제로는 몇 분 전에 측정된 값일 수 있고, 그 사이 회선 상태는 이미 바뀌었을 수 있습니다. 특히 저녁 피크 시간대처럼 변동이 큰 회선일수록 그렇습니다.

테스트 주소의 선택 역시 결과의 대표성에 영향을 줍니다:

• 흔히 쓰는 테스트 주소(generate_204 같은 경량 엔드포인트)는 자체적으로 CDN 가속이 적용되어 있어, 지역에 따라 이 주소로의 지연과 실제로 방문하려는 사이트로의 지연이 크게 다를 수 있습니다.
• 일부 종단 노드는 특정 주소에 대해 별도로 최적화된 라우팅을 적용해 두는데, 테스트 주소가 마침 그 최적화 경로에 걸리면 숫자가 비정상적으로 좋게 나오지만 다른 목적지 사이트로 바꾸면 원래 상태로 돌아갑니다.
• 테스트 주소가 노드가 위치한 네트워크 환경에서 제한되거나 일시적으로 접속되지 않으면, 다른 사이트는 평소처럼 잘 접속되더라도 곧바로 타임아웃으로 표시됩니다.

다시 말해 지연 숫자는 "특정 대상, 특정 시점"에 대한 샘플일 뿐, 그 노드가 하루 종일·모든 사이트에서 보이는 평균 성능이 아닙니다. 실제 상황에 가까운 판단을 하려면 이 숫자 하나만으로는 부족합니다.

낮은 지연이 높은 대역폭을 의미하지 않는다

가장 자주 간과되는 부분입니다: 지연은 "응답이 빠른가"를 측정하고, 대역폭은 "얼마나 많은 데이터를 담을 수 있는가"를 측정합니다. 두 값은 서로 완전히 다른 네트워크 특성에서 나오며, 지연이 낮은 노드의 대역폭이 낮을 수도 있고 지연이 높은 노드의 대역폭이 충분할 수도 있습니다.

직관적인 비유를 들면: 지연은 전화를 걸었을 때 상대가 받는 속도이고, 대역폭은 그 전화선이 동시에 감당할 수 있는 통화 수입니다. 빨리 받는다고 통화 품질이 좋다는 뜻은 아니며, 선 자체의 용량이 작으면 사람이 몰릴 때 여전히 끊기거나 음질이 나빠집니다. 프록시 상황에 대입하면 흔히 다음과 같은 사례가 나타납니다:

• 일부 노드는 제어 패널의 측정 요청에만 최적화되어 핸드셰이크 응답이 매우 빠르지만, 실제 종단 서버의 아웃바운드 대역폭이 제한적이어서 대용량 파일 다운로드나 동영상 재생을 시작하면 속도가 곧바로 따라가지 못합니다.
• 물리적으로 멀리 떨어진 노드는 (빛의 속도에 따른 물리적 하한선 때문에) 지연 숫자가 원래 높게 나오지만, 아웃바운드 대역폭이 충분하고 회선이 안정적이면 지속적인 다운로드에서는 실제 속도가 더 좋을 수 있습니다.
• 지연 숫자의 절대값보다 흔들리는 폭이 회선 안정성을 더 잘 보여주는 경우가 많습니다—항상 80ms 안팎에서 오르내리는 노드가 대개 30ms와 300ms를 오가는 노드보다 체감이 낫습니다.

체감에 더 가까운 노드 선택 방법

지연 숫자 하나만으로는 충분하지 않으니, 실제로 노드를 고를 때는 다음 방법들을 함께 활용하면 더 믿을 만한 판단을 할 수 있습니다:

1. tolerance 값을 합리적으로 설정한다

   허용 오차가 너무 작으면 몇 밀리초의 흔들림만으로도 노드가 자주 바뀌어 오히려 체감이 나빠집니다. 보통 50ms 안팎으로 설정하면 민감도와 안정성의 균형을 맞출 수 있습니다.

2. 실제 목적지에 가까운 테스트 주소로 바꾼다

   주된 용도가 특정 유형의 사이트에 집중되어 있다면 url을 그 사이트의 정적 리소스 주소로 바꿔, 범용 측정 엔드포인트보다 실제 사용 상황에 더 가까운 지연 숫자를 얻을 수 있습니다.

3. 단발성 스냅샷이 아니라 지연 변동 추이를 관찰한다

   패널이 몇 차례 갱신된 후의 숫자 변화를 눈여겨보세요. 평균값이 낮더라도 간혹 급등하는 노드보다는, 꾸준히 안정적인 노드가 대체로 더 낫습니다.

4. 실제 다운로드나 재생 테스트로 검증한다

   지연 순위가 앞선 노드 두세 개를 골라 실제로 다운로드나 동영상 재생을 한 번씩 해보고, 체감 속도로 최종 판단을 내리세요. 지연 숫자는 초기 필터링 용도로만 활용하는 것이 좋습니다.

5. "자동 선택"과 "수동 고정" 전략을 구분한다

   가벼운 사용에는 url-test 그룹의 자동 선택을 그대로 맡겨도 되지만, 대용량 전송처럼 속도에 민감한 상황에서는 대역폭을 이미 검증한 노드를 수동으로 고정하는 편이 더 안정적입니다.

정리하면, 지연 테스트의 가치는 명백히 사용할 수 없거나 응답이 지나치게 느린 노드를 빠르게 걸러내 후보군을 몇 개로 좁히는 데 있습니다. 일상적인 체감을 실제로 좌우하는 대역폭과 안정성은 실제 사용 시나리오에 맞춰 다시 검증해야 합니다. 이 메커니즘을 이해하고 나면, 패널의 밀리초 숫자를 노드 선택의 유일한 기준으로 삼지 않게 될 것입니다.