Clash 노드 선택 방법: 지연 시간·배율·지역·프로토콜 판단 기준

먼저 사용 목적을 정하고 측정값을 확인하세요

Clash 노드를 선택할 때 지연 시간이 가장 짧다고 해서 항상 최상의 사용 환경을 보장하는 것은 아닙니다. 웹페이지 로딩, 동영상 버퍼링, 원격 회의, 파일 다운로드, 게임 연결은 각각 요구하는 회선 조건이 다릅니다. 테스트하기 전에 현재 작업에서 응답 속도, 지속 대역폭, 출구 지역 또는 트래픽 사용량 중 무엇이 중요한지 먼저 정하세요.

예를 들어 같은 구독에 지연 시간 48ms인 홍콩 노드와 82ms인 일본 노드가 있다고 가정해 보겠습니다. 전자는 보통 웹페이지 응답이 빠르지만, 저녁 피크 시간대에 패킷 손실이 심하면 동영상 재생은 오히려 후자가 더 안정적일 수 있습니다. 160ms로 표시되는 미국 노드는 저지연 상호작용에는 적합하지 않지만, 미국 지역으로 제한된 콘텐츠에 접근할 때는 올바른 선택일 수 있습니다.

일반적인 용도별 우선 지표

일상적인 웹 탐색: 지연 시간, 연결 성공률, 저녁 피크 시간대의 안정성을 우선 확인하고 보통 지리적으로 가까운 지역을 선택합니다.
고화질 동영상: 지속 다운로드 속도와 지터를 우선 확인하세요. 순간 측정 속도는 높지만 자주 느려지는 회선은 적합하지 않습니다.
음성 회의: 양방향 지연 시간, 지터, 패킷 손실을 우선 확인하세요. 지연 시간이 80ms로 안정적인 연결이 35~180ms 사이를 오가는 연결보다 대체로 사용하기 편합니다.
대용량 다운로드: 지속 처리량, 배율, 구독 잔여 트래픽을 확인하고 단순히 최저 지연 시간만 추구할 필요는 없습니다.
지역 제한 콘텐츠: 먼저 출구 국가나 지역을 정한 다음, 조건에 맞는 노드끼리 안정성을 비교합니다.
불안정한 모바일 네트워크: 프로토콜 성능, 재연결 속도, UDP 사용 가능 여부를 중점적으로 비교합니다.

지연 시간 측정값은 어떻게 읽어야 할까요?

Clash 그래픽 클라이언트의 지연 시간 테스트는 보통 용량이 매우 작은 테스트 주소에 요청을 보내고, 연결을 시작한 뒤 응답을 받을 때까지 걸린 시간을 기록합니다. 클라이언트, 설정 파일, 프록시 제공업체마다 테스트 주소가 다를 수 있으므로 서로 다른 프로그램의 결과를 직접 비교해서는 안 됩니다.

지연 시간 결과는 DNS 확인, TLS 핸드셰이크, 테스트 서버 위치, 로컬 Wi-Fi, 노드의 현재 부하에도 영향을 받습니다. 한 번 42ms가 나왔다고 해서 그 시점의 작은 요청이 빨리 처리되었다는 뜻일 뿐, 해당 노드가 지속적으로 높은 다운로드 속도를 제공한다는 의미는 아닙니다.

측정값을 실용적으로 구간별로 보기

측정 지연 시간	일반적인 체감	판단할 점
30–80 ms	웹과 일반적인 상호작용이 빠르게 반응함	저녁 피크 시간대의 패킷 손실과 대역폭을 계속 확인
80–150 ms	대부분의 웹 탐색과 동영상 용도에서 사용 가능	수치가 안정적인지 확인
150–250 ms	웹은 사용할 수 있지만 상호작용 대기감이 커짐	특정 원거리 지역 이용 목적에 적합
250ms 초과	연결과 페이지 응답이 눈에 띄게 느려짐	우회 경로, 혼잡 또는 노드 부하를 점검
시간 초과	테스트 주소에서 응답을 받지 못함	한 번의 시간 초과만으로 노드 장애를 판단하지 않음

