Clash 정책 그룹 비교: url-test·fallback·load-balance 설정 가이드

세 가지 정책 그룹의 선택 기준

Clash 자동 정책 그룹은 “이 연결이 어떤 노드를 통해 나갈지”를 정하는 기능이지, 모든 앱의 대역폭을 자동으로 높여 주는 기능은 아닙니다. url-test는 탐지 지연 시간을 비교하고, fallback은 노드 우선순위를 유지하며, load-balance는 여러 연결을 사용 가능한 노드에 분산합니다. 먼저 낮은 지연 시간, 고정된 주·백업 회선, 연결 분산 중 필요한 항목을 정한 뒤 설정을 조정하세요.

정책 로직은 코어에서 실행됩니다. 클라이언트는 구독 가져오기, 속도 측정 결과 표시, 사용자 선택 적용을 담당합니다. 버튼 이름이 비슷해도 클라이언트마다 사용하는 코어와 지원하는 필드가 다를 수 있습니다. 아래 YAML 예제는 mihomo, 즉 Clash Meta의 후속 코어를 기준으로 합니다. 다른 Clash 코어에서 같은 필드를 지원하는지는 해당 코어의 설정 문서와 로드 로그를 확인하세요.

정책 유형	선택 기준	주요 용도	유의 사항
`url-test`	상태 확인 지연 시간과 전환 허용치	웹 브라우징과 상호작용 요청에 적합한 저지연 경로	지연 시간이 짧다고 다운로드 대역폭이 높은 것은 아님
`fallback`	목록 앞쪽에 있는 사용 가능한 노드	고정 주 회선과 백업 회선	주 노드가 계속 사용 가능하면 백업 노드가 더 빨라도 전환하지 않음
`load-balance`	분배 방식과 노드 사용 가능 상태	여러 작업이나 대상에 대한 연결 분산	단일 연결을 여러 회선으로 나눠 대역폭을 합산하지 않음

url-test: 탐지 지연 시간에 따라 자동 선택

url-test는 지정한 테스트 URL에 각 후보 노드로 접속해 탐지 지연 시간을 기록하고, 사용 가능한 후보 중 출구를 선택합니다. 여기서 말하는 ‘속도 측정’은 요청 한 번의 지연 시간을 확인하는 것이며, 지속적인 다운로드 테스트가 아닙니다. 결과는 로컬 네트워크, 노드에서 대상 사이트까지의 경로, DNS, 연결 설정 시간, 서버 응답 등 여러 요인의 영향을 받습니다.

interval과 tolerance의 차이

interval: 300: 정기 상태 확인 간격은 300초, 즉 5분입니다. 연결 타임아웃 시간이 아닙니다.
tolerance: 50: 전환 허용치는 50밀리초입니다. 후보 노드가 약간 더 빠르다는 이유만으로 자주 바뀌는 현상을 줄이는 데 사용합니다.
timeout: 5000: 상태 확인 1회의 최대 대기 시간은 5000밀리초입니다. 이 시간을 넘긴 탐지는 실패로 처리될 수 있습니다.
lazy: false: 정책 그룹이 유휴 상태여도 정기 상태 확인을 중단하지 않아 연속 탐지 결과를 확인할 수 있습니다.

예를 들어 현재 노드의 측정값이 120밀리초이고 다른 노드가 95밀리초라면 차이는 25밀리초입니다. 허용치를 50밀리초로 설정했다면 이 정도 차이만으로 노드가 바뀌리라고 기대하기 어렵습니다. 다른 노드가 60밀리초로 내려가 차이가 60밀리초가 되면 허용치를 넘을 수 있습니다. 이 수치는 설정을 설명하기 위한 예시이며 실제 회선 측정값이 아닙니다. 최종 선택은 노드의 상태와 코어 구현에도 영향을 받습니다.

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

테스트 주소는 모든 후보 노드에서 접속할 수 있고, 응답 본문이 작으며 동작이 안정적이어야 합니다. 예시 URL은 연결 확인용일 뿐 모든 사이트의 접속 품질을 대변하지는 않습니다. 주로 사용하는 서비스가 있다면 해당 사이트의 실제 요청도 확인하세요. 로그인 페이지, CAPTCHA 페이지, 대용량 파일 주소를 정기 탐지 대상으로 사용하지 마세요.

