Clash 노드 선택 가이드: 지연 시간·트래픽 배수·지역·프로토콜 비교

1. 용도에 맞는 노드를 고른 뒤 지연 시간을 비교하세요

Clash에 표시되는 노드는 보통 원격 프록시 서버에 연결하기 위한 설정 정보입니다. 연결된다고 해서 모든 작업에 적합한 것은 아니며, 지연 시간이 짧다고 다운로드 속도가 빠른 것도 아닙니다. 먼저 용도를 정하세요. 웹 서핑은 응답 속도, 동영상 시청은 지속 전송 속도와 지역별 이용 가능 여부가 중요합니다. 화상 회의라면 지터와 패킷 손실, UDP 연결도 확인해야 합니다.

‘이용하려는 서비스 접속 가능 여부 → 출구 지역 → 트래픽 배수 → 저녁 시간대 안정성 → 지연 시간’ 순으로 확인하는 것이 좋습니다. 필수 조건을 충족하지 못하는 노드를 먼저 제외한 뒤 나머지를 비교하면, 최저 지연 시간만 보고 선택하는 것보다 정확합니다.

항목	확인할 내용	이것만으로는 알 수 없는 내용
지연 시간	같은 테스트 URL로 여러 번 측정해 편차와 시간 초과 여부 확인	최대 대역폭, 모든 사이트의 접속 속도
트래픽 배수	요금제 안내와 사용량 대시보드의 실제 차감 기준	회선이 반드시 더 빠르거나 안정적이라는 점
지역	이용하려는 서비스가 인식하는 출구 IP 지역	노드 이름과 실제 서버 위치가 정확히 일치한다는 점
프로토콜	클라이언트 커널 지원 여부, UDP 지원, 현재 네트워크에서의 동작	특정 프로토콜이 모든 네트워크에서 가장 빠르다는 점

2. 지연 시간 테스트: 최저값보다 반복 결과를 확인하세요

HTTP 지연 시간은 ICMP ping과 다릅니다

Clash 계열 클라이언트는 보통 작은 HTTP 또는 HTTPS 주소에 요청을 보내 프록시 연결 상태를 확인하고 결과를 밀리초 단위로 표시합니다. 서버에 ICMP ping을 보내는 것과는 다릅니다. 측정 시간에 포함되는 단계는 커널 구현, 연결 재사용, 프로토콜 핸드셰이크, 테스트 주소에 따라 달라집니다. 주로 프록시를 통해 지정된 주소에 접속했을 때의 응답을 보여 줍니다.

같은 노드라도 사이트마다 출구 경로나 CDN이 다를 수 있습니다. 테스트 주소에서 빠른 응답을 받았다고 해서 동영상 사이트, 코드 저장소, 화상 회의도 원활하다고 단정할 수는 없습니다. 테스트 URL 자체에 접속할 수 없는 경우도 있으므로 전체 그룹에서 시간 초과가 발생하면 구독을 바로 삭제하기보다 테스트 대상을 먼저 확인하세요.

조건을 고정하고 5회 측정하세요

기기, 네트워크, 테스트 URL을 동일하게 유지하고 다운로드, 클라우드 동기화 등 대역폭을 사용하는 작업은 잠시 중단하세요.
후보 노드 3개를 정해 각각 5회 측정하세요. 측정 간격은 약 10초로 두고 지연 시간과 시간 초과 횟수를 기록합니다.
중앙값과 편차를 우선 비교하세요. 자주 사용하는 시간대, 예를 들어 현지 시간 20:00~23:00에도 다시 측정합니다.
실제 용도로 확인하세요. 웹페이지를 여러 번 열어 보고, 동영상은 몇 분간 버퍼링을 관찰하며, 회의에서는 음성 끊김과 패킷 손실을 확인합니다.

가상의 측정 결과를 예로 들면 A는 45, 48, 220, 시간 초과, 190ms이고 B는 80, 82, 79, 85, 81ms입니다. A의 최저값은 더 낮지만 B의 결과가 훨씬 일정합니다. 웹 상호작용이나 회의에는 B를 우선 검증해 볼 만합니다. 이 숫자는 비교 방법을 설명하기 위한 예시이며 실제 회선 측정값이 아닙니다.

지연 시간·전송 속도·지터를 따로 확인하세요

