Clash 정책 그룹 선택 가이드: url-test·fallback·load-balance 차이와 활용 시나리오

정책 그룹이란: 결정 그룹과 실행 그룹의 관계

Clash와 Clash Meta(mihomo)의 설정 파일에서 proxies 섹션은 구체적인 프록시 노드를 나열하고, proxy-groups 섹션은 "정책 그룹"을 정의합니다. 정책 그룹은 여러 노드나 하위 정책 그룹을 하나로 묶어 특정 규칙에 따라 실제로 어느 경로를 사용할지 결정하는 논리 단위입니다. rules 섹션이 최종적으로 가리키는 대상은 대개 특정 노드가 아니라 정책 그룹의 이름이며, 실제 트래픽이 어느 노드로 흘러갈지는 런타임에 정책 그룹이 결정합니다.

현재 주로 사용되는 정책 그룹 유형은 네 가지입니다: select(수동 선택), url-test(자동 속도 측정 선택), fallback(장애 전환), load-balance(부하 분산). 네 가지 모두 동일한 필드 구조(name, type, proxies)를 공유하지만 판단 로직은 완전히 다르며, 잘못 혼용하면 "백업 노드를 설정했는데도 전환되지 않는다" 혹은 "노드가 자꾸 바뀐다" 같은 문제가 생길 수 있습니다. 각 유형의 전환 조건을 이해하는 것이 안정적인 구독 설정을 만드는 전제입니다.

select: 수동 선택형 정책 그룹

select는 가장 기본적인 유형으로, 자체적으로 속도 측정이나 상태 확인을 하지 않고 노드나 정책 그룹 목록을 그대로 나열해 클라이언트 화면에서 수동으로 전환할 수 있게 해줍니다. 기본값은 proxies 목록의 첫 번째 항목이며, 전환 후에는 클라이언트가 마지막 선택을 기억합니다(런타임 상태에 기록되며 설정 파일 자체는 변경되지 않습니다). 대표적인 용도는 최상위 진입 그룹으로 두어 "자동 최적 선택"과 "특정 노드 직접 지정" 사이를 자유롭게 전환하는 것입니다.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 최적화
      - 홍콩 중계
      - 일본 전용선
      - DIRECT

속도 측정이나 장애 감지가 없기 때문에 select 그룹에 이미 사용할 수 없는 노드가 들어 있으면 사용자가 수동으로 전환하기 전까지 트래픽이 계속 그쪽으로 강제 전달됩니다. 따라서 실무에서는 select에 순수 노드만 나열하지 않고, 아래에서 설명할 url-test 같은 속도 측정형 하위 정책 그룹을 옵션 중 하나로 포함시켜 수동 제어와 자동 대체를 동시에 확보하는 경우가 많습니다.

url-test: 자동 속도 측정과 전환 판단 메커니즘

url-test 그룹은 설정된 테스트 주소로 주기적으로 요청을 보내 각 노드의 응답 지연을 기록하고, 현재 지연이 가장 낮으면서 지연 차이가 허용 오차 값을 넘는 노드를 자동으로 선택합니다. 핵심 필드는 세 가지입니다:

• url: 속도 측정 요청 대상. 보통 국제적으로 접속 가능한 경량 주소를 사용;
• interval: 속도 측정 주기(초 단위). 너무 짧으면 노드 부담과 배터리 소모가 늘고, 너무 길면 장애 감지가 늦어짐;
• tolerance: 허용 오차 값(밀리초 단위). 새로운 최적 노드가 현재 노드보다 이 값 이상 빨라야 실제로 전환되며, 몇 밀리초 수준의 지연 변동으로 노드가 반복적으로 바뀌는 것을 방지합니다.

proxy-groups:
  - name: 자동 최적화
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - 홍콩 중계
      - 싱가포르 전용선
      - 일본 전용선

url-test는 노드 수가 많고 "빠른 쪽을 그냥 쓰면 된다"는 방식을 원하는 경우, 예를 들어 일상적인 웹서핑이나 동영상 시청처럼 지연에는 민감하지만 특정 경로를 고정할 필요가 없는 용도에 적합합니다. 다만 측정 결과는 그 순간의 네트워크 상태만 반영하므로, 실제 업무 대상 서버와 측정 주소의 네트워크 경로가 크게 다르면 선택된 "최적" 노드가 실제 상황에서는 진짜 가장 빠른 노드가 아닐 수도 있습니다.

fallback: 장애 전환의 조건과 지연

fallback 그룹은 proxies 목록의 순서대로 탐지하며, 앞에 있고 탐지에 통과한 노드를 우선 사용합니다. 현재 사용 중인 노드의 탐지가 실패(타임아웃 또는 예상치 못한 응답)할 때만 다음 사용 가능한 노드로 순서대로 전환됩니다. url, interval 필드로 상태 확인을 한다는 점은 동일하지만 판단 로직은 url-test와 다릅니다: url-test는 "어느 것이 가장 빠른가"를 비교하고, fallback은 "앞쪽 노드가 여전히 살아 있는가"를 비교합니다.

