Clash 프록시 그룹 url-test·fallback·load-balance 선택법: 세 가지 자동 전략의 전환 방식

세 가지 자동 전략: 먼저 선택 기준부터 확인

Clash 자동 프록시 그룹은 “새 연결을 어느 노드로 보낼지” 결정합니다. 웹사이트별 트래픽 규칙을 자동으로 바꾸는 기능은 아닙니다. 규칙이 연결을 프록시 그룹으로 보내면 그룹이 자체 로직에 따라 노드를 선택합니다. 규칙 모드에서 특정 도메인이 이미 DIRECT에 일치한다면, 자동 그룹의 측정 주기를 조정해도 해당 도메인의 출구는 바뀌지 않습니다.

세 전략 모두 상태 확인을 사용할 수 있지만, 확인 결과를 활용하는 방식은 서로 다릅니다. url-test는 지연 시간을 비교하고, fallback은 순서대로 나열된 노드의 사용 가능 여부를 판단하며, load-balance는 사용 가능한 구성원 사이에 연결을 분산합니다. 아래 내용은 mihomo 커널의 설정 의미를 기준으로 합니다. 구버전 Clash 커널이나 클라이언트에 따라 일부 필드만 지원될 수 있으므로 앱 이름만 보지 말고 실제 실행 중인 커널을 확인하세요.

전략 유형	선택 기준	적합한 용도	주요 고려 사항
`url-test`	지연 시간 측정 및 전환 허용치	일반적인 웹 탐색에서 응답이 빠른 회선을 자동으로 선택	측정 대상이 모든 웹사이트의 실제 사용 경험을 대변하지는 않음
`fallback`	설정 순서에서 처음으로 사용 가능한 구성원	주 회선을 유지하다 장애 발생 시 예비 회선 사용	주 회선 복구 후 자동으로 다시 전환될 수 있음
`load-balance`	해시 또는 라운드 로빈 방식으로 분배	여러 개의 독립 연결을 여러 회선에 분산	출구가 하나로 통일되지 않으며 단일 연결의 대역폭도 합산되지 않음

url-test: 지연 시간에 따라 선택하고 tolerance로 잦은 전환 방지

url-test는 후보 노드로 지정된 테스트 URL에 접속한 뒤 측정 결과에 따라 노드를 선택합니다. 여기서 말하는 지연 시간은 ICMP Ping이나 다운로드 속도가 아닙니다. 프록시 경로를 통해 테스트 주소에 접속하는 데 걸리는 시간이며, 노드 연결 상태와 대상 사이트의 응답, 네트워크 상태 등에 영향을 받습니다.

일반적인 웹 탐색을 위한 기본 설정

아래 코드는 설정 최상위의 proxy-groups 아래에 넣습니다. 예시에서는 香港-A, 香港-B, 日本-A가 이미 proxies에 노드로 등록되어 있다고 가정합니다. 실제로 사용할 때는 구성원 이름이 기존 노드 이름과 정확히 일치해야 합니다. 서버 인증 정보가 포함된 전체 구독 설정이 아니라 프록시 그룹 예시입니다.

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

interval: 300: 상태 확인 주기는 300초, 즉 5분입니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용치는 50밀리초입니다. 지연 시간 차이가 아주 작을 때 노드가 자주 바뀌는 현상을 방지합니다.
lazy: true: 지연 검사를 활성화합니다. 사용하지 않는 그룹은 활성 그룹과 같은 주기로 계속 검사하지 않습니다. 주기를 설정했다고 해서 백그라운드에서 검사가 영구적으로 계속되는 것은 아닙니다.
url: 모든 후보 노드에서 정상적으로 접속할 수 있는 가벼운 주소를 선택합니다. 예시 주소는 일반적으로 HTTP 204를 반환합니다.

수치로 이해하는 전환 허용치

현재 노드 A의 측정값이 110밀리초이고 노드 B는 90밀리초라고 가정해 보겠습니다. 차이는 20밀리초뿐입니다. 허용치를 50밀리초로 설정했다면 이 정도 차이만으로 그룹이 즉시 B로 바뀌리라 기대해서는 안 됩니다. A가 180밀리초로 늘고 B는 90밀리초를 유지하면 차이가 90밀리초가 되므로 더 빠른 노드로 전환될 조건을 갖춥니다. 실제 전환 시점은 검사 및 선택이 이루어지는 시기에 따라 달라집니다. 이 수치는 작동 방식을 설명하기 위한 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다.

