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

사용 목적을 먼저 정하고 노드 선택하기

노드는 클라이언트가 연결하는 프록시 서버의 접속 지점입니다. 구독을 추가하면 여러 노드와 관련 설정이 클라이언트로 전달됩니다. 노드를 선택한다는 것은 트래픽이 어떤 프록시 경로를 거쳐 웹사이트에 도달할지 정하는 것입니다. 노드 이름에 표시된 지역, 배율, 회선 정보는 후보를 추리는 데 도움이 되지만, 제공업체가 임의로 붙인 이름이므로 실제 연결 결과를 대신할 수는 없습니다.

다음 순서로 고르면 편리합니다. 먼저 대상 서비스에 필요한 출구 지역을 확인하고, 트래픽 배율을 살펴본 뒤, 지연 시간과 안정성을 비교하세요. 마지막으로 현재 클라이언트와 네트워크에서 프로토콜이 제대로 작동하는지 확인합니다. 모든 노드를 지연 시간순으로 정렬해 맨 위 항목을 고르는 것보다 효율적입니다.

• 일반 웹 서핑: 응답이 안정적이고 배율이 적당한 노드를 우선 선택하고, 예비 노드도 하나 남겨 두세요.
• 대용량 파일 다운로드: 지속적인 전송 속도와 남은 데이터 용량을 확인하세요. 낮은 지연 시간은 참고 사항일 뿐입니다.
• 동영상 재생: 먼저 원하는 콘텐츠에 접속할 수 있는지 확인한 다음 화질, 재생 시작 시간, 버퍼링을 살펴보세요.
• 음성 통화와 게임: 지터, 패킷 손실, UDP 지원 여부를 확인하고, 앱 트래픽이 실제로 프록시를 통과하는지도 점검하세요.

첫 번째 기준: 지연 시간은 응답 속도와 변동 폭을 함께 확인

지연 시간 수치가 다운로드 속도를 뜻하지는 않습니다

Clash 클라이언트의 지연 시간 테스트는 보통 지정한 HTTP 또는 HTTPS 주소에 프록시로 접속해 요청에 걸린 시간을 측정합니다. 단순한 ICMP ping과는 다릅니다. 테스트 URL, 연결 재사용 여부, 코어 구현, 당시 부하에 따라 결과가 달라지며, 측정값이 모든 웹사이트의 실제 응답 시간을 의미하지도 않습니다.

예를 들어 한 노드가 45ms, 다른 노드가 110ms로 표시된다면 이번 테스트 조건에서는 앞의 노드가 더 빠르게 응답했다는 뜻입니다. 그렇다고 앞의 노드에서 다운로드 속도가 반드시 더 빠른 것은 아닙니다. 다운로드 속도에는 회선 대역폭, 서버 부하, 대상 사이트의 속도 제한, 저녁 시간대의 혼잡도도 영향을 줍니다.

같은 조건에서 세 번 연속 측정

1. 같은 네트워크와 테스트 주소를 사용하고, 다운로드와 클라우드 동기화는 일시 중지하세요.
2. 후보 노드별로 약 10초 간격을 두고 세 번 측정해 시간 초과 여부를 기록하세요.
3. 후보 노드 두 개를 골라 실제 사용하는 웹사이트를 각각 열고 첫 화면 표시와 연속 요청을 확인하세요.
4. 평소 사용하는 시간대에 한 번 더 측정하세요. 특히 저녁 8시부터 11시 사이를 확인하는 것이 좋습니다.

세 차례 테스트는 후보를 추리는 데만 사용할 수 있으며, 신뢰할 만한 패킷 손실률 통계를 내기에는 부족합니다. 화상 회의나 게임 품질을 확인하려면 앱 내 네트워크 통계를 살펴보세요. HTTP 테스트에 성공해도 UDP 전달이 정상이라는 뜻은 아니며, 게임 서버 트래픽이 반드시 같은 경로를 이용한다고 볼 수도 없습니다.