proxy-groups:
  - name: 장애 전환
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - 주 전용선
      - 백업 전용선-A
      - 백업 전용선-B

fallback은 명확한 우선순위가 있고 "불필요하게 주 노선을 벗어나지 않기"를 원하는 시나리오에 적합합니다. 예를 들어 안정적이지만 비용이 높은 전용선을 첫 번째로, 속도는 보통이지만 안정적인 백업 노드를 뒤에 배치해 주 노선이 실제로 끊겼을 때만 전환하고, 한 번 지연이 조금 높게 측정됐다고 바로 넘어가지 않게 합니다. 주의할 점은 fallback의 상태 확인 주기가 장애 감지 지연을 결정한다는 것입니다. 확인 주기가 너무 길면 주 노선 장애 후 한동안 트래픽이 여전히 끊긴 노드에 머물고, 너무 짧으면 탐지 요청 빈도가 늘어납니다.

load-balance: 부하 분산의 두 가지 전략

load-balance 그룹은 "단 하나의 최적 노드"를 고르는 것이 아니라 요청을 여러 노드에 분산시킵니다. 여러 노선이 함께 대역폭 부담을 나누어 하나의 노드가 장시간 모든 트래픽을 감당하지 않도록 하려는 시나리오에서 주로 사용됩니다. strategy 필드로 분배 알고리즘을 지정하며 주로 두 가지 값이 있습니다:

• consistent-hashing: 요청 대상 주소를 기준으로 일관 해시를 적용해 동일한 대상 도메인/IP가 항상 같은 노드로 안정적으로 매핑됩니다. 세션 유지가 필요한 경우(예: 고정 출구 IP가 있어야 정상 로그인되는 사이트)에 적합;
• round-robin: 순환 순서대로 요청을 각 노드에 차례로 분배해 더 균등하게 부담을 나누지만, 동일한 대상이라도 요청마다 다른 노드로 갈 수 있어 출구 IP 일관성이 필요한 업무에는 적합하지 않습니다.

proxy-groups:
  - name: 분산 부하
    type: load-balance
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - 전용선-A
      - 전용선-B
      - 전용선-C

load-balance 그룹도 상태 확인 기능을 갖고 있어 사용할 수 없는 노드는 자동으로 분배 대상에서 제외됩니다. 대역폭·지연이 비슷한 동질적인 노선이 여러 개 있고 목적이 최적화가 아니라 부담 분산인 경우에 더 적합합니다. 노선 품질 차이가 크면 무작정 부하 분산을 적용할 경우 요청이 무작위로 품질이 낮은 노드에 몰릴 수 있어 url-test보다 체감이 떨어질 수 있습니다.

자주 쓰는 그룹 조합과 실전 팁

실제 설정에서는 단일 유형만 쓰는 경우가 드물고, 계층형 조합이 더 흔합니다. 최상위에 사용자가 수동으로 개입할 수 있는 select 그룹을 두고, 그 아래에 서로 다른 전략의 하위 그룹을 여러 개 매달아 rules가 도메인/IP 규칙에 따라 구체적인 하위 그룹으로 트래픽을 분배하는 구조입니다. 흔히 볼 수 있는 구조는 다음과 같습니다:

proxy-groups:
  - name: 아웃바운드 정책
    type: select
    proxies:
      - 자동 최적화
      - 장애 전환
      - DIRECT

  - name: 자동 최적화
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [전용선-A, 전용선-B, 전용선-C]

  - name: 장애 전환
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies: [주 전용선, 백업 전용선-A]

선택 기준은 다음과 같이 정리할 수 있습니다: "평소에는 자동으로 가장 빠른 것을 쓰고, 가끔 바뀌어도 괜찮다"면 url-test; "명확한 주/백업 순서가 있고 주 노선을 쉽게 벗어나지 않기를 원한다"면 fallback; "여러 노선이 함께 트래픽을 감당해야 한다"면 load-balance; "사용자에게 수동 전환 스위치만 제공하면 된다"면 select. 네 가지는 서로 중첩해서 사용할 수도 있습니다. 예를 들어 url-test 그룹을 select 그룹의 옵션 중 하나로 넣으면 자동 최적화 기능을 유지하면서도 특정 노드를 수동으로 고정할 수 있는 여지를 남길 수 있습니다.

또한 정책 그룹의 판단은 프록시 계층의 연결성과 지연만을 다루며, 규칙 매칭이 실제로 적용됐는지, DNS 해석이 올바른 출구를 거쳤는지, TUN 모드에서 시스템 라우팅 테이블이 적용됐는지 같은 다른 단계는 다루지 않습니다. 정책 그룹을 전환해도 문제가 계속된다면, 먼저 규칙 섹션이 실제로 해당 트래픽을 이 정책 그룹으로 가리키고 있는지 확인한 뒤, 측정 주소와 허용 오차 값이 적절한지 다시 점검하는 식으로 한 단계씩 확인하는 것이 여러 필드를 한꺼번에 바꾸는 것보다 문제를 찾기 쉽습니다.