고급 설정 예상 읽기 시간 12분

Clash 전략 그룹 선택 가이드: url-test·fallback·load-balance

url-test, fallback, load-balance의 노드 선택 방식과 interval·tolerance 설정을 비교하고, 사용 사례별 mihomo 설정 예시를 소개합니다.

1. 먼저 구분하기: 최저 지연 시간, 우선순위, 연결 분산

세 전략 그룹 모두 여러 프록시 노드를 포함할 수 있지만, 해결하는 문제는 서로 다릅니다. url-test는 탐지 지연 시간을 기준으로 자동 선택하고, fallback은 목록 순서에 따라 사용 가능한 노드를 선택합니다. load-balance는 분배 알고리즘에 따라 여러 연결을 사용 가능한 노드에 나눠 전달합니다. 그룹을 선택하기 전에 필요한 기능이 자동 최적 노드 선택인지, 주·백업 전환인지, 연결 분산인지 먼저 확인하세요.

유형 주요 기준 적합한 용도 주의 사항
url-test 상태 확인으로 측정한 지연 시간 일반적인 웹 탐색, 지연 시간이 짧은 노드 자동 선택 탐지 응답이 빠르다고 다운로드 대역폭이 넓은 것은 아닙니다
fallback 노드 순서와 사용 가능 여부 주 회선 고정, 장애 시 백업 회선으로 전환 백업 노드가 더 빠르더라도 우선 선택하지 않습니다
load-balance 연결 분배 방식과 노드 사용 가능 여부 여러 노드에 서로 다른 대상 또는 연결 분산 단일 연결의 대역폭을 합산하지 않습니다

이 문서의 설정 예시는 mihomo 커널을 사용하는 클라이언트를 기준으로 합니다. 구버전 Clash 및 다른 포크에서는 확장 필드, 특히 부하 분산 알고리즘을 지원하지 않을 수 있습니다. 먼저 클라이언트의 ‘정보’ 또는 커널 정보에서 커널 이름을 확인한 뒤 설정을 저장하고 로드 결과를 점검하세요. 클라이언트 이름만으로 호환성을 판단하지 마세요.

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

url-test는 고정된 출구가 필요하지 않은 일반 트래픽에 적합합니다. 커널은 후보 노드별로 테스트 주소에 접속해 결과를 기록한 뒤, 사용 가능 여부와 지연 시간, 전환 허용치를 기준으로 아웃바운드를 선택합니다. 측정값은 특정 HTTP 요청의 응답 시간이며, ICMP ping이나 지속적인 다운로드 속도 측정이 아닙니다.

기본 설정: 300초 간격으로 탐지, 허용치 50ms

아래 설정을 기존 구성에 추가해 사용하세요. 예시에 나온 ‘홍콩 01’, ‘홍콩 02’, ‘일본 01’은 proxies에 이미 정의되어 있어야 하며, 실제 노드 이름과 정확히 일치해야 합니다. 구독 노드 풀을 사용하는 경우에는 뒤에서 설명하는 use 설정을 참고하세요.

proxy-groups:
  - name: 자동 저지연
    type: url-test
    proxies:
      - 홍콩 01
      - 홍콩 02
      - 일본 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false
  • interval: 300: 주기적인 탐지 간격은 300초, 즉 5분입니다. 300밀리초가 아닙니다.
  • tolerance: 50: 전환 허용치는 50밀리초입니다. 지연 시간이 조금 변할 때 노드가 자주 바뀌는 것을 방지합니다.
  • lazy: false: 지연 탐지를 끄면 사용하지 않는 그룹도 주기적으로 상태를 갱신합니다. 대신 탐지 요청이 늘어납니다.

예를 들어 현재 노드의 측정 지연 시간이 110ms이고 다른 노드는 95ms라면 차이는 15ms뿐입니다. 허용치를 50ms로 설정해도 이 정도 차이만으로 반드시 전환되는 것은 아닙니다. 후보 노드의 지연 시간이 45ms라면 개선 폭이 65ms이므로 전환 조건에 더 부합합니다. 이 수치는 매개변수 설명을 위한 예시이며 실제 회선 측정값이 아닙니다. 실제 결과는 탐지 시점, 현재 노드 상태, 커널 구현에 따라서도 달라집니다.

