Clash 전략 그룹 url-test·fallback·load-balance 선택법: 옵션과 사용 사례 비교

자동 전략 그룹 3종: 먼저 선택 기준 정하기

Clash 전략 그룹은 새로운 프록시 서버가 아니라 기존 노드 중 하나를 선택하는 설정 계층입니다. 규칙이 요청을 전략 그룹으로 보내면, 그룹에서 사용할 노드를 결정합니다. 설정에 자동 그룹이 있어도 모든 트래픽이 그곳으로 향하는 것은 아닙니다. 규칙이나 상위 선택 그룹에서 해당 그룹을 참조해야 그 요청에 자동 선택이 적용됩니다.

세 유형 모두 상태 확인과 함께 사용할 수 있지만 선택 기준은 서로 다릅니다. url-test는 테스트 지연 시간, fallback은 우선순위, load-balance는 연결 분배에 초점을 둡니다. 일반적인 웹 서핑에는 앞의 두 유형을 먼저 고려하고, 여러 출구로 연결을 나눠야 할 때만 부하 분산을 검토하세요.

전략 그룹 유형	선택 기준	적합한 사용 목적	주요 한계
url-test	테스트 지연 시간과 전환 허용치	비슷한 노드 중 지연 시간이 더 짧은 출구를 자동 선택	지연 시간이 짧다고 다운로드 속도가 빠른 것은 아님
fallback	목록에서 상태가 정상인 첫 번째 노드	주 회선을 우선 사용하고 장애가 나면 예비 회선으로 전환	예비 회선이 더 빠르다는 이유만으로 먼저 선택하지 않음
load-balance	해시 또는 라운드 로빈 방식으로 분배	연결마다 사용 가능한 노드를 다르게 배정	단일 연결의 대역폭을 합산하지 않음

url, interval, lazy: 상태 확인 작동 방식

url은 테스트 대상이며 구독 주소가 아닙니다

url은 상태 확인 요청을 보낼 주소를 지정합니다. 코어는 후보 노드를 통해 해당 주소에 HTTP 요청을 보내고 성공 여부와 소요 시간을 기록합니다. 구독 다운로드 링크도 아니고 대용량 파일 다운로드 속도를 측정하는 주소도 아닙니다. 예시의 https://www.gstatic.com/generate_204는 가벼운 테스트에 자주 쓰이는 엔드포인트지만, 실제 적합성은 회선과 대상 네트워크에 따라 다릅니다.

공정하게 비교하려면 같은 그룹에 동일한 테스트 주소를 사용하세요. 노드에서 테스트 사이트까지 빠르더라도 동영상 사이트나 업무 시스템에 빠르게 접속할 수 있다는 뜻은 아닙니다. 반대로 테스트 도메인이 차단되면 실제로 쓸 수 있는 회선도 비정상으로 표시될 수 있습니다. 문제를 확인할 때는 테스트 실패와 서비스 접속 실패를 따로 검증하세요.

interval 단위는 밀리초가 아닌 초입니다

interval: 300은 300초, 즉 5분 간격으로 상태 확인을 예약한다는 뜻입니다. 요청별 타임아웃을 의미하지 않으며, 장애를 모든 앱이 반드시 300초 안에 감지한다는 보장도 없습니다. 지연 검사 여부, 작업 예약 시점, 검사 소요 시간, 기존 연결 상태에 따라 실제 동작이 달라집니다.

일반적인 웹 서핑이라면 먼저 300초로 설정하고 일정 기간 사용한 뒤 조정하세요.
주 회선의 장애를 더 빨리 감지해야 한다면 60초를 고려할 수 있지만, 검사 요청은 늘어납니다.
노드가 20개이고 60초마다 전체 검사를 한다면 이론상 시간당 약 1,200회 테스트합니다. 300초 간격이면 약 240회이며, 실제 횟수는 지연 검사 등의 기능에 따라 달라집니다.

lazy는 사용하지 않는 그룹도 정기 검사할지 결정합니다

이 필드를 지원하는 코어에서 lazy: true는 사용하지 않는 전략 그룹의 검사 부담을 줄입니다. lazy: false는 유휴 그룹도 주기적으로 검사하도록 합니다. 예비 그룹이 선택되기 전에도 최신 상태를 유지하려면 지연 검사를 끄는 방법을 고려할 수 있지만, 노드와 자동 그룹이 많다면 추가 부하에 유의하세요. 이미 실패한 요청을 자동으로 다시 보내는 기능은 아닙니다.