허용치는 추가 대기 시간도, 노드 장애를 판정하는 타임아웃 값도 아닙니다. 0으로 설정하면 미세한 지연 시간 변화에도 민감해지지만 웹페이지가 더 빨라진다는 보장은 없습니다. 일반적인 사용은 50밀리초부터 시작하고, 전환이 잦은지 살펴본 뒤 100밀리초로 조정할지 결정하세요.

fallback: 주 회선을 우선 사용하고 장애 시 예비 회선으로 전환

fallback은 목록에서 사용 가능한 첫 번째 구성원을 선택합니다. 첫 번째 항목이 상태 확인에서 사용 가능하다고 판단되는 한, 두 번째 항목의 지연 시간이 더 짧아도 첫 번째 항목을 대신하지 않습니다. “지정한 출구를 우선 사용하고 사용할 수 없을 때만 회선을 바꾸는” 용도에 적합하며, “항상 가장 빠른 노드를 찾는” 전략은 아닙니다.

proxy-groups:
  - name: 주·예비 회선
    type: fallback
    proxies:
      - 홍콩-A
      - 일본-A
      - 홍콩-B
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

장애 발생 및 복구 시 선택 과정

세 구성원 모두 사용할 수 있으면 선택 목록의 첫 번째 항목인 香港-A를 선택합니다.
香港-A 검사에 실패하고 日本-A를 사용할 수 있으면 이후 연결은 日本-A를 사용합니다.
이후 검사에서 香港-A가 복구된 것으로 확인되면 우선순위가 다시 적용되어 새 연결이 香港-A로 돌아갈 수 있습니다.

따라서 fallback은 “예비 회선으로 전환한 뒤 계속 그 회선에 머무는” 고정형 주·예비 방식이 아닙니다. 주 회선의 사용 가능 상태가 반복해서 바뀌면 다시 전환될 수 있습니다. 특정 회선을 고정해 업무에 사용하려면 수동 select 그룹이 더 직관적입니다.

검사 간격을 120초로 설정해도 장애가 반드시 120초 안에 복구되는 것은 아닙니다. 실제 소요 시간은 장애가 발생한 지점, 검사 타임아웃, 지연 검사, 앱의 재시도 등에 따라 달라집니다. 주 회선이 심하게 혼잡하더라도 테스트 주소에 접속할 수 있으면 fallback은 계속 해당 회선을 사용할 수 있습니다. “느림”과 “사용 불가”는 서로 다른 상태이기 때문입니다.

load-balance: 연결을 분산할 뿐 단일 연결의 대역폭을 합치지는 않음

load-balance는 사용 가능한 노드 사이에 연결을 분산합니다. 여러 작업을 병렬로 실행할 때 유용하지만, 일반적인 TCP 다운로드 연결 하나를 세 회선으로 나누지는 않습니다. 노드 세 개가 각각 10MB/s를 제공하더라도 이 전략을 켰다는 이유만으로 단일 연결 다운로드 속도가 30MB/s가 되지는 않습니다.

consistent-hashing과 round-robin 비교

consistent-hashing: 대상과 관련된 정보를 바탕으로 일관성 해시를 적용해 같은 대상이 같은 구성원을 사용하도록 합니다. 같은 대상의 출구가 바뀌는 일을 줄이고 싶을 때 적합하지만, 사용 가능한 노드 집합이 바뀌면 매핑도 달라질 수 있습니다.
round-robin: 사용 가능한 구성원을 차례로 선택해 새 연결 여러 개를 분산하기 쉽습니다. 실시간 대역폭이나 CPU 부하, 남은 트래픽을 기준으로 스케줄링하는 방식은 아닙니다.

proxy-groups:
  - name: 다중 회선 분산
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 홍콩-A
      - 홍콩-B
      - 일본-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

라운드 로빈을 사용하려면 현재 커널이 해당 전략 필드를 지원하는지 확인한 뒤 위 예시의 strategy를 round-robin으로 바꾸면 됩니다. 여기서 분산 단위는 연결입니다. 웹페이지에서 클릭할 때마다 분산되는 것도, HTTP/2 연결 안의 요청마다 분산되는 것도 아닙니다. 브라우저가 장기 연결을 재사용하면 페이지에서 요청을 많이 보내더라도 소수의 노드만 사용될 수 있습니다.

