Clash 노드 선택 가이드:지연 시간,트래픽 배수,지역과 프로토콜 확인

먼저 노드 용도를 정하고 목록의 수치를 비교하세요

Clash 노드는 설정에서 선택하는 프록시 출구입니다. 클라이언트는 노드 목록을 표시하고, 코어는 연결을 구성하며, 서비스 제공자는 진입점과 출구, 경로 및 요금 방식을 결정합니다. 노드 이름에 붙은 ‘일본’, ‘전용 회선’, ‘0.5배’ 같은 표시는 보통 서비스 제공자가 추가한 설명일 뿐, 코어가 검증한 성능 정보는 아닙니다.

노드를 고를 때는 웹 탐색, 대용량 파일 전송, 지역 제한 서비스 이용, 실시간 통신으로 용도를 나눠 생각하세요. 웹 탐색은 연결 설정 속도가 중요하고, 다운로드는 지속적인 전송 속도가 중요합니다. 지역 제한 서비스는 실제 출구 지역을 확인해야 하며, 음성 통화와 게임은 UDP 지원 여부와 지터, 패킷 손실도 살펴봐야 합니다. 지연 시간 하나만으로는 이 모든 조건을 판단할 수 없습니다.

• 일상적인 웹 탐색: 안정적으로 사용할 수 있고 응답 편차가 작은 노드를 우선 선택하고, 예비 출구도 하나 마련하세요.
• 동영상 시청과 다운로드: 저녁 시간대의 지속 속도와 트래픽 배수를 확인하세요. 한 번 측정한 최고 속도만 보면 안 됩니다.
• 지역 제한 서비스: 속도를 비교하기 전에 출구 IP의 위치와 대상 서비스 접속 여부부터 확인하세요.
• 음성 통화와 게임: 앱 트래픽이 실제로 프록시를 통과하는지, 노드가 UDP를 지원하는지 확인하고 앱에서 지연 시간과 패킷 손실을 살펴보세요.

지연 시간 수치: 테스트 대상, 시간 초과와 편차

목록의 밀리초 수치는 무엇을 측정할까요?

Clash 계열 클라이언트는 지정된 URL을 통해 프록시 사용 가능 여부와 응답 시간을 측정하는 경우가 많습니다. 일반적으로 서버에 ICMP ping을 보내는 테스트도, 대역폭 측정도 아닙니다. 결과에는 기기에서 진입점까지의 연결, 프록시 핸드셰이크, 출구에서 테스트 사이트까지의 경로, 연결 재사용 여부 등이 영향을 줍니다. 클라이언트와 코어 버전에 따라 측정 방식도 다를 수 있습니다.

예를 들어 노드 A는 테스트 주소에 68ms, 노드 B는 126ms로 표시된다면, 이번 테스트에서 해당 주소에 A가 더 빠르게 응답했다는 뜻입니다. 실제로 이용할 사이트가 B의 출구에 더 가까우면 B가 더 쾌적할 수도 있습니다. 특정 테스트 도메인에서 나온 순위를 모든 사이트의 속도 순위로 받아들이지 마세요.

한 번의 순위보다 여러 번 측정한 결과가 더 유용합니다

1. 같은 네트워크와 테스트 URL을 사용하고, 대용량 다운로드와 클라우드 동기화는 잠시 중단하세요.
2. 후보 노드마다 약 10초 간격으로 5회 측정하고, 성공 횟수와 수치 범위를 기록하세요.
3. 실제로 사용할 사이트를 열어 첫 화면 로딩과 연속 작업이 원활한지 확인하세요.
4. 평소 이용 시간대에 다시 측정하세요. 예를 들어 20:00~23:00에 피크 시간대의 변동을 확인할 수 있습니다.

아래는 판단 방법을 설명하기 위한 예시이며, 이 사이트가 특정 회선을 직접 측정했거나 성능을 보장한다는 뜻은 아닙니다.

timeout이라고 해서 구독이 만료된 것은 아닙니다