이 구간은 고정된 기준이 아닙니다. 중국 본토에서 홍콩·일본·싱가포르 노드로 연결할 때는 보통 35~120ms, 유럽이나 북미 노드로 연결할 때는 140~260ms가 나올 수 있습니다. 통신사, 현재 도시, 진입 회선, 국경 간 라우팅에 따라 결과는 달라집니다.

최소 세 번 연속으로 테스트하기

진행 중인 대용량 다운로드, 클라우드 드라이브 동기화, 시스템 업데이트를 중지합니다.
후보 노드를 3~5회 연속 테스트하고, 매번 약 5초 간격을 둡니다.
최저값, 최고값, 시간 초과 횟수를 기록하고 가장 좋은 한 번의 결과만 남기지 않습니다.
낮 시간대와 20:00~23:00에 각각 한 차례씩 테스트해 피크 시간대의 차이를 비교합니다.
후보 노드를 2~3개로 좁힌 뒤 실제로 1080p 동영상을 재생하거나 약 200MB의 테스트 파일을 다운로드합니다.

노드 A의 다섯 번 측정값이 46, 49, 51, 48, 50ms이고 노드 B가 32, 37, 145ms, 시간 초과, 41ms라고 가정해 보겠습니다. 노드 B의 최저값이 더 낮더라도 노드 A의 변동 폭은 5ms에 불과하므로 실제 웹 탐색과 회의에서는 대체로 더 안정적입니다. 이 경우에는 노드 A를 우선 선택하는 것이 좋습니다.

지연 시간·지터·패킷 손실·속도의 차이

지연 시간은 요청 대기 시간을 결정합니다

지연 시간은 주로 짧은 연결과 잦은 상호작용에 영향을 줍니다. 작은 리소스가 많은 웹페이지를 열 때는 연결과 요청마다 네트워크 왕복을 기다려야 합니다. 원격 터미널, 온라인 문서, 음성 통화도 지연 시간에 민감합니다. 지연 시간이 50ms에서 180ms로 늘어나면 다운로드 대역폭이 같더라도 조작 시 대기감이 더 커집니다.

지터는 지연 시간이 얼마나 안정적인지를 나타냅니다

지터는 여러 차례 측정한 지연 시간 사이의 변동 폭으로 이해할 수 있습니다. 연속 결과가 70, 73, 76ms라면 보통 40, 160, 55ms보다 안정적입니다. 음성 및 실시간 동영상은 시간 순서대로 데이터를 계속 받아야 하므로 지터가 너무 크면 끊김, 화면 멈춤, 짧은 음성 끊김이 발생하기 쉽습니다.

패킷 손실은 재전송이나 품질 저하를 일으킵니다

TCP 트래픽은 패킷 손실이 발생하면 보통 재전송이 필요해 다운로드 속도가 떨어집니다. UDP 기반 서비스는 데이터 일부가 그대로 유실될 수 있어 실시간 음성이나 게임이 더 민감하게 반응합니다. 가정용 Wi-Fi 간섭, 로컬 통신사의 혼잡, 노드 진입부 과부하, 원격 회선 모두 패킷 손실의 원인이 될 수 있습니다.

대역폭은 지속 전송 한도를 결정합니다

지연 시간이 95ms이고 지속 다운로드 속도가 80Mbps인 노드는 지연 시간이 45ms이지만 저녁 피크에 6Mbps밖에 유지하지 못하는 노드보다 고화질 동영상 재생에 유리할 수 있습니다. 속도를 측정할 때는 최소 30~60초 동안 관찰해 일시적인 최고치와 지속 속도를 구분하세요. 8Mbps는 이론상 초당 약 1MB의 전송량에 해당하며, 실제 속도에서는 프로토콜 오버헤드가 차감됩니다.

