Clash 노드 선택 방법: 지연 시간·트래픽 배율·지역·프로토콜 확인

용도에 맞는 노드를 먼저 추린 뒤 지연 시간 비교하기

Clash 노드 목록의 이름, 지연 시간, 배율은 각각 다른 정보를 보여 줍니다. 지역은 출구 위치와 서비스 이용 가능 범위에 영향을 주고, 배율은 구독 데이터 차감량과 관련이 있습니다. 프로토콜은 코어 호환성과 네트워크 전송 조건을 좌우하며, 지연 시간은 특정 시점의 탐지 응답만 나타냅니다. 모든 노드를 밀리초 순으로 정렬한다고 해서 현재 작업에 가장 적합한 노드를 찾을 수 있는 것은 아닙니다.

먼저 클라이언트에서 현재 프로필이 활성화되어 있는지 확인한 다음 ‘프록시’ 또는 ‘정책 그룹’ 화면으로 이동합니다. 클라이언트마다 메뉴 이름은 다를 수 있으므로 정책 그룹 이름과 유형, 연결 기록을 기준으로 판단하세요. 노드를 바꾸기 전에 조작 중인 그룹이 대상 사이트의 규칙에서 실제로 사용되는지 확인해야 합니다. 현재 연결에 쓰이지 않는 예비 그룹을 바꿔도 효과가 없습니다.

용도 정하기: 웹 브라우징, 동영상 시청, 원격 터미널, 대용량 파일 전송은 각각 필요한 연결 조건이 다릅니다.
출구 지역 확인: 먼저 대상 서비스에서 허용하는 지역의 노드만 남기세요. 지역 제한이 없다면 지연 시간과 연결 안정성을 비교합니다.
비용 확인: 구독 서비스 제공업체의 배율 및 과금 기준을 확인하고, 장시간 사용하기에 부담스러운 노드는 제외하세요.
전송 방식 확인: 현재 코어가 해당 프로토콜을 지원하는지 확인하세요. UDP가 필요한 앱은 UDP 경로가 제대로 작동하는지도 따로 검증해야 합니다.
실제 연결 비교: 같은 네트워크와 대상, 비슷한 시간대에 다시 측정한 뒤 주 사용 노드와 예비 노드를 하나씩 정해 두세요.

지연 시간 테스트로 확인할 수 있는 것

HTTP 탐지 결과는 단순한 네트워크 왕복 시간이 아닙니다

Clash와 mihomo의 지연 시간 테스트는 보통 지정된 프록시를 통해 테스트 URL에 요청을 보냅니다. 노드 서버에 ICMP Ping을 보내는 방식과는 다릅니다. 결과에는 로컬 기기에서 노드 입구까지의 경로, 프록시 핸드셰이크, 출구에서 테스트 사이트까지의 경로, 테스트 서버의 응답이 모두 영향을 줍니다. DNS, TLS, 연결 재사용이 측정에 포함되는지는 코어 구현과 해당 연결의 상태에 따라 다릅니다.

예를 들어 화면에 80ms와 160ms가 표시되더라도 테스트 URL, 네트워크 환경, 측정 방식이 같을 때만 비교할 수 있습니다. 이 수치는 비교 방법을 설명하기 위한 예시이며 이 사이트에서 직접 측정한 결과가 아닙니다. 테스트 사이트에 더 가까운 출구가 해당 테스트에서는 앞설 수 있지만, 실제로 접속하려는 서비스 서버와 더 가까운 것은 아닐 수 있습니다.

테스트 결과	대략 판단할 수 있는 내용	바로 단정할 수 없는 내용
탐지 시간이 짧음	현재 테스트 경로의 응답이 빠름	지속적인 다운로드 속도도 반드시 빠름
시간 초과가 연속으로 발생함	현재 탐지 경로가 정상적으로 완료되지 않음	모든 웹사이트에서 노드를 사용할 수 없음
같은 노드의 결과 변동이 큼	경로, 부하 또는 로컬 네트워크가 불안정할 가능성	문제가 반드시 노드 서버에 있음
웹은 되지만 음성 통화는 실패함	웹에서 사용하는 연결 경로는 작동함	UDP 전달도 정상적으로 작동함

조건을 고정해 다시 측정하고, 한 번의 결과만으로 결론 내리지 않기