두 번째 기준: 배율은 데이터 차감량에 영향을 주며 속도 등급을 뜻하지 않습니다

노드 이름의 ‘0.5×’, ‘1×’, ‘2×’는 보통 서비스 제공업체의 트래픽 과금 배율을 나타냅니다. 배율에 따라 과금한다고 가정하면 2× 노드로 3GB를 전송할 때 데이터 용량은 약 6GB 차감되고, 0.5× 노드에서는 약 1.5GB가 차감됩니다. 업로드와 다운로드를 합산하는지, 소수점을 어떻게 처리하는지는 구독 서비스 안내를 확인하세요.

배율은 Clash 코어가 자동으로 정하는 속도 등급이 아닙니다. 2×라고 대역폭이 두 배인 것도 아니고, 0.5×라고 속도가 절반으로 제한되는 것도 아닙니다. 클라이언트에 표시된 노드 이름에 예전 배율 표기가 남아 있을 수도 있으니 요금제 페이지와 트래픽 사용 내역을 확인하는 편이 정확합니다.

대용량 작업 전에는 데이터 용량부터 계산하세요

• 20GB를 전송하면 1× 기준으로 약 20GB, 2× 기준으로 약 40GB가 차감됩니다.
• 남은 데이터 용량이 30GB뿐이라면 필요한 작업을 먼저 끝내고, 배율이 높은 회선은 신중하게 사용하세요.
• 속도 측정에도 데이터가 사용됩니다. 대용량 파일로 반복 측정하면 요금제 데이터에 포함될 수 있습니다.

배율이 낮고 안정적인 노드는 다운로드용으로, 응답이 빠른 노드는 상호작용이 많은 작업용으로 남겨 두세요. 속도 측정 그래프를 최고치로 만들려고 배율이 높은 회선으로 자주 바꾸지 마세요. 한 번의 최고 속도보다 실제 작업을 꾸준히 완료할 수 있는지가 더 중요합니다.

세 번째 기준: 실제 출구 지역을 확인하고 노드 이름은 참고만 하세요

접속 지점은 기기가 프록시 서비스에 연결되는 위치이고, 출구는 대상 웹사이트에 표시되는 공인 IP의 위치입니다. 중계 회선은 가까운 접속 지점으로 연결한 뒤 다른 지역의 출구를 통해 웹사이트에 접속할 수 있습니다. 따라서 ‘접속 지점이 가깝다’와 ‘출구가 가깝다’는 같은 의미가 아닙니다.

노드 이름에 ‘일본’이라고 적혀 있으면 보통 출구 지역을 나타내지만, 모든 웹사이트가 해당 IP를 일본으로 인식한다고 보장할 수는 없습니다. IP 데이터베이스마다 업데이트 시점이 다르며 대상 서비스는 계정 지역, 결제 정보, 기기 위치, 이전 세션을 참고하기도 합니다. 필요한 지역인지 여부는 대상 서비스에서 실제로 확인하세요.

출구 지역 확인 순서

1. 클라이언트의 ‘프록시’ 페이지에서 대상 규칙이 사용하는 정책 그룹을 찾아 후보 노드를 직접 선택하세요.
2. ‘연결’ 페이지를 열고 대상 웹사이트에 요청을 보내 매칭된 규칙과 프록시 경로를 확인하세요.
3. 신뢰할 수 있는 IP 조회 페이지에 접속해 요청이 프록시를 통과하는지 확인하고 출구 정보를 살펴보세요.
4. 대상 서비스를 다시 열어 콘텐츠 지역이나 서비스 이용 가능 여부를 확인하세요. 필요한 경우 기존 연결을 종료한 뒤 다시 시도하세요.

