실제 출구부터 확인한 뒤 노드 수치를 비교하세요

Clash 노드 목록의 지연 시간, 지역, 배수는 각각 다른 정보를 나타냅니다. 지연 시간은 탐색 요청에 걸린 시간이고, 지역은 보통 서비스 제공업체가 표시한 출구 위치이며, 배수는 구독 계정에서 차감되는 트래픽 양에 영향을 줍니다. 서로 대체할 수 있는 정보가 아닙니다. 노드를 선택할 때는 먼저 대상 사이트에 필요한 출구를 정하고, 연결 가능 여부와 안정성을 확인한 다음 속도와 사용량 비용을 비교하세요.

노드 테스트는 정상인데 웹페이지가 여전히 느리다면, 먼저 웹 트래픽이 해당 노드를 실제로 통과하는지 확인하세요. mode: rule에서는 rules가 순서대로 적용되며, 규칙의 대상은 정책 그룹일 수도 있고 DIRECT일 수도 있습니다. 현재 요청에 사용되지 않는 정책 그룹을 바꿔도 해당 요청의 경로는 달라지지 않습니다.

  1. 클라이언트의 ‘연결’ 페이지에서 대상 도메인에 해당하는 연결을 찾아 적용된 규칙, 아웃바운드 경로, 정책 그룹을 확인하세요.
  2. 수정하려는 그룹이 해당 연결 경로에서 실제로 사용하는 그룹인지 확인하세요. 이름이 비슷한 다른 그룹이 아닐 수 있습니다.
  3. 노드를 바꾼 뒤에는 연결을 다시 설정하세요. 기존 TCP 연결은 선택을 변경해도 보통 자동으로 전환되지 않습니다.
  4. 백그라운드 다운로드와 클라우드 드라이브 동기화를 일시 중지한 뒤 비교 테스트를 진행하세요. 로컬 대역폭 경쟁으로 판단이 흐려지는 것을 막을 수 있습니다.

지연 시간 테스트: HTTP 탐색은 다운로드 속도 측정이 아닙니다

클라이언트에서 흔히 제공하는 지연 시간 테스트는 선택한 프록시를 통해 테스트 URL에 접속하고 탐색에 걸린 시간을 기록합니다. 프록시 서버에 ICMP ping만 보내는 방식은 아닙니다. 결과에는 노드 연결, TLS 핸드셰이크, 테스트 사이트의 응답, 로컬 네트워크, 연결 재사용 등이 영향을 줄 수 있습니다. 구현 세부 사항은 코어와 클라이언트마다 다를 수 있습니다.

따라서 비교할 때는 테스트 URL, 네트워크, 테스트 시간을 동일하게 맞추세요. 한 클라이언트에서 측정한 80ms와 다른 클라이언트에서 측정한 110ms를 바로 순위로 비교하는 것은 공통 기준이 없어 적절하지 않습니다. 한 번 ‘시간 초과’가 표시됐다고 해서 모든 대상 사이트에 접속할 수 없다는 뜻은 아닙니다. 해당 탐색이 제한 시간 안에 완료되지 않았다는 의미일 뿐입니다.

반복 테스트로 낮은 지연 시간과 안정성을 구분하세요

아래는 결과를 해석하는 방법을 보여 주는 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 각 노드를 같은 네트워크 환경에서 약 10초 간격으로 5회 연속 측정합니다.

후보 노드5회 탐색 결과우선 판단
A58、61、60、59、62 ms측정 시간이 고르게 분포되어 실제 서비스에서도 추가 검증 가능
B35, 240, 시간 초과, 48, 310ms최저값은 더 낮지만 편차와 실패가 뚜렷함
C125、128、126、130、127 ms측정 시간은 길지만 이 표본에서는 비교적 안정적

웹페이지 상호작용에서는 왕복 시간과 실패율이 중요한 반면, 대용량 파일 다운로드에서는 지속 처리량이 더 중요합니다. 노드 A의 60ms가 노드 C보다 다운로드 속도가 빠르다는 뜻은 아닙니다. 지속 속도는 회선 용량, 공유 부하, 서버 측 속도 제한, 대상 사이트의 영향을 받습니다. 탐색 결과의 편차는 엄밀한 의미의 네트워크 지터 측정이 아니며, 이를 바탕으로 전체 회선의 패킷 손실률을 계산할 수도 없습니다.

