Clash 전략 그룹 종류 비교: url-test·fallback·load-balance 설정과 선택법

규칙과 노드 사이에서 전략 그룹이 하는 일

전략 그룹(Proxy Group)은 규칙이 지정한 정책을 실제로 사용할 노드로 연결합니다. 예를 들어 규칙이 특정 도메인을 ‘일상 프록시’ 그룹으로 보내면, 해당 그룹은 수동 선택이나 지연 시간 테스트, 장애 전환 방식에 따라 출구 노드를 정합니다. 규칙은 ‘이번 연결을 어디로 보낼지’를, 전략 그룹은 ‘그룹에 들어온 연결에 어떤 노드를 사용할지’를 결정합니다.

이 글에서는 Clash Verge Rev에서 사용하는 mihomo 코어 설정을 예로 듭니다. 화면에서는 상태를 확인하고 항목을 전환할 수 있지만, 그룹의 동작 방식은 proxy-groups 안의 type 값으로 결정됩니다. 시스템 프록시와 TUN 모드는 트래픽이 코어로 들어오는 방식을 바꿀 뿐, select를 자동 측정 그룹으로 바꾸거나 로드 밸런싱 알고리즘을 변경하지 않습니다.

유형	선택 기준	주요 용도	주요 제한 사항
`select`	사용자가 구성원을 직접 지정	특정 지역 노드, 수동 출구 선택	다른 구성원으로 자동 전환하지 않음
`url-test`	지연 시간 측정 및 전환 허용 폭	비슷한 회선 중 지연 시간이 짧은 노드를 자동 선택	측정 지연이 짧다고 다운로드 속도가 빠른 것은 아님
`fallback`	구성원 순서 및 사용 가능 여부	주 회선 장애 시 백업 회선 사용	지연 시간이 가장 짧은 노드를 고르는 방식이 아님
`load-balance`	지정된 연결 분배 알고리즘	여러 연결을 여러 출구로 분산	단일 연결의 대역폭을 합산하지 않음

select: 수동 진입점과 고정 출구

select는 출구를 직접 지정해야 하는 경우에 적합합니다. Clash Verge Rev의 ‘프록시’ 페이지에서 해당 전략 그룹을 펼친 뒤 노드나 하위 그룹을 선택하면 됩니다. 선택한 노드에 문제가 생겨도 다른 구성원이 사용 가능하다는 이유만으로 수동 그룹이 자동 전환되지는 않습니다. 다만 선택한 구성원 자체가 자동 전략 그룹이라면 해당 하위 그룹은 자체 선택 로직에 따라 노드를 자동으로 고릅니다.

수동 진입점 안에 자동 전략 그룹 배치하기

흔히 최상위 그룹은 select로 구성하고, 그 안에 ‘저지연 자동 선택’, ‘주·백업 회선’, 개별 노드를 함께 넣습니다. 평소에는 자동 그룹을 선택하고, 지역 제한이 있거나 출구를 고정해야 할 때는 원하는 노드를 직접 고르면 됩니다. 규칙은 계속 같은 진입점을 참조하므로 임시로 회선을 바꿀 때마다 규칙 전체를 수정할 필요가 없습니다.

계정 로그인, 결제, 관리자 페이지: 지역이 안정적이고 출구가 명확한 노드를 우선 선택합니다.
일반 웹 탐색: 자동 측정 하위 그룹을 선택하면 수동 전환을 줄일 수 있습니다.
문제 해결: 자동 전환이 점검을 방해하지 않도록 노드를 하나로 고정합니다.

‘노드 고정’이 ‘공인 IP 고정’을 뜻하지는 않습니다. 서버 측에서 출구를 바꾸거나 여러 출구를 운영할 수 있습니다. 고정 IP가 필요한 업무라면 서비스 제공 업체에 회선 특성을 확인해야 하며, 클라이언트의 전략 그룹만으로는 보장할 수 없습니다.

url-test: 측정 지연으로 노드를 선택하고 tolerance로 전환 폭 조절

url-test는 후보 노드를 통해 지정한 테스트 URL에 접속하고 측정 결과와 현재 노드 상태, 허용 편차를 바탕으로 노드를 선택합니다. 지역과 용도가 비슷한 회선에 적합합니다. 여러 지역의 노드를 한 그룹에 섞으면 지연 시간이 짧은 지역이 계속 선택될 수 있지만, 접속하려는 사이트에서 요구하는 지역과 맞지 않을 수 있습니다.

