Clash 전략 그룹 설정 가이드: url-test·fallback·load-balance

필요에 맞는 전략 그룹 선택하기

노드를 직접 고르려면 select, 지연 시간이 짧은 노드를 자동으로 고르려면 url-test를 사용하세요. 고정 노드를 우선 사용하고 장애가 발생했을 때만 예비 노드로 전환하려면 fallback, 여러 노드에 연결을 분산하려면 load-balance가 적합합니다. 네 가지 방식은 해결하려는 문제가 서로 다르므로, 이름에 ‘자동’이 들어가는지만 보고 선택하면 안 됩니다.

전략 그룹은 노드나 다른 전략 그룹을 묶은 것입니다. 규칙이 먼저 트래픽을 어느 그룹으로 보낼지 정하고, 그룹이 실제로 사용할 출구를 선택합니다. 예를 들어 MATCH,출구 선택은 앞선 규칙에 걸리지 않은 연결을 ‘출구 선택’ 그룹으로 보낸다는 뜻입니다. 이 규칙은 속도 측정 명령이 아니며 모든 규칙이 자동으로 이 그룹을 사용하게 만들지도 않습니다.

유형	선택 기준	적합한 용도	주의 사항
`select`	사용자가 직접 선택	고정 지역 출구, 수동 문제 해결	일반 수동 선택 그룹은 선택한 노드에 장애가 생겨도 자동으로 전환하지 않습니다
`url-test`	측정 결과와 지연 시간 차이	일상적으로 지연 시간이 짧은 출구 자동 선택	측정 지연 시간은 다운로드 대역폭과 다릅니다
`fallback`	목록 순서와 사용 가능 상태	주 회선과 예비 회선 구성	예비 회선의 속도가 더 빨라도 선택되지 않을 수 있습니다
`load-balance`	분배 알고리즘과 사용 가능 상태	여러 출구에 연결 분산	단일 다운로드 연결의 대역폭을 합산하지 않습니다

설정 전에 코어와 노드 이름 확인하기

클라이언트는 화면을 제공하고, 코어는 설정을 실행합니다. 화면 구성이 비슷한 클라이언트라도 포함된 코어는 다를 수 있습니다. 먼저 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 Clash 호환 코어를 사용하는지 mihomo를 사용하는지 확인한 다음, 해당 버전의 설정 문서를 확인하세요. 아래 예제는 일반적인 Clash 전략 그룹 필드를 사용하며, 로드 밸런싱 예제는 mihomo에서 지원하는 consistent-hashing 전략을 명시적으로 사용합니다.

현재 설정 파일과 클라이언트에서 별도로 저장하는 오버라이드 설정을 백업하세요. 오버라이드는 구독 원본 설정에 필드를 추가하거나 수정하는 방식입니다.
현재 proxies에 사용 가능한 노드가 있는지 확인하고 이름을 그대로 복사하세요. 공백, 대소문자, 기호까지 정확히 일치해야 합니다.
노드가 proxy-providers에서 제공된다면 그룹 안에서 use로 해당 제공자를 참조하세요. 제공자 이름을 노드처럼 proxies에 적으면 안 됩니다.
클라이언트에서 로컬 설정 또는 오버라이드 메뉴를 찾으세요. 구독 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다.

select: 하나의 진입점에서 직접 전환

select 자체는 지연 시간을 비교하지 않습니다. 후보를 화면에 표시하고 사용자가 선택하도록 합니다. 후보에는 실제 노드뿐 아니라 자동 속도 측정 그룹이나 장애 전환 그룹 같은 다른 그룹도 넣을 수 있습니다. 따라서 가장 실용적인 구성은 바깥쪽에서 직접 선택하고 안쪽에서 자동으로 처리하는 방식입니다.

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - 자동 속도 측정
      - 장애 전환
      - 연결 분산
      - 홍콩 주 회선
      - 일본 예비 회선
      - 싱가포르 예비 회선

이 코드에서 참조하는 하위 그룹 세 개는 뒤에서 정의합니다. 실제로 사용할 때는 네 그룹의 항목을 하나의 최상위 proxy-groups 아래에 합치세요. YAML 파일에 같은 최상위 키를 여러 번 추가하지 마세요. 중복 키는 파싱 오류를 일으키거나 앞선 설정을 뒤의 설정으로 덮어쓸 수 있습니다.

