이 글이 해 주는 일

Windows 11에서 Clash Verge Rev로 Mihomo(Clash Meta) 프로필을 돌릴 때, 트래픽을 “항상 이 순서대로 쓰되 장애만 피하고 싶다”면 fallback 전략 그룹이 맞는 선택입니다. 검색으로 자주 나오는 Clash Verge Rev fallback·fallback group 설정은 결국 proxy-groups 안에 type: fallback 블록을 두고, 헬스 체크(전략 그룹에 넣는 측정용 URL과 간격)으로 주기적으로 후보 상태를 보는 흐름으로 정리됩니다. 지연만 보고 매번 1위가 바뀌는 url-test와 목적이 다르니, 먼저 타입을 헷갈리지 않는 것이 중요합니다.

설치·스마트스크린·구독 넣기 전반은 Clash Verge Rev 전체 가이드, 전략 그룹 유형 개요와 측속 UI 감은 Windows 11 전략 그룹·측속 편, url-test 튜닝만 깊게 보고 싶다면 url-test 헬스 체크·tolerance 글과 역할을 나눕니다. 이 문서는 우선순위 유지 + 장애 시 다음 줄로 넘어가기에 초점을 맞춥니다.

범위: 규칙이 어떤 그룹 이름을 바라보는지 모호하면 규칙 분할 가이드로 상위 맥락을 잡은 뒤 돌아오세요. DNS·UDP 이슈가 섞이면 지연·UDP·DNS 트러블슈팅도 함께 보는 편이 빠릅니다.

fallback과 url-test, 무엇을 고를까

url-test는 이름 그대로 같은 기준으로 후보들을 재측정하고, 통상적으로 가장 낮은 지연 쪽으로 출구가 움직입니다. 반면 fallback은 YAML에 적힌 proxies 배열의 위에서 아래 순서가 의미 있습니다. 헬스 체크가 정상이라고 판단한 첫 후보를 쓰고, 그 노드가 실패로 표시되면 목록에서 다음 건강한 멤버로 넘어갑니다. 그래서 “무조건 가장 빠른 한 줄만 고른다”보다 “내가 정한 우선순위 안에서 살아 있는 것만 쓴다”에 가깝습니다.

실무에서는 메인 전용 계정 → 백업 무료 라인, 저렴한 라인 → 트래픽 많은 라인, 회사 정책상 특정 출구만 허용 같은 이유로 순위 자체가 중요할 때 fallback이 자주 쓰입니다. 반대로 회선 품질이 시간대마다 크게 바뀌어 “매번 자동으로 제일 빠른 데만 붙고 싶다”면 url-test 쪽이 더 자연스럽습니다. 한 프로필 안에서도 목적별로 타입을 섞을 수 있으니, 규칙에서 바라보는 그룹마다 선택지를 나누면 됩니다.

fallback이 헬스 체크와 만나는 방식

Mihomo 계열에서 fallback 그룹은 후보 하나하나에 대해 주기적으로 전략 그룹에 지정한 URL로 간단한 연결·응답 시간을 재고, 실패하거나 타임아웃이 나면 그 멤버를 일시적으로 건강하지 않은 것으로 보고 목록에서 빼고 다음을 시도합니다. 사용자 입장에서는 UI에서 빨간 표시나 지연 숫자로 상태가 드러나는 경우가 많지만, 근본 규칙은 여전히 YAML의 url·interval(초 단위 재측정 주기) 같은 필드가 정합니다.

중요한 착각 하나는 “헬스가 좋으면 무조건 위쪽만 쓴다”가 아니라는 점입니다. 여러 후보가 동시에 건강하면 목록 상단에 가까운 살아 있는 노드가 선택됩니다. 따라서 순서를 바꾸는 것만으로도 행동이 완전히 달라집니다. 반대로 헬스 URL이 특정 지역·CDN에서만 간헐적으로 막히면, 실제 앱은 멀쩡한데도 위쪽 후보가 전부 빨간색으로 찍히는 식의 역설이 생길 수 있습니다. 이때는 tolerance 숫자만 만지는 것보다 측정 URL 자체를 교체하는 편이 빠른 경우가 많습니다.

팁: 스트리밍처럼 카탈로그 지역이 출구에 민감하면, fallback으로 순위만 두고 자동 페일오버에 맡기기보다 select로 원하는 지역을 고정하는 편이 체감이 나은 경우도 많습니다. fallback은 ‘장애 대비 연속성’에 특히 잘 맞습니다.

