Clash 정책 그룹 선택법: url-test·fallback·load-balance 3가지 유형 완벽 분석

설정 파일에서 정책 그룹의 위치

Clash의 노드 분기는 proxy-groups 설정 항목에 의존합니다. proxies에 나열된 개별 노드들을 하나의 "논리적 출구"로 묶어주며, rules 규칙 항목이 참조하는 것은 특정 노드가 아니라 바로 이 정책 그룹의 이름입니다. 이렇게 하면 좋은 점은, 서버 서비스나 노드를 바꿀 때 proxies와 proxy-groups만 수정하면 되고 규칙 자체는 한 줄도 손댈 필요가 없다는 것입니다.

각 정책 그룹은 반드시 type을 선언해야 하며, 이는 클라이언트가 이 그룹 안에서 "어떻게 노드를 선택할지"를 결정합니다. 흔히 쓰이는 네 가지 유형은 select(수동 선택), url-test(자동 속도 측정), fallback(장애 전환), load-balance(로드 밸런싱)입니다. select는 가장 단순하게 사람이 직접 전환하는 방식이라 이 글에서는 다루지 않으며, 나머지 세 유형은 모두 "자동 판단" 로직을 갖고 있어 오용되기 가장 쉬운 세 가지이기도 합니다. 아래에서 하나씩 살펴보겠습니다.

url-test: 지연 시간 기반 자동 속도 측정

url-test는 세 자동 유형 중 가장 흔히 쓰입니다. 동작 방식을 정리하면: 클라이언트가 일정 주기마다 그룹 내 각 노드로 HTTP 요청을 보내(대상 주소는 url 필드로 지정) 왕복 지연 시간을 기록하고, 항상 현재 측정된 지연 시간이 가장 낮은 노드로 트래픽을 보냅니다.

주요 필드 설명:

url: 속도 측정 대상 주소. 보통 해외에서 정상적으로 접속되고 응답이 빠른 주소를 사용하며, 연결성 확인용으로 흔히 쓰이는 경량 엔드포인트를 지정합니다;
interval: 측정 주기(초 단위). 보통 300초(5분) 전후로 설정하며, 너무 짧으면 노드 측 부담이 커지고 너무 길면 지연 변화에 대한 반응이 늦어집니다;
tolerance: 전환 허용 오차(밀리초 단위). 새 노드의 지연 시간이 현재 노드보다 이 오차 값 이상 낮아야 실제로 전환이 일어나며, 두 노드 사이에서 지연 시간이 오락가락하면서 연결이 자주 재수립되는 것을 막아줍니다;
lazy(Clash Meta/mihomo 지원): 활성화하면 실제 요청이 발생할 때만 측정이 트리거되며, 트래픽 유무와 무관하게 주기마다 공회전 측정을 하지 않습니다. 장시간 켜두지만 연결 수가 적은 상황에 적합합니다.

적용 상황은 명확합니다. 서비스 제공자가 동질적인 중계 노드(예: 같은 회선의 여러 출구)를 제공하고, 어느 노선을 타는지는 신경 쓰지 않고 지연 시간이 가장 낮기만 하면 될 때 적합합니다. 단점도 여기서 나옵니다 — url-test는 지연 시간만 보고 손실률이나 실제 처리량은 보지 않으므로, 지연은 낮지만 속도 제한이 심한 노드는 측정 단계에서 전혀 드러나지 않습니다.

fallback: 순서대로 탐지하는 장애 전환

fallback의 로직은 url-test와 완전히 다릅니다. 지연 시간을 비교하지 않고, proxies 목록에 나열된 노드 순서대로 엄격하게 가용성을 탐지합니다. 첫 번째 노드가 연결만 가능하면(탐지 요청 성공) 계속 그 노드를 사용하며, 현재 사용 중인 노드의 탐지가 실패했을 때만 다음으로 연결 가능한 노드로 순서대로 전환합니다.