처음 불러올 때는 일반적으로 목록의 첫 항목을 사용하지만, 클라이언트가 이전에 저장한 선택을 복원할 수도 있습니다. 목록 순서를 바꾼 뒤에도 전략 그룹 화면에서 현재 선택된 항목을 확인하세요. 문제를 진단할 때는 하위 그룹 중첩의 영향을 배제할 수 있도록 실제 노드를 임시로 선택해 보세요.

url-test: 자동 속도 측정과 tolerance의 역할

url-test는 후보 노드로 지정된 테스트 주소에 접속하고, 측정 결과를 바탕으로 출구를 선택합니다. 비교 대상은 해당 테스트 주소에 요청했을 때 걸리는 시간이지, 모든 웹사이트에서의 종합 성능이 아닙니다. 테스트 주소에 빠르게 접속하는 노드라도 동영상 사이트, 게임 서버, 대용량 파일 다운로드에서는 성능이 평범할 수 있습니다.

  - name: 자동 속도 측정
    type: url-test
    proxies:
      - 홍콩 주 회선
      - 일본 예비 회선
      - 싱가포르 예비 회선
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval은 초 단위, tolerance는 밀리초 단위입니다

interval: 300: 정기 측정 간격을 300초, 즉 5분으로 설정합니다. 300밀리초마다 노드를 바꾼다는 뜻이 아닙니다.
tolerance: 50: 자동 선택에 50밀리초의 전환 허용 범위를 둡니다. 노드 간 지연 시간 차이가 미미할 때 잦은 전환을 방지합니다.
lazy: false: 그룹을 최근에 사용했는지와 관계없이 정기 측정을 수행합니다. 유휴 상태에서도 네트워크 활동이 늘어나므로, 필요에 따라 모바일에서는 true로 바꿀 수 있습니다.

허용 범위를 가상의 수치로 살펴보겠습니다. 현재 노드의 지연 시간이 120밀리초이고 다른 노드는 100밀리초라면, 20밀리초만 빠르므로 허용 범위를 50밀리초로 설정했을 때는 보통 현재 노드를 유지합니다. 다른 노드가 60밀리초까지 낮아져 60밀리초 앞서면 전환될 수 있습니다. 이는 작동 방식을 설명하기 위한 예시이며 실제 회선 측정 결과나 성능 보장이 아닙니다. 실제 선택은 측정 성공 여부, 이전 상태, 코어 구현에도 좌우됩니다.

허용 범위는 시간 초과를 뜻하지 않습니다. 현재 노드의 측정이 실패했을 때 ‘50밀리초가 더 지날 때까지 기다린 뒤 전환한다’고 이해하면 안 됩니다. 모바일에서는 우선 간격 300초, 허용 범위 50밀리초로 시작해 상태를 살펴보세요. 간격을 5초로 줄이면 측정 횟수는 크게 늘지만 서비스 연결이 더 안정적이라고 보장할 수는 없습니다.

fallback: 우선순위에 따른 장애 전환

fallback은 목록 순서대로 사용 가능한 노드를 찾습니다. 가장 빠른 노드를 계속 고르는 것이 아니라 우선 회선을 유지하는 것이 목적입니다. 아래 설정은 먼저 ‘홍콩 주 회선’을 시도하고, 사용할 수 없다고 판단될 때만 ‘일본 예비 회선’을 고려하며, 그다음에 ‘싱가포르 예비 회선’을 시도합니다.

  - name: 장애 전환
    type: fallback
    proxies:
      - 홍콩 주 회선
      - 일본 예비 회선
      - 싱가포르 예비 회선
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

주 회선의 측정 지연 시간이 180밀리초이고 예비 회선은 80밀리초라고 가정해도, 주 회선이 계속 사용 가능하다고 판단되는 한 보통 주 회선을 사용합니다. 주 회선이 복구되고 이후 측정에서 상태가 확인되면 그룹은 다시 주 회선을 우선합니다. 따라서 출구 지역을 고정해야 하거나 계정 로그인 환경이 중요한 경우에는 지연 시간이 가장 짧은 노드만 쫓기보다 장애 전환 방식을 사용하는 편이 관리하기 쉽습니다.

