Clash 노드 선택법: 지연 시간·배율·지역·프로토콜 4가지 기준 실전 가이드

“지연 시간이 가장 짧은 노드가 최고”라는 선택부터 버리세요

Clash 클라이언트의 노드 목록에서는 보통 지연 시간 수치가 가장 눈에 잘 띕니다. 홍콩 A가 58ms, 싱가포르 B가 91ms, 미국 C가 168ms로 표시되면 많은 사용자가 바로 58ms 노드를 고릅니다. 이 방법은 1차 선별에는 적합하지만 최종 판단에는 부족합니다. 지연 시간은 한 번의 테스트 요청이 얼마나 빨리 완료됐는지만 보여 줄 뿐, 노드의 잔여 대역폭, 피크 시간대 혼잡, 트래픽 배율, 출구 지역, 프로토콜 호환성, 콘텐츠 플랫폼 이용 가능 여부까지 알려 주지는 않습니다.

노드 선택은 필수 조건이 있는 정렬 문제에 가깝습니다. 먼저 현재 커널이 지원하는 프로토콜이어야 하고, 지역은 접속 목적에 맞아야 하며, 배율은 요금제 예산을 넘지 않아야 합니다. 그다음 지연 시간과 실제 전송 성능을 기준으로 주력 노드를 정합니다. 잠깐 웹을 둘러보는 정도라면 지연 시간에 높은 비중을 둬도 되지만, 4K 영상 시청·원격 개발·대용량 파일 동기화가 목적이라면 지속 처리량, 패킷 손실, 회선 변동까지 함께 봐야 합니다.

이제 클라이언트 화면에서 흔히 확인하는 순서대로 살펴보겠습니다. 지연 시간, 배율, 지역, 프로토콜 순입니다. 글 마지막에서는 네 가지 기준을 실행 가능한 선택 절차로 묶어 보겠습니다.

첫 번째 기준: 지연 시간은 1차 선별용, 최소 3회 연속 측정

클라이언트가 실제로 측정하는 값

일반적인 Clash 그래픽 클라이언트는 커널을 통해 특정 테스트 URL에 HTTP 또는 HTTPS 요청을 보내고, 연결 시작부터 유효한 응답을 받을 때까지 걸린 시간을 기록합니다. 전략 그룹의 url-test도 비슷한 방식으로 작동하며, 설정한 간격마다 다시 측정합니다. 이 수치에는 보통 로컬 기기에서 프록시 진입점까지, 프록시 서버 처리 시간, 프록시 출구에서 테스트 사이트까지의 구간, 핸드셰이크에 걸린 시간이 함께 포함됩니다.

이는 종합 속도 측정값이 아닙니다. 노드에 60ms가 표시됐다고 해서 100Mbps를 계속 유지할 수 있다는 뜻은 아닙니다. 반대로 140ms로 표시된 노드라도 회선이 안정적이고 대역폭이 충분하다면, 대용량 파일을 내려받을 때 피크 시간대에 혼잡한 60ms 노드보다 훨씬 빠를 수 있습니다.

구간으로 판단하고 5ms 차이를 쫓지 마세요

구간은 경험적 기준일 뿐 합격선은 아닙니다. 베이징에서 도쿄로 연결하는 물리 경로와 광저우에서 홍콩으로 연결하는 경로는 다르고, 모바일 네트워크·가정용 인터넷·회사 네트워크에서도 결과가 달라집니다. 두 노드가 각각 61ms와 67ms라면 그 차이는 대개 선택에 의미가 없습니다. 한 노드가 90ms에서 안정적인 반면 다른 노드가 45~320ms 사이를 오간다면 전자를 우선하는 편이 낫습니다.

3회 측정법

1. 클라이언트에서 「프록시」→대상 전략 그룹으로 이동한 뒤, 후보 노드 전체 속도 측정을 한 번 실행합니다.
2. 5~10초 간격으로 두 번 더 측정해 총 3회의 결과를 기록합니다. 마지막 결과만 보지 마세요.
3. 중간값을 기준으로 삼고, 최댓값과 최솟값 사이의 폭도 함께 확인합니다.
4. 측정값 차이가 150ms를 넘거나, 시간 초과가 잦거나, 간헐적으로 수 초가 표시되는 노드는 예비 노드로 내립니다.
5. 피크 시간대인 20:00~23:00에도 한 번 더 측정해 한산한 시간대의 데이터만으로 결정하지 않도록 합니다.