1단계: YAML에서 fallback 블록 이해하기

구독마다 프록시 이름과 그룹 라벨은 다르지만, 구조는 아래처럼 잡습니다. 이름은 예시이므로 본인 프로필의 proxies: 섹션과 동일한 식별자를 써야 합니다.

proxy-groups:
  - name: "🔁 폴백 메인"
    type: fallback
    proxies:
      - 서버-프리미엄
      - 서버-백업-A
      - 서버-백업-B
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

proxies 배열의 위쪽에 둔 항목이 우선입니다. 위 예에서 세 노드가 모두 헬스상 통과하면 가장 위의 프리미엄 라인이 선택되고, 그 라인만 실패로 분류될 때 아래 백업으로 내려갑니다. 필요하면 마지막에 DIRECT나 다른 그룹 이름을 넣어 최후의 출구를 정할 수 있습니다. 다만 DIRECT를 넣었다고 해서 규칙 레벨의 분할 의도가 자동으로 맞춰지지는 않으니, 상위 rules:와 함께 설계해야 합니다.

코어 버전과 템플릿에 따라 lazy 같은 부가 옵션이 보일 수 있습니다. 배터리 절약을 위해 실제로 그룹을 쓰기 전까지 측정을 줄이는 성격이라면, 첫 연결 직후 잠깐 이전 선택이 남아 있는 느낌이 들 수 있습니다. 지원 필드는 사용 중인 Mihomo 릴리스 문서와 맞춰 확인하세요.

2단계: 전략 그룹 URL(헬스 체크) 고르기

전략 그룹 URL은 검색에서도 자주 쓰는 표현인데, Mihomo YAML에서는 보통 url: 키에 해당합니다. 좋은 주소는 응답이 가볍고, 과도한 HTTP 리다이렉트 체인이 없으며, 대부분의 후보 지역에서 443 근처로 안정적으로 닿는 편이 안전합니다. 특정 클라우드 엣지나 지역 정책 한쪽에서만 막히는 엔드포인트를 쓰면, 노드 품질과 무관하게 위쪽 후보가 줄줄이 실패하는 일이 생깁니다.

직접 바꿀 때는 브라우저나 curl으로 같은 회선에서 한 번 열어 보고, Verge Rev 로그에 해당 호스트에 대한 타임아웃이 반복되는지 함께 보세요. 회사·학교망 필터가 헬스 호스트만 막는 패턴도 있어, 그럴 때는 정책에 걸리지 않는 다른 HTTPS 소량 응답 URL을 고르는 편이 낫습니다.

3단계: interval과 Windows 11 사용 습관 맞추기

interval은 초 단위입니다. 너무 짧게 두면 모든 후보에 대한 재시도가 잦아져 배터리·CPU 부담이 커지고, 무선 LAN에서는 순간적인 지터만으로 상태 표시가 출렁일 수 있습니다. 너무 길면 장애를 알아채고 다음 순위로 넘어가기까지 체감 지연이 커집니다.

Windows 11에서는 절전에서 깨어난 직후 NIC이 다시 잡히며 잠깐 모든 헬스가 실패하는 순간이 종종 있습니다. 이때 숫자만 의심하지 말고 수십 초 기다리거나, 앱에서 제공하는 일괄 지연 측정으로 스냅샷을 새로 고치는 습관이 도움이 됩니다. TUN을 켠 상태에서 다른 VPN과 겹치거나 관리자 권한·라우팅이 꼬이면 측정 경로만 끊기는 경우도 있으니, 증상이 반복되면 경로를 단순화해 재현해 보는 편이 빠릅니다.

4단계: Clash Verge Rev에서 편집·적용하기

Verge Rev에서는 프로필 편집으로 들어가 proxy-groups 섹션을 연 다음, 새 그룹을 추가하거나 기존 그룹의 type을 fallback으로 바꿉니다. proxies 목록의 순서를 드래그로 바꿀 수 있는 UI가 있다면 그 순서가 그대로 우선순위가 되고, 텍스트 편집만 가능하면 배열 안에서 줄 순서를 직접 조정합니다.