다운로드와 동영상은 별도로 확인하세요

  • 신뢰할 수 있는 동일한 다운로드 소스를 사용해 약 30~60초 동안 테스트하고, 시작 직후의 최고 속도만 보지 말고 속도가 안정된 뒤의 수치를 확인하세요.
  • MB/s와 Mbps를 구분하세요. 이론적으로 10MB/s는 약 80Mbps이며, 실제 전송에는 프로토콜 오버헤드가 발생합니다.
  • 동영상은 재생 시작 시간, 버퍼링 횟수, 플레이어에 표시되는 연결 속도를 확인하세요. 한 번 재생에 성공했다고 해서 사용량이 많은 시간대에도 계속 원활하다는 뜻은 아닙니다.
  • 속도 테스트에도 트래픽이 사용됩니다. 대용량 파일을 테스트하기 전에 남은 사용량과 해당 노드의 배수를 확인하세요.

트래픽 배수: 서비스 제공업체의 과금 기준으로 계산

배수는 구독 서비스 제공업체의 과금 기준이며, Clash에 공통으로 적용되는 로컬 과금 옵션이 아닙니다. 기본 Clash와 mihomo에는 서비스 제공업체의 계정 차감량을 클라이언트가 바꿀 수 있는 공통 노드 ratio 필드가 없습니다. 노드 이름에 ‘2×’라고 표시되어 있어도 안내 문구일 뿐입니다. 실제 기준은 서비스 제공업체의 노드 안내, 청구 내역, 계정 사용량 기록으로 확인하세요.

흔히 ‘실제 사용량 × 노드 배수’로 계산합니다. 서비스 제공업체가 업로드와 다운로드 합계를 기준으로 과금한다고 가정하면, 다운로드 8GB와 업로드 2GB의 기본 사용량은 10GB입니다. 0.5×, 1×, 2× 노드를 사용하면 각각 5GB, 10GB, 20GB가 차감될 수 있습니다. 여기서는 같은 단위로 예를 들었습니다. GB와 GiB 중 어떤 단위를 쓰는지, 반올림 방식과 시간대별 과금 여부는 별도로 확인해야 합니다.

배수를 기준으로 사용 가능한 트래픽을 계산하세요

  • 계정 잔여량이 100GB이고 2× 노드를 계속 사용한다면, 같은 과금 기준에서 실제 전송할 수 있는 기본 트래픽은 약 50GB입니다.
  • 0.5×라고 속도가 더 느린 것은 아니며, 2×라고 대역폭이 두 배가 되는 것도 아닙니다. 배수는 요금 관계를 나타낼 뿐 성능을 보장하지 않습니다.
  • 장시간 동영상 시청, 대용량 파일 다운로드, 기기 백업은 먼저 사용 가능량을 확인하세요. 짧은 로그인이나 특정 지역에서의 접속은 필요한 기능이 가능한지부터 확인하면 됩니다.
  • 클라이언트에 표시되는 누적 트래픽과 서비스 제공업체의 과금량은 다를 수 있습니다. 집계 대상 연결, 통계 기간, 프로토콜 오버헤드가 서로 다르면 차이가 발생합니다.

지역 선택: 출구 위치와 회선 품질을 따로 확인

노드 지역은 보통 외부 사이트에 접속할 때 사용하는 출구 위치를 의미하며, 구독의 server 주소가 있는 물리적 위치와 반드시 같지는 않습니다. 진입 지점, 중계 지점, 출구가 서로 다른 네트워크에 있을 수 있습니다. 홍콩, 일본, 싱가포르처럼 지리적으로 가까운 곳을 우선 후보로 삼을 수는 있지만, 거리만으로 통신사 간 라우팅, 저녁 시간대 혼잡, 출구 품질을 모두 판단할 수는 없습니다.

실제 용도에 맞게 필터 조건을 설정하세요

