이 글을 읽으면 좋은 분

Clash 규칙(rules)으로 도메인·지역이 어디로 가야 하는지는 이미 맞췄는데, 같은 프록시 슬롯(예: PROXY·Proxy·사용자 정의 전략명)에 묶인 여러 아웃바운드(노드) 가운데 어떤 것을 쓸지 매번 손으로 고르기 싫다는 경우가 이 글의 출발입니다. Clash 전략 그룹의 type: url-test 는 주기적으로 url 을 요청해 RTT(왕복 지연)를 비교해 가장 짧은 쪽을 골라 주고, type: fallback 은 proxies 목록을 위에서 아래로 보면서 연결·헬스 실패에 따라 다음 후보(예비)로 넘깁니다. 「도메인을 어떤 전략 그룹 이름으로 보낼지」는 rules 층이고, 지금 층은 그 안에서 실제로 어느 아웃바운드로 나갈지를 지연과 장애 신호에 맞춰 자동으로 고릅니다. proxy-groups 의 이름·타입·interval 이 곧 자동 절체의 스위치이며, 주·부 는 설명을 위해 우선(대표)·차순(예비) 으로 읽으면 됩니다. 코어(Clash Meta/Mihomo) 문서의 필드명과 맞췄습니다.

select·url-test·load-balance·fallback을 한 문장씩

select 는 사용자(또는 API)가 지금 쓸 자식을 골라 고정하는 수동 층이고, url-test 는 대상 노드에 대해 같은 URL로 측정을 돌리며, 조건(공차·최고 지연 등) 안에서 가장 유리한 한 줄로 붙이는 지연 측정 자동 층입니다. load-balance (지원·구현은 클라이언트/코어에 따름)는 흐름을 여러 백엔드에 흩뿌릴 때 쓰는 패턴이고, 장애 대비 1+1 이미지로 가장 맞는 것이 fallback 입니다. fallback 은 “첫 후보가 정상이면 그대로, 연속 실패 시 아래로” 흐르는 순서형 백업이며, url-test 는 “누가 가장 낮은 핑(지연)인가” 쪽에 가깝습니다. 둘 다 rules 끝의 …,GROUP_NAME 이 가리킨 그룹이 내부에서 최종 아웃바운드를 정합니다.

최소 YAML: proxy-groups 뼈대 (예시)

아래는 자식으로 쓰인 SERVER_A·SERVER_B·REJECT 등이, 같은 파일의 proxies: 에 이미 이름으로 정의돼 있다는 전제의 스케치입니다. 집이나 팀에 맞게 이름·노드만 바꾸세요. 주석은 읽기용으로 넣은 것이고, 실제 저장 시에는 쓰지 않는 편이 안전합니다.

# proxy-groups fragment — group names in rules must match these names
proxy-groups:
  - name: PROXY_AUTO_LATENCY
    type: url-test
    proxies:
      - SERVER_A
      - SERVER_B
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

  - name: PROXY_FAILOVER
    type: fallback
    proxies:
      - SERVER_A
      - SERVER_B
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

여기서 url·interval 는 url-test·fallback 이 “건강·지연”을 잴 때 쓰는 프로브에 해당합니다. PROXY_AUTO_LATENCY 는 300초마다 자식을 치고, 지연이 50ms 이내로 비슷하면 굳이 갈아타지 않게 하려는 식의 tolerance 를 쓰는 예이며, lazy: true 는 (지원하는 빌드에서) 실제로 트래픽이 있을 때 측정을 더 적극적으로 돌릴지 등의 동작과 연결될 수 있으니, GUI에 같은 스위치가 있으면 설명을 함께 읽는 것이 좋습니다. PROXY_FAILOVER 쪽 proxies 순서가 곧 주(위)·부(아래)이며, DIRECT 를 맨끝에 두면 “둘 다 아니면 잠깐 직행” 같은 탈출구로 쓰는 팀이 있습니다. API·결제 같이 세션이 끊기면 안 되는 흐름에 fallback 을 짧은 간격·공격적 실패 시 전환으로 쓰면, 서비스 측에서 다른 IP·지역으로 찍혀 rate limit 이 날 수 있으니, API 예시 글에서 말한 것처럼 진단 구간에서는 먼저 select 로 한 노드를 고정해 재현을 잡는 편이 안전합니다.

흔히 쓰는 키: interval, tolerance, url

url 은 응답이 가벼우면서(204 등)·HTTPS로 안정적으로 열리는 쪽을 골랐다는 뜻이지, “내가 쓰는 YouTube/게임 서버”와 같은 PoP·peer 를 보장하지는 않습니다. 그래서 프로브 RTT 가 좋아도, 실서비스 호스트는 여전히 막힌 일이 생깁니다. 확인 은 애플리케이션이 쓰는 FQDN이 실제로 그룹을 타는지, 코어/클라이언트 연결 로그에 찍힌 체인(그룹 → 최종 outbounds) 으로 맞추는 것이 중요합니다. interval 은 너무 짧으면 불필요한 갈아탐·배터리·CPU가 늘고, 너무 길면 끊긴 뒤 복구가 늦어집니다. tolerance (url-test) 는 “1등과 2등의 RTT가 이 정도면 굳이 바꾸지 않는다”는 쿨다운 느낌으로 쓰면, 지연이 5~10ms씩 떨리는 회선에서 세션이 끊기는 것처럼 보이는 현상을 줄이는 데 도움이 됩니다.

rules 끝에서 PROXY(전략) 그룹을 가리키기