interval, timeout, tolerance의 단위

interval: 300: 단위는 초이며, 상태 확인 주기를 설정합니다. 300초는 5분입니다.
timeout: 5000: 단위는 밀리초이며, 한 번의 측정에 허용되는 시간은 5초입니다.
tolerance: 50: 단위는 밀리초이며, 지연 시간이 조금 변할 때 불필요하게 전환되는 것을 줄입니다.
lazy: true: 지연 검사를 활성화합니다. 그룹을 사용하지 않을 때는 주기적으로 계속 측정하지 않을 수 있으므로, ‘모든 후보를 300초마다 반드시 측정한다’는 뜻은 아닙니다.

예시 수치로 살펴보겠습니다. 현재 노드의 지연 시간은 105ms, 다른 노드는 80ms로 차이가 25ms입니다. tolerance: 50이면 이 정도의 작은 차이로는 보통 회선을 전환하지 않습니다. 현재 노드가 180ms로 느려지고 후보 노드가 80ms라면 차이가 허용 편차를 크게 넘습니다. 노드를 사용할 수 없게 되면 사용 가능 여부를 기준으로 다시 선택하며, tolerance가 장애가 난 노드를 계속 유지하라는 뜻은 아닙니다.

측정 결과만으로 실제 전송 속도를 판단할 수는 없습니다

테스트 URL에서 작은 응답을 받아 보는 것은 주로 연결 가능 여부와 요청 지연 시간을 확인하기 위한 것입니다. 지연 시간이 80ms인 노드가 120ms인 노드보다 대용량 파일 다운로드에 적합하다고 단정할 수는 없습니다. 대역폭, 혼잡도, 목적지까지의 경로, 서버 부하에 따라 결과가 달라집니다. 클라이언트에 표시되는 측정 지연을 ICMP ping 값과 동일하게 봐서도 안 됩니다. 측정 경로와 방식이 서로 다릅니다.

fallback: 목록 순서에 따라 주·백업 회선 전환

fallback은 구성원 목록의 앞에서부터 사용 가능한 노드를 찾습니다. 첫 번째 노드가 정상으로 확인되는 한 해당 노드를 우선 사용하며, 모든 노드의 지연 시간을 비교해 가장 짧은 노드를 고르지는 않습니다. 따라서 주 회선을 앞에 두고 백업 회선을 그 뒤에 순서대로 배치해야 합니다. 목록 순서는 업무상 우선순위이지, 단순한 메모 순서가 아닙니다.

예를 들어 노드 A의 지연 시간은 160ms, 노드 B는 70ms여도 A가 사용 가능하고 목록에서 B보다 앞에 있다면 주·백업 그룹은 A를 우선 사용합니다. A의 상태 확인에 실패한 경우에만 뒤에 있는 사용 가능한 구성원을 선택합니다. 이후 측정에서 A가 복구된 것으로 확인되면 새 연결은 다시 A를 우선 사용할 수 있습니다.

장애 전환은 기존 연결을 옮기는 기능이 아닙니다

이미 연결된 TCP 세션은 기존 경로에 묶여 있습니다. 전략 그룹이 백업 노드로 전환되어도 기존 연결을 끊김 없이 다른 출구로 옮길 수는 없습니다. 웹페이지는 새 요청을 보내 복구될 수 있지만, 다운로드나 원격 터미널, 회의 연결은 다시 연결해야 할 수 있습니다. 장애를 발견하는 데 걸리는 시간은 확인 주기와 단일 요청의 제한 시간, 지연 검사 설정, 장애 발생 시점에 따라 달라집니다. interval: 300을 정확히 300초 안에 복구된다는 보장으로 해석하면 안 됩니다.

주·백업 회선은 같은 서버의 이름만 다른 노드보다는 진입점이나 서버가 다른 회선처럼 장애 원인이 겹치지 않는 구성을 선택하는 것이 좋습니다.
주·백업 그룹은 ‘지정한 회선을 우선 사용’할 때 적합하며, ‘항상 지연 시간이 가장 짧은 회선을 사용’하는 용도에는 적합하지 않습니다.
백업 회선이 종량제라면 트래픽 통계를 확인해 실제 사용량을 점검하세요. 상태 확인 과정에서도 소량의 요청이 발생합니다.

