Clash 노드 선택 가이드: 지연 시간, 트래픽 배율, 지역 표시와 프로토콜

Clash 지연 시간 측정값의 의미와 한계를 알아보고, 노드 이름의 트래픽 배율·지역 표기와 프로토콜별 속도 및 배터리 소모를 살펴 노드를 선택하는 방법을 안내합니다.

노드 선택 순서: 연결 가능 여부를 먼저 확인하고 안정성과 비용 비교

구독을 가져오면 노드 목록에 지역, 배율, 회선, 프로토콜 정보가 함께 표시될 수 있습니다. Clash GUI 클라이언트는 이런 정보를 보여 주지만, 노드 이름은 보통 구독 제공자가 붙인 것이며 커널이 검증한 회선 성능 보고서는 아닙니다. 노드를 고를 때는 먼저 원하는 서비스에 접속할 수 있는지 확인한 다음 지연 시간 변동, 지속 전송 성능, 트래픽 비용을 비교하세요. 목록에서 가장 낮은 밀리초 수치만 보고 선택하는 것보다 신뢰할 수 있습니다.

  1. 설정과 모드 확인: 방금 가져온 설정을 활성화하고 규칙 모드를 사용합니다. 테스트할 웹사이트에 적용되는 규칙이 테스트 대상 정책 그룹을 가리키는지 확인하세요.
  2. 후보를 소수로 추리기: 지역이나 회선 유형이 서로 다른 노드 3개를 먼저 고릅니다. 수백 개 노드에 한꺼번에 테스트를 실행하지 마세요.
  3. 지연 시간 반복 측정: 같은 네트워크와 테스트 주소를 사용해 5회 측정하고, 가장 좋은 결과만 보지 말고 실패 횟수와 중앙값을 기록합니다.
  4. 실제 작업으로 확인: 자주 쓰는 웹사이트를 열거나 동영상을 재생하고, 크기를 아는 파일을 전송해 지속 속도와 전송 중단 여부를 확인합니다.
  5. 주·예비 노드 구성: 평소 사용할 노드 하나를 고르고 다른 회선의 예비 노드도 남겨 둡니다. 저녁 혼잡 시간대에 다시 확인하세요.

Clash 지연 시간 측정: 밀리초 수치가 의미하는 것

Clash와 mihomo에서 흔히 사용하는 지연 시간 측정은 지정한 프록시를 통해 테스트 URL에 HTTP 요청을 보내는 방식이며, 노드 서버에 일반 ICMP ping을 보내는 것이 아닙니다. 측정 결과에는 프록시 연결 설정, 회선 왕복 시간, 대상 사이트 응답, 캐시 및 연결 재사용 등이 영향을 줍니다. 구체적인 측정 방식은 커널과 클라이언트 구현에 따라 달라집니다.

따라서 80ms가 표시되면 이번 테스트 경로에서 노드 응답이 빨랐다고 볼 수는 있지만, 다운로드 속도가 반드시 빠르거나 다른 웹사이트에서도 원활하다는 뜻은 아닙니다. 테스트 주소에 접속할 수 없거나 DNS 조회에 실패하거나 노드 인증이 만료된 경우에도 시간 초과가 발생할 수 있습니다. 클라이언트에 표시된 timeout은 이번 테스트가 실패했다는 뜻이므로 로그를 함께 확인해 원인을 판단하세요.

주소와 네트워크를 고정하고 결과를 5회 비교

자동 테스트 그룹에서는 https://www.gstatic.com/generate_204처럼 짧은 응답을 반환하는 주소를 자주 사용합니다. 두 노드를 비교할 때 테스트 주소, Wi-Fi, 규칙 설정을 동시에 바꾸지 마세요. 아래 수치는 결과를 해석하는 방법을 보여 주기 위한 가상 예시이며, 이 사이트에서 측정한 값도 특정 구독 서비스의 성능을 나타내는 값도 아닙니다.

5회 지연 시간 측정 결과 해석 예시
노드 후보측정 결과 5회선택 기준
후보 A72、76、74、79、75 ms중앙값 75ms, 변동 폭이 작음
후보 B39, 240, 시간 초과, 310, 46ms최저값은 더 낮지만 실패가 발생하고 변동 폭이 큼
후보 C118、121、119、124、120 ms중앙값 120ms, 지속 전송 성능 추가 확인 가능

메신저나 반응형 웹페이지는 대체로 안정적인 응답이 중요합니다. 예시에서는 최저값만 보고 고른 B보다 A를 먼저 써 보는 편이 낫습니다. 대용량 파일 전송에서는 처리량도 확인해야 합니다. 지연 시간이 조금 더 긴 C도 사용 가능한 대역폭이 넉넉하다면 지속 속도가 더 빠를 수 있습니다. 5회 측정은 후보를 추리는 용도일 뿐, 장기적인 안정성을 계산할 수는 없습니다.

