Clash 전략 그룹 유형 완벽 가이드: url-test, fallback, load-balance 차이

Clash 규칙 라우팅에서 전략 그룹은 어떻게 작동할까

Clash 설정에서 프록시 노드는 실제 연결을 담당하고, 규칙은 트래픽의 유형을 판별합니다. 전략 그룹은 그 사이에서 특정 트래픽을 최종적으로 어떤 노드에 전달할지 결정합니다. 규칙의 대상에는 보통 특정 노드 이름을 직접 입력하지 않고 전략 그룹을 참조합니다. 예를 들어 업무용 도메인은 “업무 서비스”, 스트리밍 도메인은 “미디어 서비스”로 보내고, 그룹 내부의 선택 로직이 노드 전환을 처리하는 방식입니다.

url-test, fallback, load-balance는 모두 자동 전략 그룹이지만, “자동”이라고 해서 같은 방식으로 선택하는 것은 아닙니다. 세 유형은 각각 지연 시간 우선 선택, 순차적 장애 전환, 여러 노드로의 연결 분산에 해당합니다. 노드 목록만 보고 그룹 유형을 무시하면 같은 노드 구성에서도 접속 결과가 완전히 달라질 수 있습니다.

proxy-groups:
  - name: 업무 서비스
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,example.com,업무 서비스
  - MATCH,업무 서비스

위 설정에서 규칙은 일치하는 연결을 “업무 서비스”로 보내는 역할만 합니다. 실제로 노드 A, B, C 중 무엇을 사용할지는 url-test의 측정 결과와 전환 매개변수가 결정합니다. 전략 그룹은 별도의 네트워크 터널이 아니며 노드 자체의 프로토콜, 암호화 방식 또는 서버 경로를 바꾸지도 않습니다. 노드를 묶고 선택 로직을 실행할 뿐입니다.

자동 전략 그룹에서 상태 확인의 역할

자동 그룹은 보통 각 후보 노드로 테스트 URL에 주기적으로 접속합니다. 코어는 요청 성공 여부, 응답 시간과 연속 확인 결과를 바탕으로 노드 상태를 관리합니다. 테스트 URL은 안정적이고 응답 본문이 작으며 실제 네트워크 출구와 최대한 가까운 것이 좋습니다. 204 응답을 반환하는 주소는 기본 연결성 측정에 적합하지만, 특정 서비스에 주로 사용할 설정이라면 장기간 직접 관리할 수 있는 가벼운 주소를 사용해도 됩니다.

interval은 상태 확인 간격을 의미하며, 일반적으로 단위는 초입니다. 간격이 너무 짧으면 노드와 기기에서 발생하는 추가 요청이 늘고, 모바일 네트워크에서는 연결이 자주 깨어날 수 있습니다. 반대로 너무 길면 회선 장애를 발견하는 시점이 늦어집니다. 데스크톱 상시 실행 환경에서는 약 300초부터 관찰하고, 네트워크 변동이 크거나 노드가 많다면 실제 사용 환경에 맞춰 조정하세요.

url-test: 상태 확인 지연 시간으로 노드 선택

url-test는 그룹 내 노드를 테스트한 뒤, 현재 사용 가능한 노드 중 측정 지연 시간이 낮은 노드를 우선 선택합니다. 여러 지역 출구의 기능이 비슷하고 응답 속도가 중요한 경우에 적합합니다. 예를 들어 같은 지역의 여러 출구, 동일한 서비스에 모두 접속할 수 있는 여러 노드, 일상적인 웹 탐색과 코드 저장소 접속 등에 사용할 수 있습니다.

여기서 “가장 낮은 지연 시간”은 상태 확인 요청에만 해당하며, 다운로드 속도가 가장 빠르다는 뜻은 아닙니다. 소규모 HTTP 요청은 주로 핸드셰이크, 왕복 시간과 현재 회선의 도달 가능성을 반영하므로 대용량 파일 처리량, 피크 시간대의 혼잡 또는 대상 사이트와 출구 서버 사이의 대역폭을 완전히 보여주지 못합니다. 따라서 url-test는 지속적으로 대역폭을 겨루는 기능이 아니라 “테스트 결과를 바탕으로 응답이 빠른 정상 노드를 선택하는 기능”으로 이해하는 편이 정확합니다.

