Windows 11 Clash Verge Rev: Mihomo url-test 전략 그룹 헬스 체크(URL·interval·tolerance) 설정

이 글이 맞는 상황인가요?

Windows 11에서 Clash Verge Rev로 Mihomo(Clash Meta) 프로필을 돌리는데, url-test 타입 전략 그룹이 짧은 간격마다 노드를 갈아타거나 반대로 느린 노드에 오래 머무르는 문제로 스트레스를 받는다면 이 문서가 좋습니다. TUN 전반이나 DNS fake-ip 전체 흐름은 다른 글과 역할을 나누고, 헬스 체크 URL·interval(재측정 주기)·tolerance(허용 오차)만 따로 다룹니다. 설치·스마트스크린·구독 넣기는 Clash Verge Rev 전체 가이드, 프록시 화면에서 그룹 유형 익히기는 전략 그룹·측속 편과 이어집니다.

Mihomo 설정의 proxy-groups에서 type: url-test로 선언된 블록은 주기적으로 같은 기준으로 후보 프록시를 재측정하고, 조건을 만족하면 자동으로 출구를 바꿉니다. 사용자 입장에서는 “자동” 그룹으로 보이지만, 실제 안정성은 YAML에 있는 url·interval·tolerance 숫자가 거의 좌우합니다. 기본값을 무조건 의심할 필요는 없고, 자신의 네트워크에서 패턴만 보이면 그때 손대는 편이 안전합니다.

용어: UI에서 보이는 전략 그룹 이름은 구독 제공자가 지은 라벨과 같습니다. 규칙이 어떤 그룹 이름을 가리키는지 모르겠다면 규칙 분할 가이드로 맥락을 잡고 돌아오면 됩니다.

url-test가 하는 일과 한계

코어는 url에 적힌 주소까지의 연결·간단한 HTTP 수준 측정을 바탕으로 후보별 지연을 비교합니다. 보통 TCP TLS 왕복 성격이 강해, 장시간 대역폭이나 UDP 음성·게임 품질과는 항상 일치하지 않습니다. 그래서 “자동으로 가장 빠른 줄만 고른다”는 말은 반만 맞습니다. 지정한 한 점의 합성 지표에 가장 잘 맞는 후보를 고르는 것에 가깝습니다.

테스트 URL이 특정 클라우드 엣지나 지역 정책 때문에 간헐적으로만 실패하면, 실제 앱은 멀쩡한데도 그룹 전체가 바뀌거나 반대로 계속 실패로 찍히는 모순이 생깁니다. 이런 때는 먼저 헬스 URL 자체를 교체하거나, 실패 로그가 DNS·차단·타임아웃 중 무엇인지 나눕니다. 노드 품질과 무관한 측정 목표를 쓰고 있으면 tolerance만 만져서는 근본 해결이 안 되는 경우가 많습니다.

1단계: 테스트 URL(url) 고르기

좋은 헬스 체크 URL은 대체로 다음을 만족합니다. 응답이 가볍다. 과도한 302 체인이 없다. 대부분의 후보 지역에서 443 근처로 닿는다. 구독에 이미 들어 있는 글로벌 엔드포인트가 본인 회선에서도 안정적이면 그대로 두어도 됩니다. 가끔 중국 본토·해외를 가리는 템플릿이 섞여 있어 특정 풀에서만 전 멤버가 빨간색이 되기도 하니, 그때는 같은 역할을 하는 다른 HTTPS 소량 응답 URL로 교체해 보는 것이 첫 수순입니다.

직접 고른다면 회사나 학교망 정책으로 막히지 않는지, 브라우저에서 동일 회선으로 한 번 열어 보는 정도의 검증은 필요합니다. Verge Rev의 로그에서 해당 호스트에 대한 타임아웃이 반복되는지 함께 보면 원인 분리가 빨라집니다. DNS fake-ip와 규칙이 꼬여 실제 앱 트래픽과 측정 경로가 다를 가능성은 지연·UDP·DNS 트러블슈팅 참고가 좋습니다.

팁: 스트리밍 전용 그룹을 url-test로 돌리면서 카탈로그 지역이 자꾸 바뀐다면, 자동보다 select로 고정 출구를 쓰는 편이 사용자 경험이 더 나은 경우가 많습니다. 이 글의 튜닝은 “회선이 자주 흔들리는 일반 인터넷 자동 그룹”에 특히 잘 맞습니다.

2단계: interval(재측정 주기) 현실적으로 잡기

interval은 초 단위입니다. 값이 작을수록 장애 노드에서 빠르게 이탈하지만, 모든 후보에 대해 자주 연결을 시도하므로 배터리·CPU 부하와 구독 업스트림 부담이 커집니다. 무선 LAN에서는 아주 짧은 interval이 순간 지터만으로도 우승자를 자주 바꿔 체감이 들쭉날쭉해질 수 있습니다.

현실적인 접근은 기본값에서 시작해 증상 중심으로 조정하는 것입니다. 노드가 도미노처럼 갈아타면 interval을 약간 늘리고, 장애에 수 분 동안 묶여 있다면 늘리기보다 url 신뢰도를 먼저 의심한 뒤 interval을 소폭 줄입니다. 집과 이동, 저녁 피크 시간대를 나눠 한 주 정도 관찰하면 자기에게 맞는 구간이 보입니다.

3단계: tolerance(허용 오차)로 깜빡임 줄이기

tolerance는 밀리초 단위입니다. 최적 후보가 현재 선택보다 조금 나아졌다고 해서 곧바로 갈아타지 않고, 차이가 tolerance를 넘을 때만 바꾸려는 여유를 줍니다. 값이 너무 좁으면 소폭의 지연 변동에도 스위칭이 잦아지고, 너무 넓으면 분명 더 나은 노드가 있는데도 오래 붙잡아 체감 속도만 떨어질 수 있습니다.

