Clash Meta(Mihomo) url-test·fallback: 헬스체크와 자동 전환을 proxy-groups로 설정하는 단계별 가이드 (2026)

무엇을 해결하나: “가장 빠른 줄”과 “주·예비 줄”

같은 PROXY 그룹이라도 운영 의도에 따라 두 갈래로 나뉩니다. 첫째, 여러 후보 중에서 지연(latency)이 가장 낮은 노드를 자동으로 고르고 싶은 경우입니다. 뉴스·웹 서핑처럼 “지금 당장 체감이 빠른 곳”이 중요할 때 url-test가 이 역할에 가깝습니다. 둘째, 1번 노드를 기본으로 쓰다가 응답이 깨지거나 측정이 실패하면 2번·3번으로 넘어가는 주·예비 구조를 원할 때입니다. 이 패턴은 fallback이 자연스럽습니다. 둘 다 헬스체크라는 공통 장치를 쓰지만, “누가 이기나 경쟁”이냐 “순서대로 통과할 때까지 시험”이냐가 다릅니다.

전제는 간단합니다. proxies에 이미 이름 붙은 업스트림이 있어야 하고, proxy-groups에서 그 이름들을 묶은 뒤, rules의 정책 열이 그 그룹 이름을 가리키면 됩니다. relay 같은 다른 타입과 섞을 수는 있으나, 이 글에서는 relay 체인 글과 달리 단일 홉 선택·페일오버만 다룹니다. 규칙 설계의 큰 그림은 GEOIP·GEOSITE 가이드를 참고하세요.

url-test와 fallback, 한눈에 비교

url-test는 주기적으로 각 후보에 대해 url로 지정한 주소에 HTTP 요청을 보내고, 응답이 정상인 노드들 사이에서 가장 짧은 지연을 가진 것을 선택합니다. 이때 tolerance(밀리초 단위로 두는 경우가 많음)는 “지금 쓰는 노드가 충분히 괜찮으면 조금 더 빠른 후보마다 무조건 갈아타지 말자”는 전환 완충대 역할을 합니다. 값이 너무 작으면 회선이 조금만 흔들려도 그룹 선택이 자주 바뀌고, 너무 크면 체감상 느린 노드에 오래 머무를 수 있습니다.

fallback은 proxies 배열의 위에서 아래 순서가 우선순위입니다. 헬스체크 결과 첫 번째로 정상인 노드를 고릅니다. 즉 “가장 빠른 노드”보다는 “지정한 순서에서 가장 먼저 살아 있는 노드”가 핵심입니다. 상용 회선에서 메인 DC와 백업 회선을 이미 정해 두었다면 fallback이 잘 맞습니다. 반면 후보 여섯 개 중 “지금 제일 빠른 아무거나”를 원하면 url-test 쪽이 맞습니다.

헬스체크 URL 고르기

url은 짧은 응답·낮은 페이로드를 선호합니다. 흔히 쓰는 것은 204나 짧은 바디를 돌려주는 엔드포인트입니다. 다만 특정 도메인이 소속국·업체 방화벽에서 막히면 모든 후보가 동시에 실패한 것처럼 보일 수 있으니, 자신의 네트워크에서 브라우저나 curl로 한 번 직접 열어보는 습관이 좋습니다. 또한 헬스체크만 특이하게 빠르고 실제 사이트는 막히는 경우도 있어, 최종 검증은 항상 실제 접속 대상으로 합니다.

interval은 초 단위로, 너무 짧으면 배터리·로그·업스트림 측에서 부담이 되고, 너무 길면 장애 반영이 늦습니다. 처음에는 보수적인 값에서 시작해 체감을 보며 조정하는 편이 안전합니다. 코어 버전에 따라 lazy 같은 옵션으로 “해당 그룹을 실제로 쓸 때만 적극적으로 재측정한다”에 가까운 동작을 제공하기도 하니, 사용 중인 빌드의 문서 허브와 릴리스 노트를 함께 확인하세요.