url-test: 지연 시간이 짧은 노드를 자동 선택하고 tolerance로 전환 조정

url-test는 후보 노드를 테스트한 뒤 결과에 따라 사용할 노드를 자동으로 선택합니다. 같은 용도로 쓸 수 있고 출구가 바뀌어도 괜찮은 경우, 예를 들어 같은 지역의 일반 웹 서핑용 회선 여러 개를 사용할 때 적합합니다. 후보 노드의 지역, 계정 보안 정책 또는 접속 가능한 서비스가 크게 다르다면 지연 시간만 비교하는 것은 적절한 선택 기준이 아닐 수 있습니다.

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

여기에 적은 세 노드 이름은 설정의 proxies에 이미 존재해야 하며 철자까지 정확히 일치해야 합니다. 이 예시는 전략 그룹 일부만 보여 줍니다. 서버 주소, 인증 정보, 전체 규칙이 포함되어 있지 않으므로 그대로 연결할 수 있는 구독 설정으로 사용할 수 없습니다.

tolerance 단위는 밀리초입니다

tolerance: 50은 전환 허용치가 50밀리초라는 뜻으로, 지연 시간이 조금 변할 때 노드가 자주 바뀌는 것을 줄여 줍니다. 예를 들어 현재 노드의 측정값이 120밀리초이고 다른 노드가 100밀리초라면 차이는 20밀리초뿐이므로, 보통 이 정도 차이만으로 전환할 필요는 없습니다. 다른 노드가 60밀리초로 낮아져 60밀리초 개선되면 전환 조건을 충족할 수 있습니다. 이는 설명을 위한 예시이며 실제 측정값이 아닙니다.

허용치는 지연 시간 상한이나 장애 판정 기준이 아닙니다. 값을 50으로 설정해도 50밀리초를 초과하는 노드가 모두 제외되는 것은 아닙니다. 현재 노드를 사용할 수 없는 상황에서 큰 허용치로 해당 노드를 억지로 유지할 수도 없습니다. 구체적인 비교 방식과 최초 선택 동작은 사용 중인 코어의 구현을 확인하세요.

노드가 자주 바뀜: 노드가 반복해서 시간 초과되는지 먼저 확인한 뒤 허용치를 적절히 높여 보세요.
테스트 지연은 짧지만 다운로드가 느림: 실제 서비스 이용 환경에서 처리량, 패킷 손실, 회선 혼잡을 따로 점검하세요.
계정에서 지역 고정이 필요함: 후보 노드를 특정 지역으로 제한하거나 수동 선택을 사용해 지역이 다른 노드가 섞이지 않도록 하세요.

fallback: 주 회선을 우선 사용하고 장애 시 예비 회선으로 전환

fallback은 proxies 목록의 순서대로 사용 가능한 노드를 찾습니다. 첫 번째 노드의 상태가 정상이면 뒤에 있는 노드의 지연 시간이 더 짧더라도 우선 선택되지 않습니다. 주 회선이 더 안정적이고 예비 회선은 비상시에만 쓸 때 적합하며, 언제나 가장 빠른 노드를 선택하는 용도는 아닙니다.

proxy-groups:
  - name: 주·예비 회선
    type: fallback
    proxies:
      - 홍콩 회선 A
      - 일본 회선 A
      - 싱가포르 회선 A
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

이 순서는 홍콩 회선 A를 우선 사용하고, 상태 확인에 실패하면 일본 회선 A를 고려하며, 앞의 두 노드를 모두 사용할 수 없을 때 싱가포르 회선 A를 사용한다는 뜻입니다. 이후 검사에서 우선순위가 높은 노드의 복구가 확인되면 새 연결은 다시 앞쪽의 사용 가능한 노드로 전환될 수 있습니다. 따라서 주 노드가 반복해서 복구됐다가 다시 실패하면 출구가 계속 바뀔 수도 있습니다.

장애 전환이 기존 연결의 이동을 뜻하지는 않습니다

동영상 재생, SSH 세션, 대용량 파일 다운로드는 보통 연결이 이미 설정된 상태입니다. 전략 그룹에서 노드를 바꾸더라도 기존 TCP 연결이 다른 서버로 매끄럽게 이동하지는 않습니다. 기존 연결은 끊길 수 있고 앱에서 다시 연결해야 합니다. 새로 만들어지는 연결부터 변경된 노드 선택이 적용됩니다. 실시간 통화나 원격 터미널에서는 예비 회선으로 복구에 걸리는 시간을 줄일 수 있지만, 연결이 전혀 끊기지 않는다고 보장할 수는 없습니다.