interval, 테스트 주소, 노드 제공자의 역할 구분

자동 전략의 상태 확인 트래픽은 후보 노드를 통과합니다. 노드 30개의 간격을 30초로 설정하고, 그룹이 계속 활성 상태이며 매번 전체 검사를 한다고 단순화하면 시간당 약 30 × 120 = 3600회의 검사가 발생합니다. 300초로 바꾸면 약 360회입니다. 실제 횟수는 지연 검사와 제공자 및 커널의 스케줄링 방식에 따라 달라집니다. 주기를 줄이면 비용이 따르므로 짧게 설정할수록 좋은 것은 아닙니다.

설정 항목	단위 또는 기능	권장 시작값
그룹의 `interval`	상태 확인 주기(초)	일반 사용은 300초, 주·예비 구성은 120초부터 확인
`tolerance`	url-test 전환 허용치(밀리초)	50밀리초. 범용 타임아웃 설정이 아님
`lazy`	지연 검사 사용 여부	일반적으로 `true`부터 시작
`strategy`	load-balance 분배 알고리즘	먼저 `consistent-hashing` 사용

구독 업데이트와 상태 확인 구분하기

proxy-providers를 사용하는 경우, 제공자 바깥쪽의 interval은 일반적으로 원격 노드 목록의 업데이트 주기를 제어합니다. health-check.interval은 노드 상태 확인 주기를 제어합니다. 이는 프록시 그룹에 있는 같은 이름의 필드와는 별개입니다. 구독 업데이트 주기를 60초로 바꿔도 매분 속도 측정이 자동으로 이루어지는 것은 아닙니다.

use로 제공자를 불러온다면 제공자의 상태 확인 설정을 살펴보세요. 프록시 그룹에 테스트 URL을 지정했다고 해서 제공자에 속한 모든 노드가 예상대로 검사되는 것은 아닙니다. 여러 위치에서 무분별하게 고빈도 검사를 설정하지 마세요. 먼저 노드를 몇 개 직접 나열해 전략을 확인한 다음 제공자를 연결하고, 제공자의 업데이트 로그와 상태를 별도로 점검하는 것이 좋습니다.

테스트 주소에 접속할 수 있고 측정 결과를 비교할 수 있어야 합니다

일부 노드가 연결된 네트워크에서 테스트 주소를 차단하면 다른 사이트에는 정상적으로 접속할 수 있는 노드도 사용할 수 없는 것으로 판단될 수 있습니다. 반대로 테스트 주소에 접속할 수 있다고 해서 모든 서비스가 정상이라는 뜻도 아닙니다. 그룹 전체에서 타임아웃이 발생하면 먼저 정상 노드 하나로 같은 주소에 접속해 테스트 사이트 장애, DNS 오류, TLS 핸드셰이크 실패 여부를 확인한 뒤 노드 문제인지 판단하세요.

설정 적용 및 확인: 새 연결이 실제로 대상 그룹에 들어가는지 확인

세 자동 그룹을 모두 동시에 활성화할 필요는 없습니다. 한 설정 파일에서 비교하려면 앞의 세 그룹 정의를 동일한 proxy-groups 목록에 넣고 수동 진입 그룹을 하나 더 추가하면 됩니다. YAML 최상위에 같은 이름의 proxy-groups 키를 여러 번 작성하지 마세요. 기존 내용이 덮어쓰이거나 구문 분석 오류가 발생할 수 있습니다.

  - name: 프록시 진입점
    type: select
    proxies:
      - 일상 자동
      - 주·예비 회선
      - 다중 회선 분산
      - 홍콩-A

위 예시는 같은 목록에 추가하고 다른 그룹과 들여쓰기를 맞춰야 합니다. 기존 규칙에서 프록시가 필요한 대상은 프록시 진입점을 가리키도록 설정합니다. 예를 들어 example.com과 그 하위 도메인을 프록시로 보내려면 아래 규칙을 범위가 더 넓은 관련 규칙보다 앞에 배치하면 됩니다. 이 규칙은 대상 규칙의 예시일 뿐, 기존 모든 트래픽을 프록시로 바꿔야 한다는 뜻은 아닙니다.

rules:
  - DOMAIN-SUFFIX,example.com,프록시 진입점
  - MATCH,DIRECT

