Clash 프록시 그룹 url-test·fallback·load-balance 비교와 YAML 설정법

세 가지 프록시 그룹, 어떤 걸 선택할까?

지연 시간이 짧은 출구를 자동으로 선택하려면 url-test, 주 회선과 백업 회선의 순서를 고정하려면 fallback, 여러 연결을 여러 출구에 분산하려면 load-balance를 사용하세요. 세 가지 모두 프록시 그룹이지 프록시 프로토콜이 아니며, 새 노드를 만들지도 않습니다. 그룹에는 이미 등록된 프록시 노드나 호환되는 프록시 그룹을 지정해야 합니다.

Clash는 규칙 기반 프록시 코어와 클라이언트 생태계를 통칭할 때 흔히 쓰이는 이름이며, Clash Meta는 이후 mihomo라는 이름으로 개발되고 있습니다. 클라이언트의 외관이 비슷하더라도 같은 코어를 사용한다고 볼 수는 없습니다. 이 문서의 YAML 예제는 mihomo를 기준으로 합니다. 구형 Clash 코어는 선택 필드나 부하 분산 알고리즘을 지원하지 않을 수 있으므로 실제 코어 문서와 설정 검사 결과를 확인하세요.

유형	선택 기준	사용 사례	주요 제한 사항
`url-test`	측정 결과와 전환 허용 범위	일상적인 웹 탐색에서 지연 시간이 짧은 노드를 자동 선택	측정된 지연 시간은 다운로드 대역폭을 의미하지 않음
`fallback`	목록에서 우선순위가 가장 높은 사용 가능한 구성원	주 회선을 우선 사용하고 장애 발생 시 백업 회선으로 전환	주 회선이 느려도 사용 가능한 상태라면 대체로 전환하지 않음
`load-balance`	사용 가능한 구성원과 지정된 분배 알고리즘	여러 대상 또는 연결을 여러 출구로 분산	단일 연결의 대역폭을 합산하는 방식이 아님

url-test: 측정된 지연 시간에 따라 경로 선택

url-test는 각 구성원으로 지정된 URL에 접속해 결과를 기록한 뒤, 이를 바탕으로 출구를 선택합니다. 노드 품질이 시간에 따라 달라지고 매번 수동으로 전환하고 싶지 않을 때 적합합니다. 측정값은 탐색 대상에 요청을 한 번 보내는 데 걸린 시간이며, 로컬에서 노드 서버까지의 단순 ICMP 지연 시간은 아닙니다.

interval과 tolerance는 단위가 다릅니다

interval: 300: 자동 상태 확인 간격은 300초, 즉 5분입니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용 범위는 50밀리초입니다. 지연 시간이 조금 흔들릴 때 반복해서 전환되는 것을 줄이기 위한 값이지, 탐색 제한 시간이 아닙니다.
url: 상태 확인에 사용할 HTTP 또는 HTTPS 주소입니다. 안정적으로 응답하고, 응답 내용이 작으며, 모든 구성원이 접속할 수 있는 주소를 선택하세요.
lazy: false: 지연 검사를 끄고 설정을 확인하는 동안 검사 결과를 계속 살펴볼 수 있습니다. 노드가 많으면 백그라운드 탐색 요청이 늘어납니다.

예를 들어 현재 출구의 측정값이 120밀리초이고 다른 구성원이 95밀리초라면 개선 폭은 25밀리초입니다. 허용 범위가 50밀리초라면 즉시 전환을 기대하기 어렵습니다. 다른 구성원의 측정값이 60밀리초라면 개선 폭은 60밀리초로 허용 범위를 넘습니다. 이 예시는 매개변수 간 관계를 설명하기 위한 것으로, 실제 측정 결과가 아닙니다. 실제 선택은 구성원의 가용성, 검사 완료 시점, 코어 구현 방식에도 영향을 받습니다.