지연 시간은 가장 짧은데 동영상이 끊기는 이유는?

용량이 작은 탐지 요청만으로는 사용량이 많은 시간대의 처리량을 알 수 없습니다. 테스트 주소에는 빠르게 응답하는 노드라도 동영상 서비스에서 속도 제한을 받거나 대상 사이트까지의 경로가 혼잡할 수 있습니다. 이럴 때는 실제 서비스 이용 상태와 연결 로그를 함께 확인하세요. 대역폭을 높이려고 interval을 300에서 5로 낮춰 탐지 횟수만 늘리는 것은 해결책이 아닙니다.

저지연 노드가 두 지역 사이에서 반복해서 바뀌면 로그인한 사이트에 출구 IP 변경이 감지될 수 있습니다. tolerance를 적절히 높이거나 같은 지역의 노드를 별도 그룹으로 묶어 보세요. 출구를 장기간 고정해야 하는 서비스에는 수동 선택이나 명확한 주·백업 구성이 더 적합합니다.

3. fallback: 노드 순서로 주·백업 구성하기

fallback의 핵심은 순서입니다. 목록에서 사용 가능한 첫 번째 노드의 우선순위가 가장 높으며, 해당 노드를 사용할 수 없을 때 다음 후보를 시도합니다. 주 노드가 상태 확인에서 다시 사용 가능한 것으로 확인되면 이후에는 우선순위가 더 높은 노드로 돌아갈 수 있습니다. 따라서 백업으로 전환된 뒤 계속 그 노드에 머무르는 방식은 아닙니다.

proxy-groups:
  - name: 주·백업 회선
    type: fallback
    proxies:
      - 홍콩 01
      - 홍콩 02
      - 일본 01
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

이 예시에서는 ‘홍콩 01’의 지연 시간이 180ms이고 ‘홍콩 02’는 60ms여도, 첫 번째 노드를 사용할 수 있다고 판단하면 ‘홍콩 01’을 우선 사용합니다. 따라서 더 느리지만 안정적인 회선을 맨 앞에 두는 것은 정상적인 주·백업 설정이며, 속도 측정이 제대로 작동하지 않는다는 뜻이 아닙니다.

전환에 걸리는 시간이 항상 60초인 것은 아닙니다

interval: 60은 주기적인 탐지 간격만 지정하며, 장애 복구 시간을 보장하지 않습니다. 두 번의 탐지 사이에 장애가 발생하면 다음 확인까지 기다려야 할 수 있고, 확인 자체에도 시간이 걸립니다. 연결 실패로 추가 확인이 실행되는 조건과 관련 설정은 커널 버전 및 구성에 따라 다를 수 있습니다.

  • 서비스에서 우선 사용할 노드를 목록 맨 앞에 두고, 속도 측정 결과만 보고 순서를 바꾸지 마세요.
  • 주 노드와 백업 노드는 가능한 한 같은 장애 지점을 공유하지 않도록 구성하세요. 동일한 상위 회선 장애로 모든 후보가 동시에 중단될 수 있습니다.
  • 주 노드에 장애가 발생하면 기존 TCP 연결이 끊길 수 있어 애플리케이션이 다시 연결해야 합니다. 전략 그룹은 기존 연결을 다른 노드로 옮기지 않습니다.

4. load-balance: 여러 연결을 분산하며 단일 연결 속도는 합산하지 않음

load-balance는 사용 가능한 후보 중 노드를 선택하지만, 하나의 TCP 연결을 여러 프록시 노드로 나누지는 않습니다. 단일 스레드 다운로드는 대개 하나의 출구를 사용합니다. 여러 연결을 사용하는 다운로드는 서로 다른 노드를 사용할 수 있지만, 다운로드 도구와 서버, 연결 재사용 방식, 분배 알고리즘의 영향을 받으므로 전체 속도가 몇 배로 늘어난다고 보장할 수 없습니다.

consistent-hashing: 같은 대상은 가능한 한 같은 출구로 연결

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

