Clash 노드 속도 측정 원리: 지연 낮은 노드가 실제로는 왜 끊기는가

1. 지연 수치는 어떻게 측정되는가

Clash 클라이언트 노드 목록에서 속도 측정 버튼을 누르면 몇백 밀리초 뒤 각 노드 옆에 밀리초 값이 뜹니다. 이 수치가 나오는 과정은, 커널이 해당 노드를 출구로 삼아 특정 테스트 주소로 HTTP 요청을 한 번 보내는 것입니다. 흔히 쓰는 테스트 주소는 https://www.gstatic.com/generate_204로, 204 빈 응답만 반환하며 응답 본문은 0바이트입니다. 요청을 보낸 시점부터 응답 헤더를 받는 시점까지의 시간이 화면에 표시되는 '지연'입니다.

이 요청 하나를 뜯어보면 소요 시간은 세 부분으로 나뉩니다: 로컬에서 노드 서버까지 연결 수립(TCP 핸드셰이크, TLS 계열 프로토콜이면 TLS 핸드셰이크가 한 번 더 추가), 노드 서버에서 테스트 주소까지 연결 및 전달, 테스트 주소가 응답을 생성해 되돌아오는 과정입니다. 즉 본질적으로 '작은 요청 하나의 전체 경로 왕복 시간'이며 다운로드 속도도, 영상 비트레이트도 아닙니다.

url-test 정책 그룹의 자동 속도 측정도 수동 클릭과 같은 원리이며, 다만 주기적으로 자동 실행될 뿐입니다. 대표적인 자동 선택 설정 예시는 다음과 같습니다:

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

여기서 interval은 측정 주기로, 기본값은 300초입니다. tolerance는 허용 오차로, 다른 노드가 현재 노드보다 이 밀리초 값만큼 빠를 때만 전환하며 기본값은 50밀리초입니다. 지연이 비슷한 두 노드 사이를 계속 오가는 것을 막기 위한 값입니다. 이 두 파라미터는 뒤에서 노드를 고를 때도 다시 쓰입니다.

2. 지연이 낮다고 빠른 게 아닌 이유

204 요청 한 번의 전체 데이터량은 수백 바이트에 불과합니다. 이는 경로의 '반응 속도'만 측정할 뿐, 파이프의 '굵기'는 전혀 알 수 없습니다. 실제 체감을 결정하는 아래 요인들은 지연 수치로는 전혀 드러나지 않습니다.

대역폭과 단일 연결 처리량

실제 다운로드 속도는 남은 대역폭과 TCP 혼잡 제어에 달려 있습니다. 대략적으로 단일 TCP 연결의 처리량 상한은 '전송 중 윈도우 크기 ÷ 왕복 지연'에 가깝습니다. 지연이 낮으면 확실히 유리하지만, 대역폭이 충분하고 패킷손실이 없어야 한다는 전제가 붙습니다. 30밀리초지만 남은 대역폭이 5Mbps뿐인 경로는 200밀리초지만 남은 대역폭이 300Mbps인 경로에 다운로드 속도에서 반드시 뒤집니다. 밀리초 값이 좋다고 데이터 전송이 빠른 게 아닙니다.

패킷손실: 보이지 않는 함정

TCP는 패킷을 잃으면 재전송하고 혼잡 윈도우도 줄어듭니다. 패킷손실률 1%만으로도 처리량이 반토막, 또 반토막 날 수 있는데, 측정에 쓰이는 작은 204 요청은 마침 한 번도 손실을 겪지 않아 결과가 정상으로 나오는 경우가 흔합니다. 피크타임 국제 회선에서는 패킷손실이 지연보다 먼저, 더 심하게 나빠지는 경향이 있습니다.

지터: 안정성의 또 다른 얼굴

지연이 들쭉날쭉한 것을 지터라 부릅니다. 측정은 한 번의 샘플만 보므로 지터를 알 수 없습니다. 영상 시청 중 갑작스런 끊김, 게임의 핑 튐, 음성 통화의 뚝뚝거림은 대부분 지터와 순간적인 패킷손실 때문이며 평균 지연과는 관계가 적습니다. 평균 60밀리초이지만 간혹 400밀리초까지 튀는 노드는, 꾸준히 150밀리초인 노드보다 체감이 훨씬 나쁩니다.

피크타임 혼잡과 통신사별 기준

많은 회선이 낮에는 여유롭다가 저녁 8시부터 11시 사이에 몰립니다. 오후에 측정해서 노드를 고르는 습관이 있다면, 뽑아낸 '가장 빠른 노드'가 피크타임을 버텨내지 못할 수 있습니다. 또한 일부 통신사는 특정 포트나 프로토콜에 속도 제한(QoS)을 걸기도 하는데, 작은 요청으로는 느껴지지 않지만 지속적인 대용량 트래픽에서는 바로 드러납니다.

노드 서버 자체의 부하

노드는 공유 자원입니다. 같은 서버에 접속하는 사용자가 많아질수록 CPU의 암복호화 처리 대기, 네트워크 카드 대역폭 분할이 심해집니다. TLS, 난독화 등 프로토콜 오버헤드는 서버가 바쁠 때 응답 시간을 더 늘리는데, 이때 지연 수치도 나빠지지만 그 반응 속도는 실제 체감 저하보다 늦게 따라오는 경우가 많습니다. 밀리초 값이 오르는 걸 눈으로 확인할 즈음이면 끊김은 이미 한동안 이어진 상태입니다.