지연 시간이 40ms인 노드라도 사용 가능한 대역폭이 낮을 수 있고, 150ms인 노드도 대용량 파일을 안정적으로 전송할 수 있습니다. 다운로드 속도는 서버 부하, 네트워크 혼잡, 원격 서버의 속도 제한, 로컬 인터넷 회선에 따라 달라집니다. 속도 테스트는 트래픽을 소모하므로 소규모 테스트로 먼저 후보를 추린 뒤 일부 노드에서만 지속 속도를 확인하세요. 모든 노드에서 대용량 파일을 내려받아 테스트할 필요는 없습니다.

3. 트래픽 배수: 서비스 제공업체의 기준으로 사용량을 계산하세요

‘0.5배’, ‘1배’, ‘2배’는 보통 구독 서비스 제공업체의 요금 계산 표기이며, Clash 커널 공통의 과금 설정은 아닙니다. 클라이언트에 표시된 노드 이름의 배수는 단순한 텍스트이므로 이름을 바꿔도 차감 방식은 달라지지 않습니다. 실제 차감 기준은 제공업체의 정책과 사용량 대시보드에서 확인하세요. 업로드와 다운로드를 합산하는지, 시간대별 배수나 별도 트래픽 풀이 있는지도 살펴봐야 합니다.

과금 대상 사용량 = 과금 대상 전송량 × 노드 배수

예: 다운로드 8 GB, 업로드 2 GB, 양방향 합산 과금
0.5배: 10 GB × 0.5 = 5 GB
1배:  10 GB × 1   = 10 GB
2배:  10 GB × 2   = 20 GB

위 계산은 이해를 돕기 위한 단순한 예입니다. 집계 주기, 단위 환산, 프로토콜 오버헤드 때문에 클라이언트와 서버 대시보드의 사용량이 정확히 일치하지 않을 수 있습니다. 적은 양을 한 번 테스트한 뒤 차이가 있다고 해서 과금 오류로 판단하지 마세요. 대시보드 수치를 기록하고 전송량을 조절해 테스트한 다음, 사용량 통계가 갱신되면 다시 비교하세요.

웹 서핑 및 메신저: 사용량이 적은 편이므로 응답 속도와 안정성을 우선 고려할 수 있습니다.
운영체제 이미지 및 대규모 업데이트: 프록시가 필요한지 먼저 확인하고, 배수가 낮은 노드의 지속 전송 속도를 비교하세요.
장시간 동영상 시청: 하루 시청량을 사용량 예산에 반영하세요. 한 번 재생이 원활한지만 확인해서는 안 됩니다.

높은 배수는 서비스 제공업체가 정한 특수 회선일 수도 있고 단순한 요금 정책일 수도 있습니다. 대역폭이나 안정성을 보장하는 기술적 기준은 아닙니다. 장기간 사용할 노드라면 같은 시간대의 실제 성능과 차감량을 함께 기록해야 비용 대비 효율을 판단할 수 있습니다.

4. 출구 지역: 이용하려는 서비스가 인식하는 지역을 확인하세요

노드 이름에 표시된 ‘홍콩’, ‘일본’, ‘미국’은 보통 예상 출구 지역을 뜻하지만, 이름만으로 실제 지역을 확인할 수는 없습니다. 중계 서버와 최종 출구가 서로 다른 지역에 있을 수 있고 IP 위치 정보도 늦게 갱신될 수 있습니다. 확인해야 할 것은 이용하려는 서비스가 어떤 출구 IP를 확인하고, 그 IP를 어느 지역으로 인식하는지입니다.

지역이 맞아도 서비스 이용이 보장되지는 않습니다

스트리밍을 비롯한 지역 제한 서비스는 IP 지역뿐 아니라 데이터센터·가정용 네트워크 여부, 계정 지역, 결제 정보, 위험 관리 상태 등을 함께 확인할 수 있습니다. 로그인 페이지가 열려도 모든 콘텐츠를 재생할 수 있는 것은 아니며, 프로그램 하나를 재생했다고 전체 콘텐츠를 이용할 수 있는 것도 아닙니다. ‘차단 해제’ 여부는 특정 서비스와 콘텐츠, 테스트 시점을 기준으로 확인해야 합니다. 노드 이름만 보고 판단하지 마세요.