load-balance: 여러 연결을 분배하며 단일 연결의 대역폭을 합치지는 않음

load-balance는 지정한 정책에 따라 연결을 후보 노드에 분배합니다. 하나의 TCP 연결을 나눠 두 노드로 각각 전송하지 않으며, 여러 회선을 묶는 기능도 아닙니다. 단일 연결로 진행하는 다운로드는 일반적으로 선택된 노드의 대역폭에 영향을 받습니다. 여러 연결을 사용하는 작업이라면 서로 다른 출구로 부하를 분산할 수 있습니다.

주요 strategy 차이

strategy	주요 동작	선택 시 참고 사항
`consistent-hashing`	대상 정보를 바탕으로 일관된 해시 매핑 적용	같은 대상은 같은 출구로 연결되는 경향이 있지만, 구성원이 바뀌면 매핑도 달라질 수 있음
`round-robin`	사용 가능한 구성원에 연결을 차례로 분배	같은 웹사이트의 여러 연결이 서로 다른 출구 IP를 사용할 수 있음
`sticky-sessions`	출발지와 목적지 주소 조합을 바탕으로 일정 시간 매핑 유지	mihomo의 세션 고정 전략이며 출구를 영구 고정하는 기능은 아님

목적지가 도메인인지 IP인지, DNS 모드에서 도메인 정보가 유지되는지에 따라 실제 분배 결과가 달라질 수 있습니다. 따라서 ‘브라우저 하나는 항상 한 노드만 사용한다’고 볼 수 없습니다. 계정 서비스는 로그인 도메인과 정적 리소스 도메인, API 도메인에 각각 접속할 수 있으므로, 일관된 해시를 사용해도 서로 다른 출구로 연결될 수 있습니다.

전체 구성 예시: 수동 진입점 하나와 자동 전략 세 가지

아래는 기존 mihomo 설정에 추가할 전략 그룹 및 규칙 예시이며, 노드 인증 정보까지 포함한 완전한 구독 설정은 아닙니다. HK-A, HK-B, SG-A는 현재 설정의 proxies에 이미 정의되어 있어야 하며, 이름도 정확히 일치해야 합니다. 노드가 proxy-providers에서 제공된다면 실제 provider 이름에 맞춰 use로 가져와야 합니다. provider 이름만 노드 이름인 것처럼 목록에 입력해서는 안 됩니다.

proxy-groups:
  - name: 일상 프록시
    type: select
    proxies:
      - 저지연 자동 선택
      - 주·백업 회선
      - 다중 연결 분배
      - HK-A
      - HK-B
      - SG-A

  - name: 저지연 자동 선택
    type: url-test
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

  - name: 주·백업 회선
    type: fallback
    proxies:
      - HK-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true

  - name: 다중 연결 분배
    type: load-balance
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,일상 프록시
  - MATCH,일상 프록시

설정을 병합할 때 확인할 세 가지

그룹 목록 병합: 새 그룹을 기존 proxy-groups에 추가하세요. 같은 계층에 같은 이름의 키를 다시 만들지 마세요. 그룹 이름은 서로 달라야 하며, 하위 그룹끼리 서로를 순환 참조해서는 안 됩니다.
기존 규칙 유지: 예시의 example.com은 도메인 매칭을 보여 주기 위한 것입니다. 기존 설정에 직접 연결, 차단, 지역별 규칙이 있다면 그대로 유지하고, 기본 규칙인 MATCH는 규칙 목록 맨 아래에 두세요. 규칙은 위에서부터 차례로 매칭되므로 기본 규칙을 업무별 규칙보다 앞에 배치하면 안 됩니다.
수정 대상 확인: Clash Verge Rev의 ‘프로필’ 페이지에서 현재 활성화된 설정을 확인하세요. 원격 구독을 새로 고치면 직접 수정한 내용이 덮어써질 수 있습니다. 장기간 유지할 수정 사항은 현재 클라이언트에서 지원하는 설정 병합 또는 스크립트 기능을 사용하고, 최종 적용된 설정을 확인하세요.