시간 초과는 노드 오프라인, 테스트 사이트 접속 불가, DNS 조회 실패, 핸드셰이크 실패 또는 시간 초과 기준이 너무 짧은 경우에 발생할 수 있습니다. 먼저 다른 노드도 동시에 실패하는지 확인한 다음 실제 사이트에 접속해 보세요. 모든 노드가 실패하면 기기 네트워크와 설정을 점검하고, 한 노드만 실패하면 해당 노드의 연결 로그를 확인하세요. HTTP 테스트에 성공해도 UDP 통신이 정상이라는 뜻은 아닙니다.

트래픽 배수: 사용량 계산 기준이지 대역폭이 아닙니다

‘0.5×’, ‘1×’, ‘2×’는 보통 서비스 제공자가 해당 노드에 적용하는 트래픽 과금 계수를 뜻합니다. 배수는 Clash 공통 프로토콜 필드가 아니며, 노드 이름에 ‘2×’라고 적혀 있어도 코어가 대역폭을 두 배로 늘려 주지는 않습니다. 정확한 계산 기준은 서비스 제공자의 사용량 안내와 계정 페이지에서 확인하세요.

사용량 계산 예시

서비스 제공자가 업로드와 다운로드를 합산한 트래픽에 배수를 곱해 요금제 용량을 차감한다고 가정하면, 과금 트래픽은 다음과 같이 계산할 수 있습니다. 과금 트래픽 = 실제 집계 트래픽 × 노드 배수. 실제 집계량이 8GB일 때 배수별 차감량은 다음과 같습니다.

실제 차감량은 업로드와 다운로드 집계 기준, GB와 GiB 단위 차이, 프로토콜 오버헤드, 청구 정보 갱신 지연 등에 따라 달라질 수 있습니다. 클라이언트에 표시되는 다운로드량과 계정 페이지의 수치가 완전히 일치하지 않을 수도 있습니다. 노드 이름에 ‘배수 0’이라고 적혀 있더라도 적용 시간, 속도 제한, 사용량 규칙을 확인하세요. 노드 이름만으로 판단해서는 안 됩니다.

속도 테스트에도 데이터가 사용됩니다

소량의 데이터를 사용하는 URL 응답 시간 테스트와 달리, 전체 대역폭 테스트는 대량의 데이터를 계속 전송할 수 있습니다. 평균 다운로드 속도가 50Mbps일 때 30초 동안 전송되는 데이터는 약 50 ÷ 8 × 30 = 187.5MB입니다. 추가 오버헤드는 포함하지 않은 값이며, 노드 배수가 2배라면 이 기준으로 약 375MB가 차감됩니다. 수십 개 노드에서 대역폭 테스트를 일괄 실행하면 요금제 용량이 빠르게 줄어들 수 있습니다.

노드 지역: 진입점, 출구와 웹사이트의 위치 인식 구분하기

‘홍콩 진입｜미국 출구’라는 이름의 노드는 가까운 서버로 먼저 연결한 뒤 중계 회선을 거쳐 미국에서 대상 사이트에 접속할 수 있습니다. 진입점은 기기에서 노드까지의 경로에 영향을 주고, 출구는 웹사이트에 표시되는 IP를 결정합니다. 설정에 적힌 서버 도메인이나 주소는 진입점일 수 있으며, 이것만으로 최종 출구가 어느 국가인지 단정할 수는 없습니다.

실제 접속 대상에 맞춰 지역을 선택하세요

• 일반 웹사이트 접속: 우선 연결 경로가 짧은 지역을 시험하되, 다른 지역도 비교 대상으로 남겨 두세요. 물리적으로 가까워도 통신사 경로가 더 짧다는 보장은 없습니다.
• 특정 지역 콘텐츠 이용: 해당 노드의 출구 IP를 조회한 뒤 대상 서비스에서 접속 결과를 확인하세요. IP 데이터베이스 반영이 늦을 수도 있습니다.
• 특정 계정 이용: 출구 지역을 가능한 한 일정하게 유지해 지역을 자주 바꿀 때 발생할 수 있는 보안 인증을 줄이세요.
• 해외 파일 다운로드: 실제 속도는 출구와 다운로드 서버 간의 연결 상태에 따라 달라집니다. 기기에서 가장 가까운 노드만 고집하지 말고 다운로드 서버와 가까운 출구도 비교해 보세요.

