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

먼저 트래픽 경로 확인: 노드 선택이 실제로 적용되는지

노드를 고르기 전에 대상 연결이 실제로 현재 조정 중인 정책 그룹을 통과하는지 확인하세요. Clash 규칙 모드는 rules를 위에서 아래로 확인합니다. 브라우저 요청이 DIRECT에 매칭되면 프록시 노드를 바꿔도 해당 요청의 경로는 달라지지 않습니다. 스트리밍 규칙이 별도의 정책 그룹을 가리키는 경우도 있어, 홈 화면에 표시된 기본 프록시 그룹과 다를 수 있습니다.

1. 클라이언트의 ‘프로필’ 또는 ‘Profiles’에서 업데이트만 해 둔 다른 설정이 아니라 현재 활성화된 구독 설정인지 확인하세요.
2. ‘프록시’ 또는 ‘Proxies’에서 규칙이 실제로 참조하는 정책 그룹을 찾아 노드를 하나 직접 선택하세요.
3. 대상 사이트에 접속한 다음 ‘연결’ 또는 ‘Connections’를 열어 도메인, 적용된 규칙, 아웃바운드 경로를 확인하세요. 메뉴 이름은 클라이언트마다 다르지만 이 세 항목을 확인하는 것이 중요합니다.
4. 노드를 바꾼 뒤 새 연결을 만들어 테스트하세요. 기존 TCP 장기 연결은 보통 자동으로 전환되지 않으므로 필요하면 진행 중인 작업을 중단하고 다시 연결하세요.

지연 시간은 안정성을 기준으로 판단하세요: 최저 기록만 보지 마세요

클라이언트에 표시되는 지연 시간은 보통 노드를 통해 테스트 URL에 접속해 측정한 값입니다. 기기에서 노드 서버까지의 단순 ICMP 지연 시간이나 다운로드 속도와는 다릅니다. 테스트 주소, DNS, 연결 수립, 프로토콜 핸드셰이크, 연결 재사용, 코어 구현에 따라 결과가 달라질 수 있습니다. 두 노드는 같은 네트워크와 테스트 주소에서 비교해야 수치를 제대로 참고할 수 있습니다.

5회 측정 기록으로 후보 노드 추리기

후보 노드 3개를 정하고 약 30초 간격으로 총 5회 테스트하세요. 대용량 다운로드를 동시에 실행하지 말고, 시간 초과 결과도 기록하세요. 성공한 측정 중 최저값만 남겨서는 안 됩니다. 아래는 판단 방법의 예시이며 이 사이트가 실제 서비스에서 측정한 데이터가 아닙니다.

위 예시에서는 B가 25ms를 한 번 기록했다는 이유만으로 선택하기보다 일상적인 웹 검색에는 A를 먼저 테스트하는 편이 낫습니다. C가 대상 서비스의 지역 요건을 충족한다면 불안정한 B보다 적합할 수도 있습니다. 탐색 시간 초과만으로 패킷 손실률을 단정할 수는 없습니다. 패킷 손실을 판단하려면 네트워크 진단 결과와 실제 연결 상태도 함께 확인해야 합니다.

저녁 혼잡 시간대에 실제 작업을 다시 테스트하세요

• 웹 검색: 자주 이용하는 페이지 5개를 연속으로 열어 첫 로딩과 이미지·스크립트가 반복해서 기다리는지 확인하세요.
• 동영상: 같은 영상과 화질을 고정한 뒤 3분 동안 재생하며 버퍼링을 확인하세요. 재생이 빨리 시작되는지만 보면 안 됩니다.
• 다운로드: 동일한 합법적 테스트 파일을 사용해 시작 직후의 속도와 60초 동안 유지되는 속도를 각각 기록하세요. 여러 작업이 대역폭을 나눠 쓰지 않도록 합니다.

낮에는 괜찮다가 저녁에 속도가 크게 떨어진다면 회선이나 서버 부하가 달라졌을 가능성이 큽니다. 프로토콜을 바꿔도 해결되지 않을 수 있으므로 다른 회선을 먼저 비교하고, 평소 실제로 사용하는 시간대에 다시 테스트하세요.

트래픽 배율: 사용량을 계산한 다음 속도 비교하기