자동 테스트 그룹 설정의 의미

아래 mihomo 정책 그룹 설정 예시는 url-test로 기존 노드 두 개를 비교합니다. 설정에 HK-01과 JP-01이 이미 정의되어 있어야 이 예시를 유효하게 참조할 수 있습니다. 실제로 사용할 때는 구독에 표시된 노드 전체 이름으로 바꾸고 기존 proxy-groups 목록에 합치세요.

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - HK-01
      - JP-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  • interval: 300은 테스트 간격이 300초라는 뜻입니다. 테스트가 즉시 실행되는지는 지연 로딩 등의 설정에도 영향을 받습니다.
  • tolerance: 50은 전환 허용 오차입니다. 지연 시간이 조금 변할 때 잦은 전환을 줄여 주며, 노드 시간 초과 기준은 아닙니다.
  • 자동 선택은 테스트 주소의 지연 시간만 기준으로 삼으며, 동영상 서비스 이용 가능 여부, 계정의 이상 접속 감지, 다운로드 처리량은 평가하지 않습니다.

GUI 클라이언트는 구독 오버라이드나 확장 설정으로 정책 그룹을 관리할 수 있습니다. 구독에서 내려받은 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 먼저 클라이언트의 로컬 오버라이드 방식을 확인한 뒤 사용자 지정 테스트 그룹을 저장하세요. 규칙에서 정책 그룹을 참조하는 방법은 규칙 분기 참고를 확인하세요.

트래픽 배율: 노드 이름과 구독 데이터 차감 방식

노드 이름에 표시된 0.5x, 1x, 2x는 보통 서비스 제공자의 과금 배율을 의미합니다. Clash 커널의 속도 단계나 대역폭 배수가 아닙니다. 2x라고 속도가 두 배가 되는 것은 아니며, 0.5x라고 전송 속도가 절반으로 줄어드는 것도 아닙니다. 실제 데이터 차감 방식은 서비스 제공자가 정하므로 안내 내용과 계정 사용량 기록을 기준으로 확인하세요.

실제 사용량으로 비용 추산하기

어떤 서비스가 업로드와 다운로드를 합산한 트래픽에 배율을 곱해 제공량을 차감한다고 명시했다고 가정해 보겠습니다. 총 4GB를 전송하면 0.5배 노드는 약 2GB, 1배 노드는 약 4GB, 2배 노드는 약 8GB가 차감됩니다. 여기서는 같은 단위로 계산했습니다. 서비스가 십진법 GB와 이진법 GiB 중 어느 단위를 사용하는지, 통계 산정 방식이 어떤지에 따라 표시량은 달라질 수 있습니다.

  • 장시간 동영상 시청과 시스템 업데이트: 먼저 일반 배율 노드의 안정적인 처리량을 비교하고, 배율이 높은 회선은 꼭 필요한 작업에만 사용하세요.
  • 특정 지역 서비스 가끔 이용: 수동 선택 그룹을 따로 만들어 모든 트래픽이 배율 높은 노드를 거치지 않도록 하세요.
  • 이름 표시와 관리 페이지 정보가 다름: 구독을 새로고침한 뒤 서비스 제공자의 공지를 확인하세요. 이전 노드 이름만으로 현재 과금 방식을 추측하지 마세요.

지역 표시: 연결 진입 지점, 출구 IP와 대상 서비스

‘홍콩’, ‘일본’, ‘미국’은 출구 지역을 나타낼 수도 있고 회선을 홍보하기 위한 이름일 수도 있습니다. 일부 중계 노드는 한 지역에서 연결을 받고 다른 지역을 출구로 삼아 웹사이트에 접속합니다. 클라이언트에 표시된 연결 서버 주소만으로 대상 웹사이트에서 보이는 출구 위치를 확정할 수는 없습니다.

지역 표시만 보지 말고 대상 서비스에서 출구 확인

  1. 대상 웹사이트에 적용되는 정책 그룹에서 후보 노드를 직접 선택합니다.
  2. 기존 연결을 종료한 뒤 페이지를 다시 엽니다. 필요하면 관련 앱을 완전히 종료하고 다시 실행해 기존 세션을 재사용하지 않도록 하세요.
  3. 신뢰할 수 있는 IP 조회 서비스에서 출구 IP와 지역을 확인하고, 실제 대상 서비스에서도 접속 가능 여부를 확인합니다.
  4. 두 결과가 다르면 IP 데이터베이스 갱신 지연, 계정 지역, 결제 정보 또는 서비스 자체 제한을 고려하세요.