예제 적용 범위: 이 문서의 YAML은 설정 일부만 보여 주는 예제입니다. 노드 이름은 기존 proxies 정의와 정확히 일치해야 합니다. 예제의 “홍콩-A”, “홍콩-B”, “일본-A”는 노드를 참조하는 이름일 뿐, 서버 주소나 인증 정보가 아닙니다. 기존 proxy-groups가 있다면 그룹 항목을 병합하고, 같은 최상위 키를 중복으로 만들지 마세요.

fallback: 목록 순서에 따라 주·백업 회선 유지

fallback은 최저 지연 시간을 목표로 하지 않습니다. 후보 목록에서 순서가 앞서고 상태 확인을 통과한 노드를 선택합니다. 평소에는 같은 출구를 유지하다가 주 회선에 문제가 생겼을 때만 백업 회선을 사용하는 구성에 적합합니다.

proxy-groups:
  - name: 주·백업 회선
    type: fallback
    proxies:
      - 홍콩-A
      - 일본-A
      - 홍콩-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false

장애 전환 및 복구 순서

“홍콩-A”가 상태 확인을 통과하면 “일본-A”의 탐지 지연 시간이 더 낮더라도 “홍콩-A”를 우선 사용합니다.
“홍콩-A”를 사용할 수 없는 것으로 판단하면 다음 사용 가능 노드인 “일본-A”를 선택합니다. 이 노드도 사용할 수 없으면 “홍콩-B”를 확인합니다.
이후 상태 확인에서 “홍콩-A”가 복구된 것으로 확인되면 다시 우선 선택될 수 있으며, 이후 연결은 주 회선으로 돌아갈 수 있습니다.

따라서 fallback은 우선순위에 따라 노드를 선택한다는 뜻이지, “백업으로 전환한 뒤 계속 백업만 사용한다”는 의미가 아닙니다. 사람이 확인한 뒤에만 주 회선으로 복귀해야 한다면 수동 select 그룹으로 출구를 관리하세요. 자동 주·백업 그룹만으로는 이 절차를 구현할 수 없습니다.

장애가 발생한 순간에 바로 감지되는 것도 아닙니다. 정기 확인만 고려하면 탐지 직후 회선이 끊긴 뒤 다음 확인 주기와 타임아웃 판정을 기다릴 수 있습니다. 그 밖의 실패 감지 방식은 코어 설정에 따라 다르므로 interval: 300을 즉시 전환을 보장하는 설정으로 해석하지 마세요.

백업 회선은 가능한 한 주 회선과 장애 원인을 공유하지 않아야 합니다. 이름만 다른 두 노드가 실제로 같은 상위 출구를 사용한다면 동시에 장애가 날 수 있습니다. 중요한 작업에서는 로컬 접속망, 노드 상태, 대상 서비스 상태를 각각 확인해 대상 사이트의 장애를 주 노드 문제로 오인하지 않도록 하세요.

load-balance: 대역폭 합산이 아닌 연결 분산

load-balance는 사용 가능한 노드에 연결을 분산합니다. 여러 웹 페이지, 다운로드 작업 또는 서로 다른 대상에 대한 요청을 각각 다른 출구로 보낼 수 있지만, 이미 설정된 TCP 연결은 선택된 노드를 계속 사용합니다. 브라우저에 표시되는 전체 다운로드 속도가 높아지는지는 작업의 동시성, 서버 제한, 각 노드의 대역폭 공유 여부에 따라 달라집니다.

proxy-groups:
  - name: 연결 분산
    type: load-balance
    proxies:
      - 홍콩-A
      - 홍콩-B
      - 일본-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: false
    strategy: consistent-hashing

consistent-hashing과 round-robin

strategy	분배 방식	적용 상황
`consistent-hashing`	대상과 관련된 정보를 이용해 일관성 해싱을 적용하므로 같은 대상은 같은 출구를 사용하는 경향이 있습니다.	같은 사이트에 접속할 때 노드가 바뀌는 현상을 줄이고 싶다면 우선 고려하세요.
`round-robin`	새 연결을 사용 가능한 후보에 순환 배분합니다.	출구가 바뀌어도 괜찮은 독립적인 병렬 작업에 적합합니다.