클라이언트의 지연 시간 테스트는 정상인데 브라우저가 여전히 느리다면 먼저 다른 테스트 주소로 바꾼 다음 DNS, 규칙 매칭, 시스템 프록시를 확인하세요. TUN 모드를 활성화했다면 트래픽이 실제로 Clash를 통과하는지, 인계되지 않은 애플리케이션이 다른 네트워크 인터페이스로 직접 연결되고 있지는 않은지도 확인해야 합니다.

노드 배율이 구독 트래픽에 미치는 영향

배율은 보통 프록시 서비스 제공업체의 과금 속성이며 Clash 프로토콜 자체의 기능은 아닙니다. “0.5×”는 실제 트래픽 1GB를 사용했을 때 구독에서 약 0.5GB를 차감할 수 있다는 뜻이고, “2×”는 약 2GB를 차감할 수 있다는 뜻입니다. 구체적인 집계 방식은 구독 서비스의 관리 패널 안내를 따르며, 업로드·다운로드와 프로토콜 오버헤드를 함께 계산하는지는 서비스마다 다를 수 있습니다.

노드 배율	실제 10GB 전송 시 예상 차감량	일반적인 선택 기준
0.5×	약 5GB	대용량 파일과 고화질 동영상에 적합하지만 속도 확인이 필요함
1×	약 10GB	일상적인 사용에 적합하고 구독 사용량을 계산하기 쉬움
1.5×	약 15GB	보통 회선 품질이나 지역 지원 수준과 비교해 선택해야 함
2×	약 20GB	특정 진입점이나 전용 회선을 임시로 사용할 때 적합함

배율이 낮다고 해서 반드시 속도가 느린 것은 아니며, 배율이 높다고 해서 지연 시간이 반드시 낮은 것도 아닙니다. 배율은 회선 비용, 진입 품질, 지역 리소스, 운영 정책과 관련될 수 있습니다. 선택할 때는 이를 성능 등급이 아니라 “사용량 1단위당 구독 비용”으로 보는 것이 좋습니다.

월간 트래픽을 기준으로 허용 가능한 배율 계산하기

월 200GB 구독을 사용하고 일상적인 동영상 시청과 다운로드에 실제 120GB를 쓴다고 가정해 보겠습니다. 전부 1.5× 노드를 사용하면 이론상 과금량은 약 180GB가 되어 잔여량이 20GB뿐입니다. 이 중 80GB를 0.5× 노드로, 나머지 40GB를 1.5× 노드로 처리하면 예시 과금량은 약 100GB입니다. 대용량 작업에는 낮은 배율의 정책 그룹을 따로 지정하는 편이 자주 수동 전환하는 것보다 관리하기 쉽습니다.

설정에 “일상”, “다운로드”, “지역 서비스”라는 세 가지 정책 그룹을 만들 수 있습니다. 일상 그룹에는 안정적인 1× 노드를 사용하고, 다운로드 그룹에는 낮은 배율의 노드를 추가하며, 지역 서비스 그룹에는 출구 조건에 맞는 노드만 넣습니다. 규칙이 도메인이나 애플리케이션별 트래픽을 해당 정책 그룹으로 전달하게 하면 노드 선택을 더 쉽게 관리할 수 있습니다.

지역 선택은 출구 위치와 라우팅에 따라 달라집니다

노드 이름에 표시된 홍콩, 일본, 싱가포르, 미국 등은 보통 프록시 서버의 출구 위치를 뜻하지만, 이름만으로 진입 경로와 중계 경로까지 완전히 알 수는 없습니다. 같은 일본 노드라도 서로 다른 통신사와 중계 회선을 거칠 수 있어 지연 시간과 저녁 피크 성능이 크게 달라질 수 있습니다.

가까운 거리는 보통 출발점일 뿐입니다