또한 ‘테스트 주소에 접속할 수 있음’은 해당 측정이 성공했다는 뜻일 뿐입니다. 노드가 테스트 주소에는 접속할 수 있지만 실제 서비스에는 접속하지 못해도 그룹은 노드를 사용 가능하다고 판단할 수 있습니다. 이 경우 측정 간격만 줄이지 말고 대상 서비스의 지역 제한, DNS 확인 결과, 규칙 적용 여부를 살펴보세요.

load-balance: 연결 분산이지 대역폭 합산이 아닙니다

load-balance는 알고리즘에 따라 여러 연결을 후보 노드에 분산합니다. 아래 예제에서는 일관성 해시 전략인 consistent-hashing을 사용합니다. 대상 정보를 기준으로 같은 유형의 대상이 가능한 한 안정적인 출구를 사용하도록 합니다. mihomo에서는 일반적으로 대상 도메인의 등록 가능 도메인 등의 정보를 기준으로 매핑하며, 자세한 작동 방식은 실제 코어 버전에 따라 다를 수 있습니다.

  - name: 연결 분산
    type: load-balance
    proxies:
      - 홍콩 주 회선
      - 일본 예비 회선
      - 싱가포르 예비 회선
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

또 다른 일반적인 옵션은 라운드 로빈 방식으로 분배하는 round-robin입니다. 새 연결이 생길 때마다 순환 방식으로 출구를 선택하며, 이미 연결된 세션에서 데이터를 조금 보낼 때마다 노드를 바꾸는 것은 아닙니다. 로그인 상태를 안정적으로 유지해야 하는 웹사이트에서 여러 연결이 서로 다른 지역의 출구를 사용하면 추가 인증이 발생할 수 있으므로, 모든 트래픽에 무조건 적용하는 것은 피하는 편이 좋습니다.

파일 하나를 다운로드할 때 TCP 연결 하나만 사용한다면, 그룹에 노드가 세 개 있다고 해서 속도가 자동으로 세 배가 되지는 않습니다.
서로 독립된 여러 다운로드나 대상이 다른 연결은 여러 노드에 분산될 수 있지만, 바이트 수가 균등하게 나뉜다는 보장은 없습니다.
여러 노드가 결국 제한된 동일한 상위 회선을 공유한다면, 연결을 분산해도 그 회선의 병목을 넘어설 수 없습니다.
UDP가 정상 작동하는지는 실제 노드 프로토콜, 서버 기능, 트래픽 가로채기 방식에도 좌우되므로 그룹 유형만으로 판단할 수 없습니다.

규칙에서 전략 그룹 사용하기

전략 그룹을 정의한 뒤에는 규칙을 통해 연결을 해당 그룹으로 보내야 합니다. 아래에는 기존 규칙 구성에서 위치를 파악할 수 있도록 두 가지 규칙만 표시했습니다. 도메인 예시인 example.com은 특정 트래픽을 분기하는 방법을 설명하기 위한 것이며, 실제 서비스 요건을 나타내지 않습니다.

rules:
  - DOMAIN-SUFFIX,example.com,장애 전환
  - MATCH,출구 선택

규칙은 위에서 아래로 확인하며, 일치하는 항목을 찾으면 보통 그 뒤의 규칙은 확인하지 않습니다. 특정 도메인 규칙은 최종 MATCH보다 앞에 두세요. 기존 설정에 규칙 세트, LAN 직접 연결, 지역별 분기가 있다면 유지하고 실제로 바꿔야 하는 전략 대상만 수정하세요. 전략 그룹 하나를 시험하려고 전체 규칙을 위 두 줄로 줄이지 마세요.

클라이언트가 규칙 모드로 실행 중인지도 확인하세요. 전역 모드는 전역 전략을 사용하고, 직접 연결 모드에서는 위 규칙에 따라 프록시 출구를 선택하지 않습니다. Android의 VpnService나 데스크톱의 TUN으로 트래픽을 가로채더라도 네 가지 그룹의 기본 경로 선택 방식은 바뀌지 않습니다. TUN은 트래픽을 가로채는 방식이지 다섯 번째 속도 측정 알고리즘이 아닙니다.