사용 사례먼저 확인할 항목그다음 비교할 항목
웹사이트 및 개발 문서대상 사이트 접속 가능 여부, DNS 조회 정상 여부연속 탐색 시간, 페이지 로딩 안정성
지역 제한 콘텐츠실제 출구 위치, 계정 지역 요건재생 시작 성공률, 지속 속도, 배수
음성 통화 및 실시간 게임UDP 지원 여부, 앱 트래픽의 프록시 경유 여부서비스 내 지연 시간, 끊김 여부
대용량 파일 전송사용 가능량, 배수, 서비스 제공업체의 이용 제한지속 처리량, 장시간 연결 안정성
특정 계정으로 로그인출구 위치의 일관성, 플랫폼 보안 요건연결 안정성, 잦은 지역 전환 방지

대상 사이트는 자체 IP 지리정보 데이터베이스를 사용할 수 있으며, 계정 지역, 결제 정보, 기기 위치를 함께 고려해 이용 가능 지역을 판단하기도 합니다. IP 조회 페이지에 특정 지역으로 표시되더라도 모든 플랫폼에서 같은 결과가 나오지는 않습니다. 대상 서비스에서 직접 확인하고, ‘지역 태그가 맞다’는 이유만으로 접속 권한이 보장된다고 생각하지 마세요.

프로토콜 선택: 먼저 코어 호환성을 확인하고 네트워크 성능을 비교

프로토콜은 연결 방식과 기능상의 한계를 결정하지만, 회선 조건과 분리해 순위를 매길 수는 없습니다. Shadowsocks, Trojan, VMess, VLESS, Hysteria2, TUIC 등의 지원 여부는 실제 사용하는 코어에 따라 달라집니다. mihomo가 지원하는 프로토콜은 과거 Clash 코어와 완전히 같지 않으며, 클라이언트의 외관이 비슷하다고 내장 코어까지 같은 것은 아닙니다.

가져온 뒤 ‘unsupported proxy type’ 같은 오류가 나타나면 속도 테스트 주소를 계속 바꾸기보다 노드의 type과 클라이언트에서 실제로 사용하는 코어를 먼저 확인하세요. 클라이언트를 바꿔야 한다면 클라이언트 선택 가이드를 확인한 다음 다운로드 페이지에서 해당 플랫폼용 클라이언트를 선택하세요.

UDP, 시스템 프록시, TUN의 적용 범위

  • Hysteria2와 TUIC는 UDP를 통해 연결을 전송합니다. 현재 네트워크에서 UDP를 제한하면 핸드셰이크가 실패하거나 연결이 불안정할 수 있지만, TCP 기반 연결은 정상 작동할 수 있습니다.
  • 노드 설정의 udp: true는 해당 필드를 지원하는 유형에서 UDP 전달을 허용합니다. 서버나 로컬 네트워크에 없던 UDP 기능을 만들어 주지는 않으며, 모든 프로토콜 유형에 적용되는 것도 아닙니다.
  • 일반적인 HTTP 시스템 프록시는 프록시 설정을 따르는 앱을 주로 지원합니다. 따라서 게임이나 음성 통화의 UDP 트래픽까지 프록시를 경유한다고 단정할 수 없습니다.
  • TUN은 가상 네트워크 인터페이스 계층에서 트래픽을 처리하지만, 라우팅, 규칙, DNS, 권한 설정이 올바르게 되어 있어야 합니다. TUN을 켜도 서비스 제공업체가 노드에 할당한 대역폭이 늘어나지는 않습니다.

같은 회선에서는 프로토콜 차이가 핸드셰이크, 혼잡 제어, 리소스 사용량에 영향을 줄 수 있습니다. 서로 다른 회선끼리는 대역폭과 부하의 차이가 더 크게 작용하는 경우가 많습니다. 프로토콜 이름의 최신성만 따지지 말고 현재 네트워크에서의 연결 성공률, 실제 서비스 성능, 기기 부하를 기준으로 선택하세요.

정책 그룹 설정: 수동 선택과 자동 탐색을 나눠 사용