예를 들어 세 노드의 3회 측정 결과가 각각 A: 62, 65, 63ms, B: 41, 286, 79ms, C: 96, 101, 99ms라고 해 보겠습니다. A는 상호작용 작업의 주력 노드로 가장 적합하고, C는 수치가 아주 낮지는 않지만 변동이 작아 장시간 연결에도 적합합니다. B는 최저 수치만 보면 가장 좋아 보이지만 안정성이 가장 떨어지므로 41ms라는 이유만으로 1순위에 두면 안 됩니다.

자동 선택 그룹의 설정을 지나치게 민감하게 만들지 마세요

mihomo와 호환 가능한 Clash 설정에서는 url-test 전략 그룹으로 지연 시간이 낮은 노드를 주기적으로 선택할 수 있습니다. 아래 설정은 300초마다 확인하고, 50ms의 허용 오차를 적용해 노드가 불필요하게 오가는 현상을 줄입니다.

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,github.com,Auto
  - MATCH,Auto

tolerance: 50은 속도를 높이는 옵션이 아니라, 가까운 두 노드가 수십 ms의 변동만으로 계속 바뀌는 것을 막는 설정입니다. 잦은 전환은 기존 연결을 끊을 수 있어 로그인 세션, 다운로드, 영상 버퍼링에 영향을 줍니다. 테스트 URL도 안정적이고 응답 본문이 작으며 실제로 접속 가능한 주소를 선택해야 합니다. 테스트 주소를 바꾸면 측정 수치도 달라집니다.

두 번째 기준: 배율은 요금제 소모량을 결정할 뿐, 속도 등급이 아닙니다

배율은 트래픽 과금 계수입니다. 노드에 0.5배, 1배, 1.5배, 2배가 표시되어 있다면 실제 트래픽 10GB를 사용할 때 요금제에서 각각 5GB, 10GB, 15GB, 20GB가 차감되는 경우가 일반적입니다. 구체적인 정산 방식은 구독 제공업체의 안내를 따라야 하지만 핵심은 같습니다. 배율은 사용 가능한 트래픽의 비용에 영향을 줄 뿐, 대역폭이나 지연 시간을 직접 결정하지 않습니다.

배율이 낮은 노드도 빠를 수 있지만 피크 시간대에 혼잡할 수 있고, 배율이 높은 노드도 더 좋은 국제 회선을 사용해서일 수도 있으며 단지 해당 지역의 리소스 비용이 높기 때문일 수도 있습니다. “2배”를 “두 배 빠르다”로 이해해서는 안 됩니다. 배율이 가치 있는지는 실제 작업으로 판단해야 합니다. 같은 30GB 파일을 1배 노드는 20분, 2배 노드는 16분에 완료한다고 해도 급하지 않다면 요금제 트래픽을 추가로 30GB 차감할 만큼 이득이 크지 않습니다.

작업별로 전략 그룹을 나누세요

보다 안정적인 방법은 낮은 배율의 노드와 품질이 높은 노드를 별도 그룹으로 구성하는 것입니다. 대용량 작업은 낮은 배율 그룹을 수동으로 선택하고, 회의·원격 터미널·중요한 업로드에는 안정적인 회선 그룹을 사용합니다. 규칙으로 작업을 해당 그룹에 보내면 매번 수십 개 노드 중에서 다시 찾을 필요가 없습니다.

proxy-groups:
  - name: Bulk-Traffic
    type: select
    proxies:
      - HK-LowRate
      - SG-LowRate
      - DIRECT

  - name: Stable-Line
    type: select
    proxies:
      - HK-Premium
      - JP-Premium
      - SG-Premium

rules:
  - DOMAIN-SUFFIX,example-download.com,Bulk-Traffic
  - DOMAIN-SUFFIX,example-meeting.com,Stable-Line
  - MATCH,Stable-Line

세 번째 기준: 지역은 출구 위치와 우회 경로에 영향을 줍니다

노드 이름에 표시된 홍콩·일본·싱가포르·미국은 보통 프록시 출구가 위치한 지역을 뜻합니다. 대상 웹사이트에는 해당 출구 주소가 보이므로 지역은 검색 결과, 현지화 콘텐츠, 계정 보안 판정, 스토어 지역, 스트리밍 콘텐츠 라이브러리에 영향을 줍니다. 또한 지역에 따라 로컬 네트워크에서 프록시 진입점으로, 다시 대상 서버로 이어지는 대략적인 경로도 달라집니다.