설정 불러오기, 검증 및 문제 해결

먼저 문법을 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭은 사용하지 마세요. 네 그룹은 모두 하나의 proxy-groups 목록 아래에 있어야 하며, 그룹 이름이 중복되어서는 안 됩니다.
설정을 다시 불러오세요. 클라이언트의 설정 화면에서 수정한 설정을 활성화하고, 노드를 찾을 수 없음, 그룹 참조가 유효하지 않음, 지원하지 않는 필드 등의 오류가 표시되는지 확인하세요.
수동으로 한 번 테스트하세요. 전략 그룹 화면에서 지연 시간 측정을 실행하고 노드 세 개 각각의 결과가 나오는지 확인하세요. 화면에 표시된 결과가 그룹의 측정 결과인지, 구독 제공자의 별도 상태 점검 결과인지도 살펴보세요.
규칙이 적용되는지 확인하세요. 연결 기록에서 대상 도메인, 일치한 규칙, 최종 노드를 확인하세요. ‘출구 선택’이 선택된 것만으로는 최종적으로 어느 하위 그룹 구성원이 사용됐는지 알 수 없습니다.
원상 복구할 수 있는 장애 테스트를 하세요. 테스트 설정에서만 주 회선을 임시로 제거한 뒤 설정을 다시 불러오고 새 연결을 만들어 예비 회선이 작동하는지 살펴보세요. 테스트가 끝나면 원래 설정으로 복구하고, 장애를 흉내 내기 위해 운영 서버 설정을 수정하지 마세요.

설정 업데이트 후 전략 그룹이 원래대로 돌아갑니다

먼저 구독 업데이트가 로컬 변경 사항을 덮어쓰는지 확인하세요. 사용자 지정 전략은 클라이언트가 지원하는 오버라이드 또는 병합 방식에 넣고, 추가·교체·스크립트 처리 중 어떤 방식으로 병합되는지도 확인하세요. 같은 이름의 전략 그룹을 처리하는 방식은 클라이언트마다 다릅니다. ‘저장 성공’만으로 최종 설정이 올바르다고 판단하지 말고 실제 실행 중인 설정을 확인하세요.

지연 시간은 정상인데 웹페이지가 열리지 않습니다

먼저 select에서 사용 가능한 노드 하나를 직접 지정하고 연결 로그를 확인하세요. 대상 도메인이 잘못해서 직접 연결로 분류됐다면 전략 그룹의 측정 설정을 바꿔도 해결되지 않습니다. 테스트 주소는 정상인데 실제 서비스 연결이 실패한다면 DNS, 서비스 지역 제한, 프로토콜 지원 여부를 확인하세요. Wi-Fi와 모바일 네트워크를 전환한 뒤에는 다시 테스트하세요. 이전 측정 결과는 새 네트워크의 상태를 반영하지 않습니다.

여러 그룹이 동시에 속도를 측정해 휴대전화 배터리가 더 빨리 닳습니다

자동 그룹 세 개가 각각 노드 세 개를 포함하고 300초마다 측정한다면, 각 그룹이 따로 실행될 경우 한 주기에 최대 아홉 번 측정할 수 있습니다. 제공자 자체의 상태 점검이 추가로 실행될 수도 있습니다. 이는 요청 횟수를 단순화해 계산한 것으로, 코어에서 측정을 예약하거나 재사용할 수 있으므로 이 수치만으로 배터리 소모량을 추산할 수는 없습니다. 모바일에서는 보통 주 자동 전략 하나만 두면 충분합니다. 유휴 그룹에는 lazy: true를 고려하고, 제공자 상태 점검 주기도 지나치게 짧게 설정하지 마세요.

일상적인 구성은 간단하게 시작해도 됩니다. 바깥쪽 select로 직접 선택하는 기능을 유지하고, 안쪽에는 url-test나 fallback 중 하나만 두세요. 여러 노드에 서비스 연결을 분산해야 할 때 로드 밸런싱 그룹을 별도로 추가하면 됩니다. 여러 전략을 한꺼번에 겹쳐 쓰기보다 먼저 규칙과 노드가 정상인지 확인한 뒤 측정 설정을 조정하는 편이 문제를 찾기 쉽습니다.