1proxies 이름 정리

그룹 YAML에 쓰는 문자열은 proxies 항목의 name과 완전히 동일해야 합니다. 구독에서 한꺼번에 들어온 이름을 손으로 줄이거나 통일하지 않으면, 저장 직후 구성 오류로 코어가 뜨지 않거나 해당 줄만 빠집니다. GUI를 쓰면 자동으로 맞춰 주는 경우도 있지만, 텍스트로 합치는 워크플로에서는 이름표를 한 번 목록으로 적어 두고 복붙하는 방식이 실수를 줄입니다.

2url-test: 지연 최소 자동 선택 예시

아래는 개념을 잡기 위한 스케치입니다. 실제 프로필에 넣을 때는 노드 이름·URL·숫자를 환경에 맞게 바꿉니다.

# Sketch — merge into your real profile; proxy names must exist under proxies:
proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - "tokyo-A"
      - "tokyo-B"
      - "seoul-C"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "PROXY"
    type: select
    proxies:
      - AUTO-BEST
      - "tokyo-A"
      - DIRECT

AUTO-BEST가 주기적으로 세 노드를 재고, 그중에서 선택합니다. 상위 PROXY select에 AUTO-BEST를 넣어 두면 사용자는 클라이언트에서 PROXY만 고르도록 하고, 실제 출구는 AUTO-BEST가 결정하게 할 수 있습니다. tolerance를 넉넉히 두면 “조금 더 빠른데 큰 차이 없음”에서는 불필요한 스위칭이 줄어듭니다.

3fallback: 주·예비 순서 예시

# Sketch — order in `proxies` is priority for fallback
proxy-groups:
  - name: "MAIN-THEN-BACKUP"
    type: fallback
    proxies:
      - "corp-primary"
      - "corp-backup"
      - "tokyo-A"
      - DIRECT
    url: "http://cp.cloudflare.com/generate_204"
    interval: 180

  - name: "PROXY"
    type: select
    proxies:
      - MAIN-THEN-BACKUP
      - DIRECT

MAIN-THEN-BACKUP은 위에서부터 헬스체크를 통과한 첫 업스트림을 고릅니다. 메인이 살아 있으면 백업은 대기하고, 메인이 실패 상태로 분류되면 한 단계씩 내려갑니다. 마지막에 DIRECT를 두면 “프록시가 전부 불량일 때만 직접 연결” 같은 운영 정책을 표현할 수 있지만, 보안·규정상 DIRECT가 허용되지 않는 환경이라면 빼야 합니다.

4rules에서 정책 그룹 가리키기

그룹을 아무리 잘 만들어도 rules가 다른 이름을 가리키면 효과가 없습니다. 흔한 패턴은 MATCH,PROXY처럼 마지막에 넓게 잡고, 특정 도메인만 별도 그룹으로 보내는 것입니다. HTTPS에서 호스트가 안 보일 때는 Sniffer로 SNI를 복원한 뒤 DOMAIN 규칙이 의미를 갖습니다. GEOIP나 광역 IP-CIDR이 먼저 매칭되면 아래쪽의 세밀한 줄은 실행되지 않으니, 규칙 순서를 다시 그리는 일이 자주 같이 붙습니다.

rules:
  - DOMAIN-SUFFIX,internal.corp.example,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위에서 PROXY는 앞 절의 select 그룹 이름입니다. 그 안에 AUTO-BEST나 MAIN-THEN-BACKUP을 넣어 두었으면, 규칙은 그대로 PROXY만 바라보게 두고 내부 선택 로직만 바꾸는 식으로 운영하면 사용자 입장의 조작은 단순해집니다.

5검증: 로그·Yacd·실사이트