즉 fallback은 태생적으로 "주-백업" 의미를 갖습니다 — 미리 노드 순서를 계획해서 가장 쓰고 싶은 주 노드를 맨 앞에, 백업 노드를 그 뒤로 순서대로 배치해야 합니다. 핵심 필드는 url-test와 거의 같습니다(url, interval, tolerance). 다만 tolerance는 fallback에서는 역할이 약한데, 전환 판단 기준이 "얼마나 지연 차이가 나는지"가 아니라 "연결 가능 여부"이기 때문입니다.

대표적인 사용 상황: 안정적인 자체 구축 노드를 주력으로 삼고, 백업용으로 서비스 제공자의 노드 한두 개를 남겨두는 경우입니다. 평소에는 트래픽이 자체 구축 노드를 우선 타게 하고, 자체 구축 노드에 문제가 생겼을 때(끊김, 접속 불가능 수준의 속도 제한)만 백업 노선으로 자동 전환되길 원할 때입니다. 이런 "주력이 있고 백업도 있으며, 필요할 때만 넘겨받는" 요구에는 fallback이 url-test보다 더 적합합니다 — url-test는 백업 노드가 어느 한 번 측정에서 지연이 더 낮게 나오면 그쪽으로 전환해버리지만, fallback은 그렇지 않고 주 노드가 살아있는 한 그대로 유지합니다.

주의: fallback 그룹 안의 노드 작성 순서가 곧 우선순위 순서입니다. 순서를 바꾸려면 proxies 참조 목록을 직접 수정해야 하며, 클라이언트 화면에는 보통 "주 노드로 설정" 같은 조작 항목이 따로 없습니다.

load-balance: 연결을 분산하는 로드 밸런싱

load-balance는 또 다른 문제를 해결합니다: 그룹 내 여러 노드의 성능이 비슷하고 모두 사용 가능할 때, 모든 트래픽이 한 노드에 몰리는 대신 동시 연결을 여러 노드로 분산시키고 싶을 때 사용합니다. 핵심 필드는 strategy로, 흔히 쓰는 값은 두 가지입니다:

consistent-hashing: 요청 대상 주소를 기준으로 일관 해싱을 적용해, 같은 목적지 도메인/IP는 대부분 같은 노드로 고정 배정됩니다. 이렇게 하면 노드 전환으로 인한 연결 끊김을 줄일 수 있어, 세션 일관성이 필요한 상황(영상 재생, 다운로드 중인 대용량 파일 등)에 더 적합합니다;
round-robin: 라운드 로빈 순서로 새 연결을 그룹 내 노드에 차례로 배정합니다. 분배는 더 균등하지만 같은 목적지 주소라도 요청마다 다른 노드로 갈 수 있습니다.

load-balance도 url과 interval을 통한 헬스 체크를 지원하며, 사용 불가로 탐지된 노드는 일시적으로 배정 풀에서 제외되고 다시 사용 가능해지면 재편입됩니다. 강조할 점은, load-balance가 분산시키는 것은 "연결 수"이며 실시간 속도 제한 개념의 "대역폭"이 아니라는 것입니다. 그룹 내 특정 노드의 대역폭 상한 자체가 낮다면, 거기로 배정된 연결은 여전히 느립니다. 로드 밸런싱이 개별 노드의 성능 부족을 대신 채워주지는 않습니다.

세 유형 중 무엇을 선택할까

셋을 함께 놓고 비교하면, 선택 기준을 한 문장으로 정리할 수 있습니다: 해결하려는 것이 "가장 빠른 것 고르기"인지, "주-백업 유지"인지, "동시 연결 분산"인지 보면 됩니다.

그룹 내 노드 노선이 비슷하고 순수하게 지연 시간이 최적이길 원한다면 → url-test 사용;
명확한 주 노드와 백업 노드가 있고, 주 노드를 우선 쓰다가 장애 시에만 전환되길 원한다면 → fallback 사용;
그룹 내 노드 수가 많고, 동시 연결을 분산해 특정 노드의 과부하를 피하고 싶다면 → load-balance 사용;
그냥 직접 수동으로 전환하고 자동 로직이 필요 없다면 → 가장 기본적인 select 사용.

