Clash 프록시 그룹 url-test·fallback·load-balance 차이와 설정법

전환 방식부터 고르고 proxy-groups 설정하기

응답이 빠른 노드를 자동으로 선택하려면 url-test, 주 회선을 유지하다 장애가 발생했을 때만 예비 회선으로 전환하려면 fallback, 여러 연결을 여러 노드에 분산하려면 load-balance를 사용하세요. 세 방식 모두 상태 점검을 활용하지만, ‘자동 선택’의 기준은 서로 다릅니다.

클라이언트는 구독을 불러오고 프록시 그룹과 설정을 표시하며, 실제 선택 로직은 코어가 처리합니다. Clash와 Clash Meta(현 mihomo)는 기본 필드가 비슷하지만 확장 필드와 지원 정책은 다를 수 있습니다. 이 문서의 예제는 mihomo 기준입니다. 저장하기 전에 클라이언트의 코어 정보나 시작 로그에서 실행 중인 코어를 확인하고 설정 검사로 필드를 검증하세요.

유형	선택 기준	주요 용도	주요 제한 사항
`url-test`	테스트 URL의 응답 시간과 전환 허용 오차를 기준으로 선택	일반 웹 브라우징, 지연 시간이 짧은 회선 자동 선택	지연 시간 측정값은 다운로드 대역폭과 다름
`fallback`	목록 순서에 따라 상태가 정상인 첫 번째 후보 선택	주 회선과 예비 회선 구성, 주로 사용하는 출구 지역 유지	장애 감지 시점은 점검 주기의 영향을 받음
`load-balance`	분배 알고리즘에 따라 상태가 정상인 후보 선택	여러 목적지와 연결을 여러 노드에 분산	단일 연결의 대역폭을 합산하지 않음

url-test: 지연 시간에 따라 선택하고 tolerance로 잦은 전환 방지

url-test는 각 후보 노드로 같은 테스트 주소에 접속한 뒤 상태 점검 결과를 바탕으로 응답이 빠른 노드를 선택합니다. 측정값에는 프록시 경로를 통해 테스트 서버에 접속하는 데 걸리는 시간이 포함됩니다. 프록시 서버에 ICMP ping을 보내는 것도 아니고, 테스트 파일의 다운로드 속도를 측정하는 것도 아닙니다.

최소 설정과 옵션 단위

proxy-groups:
  - name: 지연 시간 자동 선택
    type: url-test
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url: 상태 점검 대상입니다. 예제 주소는 보통 HTTP 204를 반환합니다. 용량이 작고 안정적이며 후보 노드로 접속할 수 있는 HTTPS 주소를 선택하세요.
interval: 300: 점검 간격은 300초, 즉 5분입니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용 오차는 50밀리초입니다. 지연 시간 차이가 아주 작을 때 출구가 자주 바뀌는 것을 방지합니다.
lazy: true: 지연 점검을 활성화합니다. 사용하지 않는 그룹의 주기적 테스트를 줄일 수 있습니다. 처음 활성화할 때나 수동 속도 측정 시, 또는 코어가 점검을 예약할 때는 테스트가 실행될 수 있습니다.

허용 오차는 고정된 지연 시간 상한이 아닙니다

예를 들어 한 번의 측정에서 현재 노드가 120ms, 다른 노드가 95ms라면 차이는 25ms입니다. 허용 오차를 50ms로 설정하면 이 정도 차이만으로는 보통 전환되지 않습니다. 다른 노드의 지연 시간이 60ms로 내려가 차이가 60ms가 되면 전환 조건을 충족할 수 있습니다. 이는 옵션을 설명하기 위한 가정이며, 이 사이트에서 측정한 결과가 아닙니다. 실제 선택은 노드 상태와 코어 구현에도 영향을 받습니다.