위에서 말한 ‘프록시’와 ‘연결’은 흔히 쓰이는 메뉴 이름입니다. 클라이언트나 버전에 따라 ‘프록시 그룹’, ‘연결 목록’ 등으로 표시될 수 있습니다. 해당 메뉴를 찾기 어렵다면 기능을 기준으로 찾아보세요. 기본 설정은 사용 설명서를 참고하세요.

출구 지역을 고정해야 하는 서비스에는 여러 국가나 지역을 섞은 자동 선택 그룹보다 지역별 프록시 그룹을 따로 만드는 편이 좋습니다. 자동 전환으로 출구 지역이 바뀌면 로그인 확인이나 콘텐츠 이용 가능 여부가 달라질 수 있습니다.

네 번째 기준: 코어 호환성을 먼저 확인하고 네트워크 조건을 살펴보세요

Shadowsocks, Trojan, VMess, VLESS, Hysteria2, TUIC 등은 서로 다른 프록시 프로토콜 또는 프로토콜 계열입니다. 프로토콜은 클라이언트와 서버 간 데이터 전송 방식을 정하지만, 노드 속도는 회선과 서버 부하에도 영향을 받습니다. 프로토콜 이름만으로 속도를 일률적으로 비교할 수는 없습니다.

Clash는 클라이언트 생태계에서 널리 쓰이는 이름이며, 실제 지원 프로토콜은 사용하는 코어와 버전에 따라 다릅니다. mihomo는 이 생태계에서 사용하는 코어로, 과거에는 Clash Meta라는 이름을 사용했습니다. 구버전 Clash 코어와 현재 mihomo가 지원하는 기능은 같지 않습니다. 구독을 내려받을 수 있더라도 현재 코어가 모든 노드를 해석할 수 있는 것은 아닙니다.

Hysteria2와 TUIC는 UDP 기반 전송을 사용하므로 UDP가 제한된 사내 네트워크나 공용 네트워크에서는 연결에 실패할 수 있습니다. 이럴 때는 클라이언트를 계속 재시작하기보다 같은 네트워크에서 사용할 수 있는 TCP 전송 노드를 비교 테스트하고 로그를 확인하세요.

TUN은 더 많은 앱 트래픽이 규칙 처리를 거치도록 하는 가상 네트워크 인터페이스 방식입니다. 프록시 프로토콜이 아니며 서버의 UDP 지원을 보완하지도 않습니다. 시스템 프록시는 보통 해당 설정을 따르는 앱에만 영향을 줍니다. 게임 트래픽이 프록시를 통과하지 않는다면 노드 성능을 따지기 전에 트래픽 가로채기가 제대로 되는지 확인하세요.

수동 선택, url-test, 장애 조치 활용법

지역과 용도가 정해져 있다면 수동 그룹이 적합합니다

select는 프록시 그룹에서 노드를 직접 선택하는 방식입니다. 출구 지역을 고정하거나 두 회선을 비교할 때, 또는 배율별 노드를 골라야 할 때 수동 선택을 사용하면 결과를 제어하기 쉽습니다. 먼저 주로 사용할 노드를 정하고 다른 회선의 예비 노드도 하나 남겨 두세요.

비슷한 노드의 응답을 비교하려면 url-test를 사용하세요

url-test는 지정한 주소와 주기에 따라 후보 노드를 검사하고 결과를 기준으로 노드를 선택합니다. 지역과 배율, 용도가 비슷한 노드끼리 묶을 때 적합하며, 구독의 모든 노드를 한꺼번에 넣는 방식은 권장하지 않습니다. 자동 선택은 보통 지연 시간을 기준으로 하며 요금제 비용이나 대상 플랫폼에서 콘텐츠를 이용할 수 있는지까지 판단해 주지는 않습니다.

아래는 설정에 병합할 수 있는 프록시 그룹 예시입니다. 노드 이름은 현재 설정과 정확히 일치해야 합니다. ‘일본-01’과 ‘일본-02’는 예시 이름이므로 사용하기 전에 구독에 실제로 있는 이름으로 바꾸세요. 규칙도 이 그룹을 가리키도록 설정해야 합니다. 프록시 그룹을 만들기만 해서는 트래픽 경로가 자동으로 바뀌지 않습니다.