노드 이름에 표시된 ‘0.5배’, ‘1배’, ‘2배’는 보통 구독 서비스의 과금 기준이며 Clash 코어 공통의 속도 제한 설정이 아닙니다. 노드 이름에 ‘2배’라고 적혀 있어도 클라이언트가 다운로드 속도를 두 배로 높여 주지는 않습니다. 실제 차감 기준은 서비스 제공자의 안내와 계정 사용량 기록을 확인하세요. 일부 서비스는 업로드·다운로드 또는 특정 시간대에 따라 별도로 계산하기도 합니다.

같은 단위로 계정 사용량 계산하기

서비스가 ‘과금 트래픽 × 배율’로 차감하고 작업량이 2GiB라고 가정하면 0.5배는 약 1GiB, 1배는 약 2GiB, 2배는 약 4GiB가 차감됩니다. 이는 계산 예시일 뿐입니다. 프로토콜 오버헤드, 양방향 과금, GB와 GiB의 단위 차이 때문에 계정 기록이 로컬 파일 크기와 다를 수 있습니다.

• 웹사이트·메신저: 보통 안정성을 먼저 보고 배율은 부차적인 조건으로 고려하세요.
• 동영상·대용량 파일: 월간 사용량을 먼저 예상한 뒤 필요한 사용량을 꾸준히 감당할 수 있는 낮은 배율의 노드를 고르세요.
• 중요한 단기 작업: 배율이 높더라도 안정적인 후보를 사용할 수 있습니다. 작업이 끝나면 평소 쓰는 노드로 돌아가세요.

지역 선택: 지리적 거리보다 출구 위치와 대상 서비스를 확인하세요

노드 이름에 표시된 지역은 출구 위치일 수도 있고 서비스 제공자가 붙인 회선 이름일 수도 있습니다. 진입 서버, 중계 경로, 최종 출구가 서로 다른 지역에 있을 수 있습니다. 기기와 가까운 지역의 노드라고 해서 반드시 더 빠른 것은 아닙니다. 통신사 간 연결, 우회 경로, 혼잡 시간대의 정체에 따라 결과가 달라질 수 있습니다.

일반 웹사이트와 스트리밍은 판단 기준이 다릅니다

일반 웹 검색은 인접 지역의 안정적인 회선부터 시험한 뒤 실제 페이지 로딩을 비교하세요. 스트리밍은 먼저 대상 콘텐츠의 계정 지역, 출구 IP, 이용 권한, 서비스 약관 요건을 확인해야 합니다. 출구 IP가 특정 국가나 지역으로 인식된다고 해서 해당 지역의 모든 콘텐츠를 볼 수 있는 것은 아닙니다.

1. 후보 노드를 직접 고정하고 대상 도메인이 예상한 정책 그룹에 매칭되는지 확인하세요.
2. 해당 아웃바운드 연결로 출구 IP와 지역을 확인한 다음 서비스의 재생 페이지에서 직접 검증하세요.
3. 화질을 고정하고 최소 3분간 재생해 반복 버퍼링, 화질 저하, 지역 제한 안내가 나타나는지 확인하세요.
4. 페이지 접속과 재생 결과가 다르면 노드가 작동하지 않는다고 바로 단정하지 말고 미디어 도메인이 다른 규칙으로 분기되는지 확인하세요.

개발 작업도 목표 서비스에 맞춰 검증해야 합니다. 코드 저장소, 패키지 저장소, 컨테이너 이미지가 서로 다른 CDN을 사용할 수 있으므로 홈페이지가 빠르다고 의존성 다운로드도 빠른 것은 아닙니다. 로그인 상태를 안정적으로 유지해야 하는 서비스라면 출구 지역을 가능한 한 고정해 자동 그룹이 여러 지역을 자주 오가지 않도록 하세요.

프로토콜 선택: 호환성을 먼저 확인하고 UDP와 네트워크 환경 살펴보기

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC는 서로 다른 프록시 프로토콜 또는 방식의 이름이지 속도 등급이 아닙니다. 같은 프로토콜이라도 회선에 따라 사용 경험은 크게 달라질 수 있습니다. 선택하기 전에 클라이언트에 포함된 코어가 해당 프로토콜과 설정값을 지원하는지 확인하세요. 구버전 Clash와 Clash Meta(mihomo)는 지원 범위가 서로 다릅니다.