실제 설정에서는 이 유형들이 중첩되어 쓰이는 경우가 많습니다. 바깥쪽에 select를 두어 사용자가 "자동 속도 측정", "고정 노선", "전체 노드 수동 선택" 사이를 전환하게 하고, 안쪽의 "자동 속도 측정" 옵션 자체는 다시 하나의 url-test 그룹으로 구성합니다. 이렇게 하면 자동화를 유지하면서도 수동 백업의 유연성을 잃지 않습니다.

바로 적용 가능한 설정 예시

다음은 세 유형 각각의 최소 사용 가능한 설정 예시입니다. proxies의 노드 이름을 필요에 맞게 바꾼 뒤 config.yaml의 proxy-groups 항목에 바로 붙여넣을 수 있습니다.

proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies:
      - "노드A"
      - "노드B"
      - "노드C"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "주백업 전환"
    type: fallback
    proxies:
      - "자체구축 주노드"
      - "서비스 백업1"
      - "서비스 백업2"
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "균형 분산"
    type: load-balance
    proxies:
      - "노드A"
      - "노드B"
      - "노드C"
      - "노드D"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

Clash Meta(mihomo) 코어는 이 기본 위에 max-failed-times(연속 몇 번 탐지 실패해야 사용 불가로 판정할지 지정해 일시적 네트워크 흔들림으로 인한 오판을 줄이는 데 사용)와 lazy 파라미터를 추가로 지원합니다. 클라이언트가 Meta 코어 규칙 세트를 지원한다고 표시되어 있다면 필요에 따라 이 두 필드를 추가해 더 세밀하게 조정할 수 있습니다. 원본 Clash 코어는 이 필드들을 인식하지 못하므로 작성해도 오류는 나지 않지만 적용되지 않습니다.

흔한 오해와 점검 팁

정책 그룹을 설정할 때 가장 흔히 빠지는 함정들:

지연 시간 차이가 큰 노드들을 같은 load-balance 그룹에 섞어 넣는 경우 — 로드 밸런싱은 지연 시간을 따지지 않으므로 느린 노드도 똑같이 연결을 배정받아, 오히려 url-test보다 체감이 나빠집니다;
fallback 그룹의 노드 순서를 반대로 써서 주력 노드가 뒤로 가버리는 경우 — 평소에 우선 사용되는 것이 백업 노선이 되어 버립니다;
url-test의 tolerance를 너무 작게(예: 0이나 5ms) 설정하는 경우 — 노드 지연 시간 자체에도 변동이 있기 때문에 오차가 너무 작으면 빈번한 전환이 일어나 연결이 계속 끊깁니다;
측정 주소 url로 국내(한국)에서 직접 연결되는 주소를 사용해, 모든 노드의 측정 지연 시간이 비슷하게 나와 노드 우열을 구분하는 의미가 사라지는 경우.

권장: 정책 그룹 유형이나 파라미터를 바꾼 뒤에는 먼저 클라이언트 내장 지연 시간 테스트 패널로 실제 전환 동작을 한 차례 관찰하고, 예상대로 동작하는지 확인한 뒤 장기간 사용하세요. 실제 사용 중에야 노선이 자주 튀는 문제를 발견하는 상황을 피할 수 있습니다.

정책 그룹의 유형과 파라미터를 잘 맞춰두면 규칙 작성이 훨씬 수월해집니다 — 규칙은 "어느 정책 그룹으로 보낼지"만 신경 쓰면 되고, 구체적으로 어느 노드로 갈지, 언제 전환할지는 이미 정책 그룹 자체의 판단 로직이 처리하기 때문입니다. 이것이 바로 Clash 분기 체계에서 규칙과 노드를 분리한 핵심 가치입니다.