선택 순서부터 정하기
노드 목록에서 가장 눈에 띄는 정보는 보통 지역명과 지연 시간이지만, 지연 시간이 가장 짧은 순서만으로 노드를 고르면 안 됩니다. 지연 시간은 응답 속도를 나타낼 뿐 다운로드 대역폭을 직접 의미하지 않습니다. 배율은 트래픽 계정에서 차감되는 양에 영향을 주며 회선 품질을 나타내지 않습니다. 지역은 접속 경로와 콘텐츠 권역을, 프로토콜은 호환성·핸드셰이크 오버헤드·네트워크 적응성을 좌우합니다. 네 가지 지표는 서로 다른 문제를 판단하는 기준입니다.
보다 안정적인 순서는 먼저 용도에 맞는 지역을 정하고, 시간 초과와 패킷 손실이 많은 노드를 제외한 뒤, 피크 시간대의 속도를 비교하고, 마지막으로 배율과 프로토콜을 확인하는 것입니다. 이렇게 하면 지연 시간은 짧지만 실제 다운로드는 느린 혼잡 노드를 고르는 일을 피할 수 있고, 몇 ms 차이 때문에 높은 배율 회선을 장기간 사용하는 일도 줄일 수 있습니다.
1분 만에 고르는 방법
- 웹 탐색이라면 먼저 거리가 가까운 홍콩·일본·싱가포르 노드를 테스트합니다.
- 스트리밍은 먼저 원하는 콘텐츠 권역에 해당하는 노드를 선택한 다음 계정과 콘텐츠 이용 가능 여부를 확인합니다.
- 같은 지역에서 지연 시간이 가장 짧은 노드 3개를 고르고, 1위 하나만 남기지 않습니다.
- 각 노드를 연속으로 5회 테스트하고, 시간 초과가 발생하거나 변동 폭이 100ms를 넘거나 지연 시간이 자주 급등하는 노드는 제외합니다.
- 같은 다운로드 소스를 사용해 30초 동안 테스트하고, 시작 직후의 순간 최고값이 아니라 안정적인 속도를 기록합니다.
- 속도가 비슷할 때는 배율이 낮고 현재 네트워크와 더 잘 맞는 프로토콜을 사용하는 노드를 선택합니다.
예를 들어 홍콩 A의 지연 시간은 42ms, 다운로드 속도는 18MB/s, 배율은 1.5이고, 홍콩 B는 지연 시간 58ms, 다운로드 속도 27MB/s, 배율 1.0입니다. 일상적인 웹 탐색에서는 두 노드의 응답 차이가 크지 않지만, 계속 다운로드한다면 B가 더 적합합니다. 다만 피크 시간대에도 A가 낮은 지터를 유지하고 B의 속도가 자주 2MB/s까지 떨어진다면, 주로 사용하는 노드를 A로 다시 바꾸는 편이 좋습니다.
지연 시간 수치 읽는 법
Clash 클라이언트의 지연 시간 테스트는 보통 프록시 노드를 통해 테스트 URL에 접속한 뒤 연결 또는 HTTP 요청이 완료될 때까지 걸린 시간을 기록합니다. 완전한 대역폭 테스트가 아니며 기존 ICMP Ping과도 다릅니다. 노드 서버에서 ICMP를 차단해도 프록시 연결은 정상일 수 있고, 반대로 지연 시간이 40ms로 표시되더라도 대용량 파일 다운로드가 빠르다는 뜻은 아닙니다.
지연 시간·지터·패킷 손실의 의미
- 지연 시간: 한 번의 요청이 왕복하는 데 걸리는 시간으로, 보통 ms 단위를 사용합니다. 수치가 낮을수록 페이지의 첫 응답과 상호작용이 대체로 빠릅니다.
- 지터: 여러 차례 테스트 결과 사이의 변동 폭입니다. 32ms, 180ms, 70ms보다 50ms, 52ms, 55ms가 더 안정적입니다.
- 패킷 손실: 데이터 패킷이 정상적으로 도착하지 못하는 현상입니다. 지속적인 패킷 손실은 로딩 멈춤, 음성 끊김, 연결 재전송을 일으킬 수 있습니다.
- 처리량: 단위 시간에 전송할 수 있는 데이터 양으로, 흔히 Mbps 또는 MB/s로 표시합니다. 실제 데이터를 전송해야 판단할 수 있습니다.
지연 시간은 용도에 따라 대략적으로 판단할 수 있습니다. 30ms~80ms는 대부분의 웹 탐색, 메신저, 동영상 재생에 적합하고, 80ms~150ms도 대체로 정상적으로 사용할 수 있지만 상호작용이 다소 느리게 느껴질 수 있습니다. 200ms를 넘으면 웹 페이지 첫 로딩, 원격 터미널, 실시간 조작에서 지연이 뚜렷해집니다. 이 범위만으로 품질을 보장할 수는 없으며 지터와 패킷 손실도 함께 확인해야 합니다.
테스트 결과 예시
45ms / 48ms / 47ms / 51ms / 46ms: 평균 약 47ms로 변동이 작으므로 실제 속도를 계속 테스트해도 좋습니다.
38ms / 220ms / timeout / 75ms / 310ms: 최저값은 훌륭하지만 회선이 불안정하므로 자동 선택의 우선 노드로 적합하지 않습니다.
같은 노드의 결과가 매번 다른 이유
테스트 요청은 로컬 Wi-Fi, 통신사 접속망, 국제 구간, 노드 입구, 테스트 서버를 거칩니다. 어느 한 구간에서든 혼잡이 발생하면 수치가 달라집니다. 클라이언트가 여러 노드를 동시에 테스트할 때는 로컬 대역폭과 연결 수도 서로 영향을 줍니다. 따라서 한 번에 모든 노드를 측정한 결과는 초기 선별에만 사용해야 하며, 장기적인 판단 기준으로 삼아서는 안 됩니다.
클라이언트의 「프록시」 페이지에서 먼저 노드 전체 그룹을 테스트한 다음, 후보 노드를 각각 5회씩 테스트하는 것이 좋습니다. Clash Verge Rev 2.x를 사용한다면 보통 「프록시」→정책 그룹 선택→지연 시간 테스트 실행 순서로 진행합니다. 배포판에 따라 버튼 이름이 “속도 측정”, “지연 시간 테스트” 또는 “URL Test”로 표시될 수 있습니다. 테스트 중에는 대용량 다운로드와 클라우드 드라이브 동기화를 일시 중지하고, 낮 시간과 20:00~23:00의 결과를 따로 기록하세요.
배율 계산법
배율은 트래픽 계정의 과금 계수이지 속도 배수가 아닙니다. 배율 2.0인 노드로 1GB를 전송하면 계정에서 보통 2GB가 차감되고, 배율 0.5인 노드로 1GB를 전송하면 보통 0.5GB가 차감됩니다. 구체적인 집계 방식은 구독 서비스마다 다릅니다. 업로드와 다운로드 트래픽을 합산하는 서비스가 있는가 하면, 특정 회선에 별도의 배율을 적용하는 서비스도 있습니다.
| 실제 전송량 | 노드 배율 | 예상 차감량 |
|---|---|---|
| 5GB | 0.5 | 2.5GB |
| 5GB | 1.0 | 5GB |
| 5GB | 1.5 | 7.5GB |
| 5GB | 2.0 | 10GB |
노드 이름에 있는 “0.5x”, “1x”, “2x”는 일반적으로 배율을 나타내지만, Clash 설정 형식 자체에는 통일된 배율 필드가 없습니다. 클라이언트는 구독 제공자가 노드 이름에 입력한 텍스트를 표시할 뿐 계정 잔액을 대신 계산하지 않습니다. 배율, 요금제 트래픽, 초기화 날짜는 구독 서비스의 계정 페이지를 기준으로 확인해야 합니다.
높은 배율 노드를 사용할 만한 경우
- 낮은 배율 노드가 피크 시간대에 계속 혼잡하지만 높은 배율의 전용 회선은 안정적인 속도를 유지하는 경우
- 원격 회의, 임시 발표 또는 파일 전달에서 연결 안정성이 중요한 경우
- 목표 지역에서 이용할 수 있는 노드가 적어 지역 접속을 우선해야 하는 경우
- 일반 노드의 패킷 손실이 뚜렷하고 높은 배율 회선의 라우팅과 입구 품질이 더 좋은 경우
높은 배율이 반드시 높은 품질을 의미하지는 않습니다. 이름에 붙은 “전용 회선”, “프리미엄” 같은 표현도 회선 표시일 뿐이므로 연속 테스트 결과를 봐야 합니다. 두 노드가 피크 시간대에 모두 안정적으로 50Mbps를 내고 지연 시간이 각각 62ms와 70ms, 배율이 각각 2.0과 1.0이라면 일반적인 웹 탐색과 동영상 시청에서는 보통 후자를 우선 선택합니다.
용도에 맞는 지역 선택
지역명은 보통 프록시 출구 IP의 위치를 나타내며, 서버가 거치는 모든 물리적 경로를 의미하지는 않습니다. “일본”으로 표시된 노드가 먼저 로컬 중계 서버에 연결된 뒤 다른 지역을 거쳐 일본 출구로 나갈 수도 있습니다. 지역을 선택할 때는 국가나 지역명을 고정된 성능 등급으로 보지 말고, 대상 서비스·회선 거리·지역 제한을 함께 고려해야 합니다.
홍콩·일본·싱가포르
중국 본토의 대부분의 네트워크에서는 홍콩 노드가 물리적으로 가까워 일반적인 지연 시간이 약 30ms~80ms이며, 웹 탐색·메신저·일반 다운로드에 적합합니다. 일본 노드는 보통 약 50ms~120ms로, 소프트웨어 저장소·개발 서비스·일본 지역 콘텐츠에 더 적합할 수 있습니다. 싱가포르 노드는 대체로 약 70ms~150ms이며 동남아시아 대상 서비스에 적합하고, 홍콩이나 일본 회선이 혼잡할 때 대안으로 사용할 수 있습니다.
이 수치는 초기 선별용일 뿐입니다. 통신사마다 국제망 출구가 크게 달라 같은 도시에서도 통신사별로 결과가 완전히 다를 수 있습니다. 모바일 핫스팟과 가정용 인터넷도 따로 테스트해야 하며, 한 네트워크 환경의 결과를 다른 환경에 그대로 적용해서는 안 됩니다.
미국·유럽
미국 노드는 미국 출구를 명확히 요구하는 서비스, 북미 서버 관리, 지역 콘텐츠에 적합합니다. 거리가 멀어 일반적인 지연 시간은 140ms~260ms입니다. 유럽 노드는 보통 더 높으며 일부 회선은 250ms를 넘기도 합니다. 동영상은 플레이어가 버퍼링하기 때문에 안정적인 200ms 지연에서도 원활할 수 있지만, 원격 데스크톱·SSH 입력·실시간 게임에서는 지연이 뚜렷하게 느껴집니다.
스트리밍과 계정 지역
스트리밍 이용 가능 여부는 지역만으로 결정되지 않습니다. 서비스는 IP 유형, 출구 IP 평판, 계정 가입 지역, 결제 수단, 위치 권한 등을 함께 기준으로 지역을 판단할 수 있습니다. 노드 속도 측정은 성공했지만 콘텐츠가 재생되지 않는다면 Clash의 DNS·포트·규칙을 먼저 수정하기보다 같은 지역의 다른 출구로 바꾸세요. 전환한 뒤에는 기존 재생 페이지를 닫고 연결을 새로 만들어 이전 연결이 계속 재사용되지 않도록 해야 합니다.
프로토콜 차이를 신경 써야 할까
구독 노드는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC 등의 프로토콜을 사용할 수 있습니다. 현재 흔히 사용되는 mihomo 코어인 Clash Meta는 다양한 프로토콜과 전송 옵션을 지원하지만, 구버전 Clash 코어 또는 오래된 클라이언트가 모든 필드를 인식하는 것은 아닙니다. 구독을 가져온 뒤 노드가 전혀 표시되지 않는다면 먼저 클라이언트 코어가 해당 프로토콜을 지원하는지 확인해야 하며, 노드가 고장 났다고 단정해서는 안 됩니다.
주요 프로토콜별 선택 기준
- Shadowsocks: 설정이 비교적 간단하고 호환 범위가 넓습니다. 실제 품질은 암호화 방식, 서버 성능, 회선에 크게 좌우됩니다.
- Trojan: TLS와 함께 구성하는 경우가 많습니다. 시스템 시간이 틀리거나 인증서 도메인이 일치하지 않거나 SNI 설정에 문제가 있으면 핸드셰이크가 실패할 수 있습니다.
- VMess와 VLESS: WebSocket, gRPC, TLS 또는 Reality와 함께 사용할 수 있습니다. 노드 매개변수가 모두 일치해야 하며 주소와 포트만 복사해서는 안 됩니다.
- Hysteria2와 TUIC: UDP 기반 전송은 지연 시간이 높거나 패킷 손실이 있는 회선에서 더 나은 성능을 보일 수 있지만, 로컬 네트워크·라우터·통신사의 UDP 정책에 영향을 받습니다.
프로토콜 이름만으로 속도 순위를 정할 수는 없습니다. 같은 품질의 회선이라면 Shadowsocks 노드가 혼잡한 회선의 Hysteria2보다 빠를 수도 있습니다. 프로토콜 차이는 같은 회선·서버·부하 조건에서 비교해야 의미가 있습니다. 초보 사용자는 프로토콜 때문에 설정을 자주 바꿀 필요가 없습니다. 먼저 구독에서 제공한 전체 노드 매개변수를 사용하고, 실제 연결 결과에 따라 선택하세요.
UDP 노드에 연결되지 않을 때
Hysteria2 또는 TUIC가 가정용 인터넷에서는 작동하지만 모바일 핫스팟에서는 시간 초과가 발생한다면 UDP 전송 계층에 문제가 있을 수 있습니다. 먼저 같은 지역의 TCP 계열 노드로 바꿔 기본 네트워크를 확인한 다음, 클라이언트가 해당 프로토콜을 지원하는 mihomo 코어를 활성화했는지 점검하세요. UDP 계열 노드만 실패한다면 시스템 프록시 포트를 계속 바꿔도 해결되지 않는 경우가 많습니다.
TUN 모드가 노드 속도를 자동으로 높여 주는 것도 아닙니다. TUN은 더 많은 시스템 트래픽을 가로채 시스템 프록시 설정을 읽지 않는 앱도 Clash를 거치게 하는 기능입니다. 노드 혼잡, 출구 대역폭 부족, 원격 서버의 속도 제한이 원인이라면 TUN을 켜도 병목이 사라지지 않으며, 오히려 확인해야 할 트래픽 처리 계층만 하나 늘어납니다.
실제 속도 측정으로 주 노드 정하기
신뢰할 수 있는 테스트를 하려면 변수를 통제해야 합니다. 모든 후보 노드는 같은 네트워크·기기·시간대·다운로드 소스를 사용해야 합니다. 노드 A로 동영상 사이트를 테스트하고 노드 B로 소프트웨어 미러를 테스트한 뒤 속도를 바로 비교해서는 안 됩니다. 브라우저 확장 프로그램, 시스템 VPN, 게임 가속기, 다른 프록시 프로그램도 잠시 종료해 트래픽 경로가 달라지지 않게 하세요.
3단계 테스트 절차
- 1차, 연결 테스트: 정책 그룹의 모든 노드에 지연 시간 테스트를 실행하고, 연속 2회 시간 초과가 발생한 노드는 제외합니다.
- 2차, 안정성 테스트: 남은 노드를 각각 5회 테스트하고 평균 지연 시간·최고 지연 시간·시간 초과 횟수를 기록합니다.
- 3차, 처리량 테스트: 고정된 테스트 파일 또는 신뢰할 수 있는 속도 측정 사이트를 사용해 노드마다 30~60초 동안 테스트합니다.
노드 A의 5회 지연 시간이 42, 45, 47, 44, 46ms이고 다운로드 속도가 12MB/s로 안정적이라고 가정해 보겠습니다. 노드 B는 35, 38, 190, 41, 220ms이며 다운로드 속도가 3MB/s~25MB/s 사이에서 변동합니다. B의 최저 지연 시간이 더 낮더라도 일상적인 주 노드로는 A가 더 적합합니다. 동영상과 파일 전송에서는 특히 지속적인 안정성이 중요합니다.
Mbps와 MB/s를 혼동하지 마세요. 속도 측정 페이지에 100Mbps가 표시되면 이론상 약 12.5MB/s이며, 프로토콜 오버헤드와 네트워크 변동을 고려하면 실제 다운로드 속도는 9MB/s~12MB/s일 수 있습니다. 브라우저 다운로드에 8MB/s가 표시된다고 해서 8Mbps밖에 안 된다는 뜻은 아닙니다.
100 Mbps ÷ 8 = 12.5 MB/s
50 Mbps ÷ 8 = 6.25 MB/s
20 MB/s × 8 = 160 Mbps자동 선택 정책 그룹
설정의 url-test 정책 그룹은 주기적으로 노드를 테스트하고 조건에 맞는 지연 시간이 낮은 노드를 자동으로 선택할 수 있습니다. 같은 지역에서 용도가 비슷한 후보 노드 그룹을 관리할 때 적합합니다. 홍콩, 미국, 스트리밍 전용, 고배율 노드를 하나의 자동 그룹에 모두 넣지는 마세요. 프로그램이 테스트 지연 시간만 보고 용도에 맞지 않는 출구로 전환할 수 있습니다.
proxy-groups:
- name: HK-AUTO
type: url-test
proxies:
- HK-01
- HK-02
- HK-03
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50interval: 300은 300초마다 한 번 테스트한다는 뜻이고, tolerance: 50은 수십 ms 차이로 노드가 자주 전환되는 것을 줄이는 데 사용됩니다. 테스트 URL은 안정적이고 응답 본문이 작으며 노드를 통해 접속할 수 있어야 합니다. 이 테스트 역시 응답 속도를 추정할 뿐 대용량 파일 처리량은 측정하지 않습니다.
노드를 바꿀 때와 설정을 바꿀 때
문제가 노드 계층에 있는지 클라이언트 계층에 있는지만 먼저 판단해도 불필요한 작업을 크게 줄일 수 있습니다. 특정 노드만 시간 초과되고 같은 그룹의 다른 노드는 정상이라면 먼저 노드를 바꾸세요. 모든 노드가 동시에 실패한다면 구독, 로컬 네트워크, 클라이언트 포트, 시스템 프록시, DNS 또는 코어를 확인해야 합니다. 특정 노드가 혼잡한데 클라이언트를 반복해서 재설치하거나, 모든 노드가 실패했는데 수십 개 노드를 무작정 바꾸는 일은 피하세요.
| 증상 | 우선 판단 | 다음 단계 |
|---|---|---|
| 노드 하나만 시간 초과 | 노드 또는 단일 회선 문제 | 같은 지역의 노드로 전환한 뒤 다시 테스트 |
| 모든 노드 시간 초과 | 구독·로컬 네트워크 또는 클라이언트 계층 | 구독 상태, 직접 연결 네트워크, 시스템 시간 확인 |
| 속도 측정은 정상이지만 브라우저가 열리지 않음 | 시스템 프록시 또는 규칙 계층 | 시스템 프록시 스위치와 연결 기록 확인 |
| 웹 페이지는 정상이나 특정 앱만 직접 연결 | 앱이 시스템 프록시를 사용하지 않음 | 앱의 프록시 설정을 확인하고 필요하면 TUN 모드 검토 |
| 낮에는 빠르고 피크 시간대에는 느림 | 회선 혼잡 | 먼저 DNS를 바꾸지 말고 회선이나 지역을 변경 |
| 모든 노드 속도가 직접 연결 한계와 비슷함 | 로컬 접속 대역폭 제한 | Wi-Fi, LAN 케이블, 통신사 대역폭 확인 |
포트 및 시스템 프록시 확인
많은 Clash 설정에서 혼합 포트로 7890을 사용하지만 실제 포트는 클라이언트에서 다른 값으로 변경될 수 있습니다. 클라이언트에 현재 표시된 값을 기준으로 하고, 설명서에 나온 값을 그대로 고정 입력하지 마세요. 브라우저에서 프록시를 수동 설정할 때 주소는 보통 127.0.0.1이며, 포트는 「설정」→「포트 설정」 또는 「설정」→「매개변수 설정」의 Mixed Port와 일치해야 합니다.
클라이언트 연결 기록에 브라우저 요청이 전혀 보이지 않는다면 문제는 대개 아직 노드 계층에 도달하지 않은 것입니다. 먼저 시스템 프록시를 켜고 다른 VPN이나 프록시 프로그램이 트래픽을 가로채고 있지 않은지 확인하세요. 연결 기록에 요청이 표시되고 특정 프록시 노드에 연결된 뒤 시간 초과가 발생할 때에만 해당 노드·정책 그룹·원격 서비스를 계속 테스트하면 됩니다.
DNS는 대역폭 혼잡을 해결하지 못합니다
DNS는 도메인 이름을 주소로 변환하고 규칙 매칭과 연결 설정에도 관여합니다. DNS 오류는 도메인이 열리지 않거나 예상과 다른 규칙이 적용되거나 첫 연결이 느려지는 원인이 될 수 있지만, 지속 속도가 5Mbps에 불과한 혼잡 회선을 100Mbps로 바꾸지는 못합니다. IP 직접 연결은 정상인데 도메인만 실패할 때 DNS를 확인하고, 모든 다운로드가 느릴 때는 먼저 노드 처리량과 로컬 대역폭을 점검하세요.
네 가지 기준으로 정리
지연 시간은 응답 속도를 판단하는 기준이며 여러 차례의 결과와 지터를 중점적으로 봐야 합니다. 배율은 차감될 트래픽을 추정하는 값이지 성능을 나타내지 않습니다. 지역은 대상 서비스와 물리적 거리에 따라 선택하고, 프로토콜은 먼저 클라이언트 호환성을 확인한 뒤 현재 네트워크에서 TCP·UDP 및 각 전송 방식이 보이는 실제 성능을 비교하세요. 네 가지 기준은 서로 대체할 수 없습니다.
일상적으로는 가까운 지역의 노드 3개를 먼저 고르고, 지연 시간 5회 테스트와 30초 다운로드 테스트를 한 번씩 진행한 뒤 안정적인 노드를 수동 정책 그룹에 넣으면 됩니다. 지연 시간은 짧지만 변동이 크거나, 최고 속도는 높지만 지속 처리량이 낮거나, 배율이 높은데 품질상 이점이 없는 노드는 장기 기본 노드로 적합하지 않습니다.
문제가 발생했을 때 특정 노드만 이상하면 노드를 바꾸고, 모든 노드가 이상하면 구독·네트워크·클라이언트를 확인하세요. 일부 앱만 문제가 있으면 시스템 프록시·규칙·TUN이 가로채는 범위를 점검해야 합니다. DNS·포트·프로토콜 매개변수를 반복해서 수정하는 것보다 계층별로 원인을 좁히는 편이 빠릅니다.