이용하려는 서비스에 연결된 전략 그룹에서 노드를 선택하고, 기존 페이지를 닫거나 연결을 종료한 뒤 다시 접속하세요.
클라이언트 연결 기록에서 해당 서비스의 요청이 예상한 규칙과 노드를 거쳤는지 확인하세요.
출구 IP의 지역을 확인한 다음 대상 서비스에서 특정 콘텐츠를 재생하는 등 실제 동작을 테스트하세요.
결과가 예상과 다르면 계정 지역, 앱의 위치 권한, IPv6 경로, 관련 도메인이 DIRECT로 연결되는지 확인하세요.

DNS 조회 위치와 최종 출구 지역은 서로 다른 개념입니다. DNS 서버를 바꿔도 프록시 출구가 다른 국가로 자동 변경되지는 않습니다. 일부 요청이 DIRECT로 연결되거나 IPv6가 예상 경로를 우회한다면 노드 지역을 따지기 전에 트래픽 처리와 분기 설정부터 수정하세요. 관련 설정을 확인하려면 전체 문서를 참고하세요.

5. 프로토콜 종류: 커널 지원과 전송 환경부터 확인하세요

Shadowsocks, Trojan, VMess, VLESS, Hysteria2, TUIC는 서로 다른 프로토콜 또는 프로토콜 체계를 가리킵니다. 정해진 속도 등급을 뜻하지는 않습니다. 실제 성능은 프로토콜 설정, 전송 계층, 서버 구현, 네트워크 혼잡, 로컬 네트워크 제한에 따라 달라집니다. 같은 프로토콜이라도 서버가 바뀌면 프로토콜을 바꾸는 것보다 성능 차이가 클 수 있습니다.

Shadowsocks: 암호화 방식과 커널 지원 범위를 확인하세요. 별도 플러그인을 사용하는 노드라면 클라이언트가 해당 플러그인을 지원하는지도 확인해야 합니다.
Trojan: 일반적으로 TLS를 사용합니다. 서버 주소, 포트, 인증 정보, TLS 설정이 서로 일치해야 합니다.
VMess / VLESS: 프로토콜 이름뿐 아니라 전송 방식과 TLS 등의 설정도 확인하세요. WebSocket과 gRPC 설정은 임의로 서로 바꿔 쓸 수 없습니다.
Hysteria2 / TUIC: QUIC 기반이며 UDP 연결이 필요합니다. 네트워크에서 UDP를 제한하면 연결되지 않을 수 있습니다. 다른 TCP 노드가 작동한다고 해서 설정이 올바르다고 단정하지 마세요.

Clash는 클라이언트 생태계에서 흔히 쓰이는 이름이며, 실제 프로토콜 지원 범위는 실행 중인 커널과 버전에 따라 달라집니다. 원본 Clash와 Clash Meta(현재 mihomo로 불림)의 지원 기능은 서로 다릅니다. 가져오기 과정에서 ‘지원하지 않는 프록시 유형’ 오류가 발생하면 먼저 커널을 확인하세요. YAML의 type 값을 다른 값으로 바꿔도 서버 프로토콜이 변환되지는 않습니다.

6. url-test: 조건을 충족한 노드 중 지연 시간이 짧은 노드 선택

지역, 배수, 실제 서비스 이용 가능 여부를 확인한 다음 url-test로 후보 노드의 지연 시간을 비교하세요. 지역이나 비용, 사용 조건이 서로 다른 모든 노드를 하나의 자동 그룹에 넣지 마세요. 지연 시간이 가장 짧은 노드가 현재 용도에 맞지 않을 수 있습니다.

아래 예시는 mihomo용입니다. 기존 설정의 proxies에 HK-01, HK-02라는 노드가 있고, 두 노드 모두 같은 용도에 적합한지 확인했다고 가정합니다. 노드 이름은 참조 관계를 보여 주기 위한 예시이므로 실제 설정에서는 기존 노드 이름과 정확히 일치시켜야 합니다.

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300: 검사 간격은 300초입니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용 오차를 50밀리초로 설정해 미세한 지연 시간 차이로 자주 전환되는 것을 줄입니다.
lazy: true: 지연 검사를 활성화합니다. 그룹을 사용하지 않을 때도 정해진 간격으로 계속 검사한다고 이해해서는 안 됩니다.
url: 안정적으로 짧은 응답을 반환하는 테스트 주소를 사용하세요. 예시 주소는 보통 HTTP 204를 반환하지만 현재 네트워크와 노드에서 접속 가능한지 확인해야 합니다.