홍콩: 지리적으로 가까워 일상적인 웹 탐색과 짧은 대기 시간이 필요한 작업에 자주 사용되지만, 피크 시간대 성능은 진입 회선에 따라 달라집니다.
일본: 보통 적당한 지연 시간을 제공하며 일본 출구가 필요한 콘텐츠에 적합하고, 동아시아 지역의 일상적인 후보로도 사용할 수 있습니다.
싱가포르: 동남아시아 서비스에 적합하며 일부 남부 지역 네트워크에서 연결 성능이 좋을 수 있습니다.
미국: 미국 출구가 필요한 서비스에 적합하지만 물리적 거리 때문에 기본 지연 시간은 보통 동아시아 노드보다 높습니다.
유럽: 특정 지역 서비스에 주로 사용하며 일상적인 상호작용 지연 시간이 높은 편이므로 라우팅 안정성을 우선 확인해야 합니다.

지역 제한 콘텐츠에 접근할 때는 노드 이름보다 출구 IP가 속한 지역이 더 중요합니다. 연결한 뒤 일반적인 IP 조회 페이지에서 국가, 지역, 네트워크 사업자를 확인할 수 있습니다. 출구 지역이 올바르게 표시되는데도 콘텐츠를 이용할 수 없다면 계정 가입 지역, 결제 정보, 브라우저 위치 정보, DNS 결과 또는 서비스 제공업체의 IP 데이터베이스 업데이트 지연이 원인일 수도 있습니다.

자동 선택 그룹은 후보 범위를 제한해야 합니다

Clash의 url-test 정책 그룹은 후보 노드를 정기적으로 테스트해 지연 시간이 낮은 노드를 선택할 수 있습니다. 하지만 모든 지역을 하나의 그룹에 넣으면 자동 선택 과정에서 미국 노드가 홍콩 노드로 바뀌어 출구 지역이 달라질 수 있습니다. 특정 지역을 고정해야 한다면 “일본 자동 선택”, “미국 자동 선택”처럼 정책 그룹을 지역별로 따로 만들어야 합니다.

proxy-groups:
  - name: 일본 자동 선택
    type: url-test
    include-all: true
    filter: "(?i)일본|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 일상 수동 선택
    type: select
    proxies:
      - 일본 자동 선택
      - DIRECT

이 예시는 300초마다 일본 이름과 일치하는 노드를 테스트하며, tolerance: 50은 작은 지연 시간 변화로 인한 잦은 전환을 줄이는 데 사용합니다. Clash Meta(mihomo)의 버전과 클라이언트에 따라 지원하는 설정 필드가 다를 수 있으므로 가져오기 전에 현재 코어 문서와 구독 생성 결과를 기준으로 확인해야 합니다.

불안정한 네트워크에서는 프로토콜 차이가 더 크게 드러납니다

구독 노드는 Shadowsocks, Trojan, VLESS, VMess, WireGuard, Hysteria2, TUIC 등의 프로토콜을 사용할 수 있습니다. Clash Meta(mihomo)가 지원하는 구체적인 프로토콜과 전송 조합은 코어 버전에 따라 달라집니다. 속도를 결정하는 요소는 프로토콜 하나뿐이 아니며 서버 성능, 진입 대역폭, 라우팅 품질, 매개변수 설정도 대체로 중요합니다.

TCP 계열 전송: 호환성이 안정적이지만 패킷 손실 시 속도가 떨어질 수 있음

Trojan과 일부 VLESS 또는 VMess 노드는 TCP와 TLS 위에서 작동하는 경우가 많습니다. TCP는 대부분의 네트워크에서 통과하기 쉽고 연결 동작도 안정적이지만, 회선에서 패킷 손실이 발생하면 하위 TCP 계층이 재전송을 수행하며 전송 속도를 낮춥니다. 프록시 터널 내부의 서비스도 TCP라면 심한 패킷 손실로 속도가 감소하고 지연이 누적될 수 있습니다.

Shadowsocks: 성숙한 구현, 회선에 따라 달라지는 성능