지역이 맞더라도 서비스 이용이 보장되는 것은 아닙니다. 서버가 데이터센터 IP를 식별하거나 계정 지역과의 일치를 요구하거나 같은 출구에서 발생하는 요청이 많은 경우 제한할 수 있습니다. DNS 설정도 서비스가 사용자를 식별하는 방식에 영향을 줄 수 있지만, DNS를 바꿔도 출구 IP가 다른 국가 주소로 바뀌지는 않습니다. 로그인 지역을 안정적으로 유지해야 하는 계정은 출구를 비교적 고정하고 자동 테스트 그룹이 국가를 자주 바꾸지 않도록 하세요.

‘전용 회선’, ‘중계’, ‘직결’도 구분해서 이해해야 합니다. 직결 노드는 보통 로컬 네트워크에서 원격 서버로 바로 연결되고, 중계 회선은 중간 전달 지점을 추가합니다. 전용 회선의 구체적인 범위는 서비스 제공자의 구성에 따라 다릅니다. 이름만으로 종단 간 연결 경로가 입증되는 것은 아니므로 혼잡, 우회 경로, 패킷 손실 여부는 시간대를 달리해 실제 작업으로 확인해야 합니다.

프로토콜 유형: 호환성, UDP와 모바일 기기 배터리 소모

Clash GUI 클라이언트는 화면과 설정을 관리하며, 실제 프로토콜 지원 여부는 실행 중인 커널과 버전에 따라 달라집니다. 원본 Clash와 Clash Meta(현재 mihomo)는 지원 기능이 다릅니다. 구독 변환을 해도 구형 커널에 없는 프로토콜 구현이 자동으로 추가되지는 않습니다. ‘알 수 없는 프록시 유형’ 같은 설정 오류가 발생하면 같은 유형의 노드를 계속 바꾸기보다 커널 버전을 기록하고 프로토콜 지원 여부부터 확인하세요.

자주 쓰이는 프로토콜별 확인 사항
프로토콜연결 특성확인할 항목
ShadowsocksTCP를 지원하며 UDP 지원 여부는 노드 설정과 실행 환경에 따라 다름암호화 방식, 플러그인 필요 여부, 클라이언트 호환성
Trojan일반적인 구현에서는 TLS로 연결을 전송서버 이름, 인증서, UDP 지원 여부, 서버 설정
VMess / VLESS다양한 전송 계층 및 보안 설정과 함께 구성 가능전송 매개변수, TLS 또는 REALITY 설정, 커널 지원 여부
Hysteria2QUIC 기반이며 하위 계층의 UDP 연결이 가능해야 함네트워크의 UDP 제한 여부, 서버 설정, 대역폭 매개변수
TUICQUIC 기반이며 하위 계층의 UDP 연결이 가능해야 함커널 구현, 프로토콜 버전, 서버 호환성

프로토콜 이름만으로 속도를 비교할 수 없습니다

프로토콜 성능은 서버 부하, 네트워크 품질, 혼잡 제어, 전송 계층 캡슐화, 기기 성능이 함께 좌우합니다. 같은 프로토콜을 사용하는 노드라도 성능 차이가 클 수 있습니다. UDP가 제한된 네트워크에서는 Hysteria2나 TUIC 연결이 제대로 설정되지 않을 수 있지만, 다른 네트워크에서는 성능이 좋을 수 있습니다. 게임이나 음성 통화 같은 UDP 앱을 쓰려면 노드와 정책, 로컬 접속 방식이 모두 해당 트래픽을 처리해야 합니다. 브라우저에서 웹페이지가 열린다는 사실만으로 UDP 연결이 정상이라고 판단할 수는 없습니다.

같은 작업 조건에서 배터리 소모 비교

휴대폰 배터리 소모는 암호화만으로 결정되지 않습니다. 약한 신호, 반복 전송, 잦은 속도 테스트, 백그라운드 연결, 대량 데이터 전송도 배터리 사용량을 늘립니다. TUN 모드는 트래픽을 가로채는 기능이지 새로운 프록시 프로토콜이 아닙니다. 더 많은 앱 트래픽이 프록시 커널을 거치게 될 수 있으므로 배터리 사용량 변화의 원인을 선택한 노드 프로토콜 하나로 돌릴 수는 없습니다.

  • 같은 Wi-Fi를 사용하고 화면 밝기를 비슷하게 맞춘 뒤, 동일한 화질의 동영상을 20분 연속 재생하는 등 같은 작업으로 비교하세요.
  • 불필요한 고주파 속도 테스트를 끄고, 테스트 요청이 모바일 네트워크와 배터리에 주는 영향을 줄이세요.
  • 시스템의 배터리 사용량 통계와 기기 온도를 확인하세요. 짧은 시간 동안의 배터리 잔량 변화는 대략적인 참고값으로만 활용할 수 있습니다.
  • 특정 노드에서만 기기가 눈에 띄게 뜨거워지거나 연결이 끊긴다면 재연결 로그와 서버 부하를 확인한 뒤 프로토콜을 바꿀지 결정하세요.