안정성을 높이겠다고 허용 범위를 지나치게 크게 설정하지 마세요. 예를 들어 500밀리초로 설정하면 지연 시간 차이가 상당해도 전환되지 않을 수 있습니다. 먼저 interval: 300과 tolerance: 50으로 동작을 확인한 뒤 네트워크 변동 폭에 맞게 조정하세요. 동영상 버퍼링이나 다운로드 속도 저하가 발생하면 패널에 표시된 최저 수치만 보지 말고 패킷 손실, 대역폭, 대상 사이트까지의 경로도 점검해야 합니다.

fallback: 목록 순서대로 주 회선과 백업 회선 전환

fallback은 목록에서 앞쪽에 있고 정상 상태인 구성원을 선택합니다. 목록 순서가 곧 우선순위입니다. 첫 번째 구성원을 사용할 수 있으면 우선 사용하고, 사용할 수 없을 때 두 번째 구성원을 고려합니다. 최저 지연 시간을 목표로 하지 않으며 tolerance 필드도 필요하지 않습니다.

평소 우선 사용할 노드를 proxies의 첫 번째 항목에 배치하세요.
백업 노드는 우선순위에 따라 나열하고, 모든 구성원이 같은 장애 회선에 의존하지 않도록 구성하세요.
모든 구성원에 같은 탐색 URL을 사용하고, 먼저 간격을 300초로 설정해 가용성을 확인하세요.
주 노드가 복구되어 정상 상태로 확인되면 이후 연결은 다시 주 노드를 우선 사용할 수 있습니다.

첫 번째 항목의 측정값이 180밀리초이고 두 번째 항목이 80밀리초라고 가정해 보겠습니다. 첫 번째 항목이 여전히 사용 가능한 상태라면 fallback은 두 번째 항목이 더 빠르다는 이유만으로 전환하지 않습니다. 주 회선으로 탐색 주소에는 접속할 수 있지만 실제 업무 사이트가 느린 경우에도 그룹은 주 회선을 계속 선택할 수 있습니다.

load-balance: 알고리즘에 따라 연결 분배

load-balance는 서로 다른 연결을 그룹 안의 사용 가능한 구성원에 분배합니다. 동시 요청이 여러 개이고 요청마다 다른 출구를 사용해도 되는 경우에 적합합니다. 세 회선에 각각 대역폭이 있다고 해서 단일 다운로드 연결이 세 회선의 대역폭을 모두 합쳐 사용할 수 있는 것은 아닙니다.

mihomo에서 자주 쓰는 분배 알고리즘

strategy 값	주요 동작	사용 시 참고 사항
`consistent-hashing`	대상 주소 관련 정보를 바탕으로 일관된 해시 방식으로 분배	같은 대상에 안정적으로 같은 출구를 사용할 수 있지만 구성원이 바뀌면 매핑이 달라질 수 있음
`round-robin`	새 연결마다 사용 가능한 구성원을 순서대로 선택	같은 사이트의 연결마다 서로 다른 공인 IP를 사용할 수 있음
`sticky-sessions`	출발지와 대상 정보를 바탕으로 일정 시간 동안 동일한 구성원에 연결을 고정	코어 지원 여부를 확인해야 하며 계정별 고정 출구를 보장하지 않음

예제에서는 consistent-hashing을 사용합니다. 대상 그룹을 나누는 방식은 도메인 정보를 확인할 수 있는지 등의 조건에 따라 달라지므로, “계정 하나에 노드 하나가 영구적으로 배정된다”는 뜻은 아닙니다. 출구 IP가 중요한 결제, 관리자 로그인, 기업 인증 업무에는 고정 노드를 사용하거나 수동 선택 그룹을 별도로 구성하세요.

round-robin은 연결을 분배할 때 순환하는 방식이지, 하나의 TCP 연결에서 발생하는 패킷을 여러 노드로 나눠 보내는 방식이 아닙니다. 브라우저가 HTTP/2 연결을 재사용할 수 있으므로 페이지를 몇 번 새로고침해도 공인 IP가 정확히 번갈아 바뀌지 않을 수 있습니다. 분배 동작을 확인하려면 클라이언트 연결 기록을 살펴보고, 서로 독립된 새 연결을 여러 개 생성하세요.

proxy-groups 설정 예제