select는 특정 지역이나 출구를 고정하거나 직접 비교할 때 적합합니다. url-test는 지정한 URL의 탐색 결과를 바탕으로 후보를 자동 선택합니다. 하지만 서비스 제공업체의 배수를 파악하거나 특정 동영상 플랫폼에서 지역별 이용이 가능한지 자동 확인하지는 않습니다. 용도가 다른 노드를 한 자동 그룹에 모두 넣으면 탐색 속도는 빠르지만 실제 사용 목적에는 맞지 않는 결과가 나올 수 있습니다.

아래는 mihomo 정책 그룹의 일부 설정이며, 전체 설정 파일은 아닙니다. 사용하려면 proxies에 이름이 정확히 일치하는 ‘홍콩-A’와 ‘일본-B’가 먼저 있어야 합니다. 프록시 그룹을 사용하는 경우에는 실제 구조에 맞게 use로 그룹을 참조해야 하며, 노드 이름 두 개만 복사해서는 안 됩니다.

proxy-groups:
  - name: 일상 선택
    type: select
    proxies:
      - 자동 지연 시간
      - 홍콩-A
      - 일본-B

  - name: 자동 지연 시간
    type: url-test
    proxies:
      - 홍콩-A
      - 일본-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300은 탐색 간격이 300초라는 뜻이며, 구독 갱신 주기가 아닙니다.
  • tolerance: 50은 밀리초 단위의 전환 허용 오차를 설정해 작은 차이로 전환이 반복되는 것을 방지합니다. 서비스 지연 시간의 상한값은 아닙니다.
  • lazy: true는 지연 탐색을 활성화합니다. 그룹을 사용하지 않을 때는 주기적인 테스트가 생략될 수 있으므로, 화면에 표시된 오래된 수치를 실시간 결과로 보면 안 됩니다.
  • url은 상태 확인 대상입니다. 안정적으로 접속할 수 있는 주소를 선택하세요. 대상을 바꾸면 변경 전후의 수치를 직접 비교하기 어렵습니다.

정책 그룹을 설정한 뒤에는 해당 규칙이 ‘일상 선택’을 참조하도록 해야 실제 요청에 적용됩니다. 수정 전 설정을 백업하고, 불러온 뒤 로그와 연결 페이지를 확인하세요. 구독을 갱신하면 생성된 파일을 직접 수정한 내용이 덮어써질 수 있습니다. 장기적으로 설정을 조정하려면 클라이언트가 제공하는 오버라이드 또는 병합 기능을 사용하세요. 메뉴 위치는 클라이언트마다 다릅니다.

노드 선택 체크리스트

  1. 요구 사항 확인: 대상 사이트, 필요한 지역, UDP 사용 여부, 이번 달 잔여 사용량을 기록하세요.
  2. 후보 선정: 지역과 프로토콜 요건을 충족하는 노드 2~3개를 추리고 배수와 코어 호환성을 확인하세요.
  3. 조건을 고정해 탐색: 같은 네트워크와 URL에서 각 노드를 5회씩 테스트하고, 반복적으로 시간 초과가 발생하거나 편차가 큰 후보는 우선 제외하세요.
  4. 실제 서비스 확인: 웹페이지는 연결을 다시 설정하고, 동영상은 연속 재생하며, 다운로드는 안정 속도를 확인하고, 게임은 앱 내 지연 시간을 확인하세요.
  5. 아웃바운드 확인: 연결 페이지에서 규칙과 프록시 경로를 확인해 직접 연결 결과를 노드 성능으로 잘못 기록하지 않도록 하세요.
  6. 혼잡 시간대 성능 재확인: 주로 사용하는 시간대에 다시 테스트하고, 같은 요구 사항을 충족하는 예비 노드를 하나 확보하세요.

최종 기록은 노드 이름, 용도, 배수, 연속 탐색 결과, 실제 서비스 성능의 다섯 항목으로 정리하면 됩니다. 한 번 측정한 최저 지연 시간이 아니라 다시 확인할 수 있는 이 정보를 기준으로 선택하세요. 포트, 규칙, DNS 필드를 더 알아보려면 설정 참고 자료를 확인하세요.