load-balance: 연결을 분배하며 대역폭을 합치지는 않습니다

load-balance는 사용 가능한 노드에 트래픽을 나눠 보냅니다. 여러 연결이 서로 다른 출구를 사용하도록 분산하는 것이 주된 이점이지, 하나의 다운로드 연결에서 두 회선의 속도를 합치는 기능은 아닙니다. 앱에서 동시 다운로드를 지원하더라도 실제 효과는 서버 제한, 분배 방식, 회선 대역폭, 앱의 동작에 따라 달라집니다.

proxy-groups:
  - name: 다중 회선 분배
    type: load-balance
    proxies:
      - 홍콩 회선 A
      - 홍콩 회선 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing: 같은 대상의 출구를 안정적으로 유지

mihomo에서 consistent-hashing은 일반적으로 대상 도메인의 등록 가능 도메인 부분을 기준으로 일관성 해시를 적용합니다. 사용할 도메인이 없으면 대상 IP가 사용될 수 있습니다. 같은 대상이 같은 노드로 연결되는 경향이 있지만, 계정 하나가 출구 하나에 영구적으로 고정된다는 뜻은 아닙니다. 사용 가능한 노드 구성, 대상 도메인, 기타 분배 조건이 바뀌면 결과도 달라질 수 있습니다.

웹페이지 하나를 열어도 로그인, API, 이미지, 정적 리소스 등 여러 도메인에 접속하는 경우가 많습니다. 따라서 같은 웹사이트를 연다고 모든 요청이 자동으로 같은 출구를 사용하는 것은 아닙니다. 로그인 세션, 결제 또는 지역 제한이 중요한 서비스에서는 관련 도메인 규칙을 고정 노드나 관리 가능한 전용 그룹으로 보내는 편이 안전합니다.

round-robin: 새 연결을 순서대로 분배

이 방식을 지원하는 코어에서 strategy를 round-robin으로 설정하면 사용 가능한 후보 노드에 새 연결을 순서대로 배정합니다. 패킷마다 번갈아 보내는 방식은 아니며, 전송량이 균등해진다는 보장도 없습니다. 한 연결은 2GB를 전송하고 다른 연결은 2KB만 전송할 수도 있으므로 연결 수가 비슷해도 트래픽 양은 다를 수 있습니다.

구버전 Clash 코어는 strategy 지원 범위가 다를 수 있으므로 mihomo의 모든 전략 값을 단종된 클라이언트에 그대로 복사하지 마세요. 필드를 인식하지 못하거나 예상과 다르게 동작한다면 먼저 코어 이름과 버전을 확인한 다음 해당 문서를 살펴보세요. GUI에서 설정을 저장할 수 있다는 이유만으로 필드가 적용됐다고 판단해서는 안 됩니다.

자동 그룹을 규칙에 연결하기: select 진입점과 전체 참조 구성

proxy-groups만 추가한다고 기존 규칙이 자동으로 바뀌지는 않습니다. 간편한 방법은 상위에 수동 선택용 select 그룹을 만들고 세 자동 그룹을 선택지로 등록한 뒤, 프록시를 사용할 규칙이 이 진입점을 참조하게 하는 것입니다. 이렇게 하면 규칙을 매번 다시 작성하지 않고 GUI에서 방식을 바꿀 수 있습니다.

proxy-groups:
  - name: 프록시 진입점
    type: select
    proxies:
      - 자동 저지연
      - 주·예비 회선
      - 다중 회선 분배
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,프록시 진입점
  - MATCH,DIRECT

이 부분도 앞서 소개한 자동 그룹과 같은 설정 파일에 병합해야 합니다. example.com은 규칙 문법을 설명하기 위한 도메인이지 테스트 사이트가 아닙니다. 이 규칙은 해당 도메인과 하위 도메인만 프록시 진입점으로 보내고, 나머지 요청은 마지막의 MATCH,DIRECT에 따라 직접 연결합니다. 이 예시를 일반적인 트래픽 분기를 모두 처리하는 완성된 규칙으로 오해하지 마세요.