아래는 mihomo 설정에 병합할 수 있는 프록시 그룹 조각입니다. 설정의 proxies에 “香港01”, “日本01”, “新加坡01”이라는 이름의 노드가 이미 있어야 합니다. 이 세 이름을 실제 노드 이름으로 바꾸고, 노드에 설정된 서버, 프로토콜, 인증 필드는 그대로 유지하세요.

proxy-groups:
  - name: 출구 선택
    type: select
    proxies:
      - 자동 속도 측정
      - 장애 전환
      - 출구 분산
      - DIRECT

  - name: 자동 속도 측정
    type: url-test
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 장애 전환
    type: fallback
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 출구 분산
    type: load-balance
    proxies:
      - 香港01
      - 日本01
      - 新加坡01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

여기서 generate_204 주소는 상태 확인에만 사용하며, 구독 링크나 노드 서버가 아닙니다. 일반적으로 이 주소는 HTTP 204를 반환합니다. 사용 중인 네트워크나 출구에서 안정적으로 접속할 수 없다면 가볍고 접근이 확인된 다른 탐색 주소로 바꾸세요. 로그인이 필요하거나 복잡한 리디렉션이 발생하거나 응답이 큰 웹페이지는 피하세요.

업무 규칙을 프록시 그룹에 연결

그룹을 정의한 뒤에는 규칙에서 해당 그룹을 참조해야 합니다. 아래는 규칙 문법 예시이며 기존 규칙 전체를 덮어쓰라는 뜻은 아닙니다. 기존 LAN, 직접 연결, 업무별 분기 규칙은 유지하고 최종 기본 규칙은 맨 마지막에 배치하세요.

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

example.com은 규칙 문법을 보여 주기 위한 예시 도메인입니다. 실제로는 트래픽을 분기할 업무 도메인으로 바꾸세요. MATCH는 앞선 규칙에 일치하지 않은 연결을 모두 처리하므로 세부 규칙보다 먼저 배치하면 안 됩니다. 클라이언트에서 규칙 모드를 사용한 다음 “출구 선택”에서 “자동 속도 측정”, “장애 전환” 또는 “출구 분산”을 선택해야 해당 정책이 트래픽 처리에 적용됩니다.

구독과 provider 병합 시 확인할 사항

proxy-providers로 노드를 불러오는 경우 프록시 그룹은 일반적으로 제공자 이름을 proxies에 넣는 대신 use로 참조합니다. 두 항목은 서로 다른 이름 공간입니다. 아래 예시는 기존 설정에 “订阅节点”이라는 provider가 정의되어 있다고 가정합니다.

proxy-groups:
  - name: 구독 자동 속도 측정
    type: url-test
    use:
      - 订阅节点
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

이 조각에는 provider의 다운로드 주소, 캐시 경로, 업데이트 설정이 포함되어 있지 않으므로 단독으로 완전한 설정이 될 수 없습니다. 기존 구독에 사용 가능한 프록시 그룹이 있다면 먼저 해당 그룹의 동작을 확인하고, 같은 그룹을 새로 만들 필요는 없습니다. 수십 개의 노드를 여러 자동 그룹에 한꺼번에 넣으면 탐색 요청이 늘고 문제를 찾기 어려워질 수 있습니다.

provider의 health-check.interval과 프록시 그룹의 interval은 서로 다른 위치의 설정입니다. 한쪽만 바꾸고 모든 검사 주기가 바뀌었다고 판단하지 마세요. 실제 탐색 구성과 재사용 방식은 코어 구현에 따라 다릅니다. 문제를 확인할 때는 provider와 프록시 그룹 설정을 모두 살펴보고 실제 로그를 기준으로 판단하세요.

구독을 업데이트하면 직접 편집한 설정 파일이 덮어써질 수 있습니다. 사용자 지정 그룹을 계속 유지하려면 클라이언트에서 지원하는 재정의, 병합 또는 확장 설정 기능을 사용하세요. 클라이언트마다 메뉴 이름과 위치가 다르므로 먼저 “구독” 또는 “설정” 페이지에서 현재 설정의 작업 메뉴를 열고, 편집 중인 파일이 영구 재정의 파일인지 다운로드된 임시 설정인지 확인하세요.