일관성 해싱이 영구적인 연결 고정을 뜻하지는 않습니다. 후보 노드 수나 상태가 바뀌면 매핑도 달라질 수 있으며, 도메인의 사용 가능 여부와 대상을 식별하는 방식도 분배에 영향을 줍니다. 한 페이지가 여러 도메인에 요청을 보낼 수도 있으므로 ‘같은 페이지’라고 해서 모든 요청이 같은 출구를 사용하는 것은 아닙니다.

mihomo는 출발지와 대상 관련 정보를 기준으로 일정 시간 분배를 유지하는 sticky-sessions 정책도 제공합니다. 사용하려면 현재 코어의 지원 여부와 동작을 확인하세요. 호환성을 확인하지 않은 확장 필드를 오래된 코어 설정에 그대로 복사하지 마세요.

로그인 및 장시간 세션의 출구 설정

은행, 결제, 기업 인증 서비스처럼 출구 IP에 민감한 서비스는 고정 노드나 수동 그룹으로 분리하는 편이 적합합니다. 로드 밸런싱을 사용하면 같은 계정의 연결마다 공인 IP가 달라져 재인증이 필요할 수 있습니다. 일관성 해싱을 사용하더라도 홈페이지 하나만 테스트하지 말고 관련 도메인 전체를 묶어 확인하세요.

정책 그룹과 규칙 연결 및 구독 설정 유지

그룹을 정의했다고 해서 트래픽이 자동으로 해당 그룹을 통과하는 것은 아닙니다. 규칙 모드에서는 연결이 rules를 위에서 아래 순서로 확인하고, 일치한 규칙이 노드나 정책 그룹을 지정합니다. 클라이언트의 시스템 프록시, TUN, 규칙 매칭은 서로 다른 단계입니다. 앞의 두 기능은 트래픽이 코어로 들어오는 방식을 정하고, 정책 그룹은 들어온 트래픽의 출구를 선택합니다.

세 가지 자동 그룹을 하나의 수동 진입점 아래에 두고 클라이언트에서 사용할 정책을 선택할 수 있습니다. 아래 예제는 세 자동 그룹이 이미 정의되어 있다고 가정합니다. 그룹 이름은 직접 정해도 되지만 참조 이름은 일치해야 하며 그룹 간 순환 참조가 생기지 않도록 하세요.

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - 자동 지연
      - 주·백업 회선
      - 연결 분산

rules:
  - DOMAIN-SUFFIX,example.com,주·백업 회선
  - MATCH,출구 선택

example.com은 규칙 구조를 설명하기 위해 예약된 예시 도메인입니다. 이 규칙은 특정 도메인을 주·백업 그룹에 고정하고, 나머지 연결은 “출구 선택”에서 처리한다는 뜻입니다. 기존 구독의 모든 규칙을 덮어쓰라는 의미는 아닙니다. MATCH는 기본 규칙이므로 우선 적용할 규칙 뒤에 배치해야 합니다.

구독 업데이트 후 설정 유지

구독에서 내려받은 YAML을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 먼저 클라이언트에서 설정 오버라이드나 병합을 지속적으로 지원하는지 확인하세요.
클라이언트 오버라이드 기능을 사용할 때 배열을 통째로 교체하는지, 항목을 추가하는지, 이름을 기준으로 병합하는지 확인하세요. 클라이언트마다 구현 방식이 다르므로 서로의 설정 방법을 그대로 적용하지 마세요.
proxy-providers를 사용하는 경우 정책 그룹은 대개 use로 프로바이더를 참조합니다. 프로바이더 자체의 상태 확인과 그룹의 후보 관리 설정을 함께 확인해야 합니다.
구독 제공 측에서 노드 이름을 변경하면 정적 proxies 참조가 끊길 수 있습니다. 업데이트 후 로드 로그와 그룹 내 후보 목록을 확인하세요.

공통 필드와 규칙 순서는 YAML 설명서의 정책 그룹 안내에서 확인할 수 있습니다. 트래픽 유입 방식을 설정할 때는 TUN 설정 가이드도 참고하세요. 정책 그룹을 바꾸기 위해 모든 네트워크 설정을 함께 수정할 필요는 없습니다.

자동 전환 문제 확인 순서

속도 측정은 정상인데 다운로드가 느림