tolerance로 불필요한 전환 줄이기

네트워크 지연 시간은 계속 변동합니다. 노드 A가 82ms, 노드 B가 76ms로 측정됐다고 해서 6ms 차이만으로 즉시 전환하면 체감 성능 향상은 거의 없고 새 연결이 다른 출구로 바뀔 수 있습니다. tolerance는 허용할 지연 시간 차이를 설정하는 값으로, 현재 노드와 후보 노드의 차이가 임계값을 넘지 않으면 기존 선택을 유지합니다.

- name: 일상 저지연
  type: url-test
  proxies:
    - 홍콩-01
    - 홍콩-02
    - 싱가포르-01
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 100
  lazy: true

이러한 필드를 지원하는 mihomo 설정에서는 lazy: true를 사용해 전략 그룹이 장시간 사용되지 않을 때 상태 확인 작업을 줄일 수 있습니다. 그룹이 트래픽을 처리하기 시작하면 코어가 해당 메커니즘에 따라 상태를 다시 갱신합니다. 구체적인 작동 시점은 코어 버전에 따라 달라질 수 있으므로 사용 전 현재 버전의 문서와 실행 로그를 확인하세요.

url-test를 사용할 때의 한계

적합: 후보 노드의 용도가 동일하고 지역 차이가 웹사이트 콘텐츠나 계정 보안 판단에 영향을 주지 않는 경우.
적합: 웹 탐색이나 API 요청처럼 응답 지연 시간의 영향을 크게 받는 연결.
주의 필요: 고정 출구 IP를 유지해야 하는 로그인, 결제, 원격 근무 또는 허용 목록 기반 서비스.
측정 결과만으로 판단하지 말 것: 대용량 파일 다운로드, 고화질 동영상 전송과 지속적인 업로드는 대역폭과 패킷 손실에도 좌우됩니다.

서비스 사용 중 동일한 출구를 최대한 유지해야 한다면 tolerance를 높이거나 구성원을 줄일 수 있습니다. 또는 자동 그룹 외부에 select 수동 선택 그룹을 추가하는 방법도 있습니다. 이렇게 하면 자동 우선 선택의 편리함을 유지하면서도 특정 시점에는 원하는 노드를 고정할 수 있습니다.

fallback: 노드 순서에 따른 장애 전환

fallback의 핵심은 가장 빠른 노드를 비교하는 것이 아니라 설정된 순서대로 첫 번째 정상 노드를 사용하는 데 있습니다. 앞쪽 노드가 상태 확인을 계속 통과하는 한 뒤쪽 노드의 지연 시간이 더 낮더라도 일반적으로 교체되지 않습니다. 현재 노드를 사용할 수 없을 때만 다음 사용 가능 구성원을 차례로 찾습니다.

이 동작은 주 회선과 예비 회선의 역할이 분명한 환경에 적합합니다. 예를 들어 주 노드가 고정 출구, 전용 회선 또는 업무 지역 조건에 더 잘 맞고 예비 노드는 주 회선 장애 때만 인계하는 경우입니다. url-test와 비교하면 fallback의 판단은 더 예측하기 쉽습니다. 노드 배열 자체가 우선순위 목록이기 때문입니다.

- name: 업무 주·예비
  type: fallback
  proxies:
    - 업무 주 회선
    - 업무 예비 회선
    - 임시 비상 회선
  url: https://www.gstatic.com/generate_204
  interval: 180
  lazy: false