proxy-groups:
  - name: 일본 자동 선택
    type: url-test
    proxies:
      - 일본-01
      - 일본-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300: 검사 간격을 300초로 설정합니다. 실제 실행 시점은 코어와 지연 검사 동작의 영향을 받을 수 있습니다.
• tolerance: 50: 노드 간 작은 지연 시간 차이로 자주 전환되지 않도록 전환 허용 오차를 50ms로 설정합니다. 실제 전환 동작은 현재 코어 구현에 따라 달라집니다.
• url: 모든 후보 노드에 같은 테스트 주소를 사용합니다. 실제 네트워크에서 해당 주소에 접속할 수 있는지 확인하세요.

이 내용을 구독 파일 전체에 그대로 덮어쓰지 마세요. 같은 YAML 최상위에 proxy-groups 키를 두 번 작성해서도 안 됩니다. 클라이언트에서 오버라이드나 병합 기능을 제공한다면 이를 사용해 로컬 설정을 저장하세요. 그래야 구독을 업데이트해도 변경 사항이 사라지지 않습니다. 구체적인 메뉴 위치는 사용하는 클라이언트에 따라 다릅니다.

예비 노드를 우선순위에 따라 유지하려면 fallback을 사용하세요

fallback은 장애 조치 그룹으로, 보통 지연 시간이 가장 낮은 노드를 계속 찾는 대신 목록 순서에 따라 사용 가능한 노드를 선택합니다. 주 회선을 우선 사용하고 사용할 수 없을 때 예비 회선으로 전환하는 상황에 적합합니다. 다만 테스트 주소에 접속된다고 대상 서비스도 이용할 수 있는 것은 아니므로 실제 웹사이트에서 예비 노드를 확인해야 합니다.

5분 만에 노드 후보 추리기

1. 설정 확인: 구독 업데이트가 완료됐는지, 프록시 페이지에 노드가 표시되는지, 파싱 오류가 없는지 확인하세요.
2. 조건에 맞지 않는 노드 제외: 출구 지역, 배율, 코어 지원 여부를 기준으로 후보 노드 2~3개를 남기세요.
3. 같은 조건으로 지연 시간 측정: 같은 네트워크에서 세 번 연속 측정하고 시간 초과와 큰 변동을 기록하세요.
4. 실제 작업으로 확인: 자주 사용하는 웹페이지를 열고 동영상을 약 2분간 재생하거나 소규모 파일을 약 30초간 다운로드해 지속 속도를 확인하세요.
5. 규칙과 예비 노드 확인: 연결 페이지에서 프록시 경로를 확인하고 주 노드와 예비 노드를 저장한 뒤, 저녁 시간대에 다시 측정하세요.

모든 노드에서 동시에 시간 초과가 발생하면 로컬 네트워크, 구독 만료 여부, 테스트 주소 접속 가능 여부, 코어 로그부터 확인하세요. 특정 노드만 실패한다면 해당 노드의 프로토콜 설정과 서버 상태를 살펴보세요. 지연 시간은 정상인데 특정 웹사이트가 열리지 않는다면 대상 요청의 규칙 매칭, 출구 지역, 기존 연결을 중점적으로 확인하세요.

목록에서 가장 낮은 수치를 고르는 것이 최종 목표는 아닙니다. 필요한 지역에 연결되고, 배율을 감당할 수 있으며, 주로 사용하는 시간대에 안정적이고, 현재 네트워크에서 프로토콜이 작동해야 일상적으로 사용할 만한 노드입니다. 후보를 추린 뒤에는 목적 없는 노드 전환을 줄이고 조건별 비교 기록을 남겨 두세요. 이후 문제를 진단하기가 한결 수월해집니다.