Clash 정책 그룹 url-test와 fallback: 자동 지연 테스트·장애 복구(페일오버) 설정

1. 정책 그룹이 필요한 이유

대부분의 사용자는 구독 URL로 프로필을 받아오면 개별 노드(proxy) 목록이 생깁니다. 그런데 「항상 이 한 노드만 쓴다」로 고정하면, 시간대·회선·서버 부하에 따라 체감 속도가 크게 달라집니다. 반대로 수동으로 바꾸기엔 번거롭고, 스트리밍·게임·원격 업무처럼 끊김에 민감한 작업에서는 특히 불편합니다.

proxy-groups는 이런 개별 노드를 묶어 하나의 논리적 출구로 만드는 레이어입니다. 타입에 따라 「지연을 재서 가장 나은 것을 고른다(url-test)」「헬스가 깨지면 목록의 다음으로 넘긴다(fallback)」「사용자가 직접 고른다(select)」처럼 동작이 갈립니다. 이번 글의 초점은 검색 의도에 맞춰 자동 최저 지연과 장애 복구에 해당하는 두 가지입니다.

설정 파일은 보통 mihomo(구 Clash Meta) 계열과 호환되는 YAML을 씁니다. GUI 클라이언트(Verge Rev, FlClash 등)에서는 동일한 개념이 「프로필 편집」이나 「정책 그룹」 화면으로 옮겨져 있을 수 있으나, 원리는 YAML과 같습니다.

2. url-test와 fallback, 무엇이 다른가

한 줄로 요약하면, url-test는 “누가 제일 빠른가”를 주기적으로 재측정하고, fallback은 “지금 쓰는 게 살아 있는가”를 검사해 죽었을 때만 순서대로 바꿉니다. 둘 다 자동 전환이라 혼동하기 쉬우나, 목적이 다릅니다.

따라서 「늘 가장 빠른 곳만 쓰고 싶다」면 url-test 쪽이 맞고, 「주 노드 하나가 절대적으로 중요하고, 안 될 때만 예비로 넘기고 싶다」면 fallback이 자연스럽습니다. 필요하면 url-test 안에 여러 프록시를 넣고, 그중 하나를 다시 fallback으로 묶는 식으로 조합할 수도 있습니다(고급 구성은 프로필 구조에 따라 달라집니다).

3. url-test: 지연 테스트·자동 최저 지연 선택

type: URLTest(YAML에서는 보통 url-test) 그룹은 url 필드에 지정한 주소로 HTTP 요청을 보내 응답 시간을 잽니다. interval마다 재측정하며, 가장 낮은 지연을 기록한 프록시를 선택합니다. 구독에서 내려온 프록시 이름을 proxies 목록에 나열하면 됩니다.

proxy-groups:
  - name: '자동-최저지연'
    type: url-test
    proxies:
      - '노드-A'
      - '노드-B'
      - '노드-C'
    url: 'http://www.gstatic.com/generate_204'
    interval: 300
    tolerance: 50
# url: latency test target (commonly generate_204 or provider-specific URL)
# interval: seconds between tests
# tolerance: ms; avoid flapping when differences are small

url은 실제로 접속할 테스트 대상입니다. 많은 구독·문서에서 http://www.gstatic.com/generate_204를 쓰는 이유는 응답이 가볍고 지연 측정에 적합하기 때문입니다. 일부 상용 노드는 전용 측정 URL을 안내하기도 하니, 제공사 가이드가 있으면 그쪽을 따르는 편이 안전합니다.

tolerance는 「조금만 느려졌다고 바로 갈아타지 않게」 막아 주는 완충입니다. 너무 작으면 노드가 자주 바뀌어 세션이 불안정해 보일 수 있고, 너무 크면 체감상 느린 노드에 오래 머물 수 있습니다. 회선에 맞게 조금씩 조정하는 것이 좋습니다.

4. fallback: 장애 시 순차 페일오버

type: Fallback(fallback)은 proxies 배열의 위에서 아래 순서가 우선순위입니다. 현재 선택된 프록시가 헬스 체크에 실패하면 그 다음 항목으로 넘어갑니다. 「메인 전용 → 일반 백업 → 직접」처럼 고정된 우선순위를 코드에 박아 두고 싶을 때 적합합니다.

proxy-groups:
  - name: '메인-백업-순차'
    type: fallback
    proxies:
      - '프리미엄-메인'
      - '일반-백업'
      - 'DIRECT'
    url: 'http://www.gstatic.com/generate_204'
    interval: 300
# DIRECT is built-in; order matters: try main first, then backup, then direct

DIRECT는 Clash에 내장된 키워드로, 프록시를 거치지 않고 나가는 경로입니다. 마지막 안전망으로 두는 경우가 많습니다. 다만 지역·방화벽 정책상 DIRECT가 의도와 다르게 동작할 수 있으니, 사용 목적에 맞게 넣을지 빼야 할지 판단해야 합니다.