Hysteria2와 TUIC는 QUIC 기반이므로 사용 가능한 UDP 경로가 필요합니다. 일부 네트워크는 UDP를 제한해 연결을 막거나 불안정하게 만들 수 있습니다. TCP 기반 프록시 전송 방식도 혼잡과 회선 품질의 영향을 받습니다. 프로토콜 이름만으로 실제 성능을 대신 판단할 수 없으며, ‘가장 빠른 프로토콜’을 일률적으로 순위 매기는 것도 적절하지 않습니다.

웹사이트는 정상인데 음성 통화나 게임이 안 된다면 UDP, TUN 연결, 트래픽 분기 규칙을 확인하세요. 클라이언트에서 지원하지 않는 프록시 유형이라고 표시되면 먼저 코어 호환성을 해결하세요. 인증서 검증을 끄는 방법을 만능 해결책으로 사용해서는 안 됩니다. 구독의 인증 정보, 서버 주소, 전송 설정은 서버 설정과 일치해야 합니다.

정책 그룹 설정: 평소에는 자동 선택, 중요한 작업에는 노드 고정

url-test는 테스트 결과에 따라 후보 중 하나를 자동으로 고르는 데 적합하지만 트래픽 배율, 동영상 이용 권한, 개발 작업의 성공 여부까지 확인하지는 않습니다. 지역과 배율이 다른 모든 노드를 하나의 자동 그룹에 넣으면 탐색 지연 시간은 낮아도 실제 요구에는 맞지 않는 노드가 선택될 수 있습니다.

mihomo 설정 예시

아래에는 proxy-groups 항목만 표시합니다. 현재 설정의 proxies에 이름이 정확히 일치하는 JP-A와 SG-A 노드가 있다고 가정합니다. 실제 노드 이름으로 바꿔 기존 설정에 병합하세요. 하나의 YAML 파일에 최상위 proxy-groups 항목을 중복해서 추가하지 마세요.

proxy-groups:
  - name: Daily
    type: select
    proxies:
      - Auto
      - JP-A
      - SG-A

  - name: Auto
    type: url-test
    proxies:
      - JP-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• type: select: 노드를 직접 선택합니다. 평소에는 Auto를 선택하고, 장시간 다운로드나 로그인이 중요한 작업에는 노드 하나를 고정할 수 있습니다.
• interval: 300: 자동 탐색 주기는 300초이며 구독 업데이트 주기가 아닙니다.
• tolerance: 50: 전환 허용 오차를 밀리초 단위로 지정해 작은 지연 시간 차이로 인한 잦은 전환을 줄입니다. 속도 제한값이나 시간 초과 기준이 아닙니다.
• url: 안정적으로 접속할 수 있는 가벼운 HTTPS 테스트 주소를 선택하세요. 주소를 바꾼 뒤에는 이전 수치와 새 수치를 직접 비교하기 어렵습니다.

위 항목은 mihomo에서 흔히 사용하는 설정 기준입니다. 다른 코어에서는 해당 문서를 확인하세요. 대상 트래픽에 적용하려면 규칙에서 Daily를 참조해야 합니다. 정책 그룹만 만들면 트래픽 분기가 자동으로 바뀌지는 않습니다. 정책 그룹 항목 설명에서 구성을 확인하고 규칙 항목 설명에서 참조 관계를 점검하세요.

사용 목적에 맞게 마무리: 주력 노드와 예비 노드 유지하기

주력 노드 하나와 다른 회선의 예비 노드 하나만 유지하면 됩니다. 테스트 날짜, 사용 네트워크, 대상 작업, 배율, 결과를 기록하세요. 문제가 생기면 같은 작업으로 예비 회선을 테스트하세요. 모든 노드의 성능이 동시에 떨어진다면 후보를 더 늘리기보다 로컬 네트워크, 트래픽 유입 모드, DNS, 현재 설정을 먼저 확인하세요.

선택 순서는 이렇게 정리할 수 있습니다. 먼저 연결이 올바른 정책 그룹을 통과하는지 확인한 뒤 안정성을 비교하세요. 지역 조건이 있다면 서비스를 먼저 검증하고, 지역 제한이 없다면 지연 시간을 비교하세요. 대용량 작업은 배율을 계산하고, 마지막으로 호환되는 프로토콜끼리 비교하세요.