가까운 지역이 항상 최단 경로는 아니지만 기본 후보로 삼기 좋습니다

중국 본토 사용자는 보통 홍콩·일본·싱가포르처럼 가까운 지역부터 테스트합니다. 물리적 거리가 가까워 평균 지연 시간이 유럽이나 북미 노드보다 낮은 경우가 많습니다. 그러나 통신사 간 연결 품질, 진입점 위치, 회선 라우팅에 따라 크게 우회할 수 있습니다. 예를 들어 현지에서 홍콩 노드로 연결할 때 다른 지역을 먼저 거치면 최종 지연 시간이 도쿄 노드보다 높아질 수 있습니다. 따라서 “지도에서 가장 가까운 곳을 고르기”는 후보를 만드는 용도로만 쓰고 최종 결정은 실측으로 해야 합니다.

• 웹 탐색과 메신저: 안정적이고 지연 시간이 짧은 인접 지역을 우선하며, 보통 홍콩·일본·싱가포르부터 시작합니다.
• 지역 제한 콘텐츠: 이용하려는 콘텐츠의 대상 지역을 직접 선택한 뒤 해당 출구가 실제로 작동하는지 테스트합니다.
• 해외 쇼핑과 계정 로그인: 평소 사용하는 지역을 최대한 유지하고, 몇 분 안에 여러 국가를 오가며 전환하지 마세요.
• 코드 저장소와 소프트웨어 리포지터리: 노드 패널의 지연 시간만 보지 말고 대상 사이트의 실제 다운로드 속도를 비교하세요.
• 대륙 간 원격 데스크톱: 원격 호스트에 가까운 쪽을 우선하고 키보드·마우스 반응과 패킷 손실을 확인하세요.

노드 이름만으로 콘텐츠 이용 가능 여부를 판단할 수 없습니다

“미국 노드”라는 표시는 출구 지역만 알려 줄 뿐, 특정 동영상 플랫폼이나 AI 서비스, 스토어가 해당 주소를 반드시 허용한다는 뜻은 아닙니다. 데이터센터 주소가 플랫폼에 식별되어 제한될 수 있고, 같은 지역의 노드라도 결과가 다를 수 있습니다. 이런 노드를 선택할 때는 구독 이름에 “스트리밍”이라고 적혀 있는지만 보지 말고 대상 서비스의 메인 화면, 로그인, 재생, 화질 전환을 직접 확인해야 합니다.

테스트할 때는 DNS 위치로 인한 간섭도 배제해야 합니다. 클라이언트에서 mihomo의 Fake-IP DNS 또는 TUN 모드를 사용하면 도메인 해석과 트래픽 가로채기 방식이 달라집니다. “노드 지역은 맞는데 콘텐츠가 여전히 다르게 표시되는” 경우 먼저 「설정」→「네트워크」→「TUN 모드」가 활성화되어 있는지 확인한 다음, 설정의 dns, nameserver, proxy-server-nameserver와 규칙 매칭 기록을 살펴보세요. TUN은 더 많은 시스템 트래픽을 가로챌 뿐 노드 품질을 자동으로 높여 주지는 않습니다.

네 번째 기준: 프로토콜은 호환성과 네트워크 적응력을 좌우합니다

프로토콜은 필수 확인 조건입니다. 구독에 노드가 있다고 해서 현재 클라이언트 커널이 반드시 올바르게 사용할 수 있는 것은 아닙니다. 기존 Clash 커널과 mihomo는 지원 범위가 다르고, 그래픽 클라이언트에 포함된 커널 버전도 서로 다를 수 있습니다. 노드 속도 측정이 모두 시간 초과되거나, 가져온 뒤 노드가 사라지거나, 연결이 즉시 실패한다면 속도 측정을 계속 누르기보다 클라이언트의 커널 유형과 실행 로그부터 확인해야 합니다.

주요 프로토콜에서 실제로 확인할 점

프로토콜 이름만으로 모든 속도 차이를 예측할 수는 없습니다. 회선 품질이 좋은 Shadowsocks 노드가 혼잡한 Hysteria2 노드보다 안정적일 수 있고, 반대의 경우도 가능합니다. 실제 사용감은 프로토콜 구현, 서버 부하, 진입점과 출구 회선, 로컬 네트워크의 TCP·UDP 처리 방식, 설정 매개변수의 일치 여부가 함께 결정합니다.