위 예시에서는 “업무 주 회선”을 우선 사용합니다. 해당 노드의 상태 확인에 실패해야 “업무 예비 회선”을 시도하고, 그다음에야 “임시 비상 회선”으로 넘어갑니다. 주 회선이 이후 복구되어 정상 상태로 다시 판정되면 전략 그룹이 앞쪽 노드로 돌아갈 수 있습니다. 복구 판정과 기존 연결의 즉시 이전은 별도로 봐야 합니다. 전략 그룹 선택은 후속 연결에 영향을 주며, 이미 성립한 TCP 또는 UDP 세션이 끊김 없이 이동한다고 보장할 수는 없습니다.

지연 시간 수치보다 중요한 노드 순서

fallback을 설정할 때는 측정 결과보다 먼저 업무 우선순위에 따라 노드를 배열해야 합니다. 주 회선은 장기적으로 사용할 회선이어야 하며, 예비 회선은 핵심 접속 기능을 동일하게 제공해야 합니다. 예비 노드가 주요 서비스에 접속할 수 없다면 상태 확인 URL이 정상 응답을 반환하더라도 실제 장애 전환은 수행할 수 없습니다.

지역에 민감한 서비스라면 서로 다른 지역의 노드를 하나의 fallback 그룹에 무작정 섞지 않는 것이 좋습니다. 지역별로 내부 주·예비 그룹을 만든 뒤 상위 수동 선택 그룹에 넘기는 방식이 더 안정적입니다. 예를 들어 “일본 주·예비”에는 일본 노드만, “싱가포르 주·예비”에는 싱가포르 노드만 포함하고, 사용자가 최상위에서 필요한 지역을 선택합니다. 이렇게 하면 장애가 발생해도 자동 전환 때문에 출구 지역이 예기치 않게 바뀌지 않습니다.

fallback에 적합한 대표 사례

원격 근무 서비스에서 접근 허용 목록에 등록된 고정 출구를 우선 사용해야 하는 경우.
주 회선의 품질과 비용이 안정적으로 정해져 있고 예비 회선은 장애 시에만 트래픽을 처리하는 경우.
노드마다 신뢰성 순위가 분명하고 순간적인 지연 시간만으로 비교하지 않는 경우.
기본 연결성을 자동으로 복구하면서도 선택 로직을 쉽게 점검하고 설명하고 싶은 경우.

load-balance: 여러 노드에 새 연결 분산

load-balance는 그룹 내 여러 정상 노드가 함께 연결을 처리하도록 합니다. 영구적인 승자 하나를 고르는 것이 아니라 부하 분산 방식에 따라 연결마다 출구를 정하는 것이 목적입니다. 서로 독립적인 요청이 많고 노드 성능이 비슷하며 여러 출구를 사용해도 되는 환경에 적합합니다.

Clash의 부하 분산은 일반적으로 연결 또는 대상을 기준으로 결정하며, 하나의 TCP 연결을 여러 프록시 서버로 나누는 방식은 아닙니다. 대용량 파일을 한 개의 연결로만 다운로드하면 속도는 해당 연결에 선택된 노드의 성능에 제한됩니다. 애플리케이션이 여러 연결을 동시에 생성할 때에만 여러 노드가 각각 일부 연결을 처리할 수 있습니다.

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

consistent-hashing과 round-robin

mihomo가 지원하는 구체적인 균형 전략은 사용하는 버전에 따라 확인해야 합니다. 일반적인 consistent-hashing은 대상 정보를 기준으로 비교적 안정적인 매핑을 수행해 동일하거나 관련된 대상이 같은 노드에 계속 연결될 가능성을 높입니다. 같은 사이트에 접속할 때 출구가 자주 바뀌는 현상을 줄이는 데 도움이 되며, 여러 리소스를 요청하는 웹사이트나 접속 출처에 민감한 사이트에 적합합니다.

round-robin은 사용 가능한 노드를 순서대로 교대해 연속적인 새 연결을 여러 구성원에 분산하는 방식입니다. 트래픽 분산은 직관적이지만 한 웹사이트의 여러 연결이 서로 다른 출구를 사용할 수 있습니다. 사이트가 출발지 IP를 기준으로 로그인 상태를 관리하거나 보안 검사를 수행한다면 추가 인증, 세션 만료 또는 지역별 콘텐츠 불일치가 발생할 수 있습니다.