먼저 지연 시간과 처리량을 구분하세요. 상태 확인은 작은 리소스 하나를 요청하므로 퇴근 시간대의 혼잡, 지속 전송 속도 제한, 단일 연결 대역폭을 측정할 수 없습니다. 같은 다운로드 대상과 테스트 시간대를 정한 뒤 후보 노드를 수동으로 선택해 지속 속도를 비교하세요. 80밀리초와 100밀리초의 차이만으로 어느 회선의 다운로드가 더 빠른지 판단하지 마세요.

노드 연결이 끊겼는데 전환되지 않음

현재 모드가 규칙 모드인지 확인하고, 연결 기록에서 실제로 일치한 규칙과 최종 출구를 확인하세요.
앱 트래픽이 실제로 Clash에 들어오는지 확인하세요. 터미널 도구는 프록시 환경 변수를 별도로 설정해야 할 수 있으며, macOS 시스템 프록시 설정을 따르지 않을 수도 있습니다.
url이 노드를 통해 접속되는지, interval이 지나치게 길지 않은지, 그룹이 지연 확인 설정 때문에 예상대로 계속 탐지하지 않는 것은 아닌지 확인하세요.
새 테스트 연결을 만들어 “새 연결이 여전히 전환되지 않는 문제”와 “기존 연결이 계속 유지되는 상황”을 구분하세요.

url-test가 자주 노드를 바꿈

먼저 여러 확인 주기에 걸친 지연 시간 변화를 기록한 뒤 허용치를 조정하세요. interval: 300과 tolerance: 50부터 관찰할 수 있으며 확인 간격을 몇 초로 줄일 필요는 없습니다. 후보 노드의 지연 시간 변동이 작다면 허용치를 조금 높여 노드 변경을 줄일 수 있습니다. 테스트 주소 자체가 불안정하다면 먼저 적절한 탐지 대상으로 바꾸세요.

모든 노드가 동시에 사용 불가로 표시됨

클라이언트를 바로 다시 설치하기보다 테스트 URL 접속 여부, DNS 확인, 로컬 네트워크, 구독 인증 정보를 먼저 점검하세요. 같은 노드로 접속이 확인된 다른 소형 페이지를 열어 보고, 로그의 타임아웃, 이름 확인 실패, 연결 거부 기록을 비교하세요. 모든 후보가 동시에 실패한다면 원격 회선이 전부 동시에 끊긴 것이 아니라 공통으로 의존하는 요소에 문제가 생겼을 수 있습니다.

설정 검증과 일상적인 선택 기준

웹 브라우징과 상호작용 요청에는 url-test를 먼저 고려하세요. 명확한 주 회선이 있고 장애 시 백업 회선으로 전환하려면 fallback을 사용하고, 서로 독립적인 여러 작업의 출구를 분산해야 할 때 load-balance를 고려하세요. 한 계정에서 공인 IP를 안정적으로 유지해야 한다면 고정 노드나 수동 선택이 대체로 관리하기 쉽습니다.

기존 설정을 저장하세요. 되돌릴 수 있는 사본을 보관하고, 먼저 정책 그룹만 수정하세요. DNS, TUN 스택, 모든 규칙을 한꺼번에 변경하지 마세요.
설정이 로드되었는지 확인하세요. 클라이언트 로그에서 알 수 없는 필드, 존재하지 않는 노드 이름, 그룹 순환 참조 등의 오류가 없는지 확인하세요.
실제 출구를 확인하세요. 새 요청을 보내고 연결 기록에서 일치한 규칙, 정책 체인, 최종 노드를 확인하세요. 그룹 이름만 보아서는 안 됩니다.
최소 두 주기 동안 관찰하세요. 간격을 300초로 설정했다면 상태 확인이 이루어질 때까지 기다리세요. 수동 속도 측정으로 알 수 있는 것은 측정 당시의 결과뿐입니다.
백업 회선을 통제된 환경에서 테스트하세요. 복구할 수 있는 환경에서 주 노드를 사용할 수 없도록 한 뒤 복구하고, 이후 연결의 전환과 복귀를 각각 확인하세요.

정책 그룹 설정의 핵심은 선택 규칙이 실제 사용 목적에 맞도록 하는 것입니다. 지연 시간, 사용 가능 여부, 출구 안정성, 동시 연결 분배는 서로 다른 지표입니다. 이를 나눠서 확인하면 속도 측정을 반복하거나 확인 간격을 무작정 줄이는 것보다 문제를 더 쉽게 찾을 수 있습니다.