Clash 전략 그룹 url-test·fallback·load-balance 비교 및 설정 방법

자동 전략 그룹 3가지: 지연 시간·우선순위·연결 분배 기준

proxy-groups는 프록시 서버 자체가 아니라 출구 선택 방식을 정의합니다. 노드는 보통 proxies 또는 proxy-providers에서 가져옵니다. 규칙이 전략 그룹에 적용된 뒤에야 그룹이 사용할 출구를 결정합니다. 설정에 그룹 이름만 추가하고 규칙에서 참조하지 않으면 실제 트래픽 경로는 바뀌지 않습니다.

먼저 클라이언트에서 실제로 사용하는 코어와 버전을 확인하세요. Clash GUI 클라이언트는 조작 인터페이스이며, 해당 필드를 해석하는 것은 Clash 원본 코어와 이후 계보인 Clash Meta의 mihomo입니다. 아래 전체 설정은 mihomo 기준입니다. 구형 코어는 확장 필드와 부하 분산 알고리즘 지원이 다를 수 있으므로 시작 로그와 해당 버전 문서를 확인하세요.

유형	선택 기준	사용 조건	주요 제한 사항
`url-test`	지연 시간 측정 및 전환 허용 범위	응답 속도가 빠른 출구를 자동으로 선택하려는 경우	측정 지연 시간은 다운로드 처리량을 나타내지 않습니다
`fallback`	목록 순서와 상태 확인 결과	주 회선을 고정하고 장애 시 예비 회선 사용	목록 뒤쪽 노드가 더 빨라도 선택되지 않을 수 있습니다
`load-balance`	알고리즘에 따라 새 연결을 분배	사용 가능한 여러 출구에 연결을 분산	여러 노드의 대역폭을 하나의 연결에 합칠 수 없습니다

url-test: interval과 tolerance의 관계

url-test는 후보 노드로 지정된 url에 접속해 결과를 기록하고, 이를 바탕으로 출구를 선택합니다. 측정값은 해당 테스트 주소에 요청했을 때의 응답 시간으로, 프록시 경로와 대상 서버의 응답에 영향을 받습니다. ICMP ping이나 동영상 사이트·파일 서버의 전체 성능 테스트와는 다릅니다.

세 매개변수의 단위부터 확인

url: 상태 확인 요청 주소입니다. 응답 데이터가 적고 안정적이며 후보 노드에서 접속할 수 있는 HTTPS 주소를 선택하세요. 예를 들면 204를 반환하는 테스트 엔드포인트가 적합합니다.
interval: 300: 주기적인 확인 간격이며 단위는 초입니다. 약 5분마다 확인한다는 뜻으로, 300밀리초나 연결 시간 제한을 의미하지 않습니다.
tolerance: 50: 전환 허용 범위이며 단위는 밀리초입니다. 지연 시간이 조금 흔들릴 때 노선이 자주 바뀌는 것을 줄여 줍니다. 패킷 손실률이나 허용 가능한 최대 지연 시간이 아닙니다.

예를 들어 현재 노드의 최근 측정값이 105ms이고 다른 노드가 80ms라면 차이는 25ms입니다. 허용 범위를 50ms로 설정했다면 이 정도 차이만으로 바로 전환될 것으로 기대해서는 안 됩니다. 현재 노드가 155ms로 올라가고 다른 노드는 80ms를 유지하면 차이가 75ms가 되어 전환 가능성이 커집니다. 이는 tolerance의 작동 방식을 설명하기 위한 계산 예시이며, 실제 측정 결과가 아닙니다. 최종 선택은 해당 시점의 코어 상태와 구현 방식에 따라 달라집니다.

확인 주기가 장애 복구 시간을 보장하지는 않습니다

interval을 300에서 60으로 낮추면 확인 횟수는 늘지만, 장애 발생 후 60초 안에 모든 서비스가 복구된다는 보장은 없습니다. 상태 확인 요청에도 시간이 걸리고 기존 연결은 시간 초과를 기다릴 수 있습니다. 후보 노드가 많을수록 주기적인 요청도 늘어납니다. 일반적인 사용은 300초부터 시작하고 로그를 살펴 조정하세요.