일부 mihomo 버전은 다른 전략 옵션도 제공하며, 필드와 동작이 변경될 수 있습니다. 설정을 마이그레이션할 때 이전 파일이 파싱된다는 이유만으로 모든 전략의 의미가 완전히 같다고 가정해서는 안 됩니다. 시작 로그의 설정 경고를 확인하고 연결 상세 정보에서 실제로 선택된 노드를 검증하세요.

부하 분산이 적합하지 않은 서비스

계정 로그인, 인터넷 뱅킹, 기업 인증처럼 안정적인 출구가 필요한 서비스는 고정 노드, select 또는 대상별 안정 매핑 방식을 우선 사용해야 합니다.
노드의 출구 지역이 서로 다르면 연결이 바뀔 때 검색 결과, 미디어 카탈로그, 통화 단위와 페이지 지역 설정이 달라질 수 있습니다.
노드 성능 차이가 큰 경우 연결을 균등하게 분배해도 대역폭이 균등하게 분배되는 것은 아닙니다. 느린 노드가 일부 요청을 계속 지연시킬 수 있습니다.
모바일 네트워크 전환이 잦거나 기기 리소스가 제한적이고 노드 수가 지나치게 많으면 상태 확인과 동시 연결로 인한 추가 부담이 발생합니다.

url-test, fallback, load-balance의 핵심 차이

비교 항목	url-test	fallback	load-balance
주요 목표	측정 지연 시간이 낮은 정상 노드 선택	목록 앞쪽의 정상 노드 우선 사용	여러 정상 노드가 새 연결을 함께 처리
노드 순서의 역할	일반적으로 주요 선택 기준이 아님	주·예비 우선순위를 직접 나타냄	균형 조정 전략에 따라 달라짐
전환 원인	지연 시간 차이가 허용 범위를 넘거나 현재 노드가 실패함	앞선 노드가 실패하거나 더 높은 우선순위 노드가 복구됨	새 연결은 전략에 따라 분배되고, 장애 노드는 제외됨
출구 안정성	보통 수준, tolerance로 전환을 줄일 수 있음	높은 편, 주 노드가 정상이면 우선 사용	해시 또는 순환 방식에 따라 달라짐
주요 용도	웹, API, 동일 지역의 저지연 노드 선택	업무용 주·예비 구성, 고정 지역 장애 전환	다중 연결 다운로드, 동시 요청 분산

이름이 아니라 요구 사항에 따라 선택

전략 그룹을 선택할 때는 먼저 세 가지 질문에 답해 보세요. 업무에 고정 지역이나 고정 출구가 필요한가? 노드 장애 시 임의의 사용 가능 노드로 자동 전환해도 되는가? 여러 노드가 동시에 연결을 처리해야 하는가? 주 출구를 유지하다가 장애 때만 전환해야 한다면 fallback이 가장 직접적입니다. 노드가 동등하고 응답 속도를 우선한다면 url-test가 적합합니다. 요청량이 많고 연결이 서로 독립적이며 출발지 변경을 허용할 수 있을 때만 load-balance를 고려하세요.

하나의 설정에서 자동 그룹을 한 종류만 사용할 필요는 없습니다. 실제 구성은 계층적으로 조합할 수 있습니다. 하위 계층에서는 fallback으로 지역별 주·예비 노드를 묶고, 중간 계층에서는 url-test로 여러 동등 지역 그룹 중 응답이 좋은 입구를 선택하며, 최상위에서는 select로 사용자가 전략을 고정하도록 할 수 있습니다. 전략 그룹 중첩은 업무 경계를 더 명확하게 표현하지만 계층이 지나치게 많으면 문제 해결이 어려워지므로 그룹 이름이 용도를 정확히 나타내도록 하세요.