UDP 프로토콜은 실제 네트워크에서 검증해야 합니다

Hysteria2와 TUIC는 UDP에 의존합니다. 가정용 인터넷에서 잘 작동한다고 해서 회사 Wi-Fi, 학교 네트워크, 호텔 네트워크, 모바일 핫스팟에서도 같은 결과가 나온다는 보장은 없습니다. 일부 네트워크는 UDP를 제한하거나 세션 유지 시간을 줄이고, 빈번한 UDP 트래픽을 제어합니다. 보통 속도 측정 시간 초과, 연결 후 몇 초 만에 끊김, 웹페이지는 간헐적으로 열리지만 지속 전송은 실패하는 형태로 나타납니다.

검증 방법은 간단합니다. 같은 네트워크에서 TCP 계열 노드와 UDP 계열 노드를 각각 테스트하고, 10분 동안 영상을 연속 재생한 다음 약 500MB의 테스트 파일을 전송합니다. UDP 노드의 속도가 자주 0으로 떨어지고 TCP 노드가 안정적이라면 해당 네트워크의 기본 대체 노드로 TCP 노드를 지정하세요. 모바일 핫스팟으로 바꾼 뒤 다시 측정하면 결과가 완전히 달라질 수 있습니다.

네 가지 기준을 하나의 선택 절차로 묶기

1단계: 호환성 정리

구독을 한 번 업데이트한 뒤 「프록시」→「전략 그룹」에서 노드가 빠짐없이 표시되는지 확인합니다. 후보 노드의 속도를 측정하고 커널 로그에서 unsupported, timeout, TLS 핸드셰이크 실패, DNS 해석 실패 등의 메시지를 확인하세요. 3회 연속 연결을 만들지 못한 노드는 먼저 후보에서 제외해 자동 선택 그룹에 방해가 되지 않도록 합니다.

2단계: 작업에 맞춰 지역 고정

일반적인 웹 탐색에는 홍콩·일본·싱가포르 등 인접 지역 2~3곳을 남기고, 지역 제한 콘텐츠에는 대상 지역만 남깁니다. 한 번에 20~30개의 노드를 남겨 지연 시간 수치만으로 결정하게 하지 마세요. 지역마다 담당하는 작업이 다르기 때문입니다. Daily, Streaming-US, Development 같은 전략 그룹을 만들어 지역과 용도를 명확히 분리할 수 있습니다.

3단계: 배율 예산 계산

요금제에 120GB가 남아 있고 이번 달이 20일 남았다면 하루 평균 예산은 약 6GB입니다. 2배 노드를 계속 사용하면 하루 실제 전송량이 3GB만 되어도 약 6GB가 차감됩니다. 25GB짜리 시스템 이미지 한 번을 내려받으면 약 50GB가 차감될 수 있습니다. 이 경우 다운로드에는 낮은 배율 노드를 사용하고, 회의·원격 연결·긴급 작업에는 안정적인 고배율 회선을 남겨 두는 편이 좋습니다.

4단계: 지연 시간 선별 후 실제 작업 테스트

1. 3회 연속 속도 측정을 실시하고 변동이 작은 노드 3~5개를 남깁니다.
2. 자주 이용하는 웹사이트를 열어 최초 연결과 연속 페이지 이동이 원활한지 확인합니다.
3. 1080p 영상을 최소 10분간 재생합니다. 일반적으로 약 8~12Mbps의 지속 속도가 필요하지만 플랫폼의 인코딩 방식에 따라 달라집니다.
4. 4K가 필요하다면 약 25Mbps 이상의 처리량을 지속적으로 제공하는지 확인하고, 화질이 반복해서 낮아지는지도 살펴봅니다.
5. 500MB~1GB 파일을 다운로드하고 최고 속도가 아니라 전송 속도가 안정적인지 기록합니다.
6. 실제로 사용할 시간대에 다시 측정하고, 피크 시간대에 지속적으로 속도가 떨어지는 노드는 예비 그룹에 넣습니다.

최종적으로는 주력 노드 하나와 다른 회선 또는 다른 프로토콜을 사용하는 예비 노드 하나를 남기는 것이 좋습니다. 주력 노드는 일상적인 트래픽을 담당하고, 주력 노드가 시간 초과되거나 패킷 손실이 발생하거나 대상 서비스를 이용할 수 없을 때 수동으로 예비 노드로 전환합니다. 자동 fallback 그룹으로 가용성에 따른 전환을 구성할 수도 있지만, 노드를 바꿔도 기존 연결이 모두 유지되는 것은 아니므로 진행 중인 다운로드나 세션은 다시 연결될 수 있습니다.