설정 검증과 문제 해결

측정값만 보지 말고 순서대로 확인하세요

현재 설정을 백업하세요. 정상 작동하는 설정 사본을 보관하고 현재 코어 이름을 기록하세요. 명령줄로 배포한 경우 mihomo -v를 실행해 버전 정보를 확인할 수 있습니다.
문법과 참조를 확인하세요. 명령줄 환경에서는 mihomo -t -f ./config.yaml을 실행할 수 있습니다. 설정이 상대 경로 리소스에 의존한다면 실제 실행 디렉터리와 환경에서 검사하세요.
설정을 다시 불러오세요. 클라이언트의 설정 다시 불러오기 기능을 사용하거나 배포 방식에 따라 코어를 재시작하세요. 파일을 저장하는 것만으로는 실행 중인 설정이 바뀌지 않을 수 있습니다.
상태 검사를 실행하세요. 프록시 그룹 페이지에서 속도 측정을 실행해 구성원 하나 이상을 사용할 수 있는지 확인하세요. 첫 검사가 끝나기 전에는 이전 지연 시간만 보고 선택 결과를 판단하지 마세요.
규칙 적용 여부를 확인하세요. 연결 기록에서 대상 도메인, 일치한 규칙, 프록시 정책 경로, 최종 노드를 확인해 트래픽이 새 프록시 그룹을 실제로 거치는지 살펴보세요.
새 연결을 만들어 다시 확인하세요. 테스트 애플리케이션의 기존 연결을 종료한 뒤 다시 시도하세요. 같은 장기 연결 페이지를 새로고침하는 데 그치지 말고 검사 상태, 정책 선택, 실제 서비스 접속 결과를 비교하세요.

자주 발생하는 증상과 원인

프록시를 찾을 수 없다는 메시지가 표시됨: 노드 이름이 정확히 일치하는지 확인하세요. 공백, 대소문자, 구독 업데이트 후 변경된 이름을 특히 살펴보세요. provider를 사용하는 경우 use 참조도 확인하세요.
자동 속도 측정 그룹이 전환되지 않음: 현재 모드와 규칙이 해당 그룹에 적용되는지, 지연 시간 차이가 tolerance를 초과하는지 확인하세요. 사용 중인 출구와 이름만 비슷한 다른 그룹을 혼동하지 마세요.
모든 구성원에서 시간 초과가 표시됨: 먼저 노드 하나를 개별적으로 테스트한 뒤 탐색 URL, DNS, 네트워크 연결을 확인하세요. 공통 탐색 대상에 장애가 발생하면 정상 회선 여러 개가 동시에 비정상으로 판정될 수 있습니다.
fallback이 계속 첫 번째 항목을 사용함: 첫 번째 항목이 정상이라면 목록 순서를 우선하는 동작에 맞는 결과입니다. 지연 시간이 더 짧은 노드를 원한다면 url-test를 사용하세요.
load-balance 사용 후 로그인 상태에 문제가 생김: 순환 분배를 사용 중인지, 서비스가 출구 IP에 민감한지 확인하세요. 분배 알고리즘을 계속 바꾸기보다 해당 서비스의 트래픽만 고정 노드로 보내는 편이 간단합니다.
구독 업데이트 후 사용자 지정 그룹이 사라짐: 업데이트로 덮어쓰이는 파일에 변경 사항을 저장했는지 확인하고, 지속적으로 유지할 수정 사항은 클라이언트에서 지원하는 재정의 기능으로 옮기세요.

마지막으로 사용 목적에 맞게 설정을 정리하세요. 일상적인 웹 탐색에는 url-test, 주 회선과 백업 회선의 순서를 고정하려면 fallback, 여러 연결을 분산해야 할 때만 load-balance를 사용하세요. 규칙이나 DNS를 더 조정하기 전에 설정 파일 참고 문서를 확인할 수 있습니다. 설치와 설정 가져오기 방법은 클라이언트 설정 가이드를 참고하세요.