proxy-groups:
  - name: 홍콩 주·예비
    type: fallback
    proxies:
      - 홍콩 주 회선
      - 홍콩 예비 회선
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 싱가포르 주·예비
    type: fallback
    proxies:
      - 싱가포르 주 회선
      - 싱가포르 예비 회선
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 자동 지역
    type: url-test
    proxies:
      - 홍콩 주·예비
      - 싱가포르 주·예비
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 120

  - name: 최종 선택
    type: select
    proxies:
      - 자동 지역
      - 홍콩 주·예비
      - 싱가포르 주·예비
      - DIRECT

전략 그룹 설정 전체 점검 절차

1. 코어, 클라이언트와 설정 필드 확인

Clash 원본, Clash Meta와 이후 mihomo 계열은 기능 범위와 필드 지원에 차이가 있으며, 그래픽 클라이언트마다 전략 그룹 편집 화면도 다를 수 있습니다. 구독에 특정 필드가 있다고 해서 현재 코어가 반드시 지원하는 것은 아닙니다. 설정을 가져온 뒤 코어 시작 로그를 확인해 알 수 없는 필드, 전략 유형 오류 또는 프록시 이름 참조 실패가 없는지 점검하세요.

클라이언트에서 코어를 바꿀 수 있다면 클라이언트 이름만 보고 판단하지 말고 실제로 어떤 코어가 실행 중인지 확인해야 합니다. 일부 클라이언트는 구독을 갱신할 때 설정을 다시 생성하므로 수동으로 수정한 전략 그룹이 덮어써질 수 있습니다. 장기간 사용할 사용자 지정 규칙과 전략은 클라이언트가 지원하는 오버라이드, 확장 설정 또는 설정 병합 기능으로 관리하는 것이 좋습니다.

2. 프록시 이름과 들여쓰기 확인

YAML은 들여쓰기에 민감합니다. 전략 그룹의 proxies 구성원 이름은 프록시 노드 또는 다른 전략 그룹의 이름과 완전히 일치해야 합니다. 중국어, 공백과 기호를 이름에 사용할 수 있지만 복사할 때 불필요한 공백이 들어가지 않도록 주의하세요. 한 그룹이 다른 그룹을 참조한다면 순환 참조도 피해야 합니다.

proxies:
  - name: 노드-A
    type: ss
    server: server.example
    port: 443
    cipher: aes-128-gcm
    password: example-password

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

3. 아이콘이 아니라 상태 확인 결과 검증

클라이언트에 표시되는 지연 시간은 수동 측정 결과일 수도 있고 전략 그룹의 상태 확인 결과일 수도 있으며, 두 측정의 테스트 주소와 시점이 같다는 보장은 없습니다. 노드는 사용 가능으로 표시되지만 웹사이트가 열리지 않는다면 연결 로그를 확인하세요. 어떤 규칙이 어떤 전략 그룹에 일치했는지, 그룹이 실제로 어떤 노드를 선택했는지, 요청 실패가 DNS, 연결 수립 또는 대상 서버 응답 중 어느 단계에서 발생했는지 확인해야 합니다.

모든 구성원이 동시에 시간 초과된다면 먼저 현재 네트워크에서 테스트 URL에 접속할 수 있는지, DNS가 비정상적인 결과를 반환하지 않는지, 시스템 시간이 정확한지, 노드 자체가 연결을 수립할 수 있는지를 확인하세요. 기본 연결 문제를 해결하지 못한 채 interval을 줄여 반복 측정하는 것은 피해야 합니다. 측정 빈도만 높여도 근본적인 연결 문제가 해결되지는 않습니다.

4. 시스템 프록시와 TUN 모드로 검증