이 코드는 완성된 설정이 아닙니다. 그룹 항목은 기존 proxy-groups 목록에 합치세요. 같은 YAML 최상위에 해당 키를 중복으로 추가하면 안 됩니다. 노드가 proxy-providers에서 제공된다면 제공자 구조에 맞춰 use와 적절한 필터 조건을 사용하세요. 위의 정적 노드 참조를 제공자 설정 대신 그대로 쓸 수 있다고 가정하면 안 됩니다.

7. fallback: 순서대로 사용할 수 있는 예비 노드 선택

fallback과 url-test는 목적이 다릅니다. 전자는 후보 순서대로 사용 가능한 노드를 선택하고, 후자는 연결 테스트 지연 시간을 비교합니다. 평소에는 우선 노드를 사용하다가 테스트에 실패하면 예비 노드로 전환하려는 경우 fallback을 사용할 수 있습니다. 모든 서비스 장애에 즉시 전환되는 것은 아닙니다.

proxy-groups:
  - name: HK-FAILOVER
    type: fallback
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: PROXY
    type: select
    proxies:
      - HK-AUTO
      - HK-FAILOVER
      - HK-01
      - HK-02

이 설정은 앞 절과 같은 proxy-groups 목록에 추가하며, HK-AUTO가 이미 있어야 합니다. 이후 프록시가 필요한 규칙에서 PROXY를 참조하고 클라이언트에서 자동 그룹, 예비 그룹 또는 개별 노드를 선택하세요. 같은 이름의 전략 그룹이 이미 있다면 새 항목을 추가하지 말고 기존 항목을 수정하세요.

예를 들어 다음 규칙은 github.com 및 하위 도메인에 해당하는 요청을 PROXY로 보냅니다. 이 규칙은 해당 트래픽을 먼저 처리할 수 있는 포괄적인 규칙과 마지막의 MATCH 규칙보다 앞에 배치해야 합니다. 예시를 적용하려고 기존 분기 규칙을 전부 덮어쓰지 마세요.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  # 기존 규칙을 유지하고 최종 MATCH는 맨 뒤에 둡니다

첫 번째 노드에서 테스트 주소에는 계속 접속되지만 동영상 서비스에서 오류가 발생하면 fallback은 첫 번째 노드를 계속 사용할 수 있습니다. 이는 테스트 대상과 실제 서비스 대상이 다르기 때문에 생기는 한계입니다. 노드를 바꾸면 새 연결에는 적용되지만, 이미 진행 중인 다운로드나 동영상 재생, 장시간 연결이 자동으로 옮겨지지는 않을 수 있습니다. 앱을 다시 연결해야 할 수도 있습니다.

8. 평소 노드를 고를 때 확인할 항목

경로 확인: 대상 앱이 시스템 프록시나 TUN을 사용하며, 연결 기록에 예상한 전략이 표시되는지 확인하세요.
필수 조건 확인: 원하는 지역과 서비스가 이용 가능하고, UDP 등 필요한 기능이 실제로 작동하는지 확인하세요.
비용 확인: 노드 이름만 보지 말고 서비스 제공업체 대시보드에서 배수, 업로드 과금 여부, 잔여 트래픽을 확인하세요.
안정성 비교: 같은 조건으로 5회 테스트한 뒤 자주 사용하는 시간대에 편차, 시간 초과, 지속 속도를 확인하세요.
후보 그룹 구성: 용도가 같은 노드를 자동 그룹에 넣고, 검증을 마친 수동 선택지도 남겨 두세요.
변경 사항 저장: 먼저 설정을 백업하고 설정 검사를 실행한 뒤 로그를 확인하세요. 구독을 업데이트한 다음 사용자 지정 그룹이 덮어써지지 않았는지도 확인합니다.

노드 선택의 핵심은 언제나 지연 시간이 가장 짧은 노드를 찾는 것이 아닙니다. 용도가 명확하고 비용을 관리할 수 있으며 결과를 반복해서 검증할 수 있는 후보군을 마련하는 것입니다. 회선 상태는 시간대와 네트워크에 따라 달라집니다. 문제가 생기면 트래픽 처리, 규칙, 테스트 주소, 실제 서비스 중 어디에서 문제가 발생했는지 먼저 구분한 뒤 노드 변경을 결정하세요.