규칙 파일이 길다면, MATCH,PROXY 나 GEOIP,CN,DIRECT 전에 DOMAIN-SUFFIX,example.com,PROXY_AUTO_LATENCY 처럼 원하는 트래픽만 방금 만든 전략 그룹으로 보내야 합니다. 이름 오타 한 글자면, 코어는 해당 줄을 무시하거나 기본 Proxy·DIRECT 로 떨어질 수 있으니, GUI에서 그룹을 바꾼 뒤에는 rules:·rule-providers 쪽 문자열을 동시에 점검하세요. “전역 PROXY” 한 줄만 있고, 그 PROXY 가 사실 select 히든 그룹이면, 여기서 url-test·fallback 를 섞는 설계는 “상위 select 를 대체하거나, 하위 셀렉터에 넣느냐”에 따라 UI가 달라질 수 있어, 클라이언트(Verge, FlClash, …)가 중첩 그룹을 어떻게 그리는지도 함께 보면 덜 혼됩니다. 대형 구성이 부담이면, 먼저 MATCH,PROXY_FAILOVER 한 줄만으로 실험한 뒤, 세분 DOMAIN 룰로 좁혀가도 늦지 않습니다.

잠깐: DNS의 fallback과는 다릅니다

구성에서 dns: 아래 fallback·nameserver 를 쓰는 것은 이름이 실제 주소로 풀리는 경로이고, 이번 글의 proxy-groups fallback 은 이미 프록시로 나갈 연결에 대해 어느 아웃바운드 를 쓸지 정하는 층입니다. 둘 다 “뒤에 대안이 있다”는 뉘앙스는 비슷하지만, 로그를 볼 위치( DNS 질의 vs. TCP/UDP 프록시 체인)가 다릅니다. Clash 에서 fake-ip·redir-host·nameserver 조합이 꼬이면, rule은 맞는데 실제 IP가 또 다른 해석으로 떨어지는 간헐 이슈가 나기도 합니다. 그때는 Fake-IP·DNS 와, 필요하면 TUN 문맥을 같이 봅니다.

실측 절차(요약): 저장 → 재로드 → 로그 → 부하

실제로 자동 절체를 검증하려면 (1) YAML/프로필 을 안전한 위치에 저장하고 코어/앱이 읽는지, (2) 구독/프로바이더 를 갱신해도 그룹이 덮이지 않는지 (팀 정책에 따라 proxy-groups 를 로컬 파일에 따로 둡니다) 확인하고, (3) 연결/프록시 로그에서 url-test 가 누구를 1위로 잡는지, fallback 이 어느 자식에서 다음으로 넘기는지 캡처합니다. (4) 노드 하나를 의도적으로 끄거나 (상위에 차단) 막힌 경로로 바꾼 뒤, 몇 번의 실패·몇 분 안에 둘째·셋째로 내려가는지 보면, interval·프로버 URL이 너무 느슨/빡빡한지 감이 옵니다. (5) 마지막으로 실제 업무/스트리밍/게임 부하를 걸고, 지연만 좋다고 체감이 좋은 것은 아니라는 점(대역, 패킷 손실)을 다른 긴 튜토리얼—예: 콘솔 상점·Steam—과 연결해 떠올리면, “프로브는 예쁜데 실서비스는 끊긴다”를 줄이는 데 도움이 됩니다.

ℹ️
한 줄 정리: url-test 는 “지연이 가장 낫다”를 고르는 쪽, fallback 은 “위가 죽으면 아래”입니다. 주(대표)·부(예비) 는 fallback 의 proxies 배열 순서에 가장 잘 맞고, url-test 는 주기적으로 1위가 바뀌는 운용에 가깝습니다.

자주 겪는 함정: 공차·URL·이름

첫째, tolerance 를 0에 가깝게 두면, RTT 측정이 조금씩 흔들릴 때마다 url-test 가 대표를 갈아엎어 HTTP/2·긴 터널 이 끊기는 느낌이 날 수 있습니다. 둘째, 같은 이름의 그룹이 merge·구독 주입·GUI 동기화로 덮이면 아무리 로컬에서 예쁘게 써도, 재시작 뒤 다시 select 뿐인 PROXY 로 돌아갑니다. 셋째, interval 을 짧게 잡는 대신, 204 응답을 주는 url 을 지역/차단에 민감하게 두면, “모두 죽었다”는 오탐 으로 fallback 이 맨 아래 DIRECT 까지 뛰는 일이 있을 수 있어, 회선/국가/회사망 에서 한 번씩 브라우저로 프로브 URL이 열리는지도 같이 봅니다. 넷째, Clash for Android·라우터/임베디드 빌드는 GUI 옵션이 desktop과 다르며, lazy·세부 behaviour·지원 type 은 빌드/코어 릴리스 노트에 맡기는 것이 맞습니다.

맺음: 수동 select 를 덜 쓰고 싶다면

규칙으로 어디로 보낼지 정한 뒤, 그 안에서 url-test·fallback 으로 누구를 쓸지 자동 절체를 걸어 두면, “해외 2번 노드 죽었을 때만 손이 가는” 스트레스를 많이 덜 수 있습니다. 다만 프로브와 실트래픽의 경로는 다를 수 있으니, 최종 검증은 항상 로그와 실서비스 둘 다에서 하세요. 최신 Clash·GUI 는 핑·룰·그룹이 한 화면에 잘 잡혀 있어, 같은 절차를 반복 실험하기에도 잘 맞는 편입니다. 배포·업데이트는 문서와, 클라이언트는 공식 내려받기 를 기준으로 잡는 것이 좋습니다.

최신 빌드는 Clash 공식 다운로드 에서 OS에 맞게 고르면 됩니다. → Clash 를 무료로 내려받고 url-test·fallback 을 연결 로그와 함께 맞춰 보시면, 수동으로 노드만 뒤집는 날이 줄어듭니다.