Clash 규칙 분할에서 URL-Test와 Fallback 작성법:
자동 지연 측정·노드 선택과 장애 조치 전환

1 왜 URL-Test와 Fallback이 필요한가

많은 사용자가 클라이언트에서 select(수동 선택)으로 한 노드만 고릅니다. 직관적이지만 공항 회선은 시간에 따라 달라지고, 어제 빠르던 노드가 오늘도 빠르다는 보장은 없습니다. 현재 노드가 차단·다운·핸드셰이크 타임아웃이면 직접 다음으로 바꿔야 해서 흐름이 끊깁니다. URL-Test와 Fallback은 이런 두 종류의 불편을 줄이기 위한 프록시 그룹 유형입니다. 전자는 후보 집합에서 주기적으로 지연을 재고 상대적으로 나은 노드를 고르고, 후자는 고정된 순서로 헬스 체크를 하다가 현재 항목이 쓸 수 없으면 뒤로 넘깁니다.

둘은 자주 같이 씁니다. 예를 들어 url-test로 홍콩 노드 여러 개를 HK-AUTO라는 그룹으로 묶고, 그다음 fallback 목록의 첫 항목으로 HK-AUTO를 두고 싱가포르 예비·마지막에 DIRECT나 REJECT를 두면 같은 지역 안에서는 자동으로 고르고, 지역·회선이 막히면 순서대로 넘어가는 구조가 됩니다. 아직 공항 구독을 Clash가 읽는 proxies 목록으로 바꾸지 않았다면 먼저《구독 변환 가이드: SS·V2Ray·Trojan을 Clash YAML로》를 보고 노드 name과 아래 그룹 참조가 일치하는지 맞추세요.

2 그룹 유형 요약: DNS의 fallback과 헷갈리지 않기

proxy-groups에는 select(수동), url-test(지연 기반 자동), fallback(순차 장애 조치), load-balance(부하 분산) 등이 흔합니다. 이 글의 핵심은 앞의 두 가지입니다. 또 하나 헷갈리기 쉬운 점은, dns 설정에도 fallback이라는 이름의 DNS 서버 목록이 있어, 오염 감지 실패 뒤 도메인 해석을 넘길 대상을 가리킵니다. 이것과 프록시 그룹의 type: fallback은 전혀 다릅니다. DNS를 같이 손보고 있다면 두 종류의 fallback을 머릿속에서 분리해 두고, 잘못된 블록을 고치지 않도록 하세요.

3 URL-Test: 지연 측정, tolerance, 복붙 템플릿

URL-Test는 interval마다 proxies의 각 항목에 대해 보통 url로 HTTP 요청을 보내 왕복 지연을 재고, 그중 현재 가장 나은 노드를 고릅니다. 임계값 근처에서 왔다 갔다 바뀌는 것을 줄이려면 tolerance를 씁니다. 새 후보가 현재 선택보다 tolerance(ms) 이상 더 좋을 때만 바꾸면 노드가 잦게 바뀌며 연결이 흔들리는 현상을 줄일 수 있습니다. 커뮤니티에서 자주 쓰는 측정 URL은 http://www.gstatic.com/generate_204, http://cp.cloudflare.com/ 등입니다. 본인 회선에서 특정 도메인이 불안정하면 로컬에서 안정적으로 닿고 가벼운 응답을 주는 URL로 바꾸세요. 그렇지 않으면 전 노드가 타임아웃으로 보이는 오판이 납니다.

최소 예시

아래 HK-1, HK-2는 proxies:에 정의된 name과 정확히 같아야 합니다. 구독에 특수문자가 섞인 노드 이름이 있으면 클라이언트에 표시된 실제 이름을 확인한 뒤 그룹에 넣으세요.

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-1
      - HK-2
      - HK-3
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval은 너무 짧게 두지 마세요. 너무 자주 측정하면 배터리·로그 부담이 커지고, 일부 공항은 빈번한 점검을 제한하기도 합니다. 보통 300초 전후를 출발점으로 삼고, 더 빠른 반응이 필요하면 클라이언트 CPU와 공항 쪽 반응을 보며 조정하세요. 코어가 지원하면 lazy: true로 규칙에서 아직 참조되지 않은 그룹의 불필요한 측정을 줄일 수 있어 노드가 많을 때 유리합니다. 필드 이름은 사용 중인 Clash / Mihomo(Clash.Meta) 버전 문서를 따르세요.

4 Fallback: 순서가 우선순위, 헬스로 언제 넘길지 결정

Fallback 유형 그룹은 순서가 있는 proxies 목록을 유지합니다. 커널은 현재 선택된 항목에 대해 연결 가능 여부를 검사합니다(url, interval 등과 연동). 실패로 판단되면 다음 멤버로 넘어갑니다. 같은 라운드에서 「누가 가장 지연이 낮은가」를 비교하지 않고, 「지금 쓰는 것이 되면 그대로」에 가깝기 때문에 주·예비 회선에 잘 맞습니다. 목록에는 다른 프록시 그룹(예: 앞의 HK-AUTO)도 넣을 수 있어, 홍콩에서 자동 선택 후 안 되면 싱가포르 자동 그룹으로 넘기는 식 구성이 가능합니다.