한 번에 비교하는 후보 노드 수를 적게 유지해 동시 탐지로 로컬 연결이 포화되지 않도록 하세요. 같은 네트워크에서 약 30초 간격으로 세 차례 결과를 기록해 볼 수 있습니다. 이는 권장 설정 예시일 뿐 성능을 보장하지 않습니다. 최솟값 하나만 보관하지 말고 중간 수준의 결과와 시간 초과 횟수도 함께 비교하세요. 저녁 시간대의 사용성을 확인하려면 실제 사용하는 시간에 다시 측정해야 합니다.

테스트 중에는 대용량 파일 동기화를 일시 중지하고 테스트 URL도 바꾸지 마세요. 모든 노드에서 동시에 시간 초과가 발생한다면 먼저 로컬 네트워크, 테스트 사이트, 구독 유효 기간을 확인합니다. 특정 노드에서만 계속 실패한다면 해당 노드의 프로토콜 설정과 서비스 상태를 점검하세요. 한 번 시간 초과가 발생했다고 DNS, TUN, 모든 규칙을 동시에 바꾸면 원인을 찾기 어려워집니다.

트래픽 배율과 구독 데이터 차감 방식

배율은 일반적으로 구독 서비스 제공업체의 과금 기준이며 Clash 프로토콜에 포함된 필드가 아닙니다. 노드 이름에 표시된 ‘0.5x’, ‘1x’, ‘2x’는 제공업체가 붙인 이름일 수 있으며, 클라이언트는 이름만 보고 데이터 차감 방식을 결정하지 않습니다. 실제 배율, 업로드와 다운로드의 합산 여부, 집계 기준, 적용 시점은 제공업체 안내와 계정 사용 내역을 기준으로 확인해야 합니다.

배율이 높다고 지연 시간이 더 짧거나 대역폭이 더 넓은 것은 아닙니다. 높은 배율은 특정 회선 비용이나 지역 자원과 관련이 있을 수 있으므로 실제로 확인해야 합니다. 운영체제 이미지 다운로드, 사진 동기화, 장시간 동영상 시청에는 필요한 성능을 충족하는 저배율 노드를 먼저 찾아보세요. 원격 작업처럼 응답 속도와 안정성이 중요하다면 예산 범위에서 더 적합한 경로를 선택할 수 있습니다.

특정 배율의 노드를 처음 사용할 때는 계정 잔여량을 기록한 뒤 전송량을 통제해 테스트하세요. 제공업체의 사용량 집계가 갱신되면 결과를 대조합니다.
클라이언트 연결 화면의 단일 트래픽 수치를 제공업체 청구 내역과 동일하게 취급하지 마세요. 두 수치는 집계 위치가 다를 수 있습니다.
여러 기기에서 구독을 공유한다면 다른 기기의 데이터 사용량도 고려하세요. 그렇지 않으면 한 번의 비교로 잘못된 결론을 내릴 수 있습니다.

노드 지역은 이름보다 실제 출구를 확인하세요

노드 이름에 표시된 지역은 구독 제공업체가 입력한 것으로, 입구 위치나 출구 위치, 회선 그룹을 나타낼 수 있습니다. 예를 들어 연결이 홍콩의 입구를 거쳐 일본 출구로 나가 웹사이트에 접속하면 대상 웹사이트에는 보통 일본 출구 IP가 표시됩니다. 물리적으로 가까운 곳이 반드시 더 짧은 경로인 것은 아니며, 통신사 간 연결과 중계 구성도 실제 성능에 영향을 줍니다.

지역은 세 가지 정보를 교차 확인하세요

실제 연결 경로 확인: 클라이언트의 ‘연결’ 화면에서 대상 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 노드를 확인합니다.
출구 IP 확인: 같은 브라우저에서 신뢰할 수 있는 IP 조회 서비스에 접속해 표시되는 공인 IP와 지역을 기록합니다. 먼저 조회 요청이 DIRECT 규칙으로 처리되지 않는지 확인하세요.
대상 서비스에서 확인: 실제로 사용할 웹사이트에 접속해 이용 가능 여부를 확인하세요. IP 데이터베이스는 최신 정보가 아닐 수 있고, 서비스마다 지역 판정이 다를 수 있습니다.