Shadowsocks의 추가 오버헤드는 일반적으로 관리 가능한 수준이며 클라이언트와 서버 구현도 널리 보급되어 있습니다. 일반적인 광대역 환경에서의 체감 성능은 암호화 방식, 서버 부하, 네트워크 경로의 영향을 더 많이 받습니다. SS, Trojan, VLESS라는 태그만 보고 프로토콜의 절대적인 성능 순위를 정해서는 안 됩니다.

Hysteria2 및 TUIC: UDP/QUIC 전송 활용

Hysteria2와 TUIC는 UDP/QUIC를 기반으로 하며, 지연 시간이 높고 일정한 패킷 손실이 있는 일부 회선에서 혼잡 제어와 연결 마이그레이션을 통해 더 부드러운 처리량을 제공할 수 있습니다. 다만 일부 학교 네트워크, 회사 네트워크, 공용 Wi-Fi, 모바일 네트워크는 UDP를 제한하므로 연결 불가, 핸드셰이크 시간 초과, 갑작스러운 속도 저하가 발생할 수 있습니다.

WireGuard: 안정적인 터널 환경에 적합

WireGuard는 UDP를 사용하고 프로토콜 구조가 간결해 전체 네트워크 터널에 자주 활용됩니다. 시스템 시간, MTU, UDP 연결 가능 여부에 민감한 편입니다. 웹페이지는 열리지만 일부 사이트가 멈춘다면 MTU를 확인해 보세요. 1280, 1380, 1420 등이 흔히 점검하는 값이지만 최종값은 고정해서 적용하지 말고 실제 회선 테스트를 기준으로 정해야 합니다.

불안정한 네트워크 테스트에는 네트워크 전환을 포함하세요

가정용 Wi-Fi, 모바일 핫스팟, 이동통신망에서 같은 노드를 각각 테스트합니다.
10분 동안 동영상을 재생하며 버퍼링이 자주 발생하는지 확인합니다.
화면을 2분간 잠근 뒤 복귀해 연결이 빠르게 재구성되는지 확인합니다.
Wi-Fi에서 모바일 네트워크로 전환하고 다시 접속할 때까지 걸린 시간을 기록합니다.
UDP 프로토콜에서 계속 시간 초과가 발생하면 TCP 계열 노드로 바꿔 테스트해 네트워크 제한인지 확인합니다.

Android에서 VpnService를 사용하거나 데스크톱에서 TUN 모드를 활성화한 경우, 네트워크 전환 후 시스템이 기본 경로를 다시 설정할 때까지 기다려야 할 수 있습니다. 이때 잠시 연결이 끊겼다고 해서 반드시 노드 장애인 것은 아닙니다. 먼저 5~10초 기다린 뒤 클라이언트 로그에서 시간 초과, DNS 오류, 인터페이스 재구성 기록을 확인하세요.

정책 그룹으로 수동 노드 선택 줄이기

구독에 수십 개의 노드가 포함되어 있다면 하나씩 클릭해 테스트하는 방식은 비효율적입니다. 용도별로 정책 그룹을 만드는 것이 더 실용적입니다. 지역 그룹은 출구를 제한하고, 자동 그룹은 지연 시간을 비교하며, 수동 그룹은 최종 제어권을 유지하고, 장애 조치 그룹은 주 노드를 사용할 수 없을 때 예비 노드로 전환합니다.

네 가지 정책 그룹의 활용 범위

select: 노드나 다른 정책 그룹을 수동으로 선택하며, 지역 콘텐츠와 출구를 고정해야 하는 계정에 적합합니다.
url-test: 정기적으로 테스트해 지연 시간이 낮은 노드를 우선 선택하며, 일상적인 웹 탐색에 적합합니다.
fallback: 사용 가능한 노드를 순서대로 사용하고 주 회선이 실패하면 예비 회선으로 전환합니다.
load-balance: 설정한 정책에 따라 여러 노드에 연결을 분산하며, 고정 출구 IP가 필요한 로그인 세션에는 적합하지 않습니다.