위의 세 자동 그룹은 모두 lazy: true를 사용하므로, 사용하지 않을 때 측정 횟수를 줄이는 데 적합합니다. 백그라운드에서 계속 확인해야 한다면 false로 변경하는 방안을 검토하되 노드 수와 확인 주기도 함께 고려하세요. 예를 들어 한 그룹에 노드가 20개 있고 확인 주기가 300초라면 한 차례에 20번 측정합니다. 여러 그룹에서 같은 노드를 반복 참조하면 실제 확인 부하는 코어의 스케줄링 및 provider 상태 확인과 함께 살펴봐야 합니다.

사용 목적에 맞는 그룹을 선택하고 실제 규칙 적용 결과 확인하기

자주 쓰는 구성 세 가지 비교

웹 탐색 및 일상 업무: 최상위 그룹은 select로 만들고, 기본값으로 같은 지역의 url-test를 선택합니다. 먼저 확인 주기 300초와 허용 편차 50ms로 동작을 살펴본 뒤, 지연 시간 변동에 따라 조정하세요.
주 회선 우선, 백업 회선으로 전환: fallback을 선택하고 계속 사용하려는 회선을 목록 맨 앞에 둡니다. 장애가 나면 다시 연결할 수 있도록 하고, 주 회선 복구 후 실제로 어떻게 전환되는지도 테스트하세요.
여러 출구를 사용해도 되는 연결이 많은 경우: load-balance를 검토하세요. 먼저 일관된 해시 방식을 시험하고, 라운드 로빈이 실제로 필요한지 확인합니다. 단일 다운로드 속도를 높이려고 로드 밸런싱으로 바꾸지는 마세요.

Clash Verge Rev에서 확인하는 순서

‘프로필’ 페이지를 열어 대상 설정이 활성화되어 있는지 확인합니다. 적용 중 오류가 발생하면 ‘로그’ 페이지에서 그룹 유형, 노드 이름, YAML 들여쓰기 오류를 먼저 살펴보세요. 설정을 불러오지 못한 상태로 계속 테스트하지 마세요.
‘프록시’ 페이지에서 ‘일상 프록시’ 그룹 안에 테스트할 하위 그룹을 선택합니다. 규칙 분기를 확인하려면 ‘규칙’ 모드로 테스트하세요. ‘전역’ 모드에서는 전역 정책 진입점을 사용하므로 업무별 규칙과 다른 결과가 나올 수 있습니다.
그룹 속도 측정을 한 번 실행하고 측정 시각과 현재 노드, 지연 시간을 기록합니다. 특정 노드에 표시된 녹색 수치만 보지 말고 최상위 진입점에서 실제로 어떤 그룹을 선택했는지 확인하세요.
프록시를 사용해야 하는 사이트에 접속한 뒤 ‘연결’ 페이지에서 도메인으로 필터링해 적용된 규칙과 프록시 체인을 확인합니다. 그룹이 선택되어 있다는 사실만으로 해당 요청이 그 그룹을 거쳤다고 볼 수는 없습니다.
기존 페이지 연결을 종료하거나 새 요청을 만든 뒤 결과를 비교합니다. 주·백업 전환을 테스트해야 한다면 복구할 수 있는 테스트 환경에서만 주 회선을 일시 중단하고, 장애가 감지된 시점과 백업 연결이 만들어진 시점을 기록하세요.

‘속도 측정은 정상인데 웹사이트가 열리지 않는’ 경우에는 측정 대상에 접속할 수 있는지와 실제 서비스에 접속할 수 있는지를 구분하세요. 서비스 도메인의 DNS 조회 결과, 적용된 규칙, 노드의 지역 제한, 로그 오류를 확인합니다. ‘전환했는데 출구가 바뀌지 않는’ 경우에는 기존 연결이 재사용되는지, 규칙이 직접 연결을 선택하지는 않았는지, 전역 진입점을 잘못 선택하지 않았는지, 두 노드가 애초에 같은 공인 출구를 공유하지는 않는지 먼저 확인하세요.

전략 그룹을 고를 때 중요한 것은 자동화 수준이 아니라 선택 기준이 요구 사항에 맞는지입니다. 직접 제어하려면 select, 지연 시간에 따라 경로를 고르려면 url-test, 순서대로 주·백업을 전환하려면 fallback, 여러 연결을 분산하려면 load-balance를 고려하세요. 규칙과 전략 그룹, 노드의 역할을 구분하면 문제를 단계별로 좁혀 갈 수 있습니다. 설정 항목은 프로토콜 안내서에서 확인하고, 관련 개념은 용어집을 참고하세요.