mihomo의 lazy 설정은 사용하지 않는 전략 그룹의 주기적 확인 방식에 영향을 줍니다. 문제를 진단할 때 false로 명시하면 “그룹을 사용하지 않아 계속 확인되지 않는” 상황을 배제하는 데 도움이 됩니다. 노드가 provider에서 온다면 provider의 health-check 설정도 별도로 확인하세요. provider 확인과 그룹 단위 측정을 같은 타이머로 보면 안 됩니다.

fallback: 목록 우선순위에 따라 사용 가능한 출구 선택

fallback은 후보 목록에서 앞쪽에 있는 사용 가능한 노드를 선택합니다. 목록에 “노드-A”, “노드-B” 순서로 있고 A의 상태 확인이 정상이라면, A가 180ms이고 B가 60ms여도 A를 사용할 것으로 예상해야 합니다. 더 빠른 노드를 우선하려면 url-test를 선택하세요. 확인 간격을 바꿔도 해결되지 않습니다.

일상적으로 사용할 주 회선을 proxies의 첫 번째 항목에 두고, 예비 회선을 뒤에 차례로 배치하세요.
모든 후보 노드에서 접속할 수 있는 확인 주소를 사용하세요. 대상 사이트의 접속 제한을 노드 장애로 잘못 판단하지 않도록 주의해야 합니다.
설정을 다시 불러온 다음 프록시 페이지에서 그룹 내 순서를 확인하고, 확인을 한 번 수동으로 실행하세요.
주 노드의 서비스를 잠시 중단하고 이후 새 연결이 예비 노드로 전환되는지 확인하세요. 테스트가 끝나면 서비스를 복구합니다.

주 노드가 다시 사용 가능하다고 판정되면 우선순위에 따라 목록 앞쪽 노드가 다시 선택됩니다. 이 동작은 “주 회선 우선, 장애 시 예비 회선”에 적합하지만 이미 연결된 TCP 연결까지 옮기지는 않습니다. 웹 페이지의 짧은 요청은 보통 새로 연결되지만 다운로드, SSH, 동영상처럼 오래 유지되는 연결은 애플리케이션에서 다시 시도해야 할 수 있습니다.

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

load-balance는 사용 가능한 후보 출구에 알고리즘에 따라 연결을 분배합니다. mihomo에서는 strategy로 알고리즘을 지정할 수 있습니다. 아래 예시는 consistent-hashing을 사용합니다. 로그인, 결제, 세션 유지가 필요한 서비스는 균등 분배보다 출구의 안정성이 중요합니다. 먼저 일관성 해시를 사용하거나 해당 도메인을 고정 노드로 보내는 편이 적합합니다.

strategy 값	용도	확인할 점
`consistent-hashing`	대상과 관련된 정보를 기준으로 비교적 안정적으로 연결	같은 서비스는 같은 출구를 사용하는 경향이 있지만 노드 변경 시 매핑이 달라질 수 있습니다
`round-robin`	새 연결을 순환 방식으로 분배	같은 사이트의 여러 연결이 서로 다른 출구를 사용할 수 있습니다

구체적인 해시 입력값, 도메인 처리 방식, 추가 알고리즘 지원 여부는 코어 구현에 따라 다릅니다. “일관성 해시”가 공인 IP를 영구 고정한다는 뜻은 아닙니다. 노드의 추가·제거, 설정 다시 불러오기, 후보 목록 변경에 따라 매핑이 달라질 수 있습니다. 서비스가 고정 출구에 크게 의존한다면 규칙을 별도로 작성해 수동 선택 그룹으로 보내는 편이 더 확실합니다.

예를 들어 브라우저가 동시에 10개의 연결을 만들면 순환 알고리즘에 따라 각 연결이 서로 다른 노드로 분배될 수 있습니다. 이미 연결된 TCP 연결 하나는 계속 하나의 출구를 사용합니다. HTTP/2나 HTTP/3는 연결을 재사용할 수도 있으므로 웹 페이지를 새로고침해도 새로 분배되지 않을 수 있습니다. 부하 분산을 확인할 때는 연결 기록에 표시된 전략 경로와 실제 노드를 살펴보세요. 같은 IP 조회 페이지를 연달아 새로고침하는 것만으로는 확인하기 어렵습니다.