자동 테스트 간격도 조절해야 합니다. 10초로 설정하면 탐색 요청이 지나치게 자주 발생하고 노드가 반복해서 바뀔 수 있으므로 일반적인 사용에는 300~600초가 더 적합합니다. tolerance를 사용하면 두 노드의 차이가 5~20ms에 불과할 때 계속 전환되는 현상을 줄일 수 있습니다. 로그인, 장바구니, 위험 관리가 중요한 서비스에는 고정 노드 또는 고정 지역 정책 그룹을 사용하세요.

구독을 업데이트하면 노드 이름이 바뀔 수 있습니다. 정규식으로 지역을 필터링할 때는 중국어, 영어 약어, 서비스 제공업체가 자주 사용하는 명칭을 함께 포함하세요. 예를 들어 일본 노드는 “일본”, “JP”, “Japan”을 매칭할 수 있습니다. 필터 결과가 비어 있으면 먼저 실제 노드 이름을 확인한 뒤 표현식을 수정하고, 빈 정책 그룹을 규칙의 출구로 직접 사용하지 마세요.

설정 안내: YAML을 수정한 뒤 먼저 공백 들여쓰기를 확인하고 클라이언트에서 설정을 다시 불러오세요. 정책 그룹이 참조하는 노드 이름은 proxies 또는 프록시 모음에 있는 이름과 정확히 일치해야 합니다.

반복해서 사용할 수 있는 노드 선택 절차

작업 정하기: 일상적인 웹 탐색, 다운로드, 회의, 지역 콘텐츠, 모바일 불안정 네트워크 중 어떤 용도인지 명확히 합니다.
지역 필터링: 출구 조건에 맞는 노드를 남기고 출구 IP로 실제 지역을 확인합니다.
배율 확인: 구독 잔여량을 기준으로 장기간 사용하기 어려운 고배율 노드를 제외합니다.
지연 시간 연속 측정: 3~5회 테스트하고 변동, 시간 초과, 피크 시간대 결과를 기록합니다.
실제 서비스 사용: URL Test에만 의존하지 말고 웹 탐색, 동영상, 다운로드 중 하나 이상을 실제로 테스트합니다.
프로토콜 비교: 현재 네트워크에서 TCP 계열 노드와 UDP/QUIC 계열 노드를 각각 테스트합니다.
정책 그룹 만들기: 최종 후보 노드를 수동, 자동 또는 장애 조치 그룹에 넣습니다.
예비 노드 확보: 주 노드 외에 최소 하나는 다른 진입점이나 다른 프로토콜을 사용하는 예비 노드로 준비합니다.

최종 선택은 지역이 정확하고 연결이 안정적이며 배율이 감당 가능한지를 먼저 확인한 뒤, 지연 시간이 가능한 한 낮은 노드를 고르는 방식으로 정리할 수 있습니다. 일상적인 웹 탐색에는 60~100ms로 안정적인 가까운 노드면 대체로 충분합니다. 고화질 동영상은 지속 대역폭을 우선 확인하고, 특정 지역 콘텐츠는 출구를 유지해야 하며, 불안정한 네트워크에서는 실제 네트워크 전환으로 프로토콜의 재연결과 지터 대응력을 검증해야 합니다.

노드 품질은 시간에 따라 달라집니다. 회선 조정, 저녁 피크 부하, 통신사 라우팅, 서버 유지보수로 인해 지난주 최고의 노드가 오늘은 평범한 노드가 될 수 있습니다. 1~2주마다 후보 그룹을 다시 테스트하고 눈에 띄게 느려졌다면 먼저 예비 노드로 전환한 뒤 로컬 네트워크, DNS, 규칙, TUN 인계 상태를 확인하면 불필요한 문제 해결을 줄일 수 있습니다.