ChatGPT 등 특정 서비스에 대해 IP를 고정하고 싶다면 전용 fallback 그룹을 두는 패턴도 흔합니다. 관련 아이디어는 ChatGPT 분할 규칙 글에서 다룬 흐름과 연결해 읽을 수 있습니다. 목적이 다르더라도 「정책 그룹 이름을 규칙에 붙인다」는 점은 같습니다.

5. rules에서 정책 그룹 쓰기

정책 그룹을 만들었어도 rules에서 그 이름을 호출하지 않으면 트래픽이 거기로 가지 않습니다. 일반적으로는 도메인·지역·IP 대역 등 조건 뒤에 그룹 이름을 적습니다. 자세한 규칙 문법과 우선순서는 라우팅 규칙 가이드를 참고하세요.

rules:
  - 'DOMAIN-SUFFIX,google.com,자동-최저지연'
  - 'MATCH,메인-백업-순차'
# Use the same proxy-group names as in proxy-groups

MATCH는 마지막 포괄 규칙으로 자주 쓰입니다. 위 예에서는 나머지 전부를 메인-백업-순차 그룹으로 보냅니다. 실제 프로필에는 국내 도메인을 DIRECT로 빼는 등 더 촘촘한 규칙이 앞에 옵니다. 위에서 아래로 첫 매칭이 승리한다는 점을 잊지 마세요.

구독이 노드 이름을 갱신해 바꾸면, proxies에 적어 둔 문자열과 어긋나 그룹이 깨질 수 있습니다. 클라이언트의 프로필 검증 오류를 주기적으로 확인하는 습관이 좋습니다.

6. interval·tolerance·lazy 등 옵션 정리

interval은 초 단위 재측정 주기입니다. 짧게 잡으면 반응은 빨라지지만 테스트 트래픽과 CPU 부담이 늘고, 길게 잡으면 회선 변화에 늦게 따라갑니다. 모바일·요금제 환경에서는 너무 공격적인 값은 데이터·배터리에도 영향을 줄 수 있습니다.

코어 버전에 따라 lazy 같은 옵션을 지원해, 해당 그룹이 실제로 쓰일 때만 테스트를 활성화하는 식의 동작을 줄 수 있습니다. 지원 여부는 사용 중인 mihomo/Clash 버전 문서를 확인하세요. GUI에서는 같은 의미의 토글이 다른 이름으로 있을 수 있습니다.

7. 클라이언트에서 확인하는 법

데스크톱 GUI에서는 프로필을 연 뒤 프록시 또는 정책 화면에서 그룹 이름이 드롭다운으로 보입니다. url-test 그룹은 종종 현재 선택된 노드 옆에 지연(ms)이 표시되기도 합니다. fallback은 활성 노드가 바뀔 때 로그에 이유가 남는 경우가 많아, 문제가 있으면 로그 뷰어를 켜 두고 확인해 보세요.

설정을 처음 편집한다면 YAML 전체를 백업한 뒤 작은 변경만 넣고 재로드하는 방식이 안전합니다. 일부 클라이언트는 구독이 덮어쓰는 영역과 사용자가 덧붙이는 영역을 분리하니, 「내가 넣은 그룹이 갱신 때마다 사라진다」면 머지 규칙이나 사용자 규칙 파일 위치를 점검해야 합니다.

CFW에서 다른 앱으로 옮기는 절차는 CFW 대체·마이그레이션 가이드에서 다룹니다. 정책 그룹 문법은 호환되는 한 동일하게 가져올 수 있습니다.

8. 자주 겪는 문제와 마무리

노드가 계속 바뀐다면 tolerance를 키우거나 interval을 조금 늦춰 보세요. fallback이 백업으로 안 넘어간다면 테스트 URL이 막혔거나 DNS 문제로 “실패”로 안 잡히는 경우가 있습니다. 다른 테스트 URL이나 DNS 설정을 점검해 보세요.

지연은 낮은데 유튜브만 버퍼링처럼 보이면, 해당 도메인이 다른 규칙 줄로 빠지고 있을 수 있습니다. 규칙 목록 상단의 DOMAIN·GEOIP·PROCESS 등이 의도대로 매칭되는지 다시 읽어 보세요.

정리하면, 자동으로 가장 낮은 지연을 쓰고 싶을 때는 url-test, 우선순위를 지켜 장애 시에만 바꾸고 싶을 때는 fallback을 기본으로 기억하면 됩니다. 둘 다 url과 interval을 공유하지만, 전환 철학이 다릅니다. 구독만으로는 부족한 “운영 감각”에 가장 가까운 부분이 정책 그룹입니다.

오픈 소스 클라이언트마다 UI는 다르지만, 규칙과 그룹을 이해하면 플랫폼을 옮겨도 같은 로직을 재사용할 수 있습니다. 설치·업데이트는 출처가 분명한 패키지를 쓰는 것이 중요하고, 여러 환경에서 검증된 배포판을 한곳에서 받을 수 있다면 관리가 훨씬 수월합니다. → Clash를 무료로 내려받고, url-test와 fallback으로 자동 전환·페일오버를 직접 맞춰 보세요.