전체 YAML 예시: 세 그룹을 나란히 두고 바깥에서 수동 선택

아래는 mihomo에서 설정 구조를 검증할 수 있는 전체 예시입니다. select 그룹을 공통 진입점으로 삼고, 내부에서 저지연·주 회선/예비 회선·균등 분산 방식을 선택할 수 있습니다. 두 노드에는 문서 예시용 주소인 192.0.2.10과 192.0.2.11을 사용했으므로 실제 프록시에는 연결되지 않습니다. 사용 전에는 노드 정의 전체를 서비스 제공자가 안내한 프로토콜, 주소, 포트, 인증 정보로 바꿔야 합니다.

config.yaml · mihomo 설정 예시

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: 노드-A
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"
  - name: 노드-B
    type: ss
    server: 192.0.2.11
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - 자동 저지연
      - 주 회선/예비 회선 전환
      - 연결 분산
      - 노드-A
      - 노드-B
      - DIRECT

  - name: 자동 저지연
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 주 회선/예비 회선 전환
    type: fallback
    proxies:
      - 노드-A
      - 노드-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 연결 분산
    type: load-balance
    proxies:
      - 노드-A
      - 노드-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,출구 선택

규칙은 위에서 아래 순서로 적용됩니다. 예시에서는 example.com과 그 하위 도메인은 직접 연결하고 나머지 트래픽은 “출구 선택”으로 보냅니다. 이는 규칙 예시일 뿐, 완전한 국내외 분기 설정은 아닙니다. mixed-port: 7890은 HTTP와 SOCKS를 함께 사용할 수 있는 포트를 제공합니다. 시스템 프록시 설정 여부는 클라이언트나 운영체제 설정에 따라 달라집니다.

구독 provider를 사용하는 경우의 설정 방법

기존 설정에 “구독 노드”라는 이름의 proxy-providers가 이미 정의되어 있다면, 아래 그룹으로 정적 후보 설정을 바꿀 수 있습니다. use는 provider 이름을 참조하고, proxies는 노드나 전략 그룹 이름을 참조합니다. 두 항목은 서로 다른 이름 공간을 사용합니다. 이 코드는 기존 provider 정의에 의존하므로 단독으로 실행할 수 있는 전체 설정은 아닙니다.

proxy-groups 코드 조각 · 기존 provider 참조

proxy-groups:
  - name: 자동 저지연
    type: url-test
    use:
      - 구독 노드
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

원격 구독을 업데이트할 때 덮어써지는 임시 설정을 직접 수정하지 마세요. 클라이언트에서 재정의, 병합 또는 확장 설정 기능을 제공한다면 해당 기능에 사용자 지정 그룹을 저장하세요. 구체적인 메뉴 위치는 클라이언트 버전별로 확인해야 합니다. 수정 후 구독을 한 번 업데이트하고 그룹과 규칙이 그대로 남아 있는지 확인하면 설정이 제대로 유지되는지 검증할 수 있습니다.

중첩 구성: 지역별 지연 시간 측정, 지역 간 주 회선/예비 회선 전환

더 세밀하게 구성하려면 지역별로 독립적인 url-test 그룹을 만든 다음, 바깥쪽 fallback에서 지역 우선순위에 따라 각 그룹을 참조하면 됩니다. 예를 들어 “주 지역 측정”에는 주 지역 노드만, “예비 지역 측정”에는 예비 지역 노드만 넣고 바깥쪽 목록에서는 주 지역을 앞에 둡니다. 이렇게 하면 지역 내부에서는 지연 시간을 고려하고 지역 간에는 서비스 우선순위를 유지할 수 있습니다.

바깥 그룹은 이미 정의된 그룹 이름만 참조할 수 있습니다. 그룹 자신을 후보 목록에 넣거나 A가 B를 참조하고 B가 다시 A를 참조하는 순환 구조를 만들지 마세요.
바깥 그룹에서 보는 것은 안쪽 그룹이 현재 선택한 경로입니다. 모든 노드를 펼쳐 다시 비교한다고 가정하면 안 됩니다.
안쪽과 바깥쪽 그룹은 각각 확인 주기를 가집니다. 복구 과정에서 여러 차례 갱신될 수 있으니 먼저 한 단계로 테스트한 뒤 두 번째 단계를 추가하세요.
로그인에 민감한 서비스는 고정 노드나 select 그룹으로 따로 보내세요. 대량 다운로드와 같은 부하 분산 정책을 공유할 필요는 없습니다.