tolerance를 ‘50ms를 넘으면 사용할 수 없다’는 뜻으로 이해하지 마세요. 이 값은 전환 시 두 노드 간 지연 시간 차이를 기준으로 하며, 모든 노드에 적용되는 50ms 합격선을 뜻하지 않습니다. 지역 간 전환이 잦다면 점검 간격을 5초로 줄이기보다 허용 오차를 20ms에서 50ms로 높여 변화를 살펴보세요.

fallback: 순서대로 주 회선을 유지하고 장애 시 예비 회선 선택

fallback의 핵심은 지연 시간이 아니라 순서입니다. 목록에서 상태가 정상인 첫 번째 노드를 우선 사용하고, 해당 노드에 장애가 생기면 다음으로 정상인 노드를 선택합니다. 주 노드가 다시 정상 상태가 되면 이후에는 보통 주 노드를 다시 우선 고려합니다.

proxy-groups:
  - name: 주 회선·예비 회선 전환
    type: fallback
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

이 예제에서 ‘일본 예비’의 지연 시간이 70ms이고 ‘홍콩 일반용’은 150ms여도, 홍콩 노드가 정상이라면 주 회선·예비 회선 그룹은 홍콩 노드를 우선 사용합니다. 따라서 지역을 유지해야 하거나 트래픽 비용이 적절한 노드를 앞에 두고, 다른 지역의 예비 노드는 뒤에 배치하세요.

장애 전환이 무중단 연결 이전을 뜻하지는 않습니다

주기 점검 사이에는 상태가 실제와 다를 수 있습니다. 점검 간격이 300초라고 해서 장애 발생을 즉시 감지하는 것은 아니며, 복구 시간을 보장하는 것도 아닙니다.
그룹 전환은 주로 이후에 생성되는 새 연결에 영향을 줍니다. 기존 TCP 연결의 서버 측 세션을 다른 출구로 그대로 옮길 수는 없으므로 동영상 재생, SSH, 다운로드 작업은 다시 연결해야 할 수 있습니다.
여기서 말하는 fallback은 요청이 실패할 때마다 같은 요청을 즉시 다른 노드로 재시도하는 애플리케이션 계층의 재시도 기능이 아닙니다.
lazy: false로 설정하면 사용하지 않는 그룹도 주기적으로 계속 점검합니다. 상태를 더 최신으로 유지할 수 있지만 테스트 요청이 늘고 모바일 기기의 화면이 켜질 수 있습니다.

서비스 이용 시 출구 지역을 유지해야 한다면 주·예비 후보를 가능한 한 같은 지역에 두세요. 테스트 주소에 접속할 수 있다는 것은 해당 점검 요청이 성공했다는 뜻일 뿐입니다. 모든 서비스 도메인에 접속할 수 있거나 두 노드에서 같은 콘텐츠를 이용할 수 있다는 보장은 없습니다.

load-balance: 연결을 분산하되 단일 연결의 속도는 합산하지 않음

load-balance는 상태가 정상인 후보들에 연결을 분산합니다. 여러 회선을 묶는 기능이 아니며, 하나의 TCP 다운로드 연결을 세 갈래로 나눠 세 노드를 동시에 사용하지도 않습니다. 여러 개의 독립된 연결이나 여러 대상에 트래픽을 분산할 때 효과가 있으며, 단일 다운로드 속도가 노드 수만큼 빨라지는 것은 아닙니다.

proxy-groups:
  - name: 여러 출구로 분산
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

consistent-hashing과 round-robin 중 무엇을 선택할까

방식	동작	주의 사항
`consistent-hashing`	대상 정보를 바탕으로 일관된 해시를 계산해 같은 대상이 같은 출구를 사용하도록 합니다	후보 목록이나 노드 상태가 바뀌면 일부 대상의 출구가 다시 배정될 수 있습니다
`round-robin`	새 연결을 후보 노드에 순서대로 배정합니다	같은 서비스의 연결마다 서로 다른 출구 IP를 사용할 수 있습니다