IP 조회 사이트에서 올바른 지역이 표시되더라도 대상 서비스가 지역 제한을 안내한다면 계정 등록 지역, 결제 정보, 이전 세션, 서비스 자체 정책도 확인해야 합니다. 지역 표시가 같은 다른 노드로 바꾼다고 이런 제한이 해결되는 것은 아닙니다. 노드 이름만으로 IP 유형, 서비스 지역 제한 해제 여부, 계정 이용 정책 준수 여부를 판단할 수도 없습니다.

장기간 로그인해야 하는 서비스는 출구 지역을 가능한 한 일정하게 유지하세요. 지역을 자주 바꾸면 추가 인증이 발생할 수 있습니다. 노드를 바꿔도 기존 TCP 연결은 보통 새 노드로 자동 이전되지 않으므로 새 출구를 확인하려면 연결을 다시 설정해야 합니다. 기존 연결을 끊을지는 진행 중인 다운로드, 통화, 원격 세션의 중단 가능 여부를 고려해 결정하세요.

프로토콜은 호환성과 UDP 지원부터 확인하세요

Shadowsocks, Trojan, VMess, VLESS, Hysteria2, TUIC 등의 이름은 서로 다른 프록시 프로토콜 또는 전송 체계를 뜻하며 속도 등급을 나타내지 않습니다. 실제 지원 범위는 클라이언트에 포함된 코어와 버전에 따라 달라집니다. Clash Meta(mihomo) 코어를 사용하는 클라이언트와 유지 관리가 중단된 구형 Clash 클라이언트의 지원 범위를 혼동하지 마세요.

설정을 가져올 때 지원되지 않는 프록시 유형, 파싱 실패, 핸드셰이크 오류가 발생하면 먼저 클라이언트의 ‘정보’ 또는 코어 정보에서 실제 코어를 확인하고 설정 요구 사항과 대조하세요. 앱 이름만 보고 판단하거나 매개변수의 의미를 모른 채 type, network, SNI, TLS 옵션을 임의로 바꾸지 마세요.

용도	중점 확인 항목	확인 방법
일반 웹 브라우징	TCP, TLS, 대상 사이트 규칙	실제 사이트를 열고 연결 기록 확인
음성 통화 및 게임	앱 트래픽 처리 방식, UDP 전달, 패킷 손실	실제 세션에 접속해 끊김과 지터 확인
UDP 기반 프록시 전송	로컬 네트워크에서 해당 UDP 통신을 허용하는지 확인	현재 네트워크와 다른 네트워크에서 각각 재측정
대용량 파일 전송	지속 전송 속도, 배율, 장시간 연결 안정성	같은 파일 출처를 사용해 조건을 통제하고 다운로드

Hysteria2와 TUIC는 QUIC 기반 전송을 사용하므로 하위 네트워크에서 UDP에 연결할 수 있어야 합니다. 일부 네트워크는 UDP를 제한하므로 프로토콜 자체를 지원하더라도 연결에 실패할 수 있습니다. 반대로 특정 노드로 TCP 웹사이트에 접속할 수 있다고 해서 게임이나 음성 통화의 UDP 트래픽도 처리할 수 있는 것은 아닙니다.

시스템 프록시가 모든 앱의 UDP 트래픽을 자동으로 처리하는 것은 아닙니다. 시스템 프록시를 따르지 않는 앱이라면 TUN 또는 앱 자체의 프록시 설정이 해당 트래픽을 처리하는지 확인하세요. 노드 설정에 udp: true를 지정했더라도 서버 측 지원이 필요하며, 클라이언트가 트래픽을 처리하고 규칙이 올바르게 라우팅해야 합니다. 일반적인 네트워크 불안정 문제를 해결하기 위해 인증서 검증을 끄지 마세요.

수동 선택과 자동 측정 함께 활용하기

select는 출구를 고정하고 직접 판단할 때 적합하며, url-test는 조건이 비슷한 후보 노드 중 탐지 결과에 따라 자동으로 선택할 때 유용합니다. 후자는 구독 배율, 계정 지역 요건, 대상 서비스 이용 가능 여부를 대신 판단하지 않습니다. 배율이 서로 다르거나 지역 조건이 맞지 않는 노드를 하나의 자동 그룹에 넣으면 수치는 더 좋아도 용도에 맞지 않는 노드로 전환될 수 있습니다.