consistent-hashing은 대상 주소를 기준으로 일관성 해시 방식으로 연결을 분배해 같은 대상이 가능한 한 같은 노드에 연결되도록 합니다. 사용 가능한 노드 구성이 바뀌면 매핑도 달라질 수 있습니다. 서로 다른 대상에 대한 접속을 분산하는 데 적합하지만, ‘브라우저 전체가 항상 하나의 출구를 사용한다’는 뜻은 아닙니다. 한 페이지에서도 로그인, 이미지, API 등에 여러 도메인을 사용할 수 있습니다.

round-robin: 새 연결을 순서대로 분배

위 예시의 strategy를 round-robin으로 바꾸면 연결이 순차적으로 분배됩니다. 라운드 로빈은 전송 바이트를 균등하게 나누는 방식이 아니며, 남은 트래픽 할당량을 기준으로 자동 분배하지도 않습니다. 장시간 이어지는 다운로드 연결과 금방 끝나는 웹페이지 연결은 데이터 사용량에 큰 차이가 날 수 있습니다.

로그인, 결제 또는 출구 변경에 민감한 서비스에는 고정 노드나 별도의 안정적인 전략 그룹을 우선 사용하세요. 기존 HTTP/2 장기 연결에서 여러 요청을 처리할 수 있으므로 웹페이지를 연속해서 몇 번 새로고침하는 것만으로 라운드 로빈이 적용되지 않는다고 판단할 수 없습니다. 연결 패널에서 새로 생성된 연결이 실제로 어떤 노드를 사용하는지 확인하세요.

5. interval·tolerance와 노드 풀: 설정 범위

필드 의미 설정 권장 사항
url 상태 확인용 HTTP 테스트 주소 응답이 안정적이고 본문이 작은 대상을 선택하세요. 그룹 간 비교 시 같은 주소를 사용하세요.
interval 탐지 간격(초) 일반적인 용도라면 300초부터 시작하고, 주·백업 전환이 중요하면 비용을 고려해 간격을 줄이세요.
tolerance url-test의 전환 허용치(밀리초) 50ms부터 시작할 수 있습니다. 주·백업 우선순위를 정하는 값은 아닙니다.
lazy 그룹을 사용하지 않을 때 주기적인 탐지를 건너뛸지 여부 백업 그룹 상태를 계속 갱신하려면 명시적으로 false로 설정하세요.
strategy load-balance의 연결 분배 알고리즘 일관성 해시 또는 라운드 로빈을 명확히 선택하고, 탐지 허용치와 혼동하지 마세요.

proxies와 use를 혼동하지 마세요

proxies는 노드나 다른 전략 그룹의 이름을 참조하고, use는 proxy-providers에 정의된 노드 제공자를 참조합니다. 기존 구성에 ‘구독 노드 풀’이라는 제공자가 정의되어 있다고 가정하면, 다음과 같이 자동 그룹에서 사용할 수 있습니다.

proxy-groups:
  - name: 구독 자동 선택
    type: url-test
    use:
      - 구독 노드 풀
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

이 설정은 단독으로 실행할 수 있는 완전한 구성이 아닙니다. ‘구독 노드 풀’이 실제로 정의되어 있어야 합니다. 제공자의 interval은 노드 목록 업데이트 간격을, 제공자 내 health-check.interval은 해당 제공자의 상태 확인 간격을 제어합니다. 그룹 안의 interval은 전략 그룹의 탐지 주기를 설정합니다. 이름이 같아도 서로 다른 계층의 필드이므로 대체해서 사용할 수 없습니다.

노드 수에 따라 비용도 달라집니다. 후보가 30개인 그룹에서 300초마다 모든 후보를 한 차례 탐지하면 시간당 탐지 요청은 약 360회입니다. 실제 횟수는 지연 탐지와 추가 확인 등의 영향을 받습니다. 간격을 30초로 줄이면 요청량은 크게 늘지만 일상적인 사용 경험이 나아진다는 보장은 없습니다.

6. 규칙과 클라이언트에 연결하기: 그룹부터 확인한 뒤 트래픽 점검

전략 그룹을 만든 뒤에는 규칙에서 참조하거나 상위 그룹에서 수동 선택하도록 설정해야 합니다. 아래 구성은 세 가지 동작을 비교하기 위한 예시입니다. 합칠 때는 각 그룹을 하나의 proxy-groups 목록에 추가하세요. YAML 최상위에 같은 키를 여러 번 선언하면 안 됩니다.