저장 후에는 빌드마다 다르지만 코어 리로드 또는 앱 재시작이 필요할 수 있습니다. 변경 직후 프록시 탭에서 각 후보 색과 지연, 선택된 출구 이름이 기대와 같은지 확인하세요. 규칙이 실제로 이 그룹을 타는지까지 보려면 연결 로그나 테스트 트래픽 한 줄을 넣어 추적하는 방법이 확실합니다.

주의: 프록시는 법령·서비스 약관·내부 네트워크 정책을 지키는 범위에서만 사용하세요. 타인 구독 무단 이용이나 약관을 회피할 목적의 우회는 삼가야 합니다.

자체 점검: 우선순위와 장애 건너뛰기 확인하기

설정이 의도대로인지 한 번에 확인하려면 아래 순서를 따르세요.

  1. 문제 시간대에 활성 프로필과 시스템 프록시·TUN 상태를 확인합니다.
  2. 해당 fallback 그룹에서 최상위 후보를 수동으로 다른 노드로 바꿔 규칙이 같은 그룹을 타는지 확인합니다.
  3. 로그에서 헬스 실패가 특정 호스트에만 반복되는지 본 뒤, 필요하면 url을 교체합니다.
  4. 상단 후보를 일부러 불안정한 회선으로 두거나 제공자 측 점검 시간을 이용해 다음 순위로 넘어가는지 재현합니다.
  5. interval을 너무 짧게 두었다면 늘리고, 장애 이탈이 느리면 소폭 줄여 보지만 한 번에 한 변수만 바꿉니다.
  6. 구독이 덮어쓴다면 복제 프로필·패치 전략을 검토합니다.

자주 묻는 질문

순서를 바꿨는데도 다른 노드가 잡힙니다

상위 규칙이 다른 그룹을 가리키거나, 중첩된 그룹 구조에서 부모 쪽이 먼저 선택을 바꾸는 경우입니다. 또한 아직 헬스상 살아 있는 더 위쪽 후보가 남아 있으면 아래로 내려가지 않습니다. 연결 한 줄을 추적해 실제로 어떤 체인이 선택되는지 확인하세요.

모든 후보가 동시에 불건강으로 보입니다

측정 URL이 막혔거나 DNS 경로가 꼬였을 가능성이 큽니다. 브라우저와 로그로 같은 호스트에 대한 타임아웃을 비교하고, fake-ip·규칙 순서를 점검하세요.

같은 후보 풀을 url-test와 fallback에 각각 쓸 수 있나요?

기술적으로는 이름만 다르게 두 개의 그룹을 만들 수 있지만, 규칙에서 어떤 이름을 쓰는지에 따라 트래픽이 갈라집니다. 같은 이름을 중복 정의하지 않도록 YAML 유효성을 확인하세요.

마무리

Windows 11에서 Clash Verge Rev와 Mihomo를 쓸 때 fallback 전략 그룹은 우선순위와 헬스 체크로 장애 노드 건너뛰기를 동시에 만족시키는 패턴입니다. 전략 그룹 URL이 현실적인지, interval이 회선 지터를 과대평가하지 않는지, YAML에서 proxies 순서가 운영 의도와 같은지 세 가지만 맞아도 현장 체감이 크게 안정됩니다.

반면 버튼 안내만 반복하고 프로필 깊은 부분을 보여 주지 않는 일부 클라이언트는, 장애 시 왜 다음 순위로 넘어갔는지 역추적하기 어렵습니다. 반대로 구성 파일과 설명이 같은 흐름으로 열리면 반복 시행착오가 줄고, 문제가 생겨도 조정 포인트가 분명해집니다. 그런 면에서 많은 도구가 설정을 숨기거나 문서가 파편화되어 있어 초보에게 부담이 큰 반면, Clash 공식 사이트는 Mihomo·Clash Verge Rev·구독 흐름을 한국어로 이어 주는 글과 검증된 다운로드 경로를 한곳에 모아 장기 운영 피로를 줄이는 데 초점을 맞춥니다.

지금 프로필에 fallback 블록을 새로 넣거나 순서만 손보고 싶다면 Clash Verge Rev 최신 빌드를 맞춘 뒤, 위 자체 점검 순서대로 한 번 적용해 보세요. 우선순위를 유지하면서도 장애 노드를 건너뛰는 예측 가능한 페일오버가 한결 정리되는 경우가 많습니다.