전략 그룹은 트래픽이 Clash 코어로 들어온 뒤에만 적용됩니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 애플리케이션을 주로 제어합니다. 시스템 프록시를 읽지 않는 프로그램, 일부 게임과 특정 UDP 트래픽은 규칙 체인에 진입하려면 TUN 모드가 필요할 수 있습니다. 브라우저는 예상대로 노드를 전환하지만 특정 애플리케이션이 계속 직접 연결된다면 전략 그룹을 먼저 수정하지 말고 해당 트래픽이 실제로 인계되고 있는지 확인하세요.

TUN 모드를 활성화한 뒤에는 DNS 모드, 라우팅 제외와 LAN 접근도 확인해야 합니다. 잘못된 DNS 설정은 도메인 규칙이 예상대로 일치하지 않게 만들 수 있고, 라우팅 제외 설정은 대상 트래픽이 코어를 우회하게 할 수 있습니다. 문제를 해결할 때는 명확한 테스트 도메인 하나를 정하고 DNS 확인, 규칙 일치, 전략 그룹 선택, 노드 연결, 대상 응답 순서로 점검하세요.

5. 구독 갱신 후 노드 변화 처리

구독 제공자가 새 노드를 추가하거나 이름을 바꾸고 기존 노드를 삭제할 수 있습니다. 전략 그룹이 구성원을 정적 이름으로 나열한다면 이름이 바뀐 뒤 참조가 끊길 수 있습니다. mihomo 설정에서는 프록시 그룹과 필터 규칙으로 구독 노드를 동적으로 구성할 수도 있지만, “잔여 데이터”, “요금제 정보” 같은 노드가 아닌 항목이 자동 그룹에 포함되지 않도록 필터 표현식을 신중하게 설계해야 합니다.

동적 필터를 사용할 때는 지역과 용도별로 그룹을 나누고 각 그룹의 경계를 명확하게 유지하세요. 예를 들어 저지연 그룹에는 동일한 업무에서 허용되는 지역의 노드만 포함하고, 주·예비 그룹에는 실제로 인계할 수 있는 회선만 넣습니다. 노드 수가 많다고 항상 좋은 것은 아닙니다. 후보 구성원이 너무 많으면 상태 확인 목록이 길어지고 문제 노드를 찾기도 어려워집니다.

안정적인 전략 그룹을 위한 실전 권장 사항

그룹 이름에 판단 로직을 담으세요. “홍콩 주·예비”, “저지연 자동”, “다운로드 균형”은 “프록시 그룹 1”보다 연결 기록을 확인하기 쉽습니다.
속도보다 업무 경계를 먼저 정하세요. 후보 노드가 지역, 계정과 프로토콜 요구 사항을 충족하는지 먼저 확인한 뒤 지연 시간을 비교하거나 연결을 분산하세요.
자동 전환을 위한 여유를 두세요. url-test의 tolerance를 적절히 설정해 작은 지연 변동 때문에 출구가 자주 바뀌지 않도록 하세요.
load-balance를 속도 측정 대신 사용하지 마세요. load-balance는 연결을 분산하는 기능이며 모든 연결을 가장 빠른 노드로 보내지는 않습니다.
실제 선택 결과를 정기적으로 확인하세요. 클라이언트의 연결 화면에서 도메인 규칙, 전략 그룹과 최종 노드가 예상대로 선택되는지 확인하세요.
수정 후 단계별로 테스트하세요. 먼저 노드 단독 사용 가능 여부를 확인하고, 다음으로 상태 확인, 그다음 규칙 일치 여부, 마지막으로 실제 업무를 검증하세요.

요약하면 url-test는 “정상 회선 중 현재 응답이 더 빠른 곳은 어디인가”를 해결하고, fallback은 “주 회선 장애 후 누가 인계할 것인가”를 해결하며, load-balance는 “여러 정상 노드가 연결을 어떻게 나눠 처리할 것인가”를 해결합니다. 업무에 필요한 것이 속도인지, 우선순위인지, 연결 분산인지 먼저 정한 뒤 상태 확인, 전환 임계값과 규칙 진입점을 설정하면 Clash의 자동 라우팅을 명확하고 예측 가능하게 유지할 수 있습니다.