다음은 기존 프로필에 병합해야 하는 mihomo 정책 그룹 예시이며 완성된 설정 파일이 아닙니다. 일상-A와 일상-B는 현재 설정에 실제로 존재하는 노드 이름으로 바꾸고, 두 노드의 배율과 출구 조건이 같은지 먼저 확인하세요. 테스트 URL 요청은 코어에서 전송되므로 현재 네트워크와 프록시 경로 모두에서 안정적으로 접속할 수 있는 주소를 사용해야 합니다.

proxy-groups:
  - name: 일상 자동
    type: url-test
    proxies:
      - 일상-A
      - 일상-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 일상 선택
    type: select
    proxies:
      - 일상 자동
      - 일상-A
      - 일상-B

interval: 300은 자동 탐지 간격이 300초라는 뜻입니다. tolerance: 50은 지연 시간 차이가 50ms 이내일 때 잦은 전환을 줄이기 위한 전환 허용치이며, 최대 허용 지연 시간을 뜻하지 않습니다. 이 설정만으로 모든 트래픽이 자동 처리되지는 않습니다. 연결이 해당 그룹으로 들어가려면 기존 규칙에서 일상 선택을 참조해야 합니다.

예를 들어 DOMAIN-SUFFIX,example.com,일상 선택 규칙은 도메인 접미사가 일치하는 연결을 이 정책 그룹으로 보냅니다. 규칙은 보통 위에서부터 순서대로 적용되며, 앞선 규칙이 먼저 일치하면 뒤의 규칙은 해당 연결을 처리하지 않습니다. 자세한 문법은 정책 그룹 설정 안내를 참조하세요.

용도별 최종 확인

웹 브라우징 및 원격 작업: 응답 속도와 안정성 우선

일반 웹 브라우징에는 배율이 낮고 연속 탐지 결과가 안정적인 노드를 우선 고려할 수 있습니다. SSH, 원격 데스크톱, 관리 페이지는 응답 속도와 세션 유지가 더 중요하므로 문제를 확인하는 동안 자동 전환을 피하고 수동으로 출구를 고정하는 편이 좋습니다. 노드 테스트는 정상인데 터미널 연결이 끊긴다면 대상 서버, 방화벽, 유휴 연결 시간 제한도 확인하세요.

동영상 및 다운로드: 지속 전송과 비용 우선

동영상은 대상 서비스에서 정상 재생되는지 먼저 확인한 뒤 버퍼링이 계속 발생하는지 살펴보세요. 대용량 파일은 속도가 처음 올라가는 순간만 보지 말고 같은 출처에서 일정 시간 안정적으로 전송되는지 비교해야 합니다. 속도 측정 사이트의 결과를 모든 다운로드 소스의 성능으로 간주하지 말고, 반복 측정으로 구독 데이터를 과도하게 사용하지 마세요.

게임 및 음성 통화: UDP 경로 별도 확인

먼저 게임 또는 음성 통화 앱이 실제로 프록시를 사용하는지 확인한 다음 앱에 표시되는 지연 시간, 지터, 패킷 손실을 살펴보세요. 웹 탐지에 성공했다는 결과는 초기 점검에만 참고할 수 있습니다. 노드를 바꿔도 차이가 없다면 프로토콜을 계속 바꾸기보다 규칙이 여전히 DIRECT로 연결을 보내는지, 앱이 기존 연결을 유지하는지 확인하세요.

안정적으로 사용할 주 노드와 검증된 예비 노드를 하나씩 정하고 각 노드의 지역과 배율을 기록하세요.
대상 서비스에 연결한 뒤 그룹에서 강조 표시된 항목만 보지 말고 클라이언트에서 실제 출구를 확인하세요.
실제 작업에서의 성능을 확인하고 계정 데이터 사용량 변화가 예상과 일치하는지도 살펴보세요.
문제가 발생하면 노드, 트래픽 처리 방식, 규칙, DNS 중 한 번에 하나만 바꾸고 매번 다시 확인하세요.

최종 선택 순서는 용도와 지역 조건을 먼저 충족하고, 배율을 감당할 수 있는지 확인한 뒤, 프로토콜과 트래픽 처리 호환성을 점검하고 지연 시간과 실제 안정성을 비교하는 것입니다. 밀리초 수치는 후보를 좁히는 데는 유용하지만 모든 상황의 노드를 단독으로 결정하는 기준은 아닙니다.