proxy-groups:
  - name: PROXY-MAIN
    type: fallback
    proxies:
      - HK-AUTO
      - SG-BACKUP
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

fallback 끝에 DIRECT를 둘지는 보안과 가용성 사이에서 결정합니다. 반드시 프록시를 타야 하는 트래픽에 마지막에 DIRECT를 두면 의도치 않은 직접 연검이 날 수 있고, 반대로 페이지만 열리면 된다면 최후 수단으로 둘 수 있습니다. YAML 한 덩어리만 복사하지 말고 rules에서 어떤 도메인이 이 그룹으로 가는지 함께 설계하세요. 스트리밍·rule-provider 이름 관습은《ACL4SSR·rule-provider로 규칙 분할》글과 맞추면 전체 설정에서 참조가 어긋나지 않습니다.

5 중첩과 rules에서의 참조

실제로는 url-test와 fallback이 사슬처럼 붙습니다. 맨 아래는 개별 노드, 중간은 지역·용도별 url-test 그룹, 맨 위는 사용자가 클라이언트에서 바꾸는 fallback이나 select(업무·게임·영상 등)입니다. 규칙 층에서는 트래픽을 가장 바깥 그룹 이름으로 보내면 됩니다. 예: - MATCH,PROXY-CHAIN 또는 GEOSITE·DOMAIN-SUFFIX로 세분화해 서로 다른 그룹 이름을 가리킵니다.

rule-providers로 외부 규칙을 쓸 때는 규칙에 적힌 정책 이름과 프록시 그룹 이름이 같아야 합니다. 이름만 바꾸고 규칙을 안 고치면 「규칙은 맞는데 다른 기본 그룹으로 간다」는 느낌이 날 수 있습니다. proxy-groups를 수정한 뒤에는 GUI의 구성 검사나 커널 -t(CLI 배포는《Linux에 Mihomo 설치 및 systemd》참고)로 문법을 확인하고, 로그에서 그룹 전환이 기대와 같은지 봅니다.

6 흔한 실수와 점검 순서

• 측정 URL이 안 됨: 로그에 모든 노드 지연이 이상하거나 타임아웃이면 먼저 url을 바꾸거나 로컬에서 탐지 도메인으로 가는 경로가 막혔는지 보고, 곧바로 공항 전체 다운으로 단정하지 마세요.
• tolerance가 0에 가깝거나 너무 작음: 비슷한 두 노드 사이를 url-test가 왔다 갔다 할 수 있습니다. interval만 줄이기보다 tolerance를 키우는 편이 나을 때가 많습니다.
• 구독 갱신 후 이름 불일치: 노드 name이 바뀌었는데 그룹에 옛 이름이 남아 있으면 기동 실패나 해당 멤버 건너뛰기가 납니다. 갱신 후 그룹 목록을 다시 확인하세요.
• fallback을 「가장 빠른 자동 선택」으로 오해: fallback은 순차 장애 조치이지 전역 지연 비교가 아닙니다. 자동으로 가장 낮은 지연을 고르려면 url-test를 쓰거나 fallback 항목 안에 url-test 그룹을 넣으세요.
• 헬스와 실제 트래픽 경로 불일치: 측정은 통과해도 장시간·대용량·UDP가 불안정할 수 있습니다. 게임·영상 문제는 목적지 도메인 규칙과 UDP 지원을 따로 봐야 합니다.

7 정리

Clash URL-Test 그룹은 같은 후보 중 지금 누가 더 나은가를 주기적 지연 측정과 tolerance로 다룹니다. Fallback 그룹은 지금 회선이 쓸 수 있는가를 순서와 헬스로 보고 장애 조치합니다. select·load-balance 등과 같이 쓰고 rules 이름을 일관되게 맞추면, 구독 속 수십 개 노드를 유지보수하기 쉬운 몇 줄 전략으로 접을 수 있습니다. dns의 fallback과 proxy-groups의 type: fallback이 이름만 같을 뿐 역할이 다르다는 점을 기억해 두면 문제 찾기가 빨라집니다.

GUI 클라이언트는 보통 그룹 화면에 측정 결과와 선택 노드를 보여 주어 YAML만 쓸 때보다 검증이 쉽습니다. 구독 가져오기·코어 전환·로그 보기까지 한곳에서 하려면 사이트 다운로드 페이지에서 본인 OS에 맞는 Clash 계열 클라이언트를 고른 뒤, 이 글의 그룹 템플릿을 환경에 맞게 줄여 쓰면 됩니다.

운영 중인 설정은 최소한으로도 동작하는 백업을 남겨 두고, 복사본에서 url-test와 fallback 중첩을 더하세요. 이상이 있으면 빠르게 select와 기본 규칙만 있는 안정 상태로 되돌려 원인을 쪼갤 수 있습니다.

→ Clash 무료 다운로드로 끊김 적은 연결 경험하기