실제 처리량 확인: 로컬 포트와 재현 가능한 기록

클라이언트의 ‘낮은 지연 시간’ 테스트만으로는 지속 다운로드 성능을 판단하기 어렵습니다. 먼저 자주 쓰는 웹사이트에 접속해 응답을 확인하고, 짧은 시간 동안 크기를 고정한 데이터를 전송해 처리량을 확인하세요. 테스트 중에는 시스템 업데이트와 다른 다운로드를 일시 중지하고 현재 네트워크, 시간, 노드, 배율, 작업 유형을 기록합니다. 저녁 혼잡 시간대에 같은 방법으로 다시 측정하세요.

로컬 HTTP 프록시로 요청 확인하기

현재 설정의 mixed-port가 실제로 7890이라면 아래 명령으로 로컬 프록시를 거쳐 예시 사이트에 접속할 수 있습니다. Windows에서는 curl.exe를 명시적으로 사용하고, macOS나 Linux에서는 보통 curl을 사용합니다. 포트가 7890이 아니라면 클라이언트에 표시된 실제 값으로 바꾸세요.

curl -x http://127.0.0.1:7890 -o /dev/null -sS \
  --connect-timeout 10 --max-time 30 \
  -w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/

위는 macOS/Linux용 명령입니다. Windows에서는 다음 한 줄 명령을 사용할 수 있습니다.

curl.exe -x http://127.0.0.1:7890 -o NUL -sS --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

여기서 time_connect는 주로 로컬 HTTP 프록시에 연결하는 데 걸린 시간이며 원격 노드의 지연 시간이 아닙니다. time_starttransfer에는 첫 바이트를 받기까지 걸리는 여러 단계의 시간이 포함됩니다. 이는 작은 요청을 확인하는 방법이지 대역폭 테스트가 아니며, 실제 출구 경로는 커널 규칙에 따라 선택됩니다. ‘연결’ 페이지에서 해당 도메인에 적용된 정책 그룹을 다시 확인하세요.

단위를 맞춰 속도를 올바르게 비교

다운로드 도구에는 MB/s가, 네트워크 대역폭에는 Mbit/s가 자주 표시됩니다. 십진법 기준으로 10MB/s는 약 80Mbit/s입니다. 100Mbit/s 회선을 환산하면 이론상 12.5MB/s이며, 실제 속도는 프로토콜 오버헤드와 회선 병목의 영향을 받습니다. 대용량 파일을 테스트할 때는 연결 직후의 순간 최고 속도보다 안정적으로 유지되는 구간을 확인하세요.

자주 발생하는 문제: 지연 시간은 정상인데 접속 실패

노드 속도 테스트는 정상인데 특정 웹사이트가 열리지 않는 이유는?

속도 테스트 주소와 대상 웹사이트는 서로 다른 서비스입니다. 먼저 대상 연결에 적용된 규칙과 프록시 경로를 확인한 다음 대상 DNS, 출구 지역 제한, 서버 응답을 점검하세요. 로그에 인증서 오류가 있다면 시스템 시간, 서버 이름, 구독 매개변수를 확인하세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용해서는 안 됩니다.

노드를 바꿨는데 웹사이트에 이전 지역이 계속 표시되는 이유는?

이미 연결된 세션은 기존 노드를 계속 사용할 수 있고 브라우저나 앱에 세션 정보가 저장되어 있을 수도 있습니다. 관련된 기존 연결을 종료한 뒤 다시 요청하고, 규칙이 방금 선택한 정책 그룹을 가리키는지 확인하세요. 출구 IP는 바뀌었는데 페이지에 표시된 지역이 그대로라면 계정 설정, 캐시, 웹사이트의 지역 판정 방식을 확인하세요.

자동 테스트는 모든 용도에 적합한가요?

지연 시간이 낮고 연결 가능한 노드를 자동으로 선택하려는 일반적인 웹 탐색에는 적합합니다. 국가와 출구를 고정해야 하거나 세션을 오래 유지해야 하는 작업에는 수동 선택 그룹을 사용하세요. 또는 같은 지역과 용도의 노드만 자동 그룹에 넣는 방법도 있습니다. 자동 그룹에 배율이 높은 노드가 섞여 있으면 전환 후 트래픽 비용이 달라질 수도 있습니다.

일상적인 노드 선택은 노드 이름, 출구 지역, 배율, 5회 지연 시간, 실제 작업 결과, 테스트 시간을 기록하는 표 하나로 정리할 수 있습니다. 데이터를 바탕으로 실패하거나 변동이 큰 노드를 먼저 제외하고 용도별 주·예비 노드를 남겨 두세요. 클라이언트 설치와 연결 방법은 프록시 연결 가이드를 참고하세요. 정책 그룹과 TUN의 차이가 익숙하지 않다면 먼저 용어 설명을 읽어 보세요.