proxy-groups:
  - name: 프록시 출구
    type: select
    proxies:
      - 자동 저지연
      - 주·백업 회선
      - 다중 회선 분산
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,프록시 출구
  - MATCH,프록시 출구

이 설정은 앞에서 설명한 세 자동 그룹이 이미 정의되어 있어야 사용할 수 있습니다. 그룹 참조 방식만 보여 주는 예시이며, 중국 본토와 해외 트래픽을 나누는 규칙 구성이 아닙니다. 마지막의 MATCH는 앞선 규칙과 일치하지 않는 요청을 ‘프록시 출구’로 보냅니다. 기존 규칙은 실제 용도에 맞게 유지하고, 테스트를 위해 기존 직접 연결 규칙을 모두 덮어쓰지 마세요.

  1. 설정을 백업하세요. 먼저 현재 구성을 내보내세요. 원격 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다. 변경 내용을 유지하려면 클라이언트에서 지원하는 오버라이드, 병합 또는 확장 설정 기능을 사용하세요.
  2. 설정을 불러오세요. 로그에 알 수 없는 그룹명이나 노드명, YAML 들여쓰기 오류가 표시되는지 확인하세요. 들여쓰기에는 공백을 사용하고 탭은 사용하지 마세요.
  3. 규칙 모드로 전환하세요. 클라이언트가 현재 ‘규칙’ 모드인지 확인하세요. ‘전역’ 모드에서는 규칙 목록으로 트래픽 분기 경로를 검증할 수 없습니다.
  4. 진입 그룹을 선택하세요. ‘프록시’ 페이지에서 ‘프록시 출구’를 찾아 세 자동 그룹을 각각 선택한 뒤 클라이언트의 ‘속도 측정’ 또는 ‘지연 시간 테스트’를 실행하세요. 버튼 이름은 클라이언트마다 다를 수 있습니다.
  5. 연결을 확인하세요. ‘연결’ 페이지에서 요청에 적용된 규칙과 전략 그룹 경로, 최종 노드를 확인하세요. 수동 속도 측정은 즉시 실행하는 테스트이며, 주기적인 상태 확인을 충분히 관찰하는 것과는 다릅니다.

주·백업 전환을 검증하려면 설정을 백업한 뒤 테스트용 구성에서 우선 노드를 일시적으로 제거하고, 다시 불러온 다음 다음 후보가 선택되는지 확인하세요. 출구 전환을 점검할 때는 새 서비스 연결을 만들어 브라우저 연결 풀이 기존 연결을 재사용하지 않게 하세요. TUN 모드 트래픽 처리 문제는 문제 해결 가이드를 참고하고, 먼저 트래픽이 실제로 커널에 전달되는지 확인하세요.

7. 사용 사례에 맞춰 기본 전략 선택하기

  • 일반 웹 탐색 및 앱: url-test를 선택하고, 300초 간격과 50ms 허용치를 조정 시작점으로 삼은 뒤 실제 변동에 맞춰 조정하세요.
  • 우선 회선을 고정해야 하는 경우: fallback을 선택하고 후보 순서를 신중히 정하세요. 백업 회선의 지연 시간이 더 짧아도 우선순위는 바뀌지 않습니다.
  • 여러 회선으로 서로 다른 접속을 처리하는 경우: load-balance를 선택하고 먼저 consistent-hashing을 고려하세요. 라운드 로빈이 필요한 경우에만 round-robin을 사용하세요.
  • 계정에 고정 출구가 필요한 경우: 수동 선택 그룹과 도메인 규칙을 별도로 설정하고, 이런 요청을 자주 바뀌는 자동 그룹에 섞지 마세요.

최종 확인 기준은 ‘실제 요청에 어떤 규칙이 적용됐고, 마지막에 어떤 노드를 사용했는가’입니다. 지연 시간 수치나 그룹 이름의 ‘자동’ 표시, 시스템 프록시 스위치만으로는 이를 확인할 수 없습니다. 후보를 적게 두고 먼저 동작을 검증한 뒤 노드 풀을 늘리면, 탐지 간격과 DNS, TUN 설정을 한꺼번에 바꾸는 것보다 문제를 찾기 쉽습니다.

Clash 다운로드