일반 웹 브라우징에는 우선 consistent-hashing을 사용해 보세요. 같은 대상의 출구가 계속 바뀔 가능성을 줄여 주지만, 계정 단위로 세션을 고정하는 기능은 아닙니다. 하나의 서비스가 여러 도메인에 접속할 수 있고, 후보 노드에 장애가 생기면 출구가 다시 배정될 수도 있습니다. 로그인이나 결제, 고정된 원본 IP가 필요한 관리자 페이지에는 별도 규칙을 만들어 수동 선택 그룹이나 안정적인 주·예비 그룹으로 보내는 편이 좋습니다.

라운드 로빈은 트래픽 바이트가 아니라 연결을 분배합니다. 세 노드가 각각 여러 연결을 맡더라도, 특정 연결 하나에서 다운로드가 오래 지속되면 노드별 사용량에 큰 차이가 날 수 있습니다. 이 기본 예제에는 가중치 설정이 없습니다. 노드의 요금 배수가 0.5배, 1배, 2배여도 부하 분산 기능이 이를 비용 가중치로 자동 반영하지 않습니다.

통합 예제: 수동 선택 경로를 유지하고 규칙에서 그룹 지정

아래 예제에서는 세 가지 자동 그룹을 하나의 select 그룹에 넣습니다. 설정을 적용하면 클라이언트의 프록시 그룹 화면에서 ‘프록시 출구’를 선택한 뒤 지연 시간 자동 선택, 주 회선·예비 회선 전환, 여러 출구로 분산 중 하나를 고르거나 노드를 직접 지정할 수 있습니다. 문제를 진단할 때 자동 정책을 우회해 개별 노드가 정상인지 확인할 수 있습니다.

proxy-groups:
  - name: 프록시 출구
    type: select
    proxies:
      - 지연 시간 자동 선택
      - 주 회선·예비 회선 전환
      - 여러 출구로 분산
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비

  - name: 지연 시간 자동 선택
    type: url-test
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 주 회선·예비 회선 전환
    type: fallback
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

  - name: 여러 출구로 분산
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 홍콩 일반용
      - 일본 예비
      - 싱가포르 예비
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

rules:
  - MATCH,프록시 출구

마지막 MATCH는 규칙과 그룹 이름의 관계를 보여 주기 위한 예시입니다. 실제 설정에서는 기존 LAN, 직접 연결, 서비스별 분기 규칙을 유지하고 기본 처리 규칙을 맨 끝에 두세요. 이 한 줄로 모든 규칙을 바꾸면 직접 연결해야 하는 트래픽도 프록시 출구로 들어갑니다.

구독에서 proxy-providers를 사용한다면 use로 참조

노드를 기존 proxy-providers에서 가져온다면 그룹 안에 노드 이름을 하나씩 직접 적지 않아도 됩니다. 설정에 회선 구독이라는 제공자가 정의되어 있다고 가정하면 다음과 같이 참조할 수 있습니다.

proxy-groups:
  - name: 제공자 자동 선택
    type: url-test
    use:
      - 회선 구독
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

use는 제공자 이름을 참조하고 proxies는 노드나 그룹 이름을 참조하므로 서로 바꿔 쓸 수 없습니다. 제공자 업데이트 간격은 노드 목록을 가져오는 시점을 정하고, 상태 점검 간격은 노드의 연결 가능 여부를 확인하는 시점을 정합니다. 점검 간격을 60초로 바꿔도 구독 목록이 60초마다 업데이트되지는 않습니다.

제공자 자체에 health-check가 설정되어 있을 수도 있습니다. 그룹과 제공자의 점검은 코어가 예약하므로 두 간격을 단순히 더해 장애 전환 시간을 계산할 수 없습니다. 설정을 관리할 때는 정기 점검을 담당하는 곳을 명확히 하고, 여러 제공자와 프록시 그룹에 지나치게 짧은 주기를 설정해 불필요한 요청이 늘지 않도록 하세요.

검증 및 문제 해결: 실제 출구를 확인한 다음 테스트 옵션 조정

먼저 YAML 형식과 노드 참조를 확인하세요