지역이 맞더라도 특정 서비스를 이용할 수 있다고 보장되지는 않습니다. 서비스는 데이터센터 IP, 계정 지역, 결제 정보 및 기타 위험 신호를 바탕으로 접속을 제한할 수도 있습니다. ‘스트리밍 잠금 해제’ 같은 노드 표시는 언제든 바뀔 수 있으므로, 현재 대상 서비스에서 실제로 접속되는지 확인하고 이용 약관을 준수하세요.

전용 회선, 직결, 중계 표시는 어떻게 볼까요?

이러한 표시는 서비스 제공자가 회선을 구성하는 방식을 설명하지만, 클라이언트가 검증하는 공통 기준은 없습니다. 중계가 혼잡을 줄일 수도 있지만 경로가 더 길어질 수도 있습니다. 전용 회선이라는 이름만으로 피크 시간대 성능을 판단할 수도 없습니다. 노드 이름만 비교하기보다 진입 네트워크, 테스트 시간, 실제 출구와 안정성을 기록해 비교하는 편이 신뢰할 만합니다.

프로토콜 종류: 먼저 코어 호환성, 다음으로 네트워크 환경을 확인하세요

Clash는 클라이언트 생태계에서 널리 쓰이는 이름이지만, 클라이언트마다 사용하는 코어가 다를 수 있습니다. mihomo는 기존 Clash Meta 프로젝트를 이어받았으며, 지원하는 프로토콜과 설정 필드는 구형 Clash 코어와 완전히 같지 않습니다. 먼저 클라이언트의 정보 화면이나 코어 정보에서 코어 이름과 버전을 확인한 뒤, 해당 버전의 문서에서 구독의 type 필드를 살펴보세요. 클라이언트 프로그램에서 YAML을 가져올 수 있다고 해서 모든 노드를 실행할 수 있는 것은 아닙니다.

프로토콜 이름만으로 속도를 예측할 수 없습니다

같은 서버에서 프로토콜을 바꿔 비교하는 것과 서로 다른 서버 두 대를 비교하는 것은 별개의 문제입니다. 회선 용량, 서버 부하, 혼잡 제어, 로컬 통신사의 경로가 프로토콜 이름보다 속도에 더 큰 영향을 줄 수 있습니다. Hysteria2나 TUIC가 일부 네트워크에서 잘 작동할 수 있지만 UDP가 제한된 환경에서는 연결에 실패할 수도 있습니다. 반대로 다른 네트워크에서는 TCP 기반 방식이 더 안정적일 수 있습니다.

노드의 전송 프로토콜과 앱의 UDP 지원 여부도 따로 확인해야 합니다. 프로토콜이 UDP 전송을 지원하더라도 서비스 제공자가 UDP를 허용한다는 뜻은 아니며, 현재 설정에서 기능이 활성화되어 있다는 보장도 없습니다. 브라우저에서 웹페이지가 열린다고 해서 게임이나 음성 통화 트래픽도 같은 노드를 통해 전달된다고 볼 수는 없습니다.

수동 선택과 자동 테스트: 정책 그룹은 어떻게 다를까요?

노드는 출구이고, 정책 그룹은 사용할 출구를 결정합니다. 수동 그룹은 특정 지역이나 계정을 고정해 이용할 때 적합합니다. url-test는 지정된 URL의 테스트 결과를 바탕으로 노드를 자동 선택하고, fallback은 보통 순서에 따라 사용 가능한 노드를 선택합니다. 이러한 기능은 주로 연결 가능 여부와 테스트 응답을 기준으로 동작하며, 다운로드 속도가 가장 빠른 노드를 자동으로 고르는 기능은 아닙니다.

mihomo 정책 그룹 예시

