Clash 정책 그룹 url-test, fallback, load-balance 차이와 설정 방법

Clash와 Clash Meta(mihomo 커널)의 proxy-groups에는 수동 선택 방식인 select 외에도 세 가지 자동 정책 그룹 유형이 있습니다: url-test, fallback, load-balance. 세 가지 모두 그룹 내 노드에 대해 주기적으로 상태 검사를 수행하지만, 검사 결과를 사용하는 방식은 완전히 다릅니다 — 하나는 가장 빠른 노드를 고르고, 하나는 사용 가능한 노드를 보장하고, 하나는 트래픽을 분산시킵니다. 이 차이를 이해하지 못한 채 인터넷에서 찾은 설정 조각을 그대로 붙여넣으면 "자동 속도 측정을 설정했는데 왜 계속 같은 느린 노드를 쓰는가" 같은 혼란을 겪기 쉽습니다. 이 글에서는 유형별로 파라미터를 하나씩 정리하고, 바로 적용할 수 있는 YAML 작성법을 제공합니다.

세 가지 자동 정책 그룹이 해결하는 문제는 서로 다르다

먼저 전제를 하나 명확히 하겠습니다: 이 세 가지 정책 그룹은 모두 그룹 내 최소 두 개 이상의 사용 가능한 노드가 있어야 의미가 있으며, 노드가 하나뿐인 그룹에서는 select와 차이가 없습니다. 이들의 핵심 차이는 "어떤 노드를 선택할지"에 대한 판단 로직에 있습니다:

• url-test: 그룹 내 각 노드에 주기적으로 속도 측정 요청을 보내고, 지연이 가장 낮은 노드를 현재 출구로 선택합니다. 목표는 "항상 가장 빠른 경로를 사용하는 것"입니다.
• fallback: 설정된 노드 순서대로 가용성을 검사하고, 검사를 통과한 첫 번째 노드를 사용하며, 현재 노드가 실패했을 때만 다음 노드로 전환합니다. 목표는 "연결 가능한 노드를 보장하는 것"이며, 속도가 아니라 안정성을 우선합니다.
• load-balance: "어느 것이 가장 좋은가"를 판단하지 않고, 알고리즘에 따라 요청을 그룹 내 여러 노드에 분산시킵니다. 목표는 "트래픽을 분산시켜" 특정 노드에 부하가 몰리거나 표적 제한을 받는 것을 피하는 것입니다.

어떤 유형을 선택할지는 지연, 안정성, 트래픽 분산 중 무엇을 더 중시하는지에 따라 달라지며, 세 가지는 서로 대체할 수 없습니다.

url-test: 지연 우선 자동 경로 선택

url-test는 가장 많이 쓰이는 자동 정책 그룹 유형으로, "여러 노드를 갖고 있는데 수동으로 전환하고 싶지 않고, 항상 지연이 가장 낮은 노드를 쓰고 싶은" 상황에 적합합니다. 대표적인 작성 예시:

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩01
      - 싱가포르02
      - 일본03
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

주요 필드 설명:

• url: 속도 측정 요청의 대상 주소로, 보통 접속이 원활한 경량 엔드포인트를 사용합니다. 요청이 성공하면 노드가 사용 가능하다고 판단하고, 응답 시간을 지연 값으로 간주합니다.
• interval: 속도 측정 주기(초 단위). 너무 짧으면 노드에 대한 탐지 부하가 커지고, 너무 길면 지연 변화에 따른 전환이 늦어집니다. 일반적으로 180~600 사이 값을 사용합니다.
• tolerance: 허용 오차(밀리초 단위). 새로 측정한 지연이 현재 노드보다 이 오차만큼 낮아야 전환이 발생합니다. 오차를 설정하는 이유는 노드 지연이 몇 밀리초 흔들릴 때마다 출구가 빈번하게 바뀌어 연결이 계속 끊기는 것을 막기 위함입니다.
• lazy: true일 경우 해당 정책 그룹이 실제로 사용될 때만 주기적 속도 측정을 실행하고, 선택되지 않은 그룹은 탐지를 멈춰 불필요한 요청을 줄입니다.

fallback: 가용성을 보장하는 대체 전환

fallback의 목적은 "최적 선택"이 아니라 "주-백업" 구조입니다. proxies 목록에 적힌 순서대로 첫 번째부터 검사하며, 현재 사용 중인 노드가 계속 연결 가능하다면 그보다 지연이 낮은 뒤쪽 노드로 능동적으로 전환하지 않습니다. 현재 노드가 검사에 실패했을 때만 순서대로 뒤로 이동해 첫 번째로 사용 가능한 노드를 찾습니다. 작성 예시:

proxy-groups:
  - name: 백업 경로
    type: fallback
    proxies:
      - 주노드-상하이 경유
      - 백업노드-도쿄 직결
      - 백업노드-서울 직결
    url: http://www.gstatic.com/generate_204
    interval: 180

fallback에는 tolerance 파라미터가 없습니다. 지연 높낮이를 비교하는 것이 아니라 "연결됨/연결 안 됨"만 판단하기 때문입니다. 이 유형은 연결 안정성을 중시하고 노드가 자주 바뀌는 것을 원하지 않는 상황, 예를 들어 오래 백그라운드에서 돌아가는 다운로드 작업이나 세션을 유지해야 하는 서비스에 적합합니다. 목록 순서가 곧 우선순위이므로, 가장 안정적이고 중요한 노드를 맨 앞에 배치하세요.

load-balance: 여러 노드에 트래픽 분산

load-balance는 "최적을 선택"하는 것이 아니라, 서로 다른 요청을 그룹 내 여러 노드에 분산 배정합니다. 사양이 비슷한 노드를 여러 개 동시에 운용하면서 특정 노드가 장기간 높은 부하를 지지 않도록 트래픽을 분산시키고 싶은 상황에서 자주 사용됩니다. 설정 예시:

proxy-groups:
  - name: 로드 밸런싱
    type: load-balance
    proxies:
      - 노드A
      - 노드B
      - 노드C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

strategy는 분배 알고리즘을 결정하며, 흔히 두 가지가 있습니다:

• consistent-hashing: 소스 주소와 목적지 주소의 해시값에 따라 노드를 배정하며, 동일한 연결 세션은 유효 기간 내에 항상 같은 노드를 사용합니다. 세션 유지가 필요한 상황(예: 출구 IP 일치를 요구하는 로그인 상태를 가진 일부 사이트)에 적합합니다.
• round-robin: 순서대로 돌아가며 배정하는 방식으로, 새 연결은 순서대로 다음 노드에 배정됩니다. 분배는 더 균등하지만, 같은 목적지가 항상 같은 노드를 쓰는 것은 보장되지 않습니다.

load-balance도 주기적으로 노드 가용성을 검사하며, 실패한 노드는 배정 범위에서 일시적으로 제외되고 복구되면 다시 편입됩니다. url-test와의 본질적인 차이는 url-test는 항상 "현재 최적"인 하나의 노드만 사용하는 반면, load-balance는 여러 노드를 동시에 사용해 요청을 분담한다는 점입니다.

파라미터 요약과 흔한 오해

흔히 빠지는 함정 몇 가지:

1. fallback 그룹에서 노드 순서를 반대로 적어, 지연이 더 높은 백업 노드가 먼저 사용되는 경우 — fallback은 지연을 비교하지 않고 목록 순서와 현재 노드의 실패 여부만 봅니다.
2. tolerance를 0으로 설정하면 url-test 그룹은 새 측정 주기에서 어떤 노드든 현재 노드보다 1밀리초라도 빠르면 바로 전환해 출구가 자주 흔들리게 됩니다. 최소 30~50밀리초의 오차를 두는 것을 권장합니다.
3. load-balance에 지연 차이가 매우 큰 노드를 함께 넣는 경우(예: 지연이 높은 경유 노드와 지연이 낮은 직결 노드를 같은 그룹에 섞음) — 트래픽을 분산해도 전체 체감은 오히려 단일 최적 노드를 고르는 것보다 못하게 됩니다. 사양이 비슷한 노드끼리 묶는 것이 적합합니다.
4. interval을 너무 짧게 설정(예: 10초 이내)하면 노드 탐지 요청이 지나치게 빈번해져 일부 서비스 제공자나 자체 구축 노드 서버 측에서 제한을 걸 수 있습니다. 120초 이상을 권장합니다.

세 가지 정책 그룹, 어떻게 선택할까

한 문장으로 정리하면: 지연을 우선한다면 url-test, 안정성을 우선한다면 fallback, 분산을 우선한다면 load-balance를 사용하세요. 실제로는 세 가지를 조합해 쓸 수도 있습니다 — 예를 들어 url-test 그룹을 일상 출구로 사용하고, 별도로 안정적인 직결 노드 몇 개를 담은 fallback 그룹을 하나 만들어서 장시간 연결이 필요한 상황(다운로드 도구, 원격 데스크톱 등)만 규칙을 통해 따로 분기시키면 속도와 안정성을 함께 챙길 수 있습니다. 정책 그룹 유형을 정한 뒤에는 규칙 세트로 도메인/앱별로 서로 다른 정책 그룹에 분기시켜야 완전한 트래픽 분배 로직이 완성됩니다. 정책 그룹 자체는 "이 종류의 트래픽이 어느 노드(들)로 가야 하는가"라는 문제만 해결합니다.