현재 정상적으로 작동하는 설정을 백업하세요. 구독 업데이트로 덮어써질 임시 파일을 직접 수정하지 말고, 영구 오버라이드나 병합 설정 메뉴에서 프록시 그룹을 변경하세요.
들여쓰기에는 공백을 사용하고 Tab은 사용하지 마세요. 그룹 이름은 고유하게 지정하고 규칙에 적은 이름과 그룹 이름을 정확히 일치시키세요. 그룹끼리 순환 참조가 생겨서도 안 됩니다.
명령줄 코어가 PATH에 등록되어 있다면 mihomo -t -f ./config.yaml을 실행해 설정을 검사하세요. 상대 경로는 실제 파일 위치에 맞게 조정해야 합니다.
설정을 다시 불러오고 상태 점검을 한 번 수동 실행한 뒤 프록시 그룹의 후보 상태를 확인하세요. 설정 검사를 통과해도 노드 연결이 정상이라는 뜻은 아닙니다.

프록시 연결을 명시해 새 연결을 확인하세요

현재 설정의 HTTP 또는 혼합 프록시 포트가 실제로 7890이라면 아래 명령으로 테스트할 수 있습니다. 이 포트는 검증을 위한 예시이며 모든 클라이언트에서 고정으로 사용하는 값이 아닙니다. 먼저 포트 설정이나 설정 파일의 mixed-port 값을 확인하세요.

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://cp.cloudflare.com/generate_204

프록시를 명시적으로 지정하면 터미널이 시스템 프록시 설정을 읽는지에 의존하지 않고 명령을 실행할 수 있습니다. HTTP 204 응답을 받으면 해당 테스트 경로가 작동하는지 확인할 수 있습니다. 클라이언트의 연결 기록에서도 적용된 규칙, 프록시 그룹, 실제 노드를 확인하세요. 서비스 이용 가능 여부를 판단하려면 실제 서비스에 새로 연결해야 합니다. 테스트 주소에 접속됐다는 이유만으로 결론을 내리지 마세요.

자주 발생하는 문제와 해결 순서

모든 노드에서 시간 초과가 발생함: 먼저 연결 가능한 것으로 확인된 노드를 하나 수동으로 선택하세요. 서비스에는 접속되지만 테스트가 실패한다면 테스트 도메인, DNS, 해당 주소에 대한 연결 가능성을 확인하세요. 곧바로 모든 노드를 삭제하지 마세요.
url-test가 계속 노드를 바꿈: 먼저 테스트 주소가 안정적인지 확인한 뒤 허용 오차를 늘리세요. 300초를 10초로 줄이면 단기적인 변동이 커지고 배터리 소모가 늘어날 수 있습니다.
fallback이 가장 빠른 노드를 선택하지 않음: 상태가 정상인 노드를 순서대로 선택하는 것이 정상 동작입니다. 지연 시간을 비교하려면 url-test로 바꾸세요. 속도 측정 순서를 흉내 내려고 예비 노드 목록을 조정할 필요는 없습니다.
load-balance에서 트래픽이 고르게 분배되지 않음: 오래 유지되는 연결이 몇 개뿐인지, 여러 요청이 같은 대상에 집중되는지 확인하세요. 일관된 해시와 연결 라운드 로빈 모두 노드별 바이트 사용량이 같다고 보장하지 않습니다.
그룹이 전환됐지만 페이지에는 이전 출구가 표시됨: 새 연결을 만들어 확인하세요. 브라우저의 연결 재사용, 진행 중인 다운로드, 장시간 연결은 기존 노드를 계속 사용할 수 있습니다. 연결을 닫으면 작업이 중단되므로 괜찮은 시점에 진행하세요.
구독 업데이트 후 설정이 사라짐: 사용자 지정 정책을 클라이언트에서 지원하는 영구 오버라이드 방식으로 옮긴 다음, 편집기의 설정 조각만 확인하지 말고 병합이 끝난 최종 설정을 확인하세요.