아래 예시는 기존 설정에 ‘일상-A’와 ‘예비-B’라는 두 노드가 이미 정의되어 있다고 가정합니다. 정책 그룹만 보여 주는 예시이며 전체 구독 설정은 아닙니다. 실제 노드 이름이 다르면 기존 이름에 맞게 바꿔야 합니다. 그렇지 않으면 존재하지 않는 프록시를 참조한다는 오류가 발생합니다.

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의 전환 허용 오차를 설정해 작은 차이로 노드가 계속 바뀌는 현상을 줄입니다. 예시에 쓰인 테스트 주소도 노드를 통해 접속하므로 접근 가능 여부가 결과에 영향을 줍니다. 안정적인 테스트 URL을 실제 사용 환경에 맞게 선택하세요.

실제 트래픽에서 이 그룹을 사용하려면 해당 규칙이 ‘수동 선택’ 또는 ‘일상 자동’을 가리키도록 해야 합니다. 정책 그룹만 추가한다고 기존 규칙이 바뀌지는 않습니다. 구독 관리형 클라이언트는 업데이트할 때 원본 파일을 덮어쓸 수 있으므로, 클라이언트의 덮어쓰기 또는 병합 기능으로 사용자 설정을 저장하세요. 설정 방법은 설정 가이드를 참고하세요.

TUN은 속도 향상 기능이 아닙니다

TUN은 더 많은 앱의 네트워크 트래픽을 가로채는 기능입니다. 시스템 프록시는 일반적으로 프록시 설정을 따르는 프로그램에만 영향을 줍니다. TUN을 켜면 어떤 연결이 코어로 전달되는지는 바뀔 수 있지만 노드 회선의 대역폭이 늘어나지는 않습니다. 브라우저는 정상인데 다른 프로그램에서 프록시를 사용하지 않는다면 트래픽 처리 방식을 확인하세요. 동일한 노드를 거치는 것이 확인됐는데도 느리다면 회선과 대상 사이트를 비교해야 합니다. TUN 전환을 모든 상황에 적용되는 속도 테스트 방법으로 여기지 마세요.

10분 만에 노드 고르기: 반복해서 활용할 점검 순서

1. 설정 확인: 구독이 불러와졌는지, 코어가 노드 프로토콜을 지원하는지, 요금제 잔여량과 유효 기간이 정상인지 확인하세요.
2. 지역과 배수로 추리기: 사용 목적에 맞춰 후보를 2~3개 고르고 출구 지역과 과금 계수를 기록하세요.
3. 사용 가능 여부 테스트: 같은 URL로 5회 연속 측정해 시간 초과가 잦거나 편차가 큰 후보를 우선 제외하세요.
4. 실제 작업 테스트: 자주 이용하는 페이지를 열거나 동영상을 재생하고, 같은 파일을 짧게 다운로드해 보세요. 최고 속도 스크린샷만으로 사용감을 판단하지 마세요.
5. 연결 확인: 연결 화면에서 규칙, 정책 그룹과 최종 노드를 확인해 프록시가 아닌 직접 연결 결과와 비교하지 않도록 하세요.
6. 예비 노드 마련: 자주 쓰는 노드 하나와 다른 회선을 사용하는 예비 노드 하나를 정하고, 피크 시간대에 다시 확인하세요.

기록 항목은 간단해도 됩니다. 날짜, 네트워크 종류, 노드 이름, 5회 지연 시간, 30초 평균 속도, 배수, 대상 서비스 접속 여부를 적어 두세요. Mbps와 MB/s는 다릅니다. 오버헤드를 제외하면 100Mbps는 약 12.5MB/s입니다. 결과를 비교할 때 단위를 통일해야 표시 방식 차이를 성능이 8배 차이 나는 것으로 오해하지 않습니다.

같은 시간대에 모든 후보가 느려졌다면 다른 로컬 네트워크와 비교한 다음 백그라운드 업로드, 기기의 DNS, 트래픽 처리 설정을 확인하세요. 한 노드만 느리다면 출구를 바꿔 비교하는 편이 좋습니다. 원인을 더 확인하려면 문제 해결을 참고하세요. 노드를 선택할 때 가장 중요한 기준은 실제 작업의 안정성과 비용이지, 목록에서 가장 낮은 숫자가 아닙니다.