설정이 반영됐는지 확인하는 최소 루틴은 다음과 같습니다. (1) 프로필 저장 후 코어가 에러 없이 올라오는지 (2) 외부 컨트롤러를 켰다면 Yacd 등에서 해당 proxy-groups의 선택된 멤버·지연이 갱신되는지 (3) 실제로 문제가 되던 사이트를 새로고침해 보고, 동시에 연결 로그에서 정책 이름이 기대한 그룹인지 봅니다. 한 번에 변수를 여러 개 바꾸면 원인 추적이 어려워지므로, interval·tolerance·헬스 URL은 하나씩만 조정하는 습관이 좋습니다.

노드가 바뀌는 순간 기존 TCP·TLS 세션이 끊기고 앱이 재접속을 시도하는 일이 흔합니다. 채팅·동기화 앱에서 “잠깐 로딩”이 보일 수 있어, 장애 대응이 아니라면 과도하게 짧은 interval과 지나치게 공격적인 tolerance를 동시에 주지 않는 것이 체감 품질에 유리합니다. WebSocket·장기 연결 이슈는 Notion·WebSocket 안정화 글의 관점과도 맞닿아 있습니다.

흔한 실수와 DNS

첫째, 그룹 이름 오타로 규칙이 엉뚱한 정책을 가리키는 경우입니다. 둘째, DNS가 코어 밖에서 해석되어 “노드는 바뀌었는데 사이트는 여전히 안 된다”는 패턴입니다. FakeIP·DoH·TUN 하이재크 등은 DNS 유출 방지 글의 순서를 따르는 것이 안전합니다. 셋째, GUI의 수동 선택이 코어의 자동 선택을 덮어쓰는 경우입니다. 테스트할 때는 클라이언트에서 해당 그룹이 자동 그룹을 가리키는지 다시 확인하세요.

넷째, 중첩 그룹을 쓸 때 순환 참조에 가깝게 이름을 엮으면 로드 오류가 납니다. 다섯째, 업스트림 풀 자체가 모두 불안정하면 url-test·fallback 어떤 것을 써도 한계가 있습니다. 이때는 구독 품질·회선 자체를 점검하고, 필요하면 구독 새로고침·403·타임아웃 글에서 URL·User-Agent·직접 연결 경로를 먼저 정리하는 편이 낫습니다.

오픈소스 정보와 설치 패키지

Mihomo의 소스·이슈·라이선스는 GitHub에서 확인할 수 있지만, 클라이언트 설치 파일의 주된 진입점으로는 이 사이트의 다운로드 페이지를 권장합니다. 저장소 링크는 신뢰·투명성용으로 두고, 실제 설치는 허브에서 플랫폼에 맞게 고르면 혼선이 줄어듭니다. 전체 옵션 지도는 문서·설정 허브와 함께 보시면 됩니다.

맺음말

url-test는 “지금 가장 빠른 후보”를, fallback은 “정해 둔 순서에서 살아 있는 첫 후보”를 고르게 만드는 proxy-groups 패턴입니다. 둘 다 헬스체크 URL·interval·(url-test의) tolerance를 손봐야 하며, 최종적으로는 rules가 그룹 이름을 정확히 가리키고 DNS·Sniffer·규칙 순서가 같은 전제를 공유해야 합니다. 이 다섯 가지를 한 번에 맞추면 “자동 전환이 안 되는 것 같다”는 증상 대부분이 “측정은 되는데 규칙이 다른 그룹을 탄다” 또는 “DNS만 따로 나간다”처럼 관측 가능한 원인으로 좁혀집니다.

같은 Clash Meta 계열이라도 GUI마다 YAML 편집 경로가 다르니, 본문의 스케치를 그대로 복사한 뒤 저장 → 로그 확인 → 실사이트 검증의 짧은 루프를 여러 번 도는 것이 가장 빠릅니다. 다른 도구에 비해 코어 로그와 정책 이름의 대응이 읽기 쉬운 편이라, 한 번 틀을 잡아 두면 이후 운영 시간이 줄어듭니다.

→ Clash를 무료로 다운로드하고, url-test·fallback 헬스체크를 프로필에 반영해 자동 전환을 검증해 보세요