자주 쓰는 4가지 상황별 조합 가이드

웹 탐색과 메신저

우선순위는 안정성, 지연 시간, 배율, 지역 순입니다. 먼저 50~120ms이고 3회 측정 변동 폭이 40ms 미만인 인접 지역 노드를 고르며, 배율은 1배 안팎으로 맞추면 됩니다. 프로토콜은 최신인지보다 현재 네트워크와 커널에서 안정적으로 연결되는지가 중요합니다. 지역을 자주 바꾸면 웹사이트에서 재인증을 요구할 수 있습니다.

스트리밍과 장시간 영상 시청

우선순위는 지역 이용 가능 여부, 지속 처리량, 배율, 지연 시간 순입니다. 먼저 대상 지역 콘텐츠가 재생되는지 확인한 다음 10~20분 동안 화질 저하나 버퍼링이 발생하는지 관찰합니다. 80ms와 130ms의 차이보다 안정적인 30Mbps와 5~60Mbps로 크게 변동하는 속도의 차이가 보통 더 중요합니다. 대용량 영상을 보기 전 배율을 계산해 4K 영상 몇 편만으로 요금제를 빠르게 소진하지 않도록 하세요.

원격 개발, SSH, 원격 데스크톱

우선순위는 변동 폭, 패킷 손실, 지연 시간, 프로토콜 순입니다. 터미널 입력은 지속적인 고대역폭을 요구하지 않지만 지연 시간이 갑자기 80ms에서 800ms로 뛰는 상황에는 매우 취약합니다. 3회 측정 결과가 안정적이고 장시간 연결이 재설정되지 않는 노드를 고르세요. 회사 네트워크를 사용한다면 UDP가 제한될 때 빠르게 전환할 수 있도록 TCP 계열 예비 노드를 준비하세요.

대용량 다운로드와 클라우드 드라이브 동기화

우선순위는 배율, 지속 처리량, 안정성, 지연 시간 순입니다. 먼저 0.5배 또는 1배 노드를 선택해 500MB 이상의 전송을 테스트하세요. 지연 시간이 150ms여도 20MB/s를 안정적으로 유지하는 노드가 지연 시간 50ms이지만 속도가 1~30MB/s 사이에서 계속 흔들리는 노드보다 대용량 파일에 적합한 경우가 많습니다.

자주 하는 오해

• 한 번만 측정하기: 단일 측정 결과는 DNS 캐시, 연결 재사용, 순간적인 혼잡의 영향을 받기 쉽습니다.
• 배율을 속도로 오해하기: 배율은 과금 계수이지 대역폭 배수가 아닙니다.
• 지역 이름만 보고 이용 가능하다고 단정하기: 출구 주소가 대상 플랫폼에서 허용되는지는 실제 접속으로 확인해야 합니다.
• 새 프로토콜이 반드시 더 빠르다고 생각하기: 프로토콜은 회선을 구성하는 한 요소일 뿐이며, 회선 품질과 부하가 보통 더 중요합니다.
• TUN을 켠 뒤 다시 측정하면 끝났다고 생각하기: TUN은 시스템 트래픽을 가로채는 범위를 바꿀 뿐 혼잡한 노드를 고쳐 주지는 않습니다.
• 전략 그룹을 너무 자주 전환하기: 자동 전환은 장시간 연결을 끊을 수 있으므로 허용 오차와 검사 간격을 보수적으로 설정해야 합니다.
• 사용 시간대를 무시하기: 새벽에 빠르게 측정된 노드가 피크 시간대에는 전혀 다른 모습을 보일 수 있습니다.

노드 선택에 영원히 정답인 방법은 없습니다. 네트워크 진입점, 서버 부하, 대상 사이트의 라우팅은 계속 변합니다. 더 효과적인 방법은 일정한 점검 절차를 유지하는 것입니다. 프로토콜은 호환성을 먼저 확인하고, 지역은 작업에 맞추며, 배율은 비용을 관리하고, 지연 시간은 1차 선별에 활용한 뒤, 마지막으로 실제 작업으로 검증합니다. 이렇게 하면 구독 노드의 이름과 수가 바뀌어도 몇 분 안에 주력 노드와 대체 노드를 다시 찾을 수 있습니다.