일반 웹 탐색에서 자동으로 출구를 고르는 것이 목적이라면 예시의 “바깥쪽 select + 안쪽 url-test”만으로 충분한 경우가 많습니다. 중첩 단계가 늘수록 연결 기록을 추적하기 어려워집니다. 지역, 비용 또는 주 회선/예비 회선 우선순위가 실제로 다를 때만 단계를 추가하세요.

흔한 설정 오류와 확인 방법

증상	먼저 확인할 항목	해결 방법
저지연 그룹에서 노선이 바뀌지 않음	현재 지연 시간 차이, tolerance, 최근 확인 시각	한 번 수동으로 확인한 뒤 규칙이 해당 그룹에 적용되는지 확인
주 회선/예비 회선 그룹에서 계속 느린 노드를 사용	목록 순서와 상태 확인 결과	목록 순서를 우선하는 방식입니다. 지연 시간 우선이라면 url-test를 사용하세요
모든 노드에서 동시에 시간 초과가 발생	확인 주소, 기기 DNS, 시스템 시간을 점검	전략 유형만 바꾸지 말고 먼저 단일 노드에서 같은 테스트 엔드포인트에 접속되는지 확인
설정에서 프록시를 찾을 수 없다는 알림이 표시됨	그룹 이름, 노드 이름, provider 이름, 들여쓰기	참조 이름을 하나씩 대조하고 YAML 들여쓰기에 Tab 대신 공백을 사용
전환 후에도 기존 다운로드에 문제가 있음	기존 연결을 계속 재사용 중인지 확인	해당 서비스 연결을 새로 만들고, 필요하면 관련 연결 기록만 종료
구독 업데이트 후 사용자 지정 그룹이 사라짐	원본 설정과 임시 설정 중 어느 쪽을 수정했는지 확인	클라이언트가 지원하는 영구 재정의 방식으로 저장

실제 적용 결과를 네 단계로 확인

먼저 설정을 검증합니다: 클라이언트의 설정 검사 기능을 사용하세요. mihomo를 직접 실행한다면 mihomo -t -f config.yaml을 실행할 수 있습니다. 검사를 통과해도 설정을 해석할 수 있다는 뜻일 뿐, 노드 인증 정보나 네트워크가 정상이라는 보장은 없습니다.
그다음 설정을 다시 불러옵니다: 설정 페이지에서 수정한 설정을 활성화하고 로그에 알 수 없는 필드, 중복 이름, 존재하지 않는 참조가 표시되는지 확인하세요. 기존 설정에 병합할 때 같은 수준의 proxy-groups나 rules 키를 중복으로 만들지 마세요.
규칙 경로를 확인합니다: Rule 모드에서 새 요청을 한 번 보내고 연결 페이지에서 적용된 규칙, 바깥 그룹, 안쪽 그룹, 최종 노드를 확인하세요. Global 또는 Direct 모드에서는 확인하려는 규칙 진입 경로를 거치지 않을 수 있습니다.
마지막으로 실제 서비스를 테스트합니다: 웹 페이지 접속, 대상 서비스 로그인, 실제 다운로드를 각각 확인하세요. 테스트 시각, 출구 노드, 측정 지연 시간을 기록한 다음 300초 간격이나 50ms 허용 범위를 조정할지 결정하세요.

선택 기준은 세 가지 질문으로 정리할 수 있습니다. 낮은 지연 시간에 맞춰 자동으로 전환하려면 url-test, 주 회선을 고정하고 장애 시 예비 회선을 사용하려면 fallback, 여러 출구에 새 연결을 나누려면 load-balance를 선택하세요. 요구 사항을 먼저 정하면 모든 전략을 여러 겹으로 쌓는 것보다 설정을 검증하고 관리하기 쉽습니다.