세션 유지가 중요한 화상 회의·원격 데스크톱·긴 다운로드에는 다소 넓은 tolerance가 심리적으로 편할 때가 있습니다. 반대로 짧은 요청이 잦은 일반 브라우징에서는 상대적으로 좁혀 반응성을 살릴 여지가 있습니다. 숫자는 프로필·노드 풀마다 최적점이 달라서, 한 번에 완벽한 상수를 외울 필요는 없습니다.

프로필에서 보는 YAML 예시

이름과 후보 목록은 구독마다 다릅니다. 구조만 참고하세요.

proxy-groups:
  - name: "♻️ 자동"
    type: url-test
    proxies:
      - 서버-A
      - 서버-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

일부 Mihomo 빌드에서는 lazy: true처럼 실제로 그 그룹을 쓰기 전까지 적극 측정을 줄이는 옵션이 있습니다. 노트북 배터리에는 도움이 될 수 있지만, 첫 연결 직후 잠시 이전 선택이 남아 있는 느낌이 든다면 끄거나 완화해 볼 수 있습니다. 지원 여부는 사용 중인 코어 버전 문서를 확인하세요.

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

Windows 11에서는 Verge Rev에서 프로필 편집을 열고 proxy-groups 블록을 찾아 해당 그룹의 url·interval·tolerance를 수정합니다. 저장 뒤 코어가 자동으로 다시 읽는지, 아니면 앱 재시작이나 코어 재시작 메뉴가 필요한지 빌드마다 다르므로 변경 직후 한 번 확인합니다.

TUN을 쓰는 환경에서는 관리자 권한·다른 VPN과의 동시 사용처럼 라우팅이 꼬이면 헬스만 간헐 실패하는 패턴도 나옵니다. 이때는 숫자만 만지지 말고 경로 전체를 잠깐 끊고 재현해 보는 편이 빠릅니다. 절전에서 깨어난 직후 NIC이 재초기화되며 잠깐 모든 체크가 실패하는 경우도 있어, 그 직후에는 수십 초 기다리거나 UI의 일괄 측정으로 스냅샷을 갱신하는 습관이 도움이 됩니다.

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

현장용 튜닝 워크플로

아래 순서를 한 사이클 돌리면 원인이 숫자 문제인지 URL 문제인지 빠르게 갈립니다.

  1. 문제가 나는 시간대에 활성 프로필과 시스템 프록시/TUN 상태를 확인한다.
  2. 해당 url-test 그룹에서 같은 후보를 수동으로 바꿔 실제 앱 체감이 달라지는지 본다.
  3. 로그에서 헬스 실패·타임아웃이 특정 호스트에만 반복되는지 본다.
  4. url을 검증한 뒤, 깜빡임이면 interval↑ 또는 tolerance↑를 소폭 적용한다.
  5. 반대로 장애 이탈이 너무 느리면 interval↓ 또는 tolerance↓를 아주 조금씩 시험한다.
  6. 한 번에 여러 변수를 바꾸지 말고, 한 항목씩만 조정해 차이를 기록한다.

자주 묻는 질문

tolerance를 키웠는데도 자꾸 갈아탑니다

interval이 매우 짧거나, 측정 url이 불안정해 숫자 자체가 크게 흔들리는 경우입니다. 두 값을 같이 점검하세요. 때로는 후보 풀 안에 구조적으로 불안정한 멤버가 섞여 있어 목록 정리가 필요합니다.

지연이 좋은데도 url-test가 안 바꿉니다

현재 노드와 최적의 차이가 tolerance 이내일 수 있습니다. 의도라면 정상이고, 아니면 tolerance를 소폭 줄이거나 규칙이 실제로 그 그룹을 타는지 추적하세요. 상위 그룹이 다른 자동 선택을 덮어쓰는 중첩 구조도 흔한 원인입니다.

구독 갱신에 덮어씌워집니다

원본 구독이 매번 같은 블록을 재생성한다면 편집이 사라집니다. 장기적으로는 복제 프로필·로컬 패치 패턴·제공자가 허용하는 커스터마이즈 방법을 확인해야 합니다.

마무리

Windows 11에서 Clash Verge Rev와 Mihomo를 쓸 때 url-test 전략 그룹의 안정성은 헬스 체크 URL이 현실적인지, interval이 네트워크 지터를 과대평가하지 않는지, tolerance가 불필요한 스위칭을 억제하는지 세 가지가 맞물려 결정됩니다. 숫자는 하루아침에 완벽해지기보다 며칠 쓰면서 미세 조정하는 쪽이 대부분입니다.

반면 버튼 위주로만 안내하는 일부 클라이언트는 proxy-groups 안을 잘 드러내지 않아, 자동 전환이 왜 그 노드에 붙었는지 역추적하기 어렵습니다. 구성 파일과 설명이 같은 흐름으로 열릴 때 장기 운영 피로가 확 줄고, 문제가 생겨도 조정 포인트가 분명해집니다. ClashSource는 Mihomo·Clash Verge Rev·구독 흐름을 한국어로 잇는 글과 검증된 다운로드 경로를 한곳에 모아 반복 시행착오를 줄이는 데 초점을 맞춥니다.

지금 프로필에서 url과 주기만 점검해 보고 싶다면 Clash Verge Rev 최신 빌드를 맞춘 뒤, 위 워크플로 순서대로 한 번 적용해 보세요. 자동 전환이 한층 예측 가능한 패턴으로 정리되는 경우가 많습니다.