3. 측정 결과에서 더 읽어낼 수 있는 것

지연 수치가 무의미한 건 아니고, 제대로 읽는 게 핵심입니다.

timeout과 '느림'은 다른 문제입니다. 측정에서 timeout이 뜨면 제한 시간(기본 약 5초) 내에 응답을 받지 못했다는 뜻이며, 흔한 원인은 노드 다운, 진입점 차단, 프로토콜 핸드셰이크 실패입니다. 이런 노드는 '느린 노드'가 아니라 바로 사용 불가로 봐야 합니다.

연속으로 여러 번 눌러보고, 단일 값이 아니라 흔들림을 보세요. 50, 55, 52밀리초는 안정적이고, 80, 300, 150밀리초는 흔들림이 큽니다. 후자는 최저값이 예쁘게 나와도 실제 체감은 대체로 나쁩니다.

대시보드로 이력 그래프를 확인하세요. metacubexd, Yacd 같은 대시보드에서는 각 노드의 지연 이력을 볼 수 있는데, 그래프가 완만한 쪽이 수치가 낮은 쪽보다 더 믿을 만합니다.

테스트 주소의 경로 편향을 기억하세요. gstatic까지 빠르다고 해서 자주 보는 동영상 사이트, 게임 서버까지 똑같이 빠른 건 아닙니다. 이들은 완전히 다른 국제 출구를 탈 수 있습니다. 측정 통과는 '테스트 주소까지의 경로가 뚫려 있다'는 것만 의미합니다.

4. 더 믿을 만한 노드 선택법

실제 트래픽으로 재검증하세요. 후보 노드를 두세 개로 좁힌 뒤 각각 10분씩 사용해 봅니다: 고비트레이트 영상을 시청하며(플레이어 통계의 연결 속도가 직관적인 지표입니다) 멀티스레드 속도 측정을 한 번 실행하고, 단일 스레드 대용량 다운로드가 안정적인지도 관찰합니다. 세 가지 모두 통과해야 합격입니다.
피크타임에 한 번 더 테스트하세요. 저녁 8시부터 11시 사이에 위 실측을 반복합니다. 여유 시간엔 빠르고 붐빌 때 무너지는 노드는 후보 순위에서 내리고 자동 선택 그룹의 앞자리에 두지 마세요.
흔들림을 보고, 단일 값을 보지 마세요. 연속으로 5~10회 측정해 최고값과 최저값의 차이를 기록하세요. 차이가 작을수록 안정적입니다. 안정성이 중요한 상황에서는 흔들리는 저지연보다 안정적인 중간 지연을 선택하는 게 낫습니다.
정책 그룹에 당직을 맡기세요. 일상적인 웹서핑은 url-test에 맡기고 적절한 tolerance를 설정하며, 안정성이 중요한 상황(원격 데스크톱, 온라인 회의)에는 fallback을 써서 주 노드 장애 시에만 전환되도록 합니다:

proxy-groups:
  - name: 안정성 우선
    type: fallback
    proxies:
      - 메인 노드
      - 대체 노드
    url: https://www.gstatic.com/generate_204
    interval: 120

상황별로 트래픽을 나누세요, '만능 노드' 하나를 찾으려 하지 마세요. 다운로드 작업은 대역폭이 큰 노드로, 게임과 통화는 저지연·저지터 노드로 서로 다른 정책 그룹에 나눠 맡기면 서로 방해하지 않습니다.

주의

측정 간격을 너무 짧게 잡지 마세요. interval을 몇십 초로 줄이면 '자주 확인하는' 것처럼 보이지만 실익은 크지 않습니다. 측정마다 노드와 테스트 주소에 추가 요청을 발생시키고, 너무 자주 하면 대상 서버의 속도 제한을 유발할 수도 있습니다. 300초 전후가 안전한 값입니다.

5. 자주 묻는 질문

지연 30밀리초인 노드로 4K를 보는데 왜 계속 버퍼링되나요?

4K 영상은 낮은 지연이 아니라 지속적인 25Mbps 이상의 처리량이 필요하기 때문입니다. 지연은 정상이어도 대역폭이 부족하거나 패킷손실이 높으면 버퍼링은 그대로 발생합니다. 4장의 방법대로 처리량을 측정하세요, 밀리초 값만 보지 말고요.

같은 노드인데 휴대폰은 빠르고 컴퓨터는 느립니다. 측정이 부정확한 걸까요?

노드 문제가 아닐 수 있습니다. 양쪽 모두 노드까지의 경로는 같으므로 병목이 컴퓨터 쪽에 있을 수 있습니다: Wi-Fi 신호가 약하거나, 로컬 방화벽이 막고 있거나, TUN 모드의 오버헤드일 수 있습니다. TUN 모드는 가상 네트워크 카드를 한 단계 더 거치므로, 성능이 약한 기기에서는 처리량이 줄어드는데 이는 지연 측정과는 무관합니다.

측정은 전부 초록불인데 왜 웹페이지가 안 열리나요?

측정은 '테스트 주소까지' 경로가 뚫려 있는지만 확인할 뿐, 규칙 매칭 오류나 DNS 해석 이상은 검사 범위 밖입니다. 이런 문제는 자주 묻는 질문 페이지를 참고해 시스템 프록시 스위치, 규칙 모드, DNS 설정 방향으로 하나씩 점검해 보세요.