구독 원본 설정은 보관하고 테스트용 복사본에 전략 그룹을 추가해 구독 업데이트 후 수정 사항이 사라지지 않도록 하세요.
모든 노드 이름, 전략 그룹 이름, 규칙 참조가 일치하는지 확인하세요. 대소문자, 공백, 한글까지 정확히 같아야 합니다.
전체 설정에는 최상위 proxy-groups와 rules를 각각 하나씩만 두고, 항목을 해당 목록에 병합하세요. 최상위 키를 중복해서 붙여 넣지 마세요.
Clash for Windows의 Profiles에서 테스트 설정을 선택한 다음 Proxies에서 Rule 모드로 전환하고 ‘프록시 진입점’을 펼쳐 테스트할 자동 그룹을 선택하세요.
Global 모드에서는 전역 전략이 트래픽을 처리하므로 기존 규칙 참조에 따라 경로가 결정되지 않습니다. Direct 모드에서도 일상적인 규칙 분기에서 자동 그룹이 작동하는지 확인할 수 없습니다.

수정 사항을 계속 유지하려면 사용 중인 클라이언트가 지원하는 오버라이드, Mixin 또는 설정 병합 기능을 사용하고 최종 실행 설정을 확인하세요. 클라이언트마다 배열을 교체하거나 병합하는 방식이 다를 수 있으므로 몇 줄을 추가하면 구독의 기존 그룹이 모두 유지된다고 가정해서는 안 됩니다.

자동 전략 그룹이 작동하지 않을 때: 4단계 점검

1단계: 코어가 설정을 받아들였는지 확인

Logs에서 YAML 파싱 실패, 노드 없음, 지원하지 않는 전략 값이 표시되는지 확인하세요. YAML 들여쓰기에는 공백을 사용하고 Tab은 사용하지 마세요. proxies 아래의 각 항목은 같은 위치에 맞춰야 합니다. 노드 이름에 콜론 뒤 공백 등 특수한 조합이 있다면 이름 전체를 따옴표로 감싸는 편이 안전합니다.

2단계: 노드와 테스트 주소를 따로 확인

먼저 노드 하나를 수동으로 선택해 실제 대상에 접속한 다음 그룹 내 지연 시간을 테스트하세요. 특정 테스트 주소만 실패한다면 모든 노드를 바로 삭제하지 말고 해당 주소에 접속할 수 있는지, HTTPS 핸드셰이크가 정상인지 확인하세요. 노드 자체에 연결할 수 없다면 tolerance를 조정하거나 부하 분산 알고리즘을 바꿔도 인증, 서버, 네트워크 장애는 해결되지 않습니다.

3단계: 요청에 실제 적용된 전략 확인

Connections에서 새 요청의 규칙과 프록시 체인을 확인해 대상 그룹을 실제로 거치는지 점검하세요. 요청이 앞에 있는 직접 연결 규칙에 해당하거나 앱이 클라이언트를 거치지 않는다면 자동 그룹은 작동하지 않습니다. 브라우저에서는 프록시가 되지만 다른 앱에서는 안 된다면 시스템 프록시, 앱별 프록시 설정 또는 TUN 처리 범위도 확인하세요. 전략 그룹만으로는 트래픽을 클라이언트에 전달하는 설정을 대신할 수 없습니다.

4단계: 새 연결로 변경 사항 확인

그룹을 전환하거나 검사가 끝날 때까지 기다린 다음 새 요청을 보내세요. 기존 연결만 계속 살펴보지 않도록 주의합니다. fallback을 테스트할 때는 통제된 환경에서 주 노드에 일시적으로 접속할 수 없게 하고 검사 시각, 최초 실패 시각, 복구 시각을 기록하세요. url-test는 한 번만 비교하지 말고 여러 차례 지연 시간을 기록하세요. load-balance는 기존 연결을 재사용할 수 있는 페이지를 한 번 새로 고치는 데 그치지 말고 여러 연결의 프록시 체인을 확인하세요.

일반 웹 서핑: 같은 지역의 노드와 url-test를 사용하고, 검사 간격 300초와 허용치 50밀리초부터 평가해 보세요.
주 회선 고정: fallback을 사용해 업무 우선순위에 따라 노드를 정렬하고 주 회선 복구 후 동작도 확인하세요.
연결이 많은 작업: 출구가 바뀌어도 괜찮은지 확인한 뒤 load-balance를 사용하고 해시와 라운드 로빈을 각각 검증하세요.
중요한 세션: 노드를 고정하거나 전용 선택 그룹을 우선 사용하고, 출구 안정성을 자동 지연 시간 비교에만 맡기지 마세요.

전략 그룹을 고를 때 중요한 것은 어느 쪽이 더 ‘고급’인지가 아니라 지연 시간, 주·예비 순서, 연결 분배 중 무엇을 최적화할지입니다. 후보 노드를 먼저 한정하고 검사 옵션을 설정한 다음 실제 서비스에서 검증하는 편이 검사 간격을 계속 줄이는 것보다 효과적입니다.