이 규칙은 일치 관계를 설명하기 위한 예시입니다. 마지막 줄은 나머지 트래픽을 직접 연결하므로 기존 구독의 전체 분기 규칙을 이대로 덮어쓰면 안 됩니다. 규칙은 위에서 아래 순서로 일치하며, 앞에 있는 기존 규칙이 테스트 트래픽을 먼저 처리할 수도 있습니다.

설정을 저장하고 확인합니다. 커널에 알 수 없는 전략, 중복 그룹 이름, 존재하지 않는 노드에 대한 오류가 없는지 확인하세요. 구독 관리자가 업데이트되면 직접 수정한 내용이 덮어써질 수 있으므로 장기적으로 유지할 변경 사항은 클라이언트의 재정의 또는 설정 병합 기능을 사용하세요.
기존 트래픽 처리 방식을 유지합니다. 먼저 이미 작동 중인 시스템 프록시 또는 TUN 설정을 그대로 사용하고 DNS, 포트, 전략을 동시에 바꾸지 마세요. 세 전략을 사용하기 위해 TUN을 반드시 켤 필요는 없습니다.
진입 그룹에서 대상 그룹을 선택합니다. 일상 자동부터 시작해 검사를 한 번 실행하고 후보 노드의 지연 시간과 현재 선택을 기록하세요. 그런 다음 주·예비 그룹으로 전환해 선택 순서를 비교합니다.
새 연결을 만들어 동작을 확인합니다. 연결 패널에서 일치한 규칙, 전략 경로, 최종 노드를 확인하세요. 기존 웹페이지는 연결을 재사용할 수 있으므로 필요하다면 해당 페이지와 연결을 닫고 다시 접속하세요.
통제된 환경에서 장애를 확인합니다. 로컬 테스트 설정에서 주 노드를 일시적으로 제거하거나 사용 불가가 확인된 구성원을 넣고, 이후의 검사와 새 연결을 관찰하세요. 고빈도 검사나 업무 네트워크 중단으로 확인하지 마세요.

자주 나타나는 현상과 점검 방법

url-test가 두 노드 사이에서 계속 전환됨: 지연 시간 차이가 허용치에 가까운지, 테스트 주소가 불안정한지, 검사 주기가 너무 짧은지 확인하세요. 먼저 설정 하나만 조정하고 일정 시간 지켜보세요.
fallback이 지연 시간이 가장 짧은 노드를 선택하지 않음: 우선순위에 따라 선택하므로 정상입니다. 지연 시간을 우선하려면 interval을 더 줄이는 대신 url-test를 사용하세요.
load-balance가 한 노드만 사용하는 것처럼 보임: 일관성 해시를 사용 중인지, 항상 같은 대상에 접속하는지, 앱이 장기 연결 하나만 맺는지 먼저 확인하세요.
그룹을 바꿔도 출구 IP가 바뀌지 않음: 확인용 웹사이트가 대상 그룹에 연결되었는지 확인하고 새 연결을 만드세요. 여러 노드가 같은 공인 IP 출구를 공유할 가능성도 고려해야 합니다.
모든 노드가 타임아웃으로 표시됨: 같은 테스트 URL, 노드 상태, 시스템 시간, 로그를 먼저 확인하세요. 클라이언트 패널에서 수동으로 한 번 측정한 결과는 자동 그룹에서 사용하는 테스트 주소 및 매개변수와 다를 수 있습니다.

선택 가이드: 지연 시간, 주·예비, 회선 분산별 설정

일반적인 웹 탐색은 url-test + interval 300 + tolerance 50부터 시작하세요. 지정한 지역이나 회선을 우선 사용하려면 순서대로 배치한 fallback을 사용하면 됩니다. 서로 독립된 여러 작업의 연결을 분산해야 할 때는 load-balance를 고려하고, 먼저 일관성 해시를 사용해 서비스와의 호환성을 확인하세요.

자동 전략은 노드를 선택하고, 규칙은 대상을 지정하며, 시스템 프록시와 TUN은 트래픽을 처리합니다. 이 세 계층을 나누어 확인하면 커널, DNS, 자동 그룹을 동시에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 필드 지원 여부와 트래픽 처리 범위는 사이트의 기술 참고 자료에서 확인할 수 있습니다. 가져오기 및 기본 연결부터 설정하려면 사용 가이드에 따라 항목별로 점검하세요.