url-test 정책 그룹이 하는 일

Clash·미호모 계열 코어에서 proxy-groups의 type: url-test는 «여러 후보 노드 중 지금 당장 가장 응답이 빠른 것 하나»를 골라 쓰기 위한 모드입니다. 사용자가 UI에서 매번 국가를 바꾸지 않아도, 정해진 주기(interval)마다 각 노드로 짧은 HTTP 요청을 보내 왕복 시간을 재고, 그 결과를 바탕으로 선택을 갱신합니다. 이 측정 요청이 곧 흔히 말하는 헬스 체크(health check)에 해당하며, url에 적은 주소가 “어디까지 연결되면 살아 있다고 볼지”의 기준이 됩니다.

rules에서 어떤 도메인이나 MATCH가 이 그룹 이름을 가리키면, 실제 아웃바운드는 그 시점에 url-test가 고른 단일 프록시로 결정됩니다. 그래서 «규칙은 그대로인데 쓰는 노드만 자동으로 바뀐다»는 체감이 생기며, 한국·해외 혼합 회선에서 유동적인 지연 변화를 어느 정도 흡수하는 데 유리합니다. 반대로 말하면, 측정 URL과 네트워크 상태가 꾸준히 들쭉날쭉하면 선택도 함께 출렁일 수 있어 tolerance와 interval 조정이 필요합니다.

한 줄로 url-test는 «목록 전체에 테스트 요청 → 지연 비교 → 최저 지연 선택»입니다. 이름만 같고 실제 노드 연결이 끊기면 테스트 자체가 실패해 다른 후보로 넘어가려 합니다(구현·버전·타임아웃 설정에 따라 세부 동작은 차이가 있을 수 있습니다).

YAML에서 꼭 채우는 필드: type·proxies·url·interval

실무에서 가장 많이 쓰는 최소 형태는 name, type: url-test, proxies 목록, url, interval 다섯 축입니다. proxies에는 반드시 proxies 섹션에 이미 정의된 단일 노드 이름이 들어가야 하며, 다른 정책 그룹 이름만 잔뜩 넣으면 의도와 다르게 동작하거나 구성 오류가 날 수 있습니다. 자동 선택용으로 구독에서 내려준 수십 개 노드를 전부 나열하기도 하고, 지역별로 먼저 select로 나눈 뒤 그 안에 소수만 url-test에 넣기도 합니다. 후자는 «한국·일본·미국 중 사용자가 고른 지역 안에서만 자동» 같은 UX를 만들 때 유리합니다.

url은 코어가 GET 등으로 요청할 테스트 주소입니다. interval은 초 단위 주기로, 값이 작을수록 반응은 빨라지지만 백그라운드 요청이 잦아지고 배터리·로그양이 늘 수 있습니다. 노트북을 끼고 다니거나 모바일 테더링 환경이라면 너무 짧은 간격은 부담이 될 수 있으니, 체감 끊김 없는 범위에서 현실적인 숫자를 잡는 편이 좋습니다. 아래는 이름만 예시로 든 최소 예입니다.

proxy-groups:
  - name: "자동"
    type: url-test
    proxies:
      - "노드-A"
      - "노드-B"
      - "노드-C"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

위 예에서 자동이라는 그룹은 규칙 마지막 MATCH,자동 같은 식으로 참조됩니다. 이미 규칙 분기 가이드에서 익숙하다면, 여기서는 «MATCH가 가리키는 대상이 곧 url-test 그룹»이라고 이해하면 됩니다.

테스트 URL(헬스 체크 주소) 고르기

테스트 URL은 “실제 스트리밍·Git·회사 VPN과 동일한 서버”일 필요가 없습니다. 대신 응답이 가볍고, 지역·시간대에 따라 과도하게 막히지 않으며, 리다이렉트 케이스가 적은지가 중요합니다. 커뮤니티 예제에 자주 나오는 generate_204류는 바디가 거의 없어 트래픽 부담이 적은 편입니다. 다만 어떤 엔드포인트는 특정 네트워크에서만 빠르게 보이거나, 일시적으로 지연 폭이 클 수 있으니 «웹 브라우저로는 빠른데 코어 테스트만 튄다»면 주소 교체를 먼저 검토하세요.

또 한 가지는 측정 결과가 기대하는 실사용 경로와 너무 다른지입니다. 예를 들어 테스트만 미국 CDN으로 가고, 실제로는 아시아 엣지를 쓰는 서비스 위주라면 자동 선택이 체감과 어긋날 수 있습니다. 완벽한 상관관계를 맞추긴 어렵지만, 장애 시 백업 위주라면 fallback 계열을 같이 두는 식으로 역할을 나누는 경우도 많습니다. 넷플릭스·챗봇 API처럼 목적지가 뚜렷하면 별도 select나 전용 그룹으로 빼고, 일반 웹 서핑만 url-test에 맡기는 식의 정책 분리가 디버깅에 유리합니다.

과신하지 말 것 테스트 URL에서의 지연이 항상 «YouTube 4K 재생 지연」이나 «SSH 체감»과 같지는 않습니다. 코어 로그와 브라우저 개발자 도구를 섞어 보는 편이 안전합니다.

tolerance와 lazy: 전환 흔들림·백그라운드 부담 줄이기

tolerance는 밀리초(ms) 단위로 자주 쓰이며, 현재 선택된 노드와 후보 노드 사이의 지연 차이가 이 값 안에 있으면 굳이 더 “조금 빠른” 쪽으로 갈아타지 않고 기존 선택을 유지하려는 완충 역할을 합니다. 와이파이·LTE 환경에서는 같은 노드라도 숫자가 조금씩 흔들리므로, tolerance가 너무 작으면 UI에서 노드가 잦게 바뀌는 것처럼 보일 수 있습니다. 반대로 너무 크게 잡으면 실제로 느려진 노드를 오래 붙잡는 일이 생기니, 사용 중 끊김이 느껴지면 점진적으로 줄여 보는 식으로 조정하는 편이 실용적입니다.

lazy: true는 url-test 그룹이 아직 트래픽에 선택되지 않았을 때 주기 테스트를 완전히 돌리지 않거나(클라이언트·코어 조합에 따라 표현이 다름) 백그라운드 측정 빈도를 줄이려는 옵션입니다. 노트북을 덮어 두었을 때 불필요한 요청을 줄이는 데는 도움이 될 수 있지만, 그룹을 처음 켠 직후에는 측정이 채 끝나기 전이라 “잠깐 느린 노드가 선택”된 듯 보일 수 있습니다. 이때는 lazy를 끄거나, 최초 한 번은 수동 select로 안정적인 노드를 고정한 뒤 자동으로 넘기는 우회도 흔합니다.

일부 고급 옵션으로 expected-status나 UDP 관련 스위치 등이 버전별로 존재할 수 있습니다. 공식 문서와 사용 중인 코어 버전 릴리스 노트를 함께 보는 것이 가장 안전합니다. 코어 업데이트 절차는 미호모 코어 업그레이드 가이드를 참고하세요.

url-test와 fallback·select를 어떻게 나누면 좋나

select는 사용자가 직접 고르는 UI 중심이고, fallback은 목록 순서대로 살아 있는 것을 찾아가는 패턴에 가깝습니다. «항상 1번 한국, 죽으면 2번 일본» 같은 고정 우선순위가 중요하면 fallback이 어울리고, «순서보다 당장 지연이 낮은 쪽»이 중요하면 url-test가 어울립니다. 실무에서는 상위에 select로 «자동·수동·직접연결」을 두고, 자동 아래에 url-test, 스트리밍 전용은 별도 그룹으로 쪼개는 구조가 읽기 쉽습니다.

또한 url-test는 주기적으로 측정 트래픽이 나가므로, 데이터 요금·로그 정책·기업망 모니터링 같은 환경에서는 간격과 lazy를 보수적으로 잡는 것이 좋습니다. 반면 24시간 서버에 올린 게이트웨이용 Clash라면 조금 더 공격적인 interval을 쓸 여지가 있습니다.

클라이언트에서 확인할 것: 프로필 적용·지연 표시·로그

Clash Verge·Clash for Windows·안드로이드용 포크 등 GUI 제품은 내부적으로 같은 YAML을 읽지만, «그룹 편집」 화면에서 필드 이름이 다르게 보이거나 일부 옵션을 숨겨 두기도 합니다. 공통적으로 할 일은 (1) 수정한 프로필이 실제로 코어에 적용되었는지, (2) 대시보드에서 각 노드·그룹 옆 지연 숫자가 주기적으로 갱신되는지, (3) 문제 시 코어 로그에 테스트 요청 실패·타임아웃이 반복되는지 확인하는 것입니다. 외부 컨트롤러 API를 쓰는 환경이라면 REST 응답으로도 비슷한 정보를 볼 수 있으나, 보안상 로컬에서만 열어두는 것이 원칙입니다.

프로필을 Git이나 클라우드에 올려 공유하는 팀이라면, url-test의 url을 누가 바꿨는지 추적 가능하게 두는 편이 낫습니다. 특정 국가 전용 엔드포인트를 넣었다가 해외 동료가 불러 쓸 때 오탐이 나는 일도 있기 때문입니다. 장애 순서를 로그로 따라가려면 분기 디버깅·MATCH 규칙 로그 가이드와 함께 보는 것이 좋습니다. DNS 모드에 따라 도메인 기반 규칙이 기대와 다르게 매칭될 때도 있으니, fake-ip 관련 글이 필요하면 fake-ip 대 redir-host 글을 참고하세요.

자주 막히는 지점: 전환 과다·전부 타임아웃·규칙 미적용

첫째, 노드 이름 불일치입니다. 구독이 갱신되며 노드 이름이 바뀌었는데 url-test 목록이 옛날 문자열을 가리키면 테스트 대상이 비어 있거나 오류가 납니다. 둘째, 테스트 URL 자체 장애입니다. 특정 시간대에만 느린 CDN이면 모든 노드가 동시에 “나쁨”으로 보일 수 있습니다. 셋째, interval이 과도하게 짧고 tolerance가 낮아 UI에서 깜빡이는 것처럼 느껴지는 경우입니다. 넷째, 규칙에서 url-test 그룹이 아닌 다른 그룹을 가리키거나, 더 위 규칙 줄에 가로막혀 MATCH까지 도달하지 못하는 경우입니다. 이는 로그의 matched rule 출력으로 확인하는 것이 가장 빠릅니다.

모든 노드가 동시에 타임아웃이면 먼저 시스템 시간·DNS·방화벽을 의심하고, 한 노드만 이상하면 그 노드 품질이나 프로토콜 호환 문제를 봅니다. DIRECT는 url-test 후보에 넣는 경우가 가끔 있는데, 이 경우 측정 의미가 섞이므로 초보 설정에서는 피하는 편이 낫습니다.

버전 차이 미호모(Clash Meta)와 구형 코어는 필드 기본값·지원 범위가 다를 수 있습니다. 이 글은 최신 메이저 기준 일반화한 설명이며, 실제 적용 전 해당 버전 문서를 한 번 더 확인하세요.

자주 묻는 질문

url-test만으로 “서비스별 최적 노드”를 완벽히 맞출 수 있나요?

어렵습니다. 테스트는 특정 URL로의 지연만 보여 줄 뿐이고, 지역 제한·UDP 의존 RTC·P2P는 별도 설계가 필요합니다. 서비스별로는 도메인 규칙과 전용 그룹을 병행하는 편이 현실적입니다.

interval을 10초 이하로 짧게 쓰면 좋지 않나요?

반응은 빨라질 수 있지만 배터리·로그·일부 취약 공유기 환경에서 부작용이 생길 수 있습니다. 먼저 tolerance와 URL 안정성부터 맞춘 뒤, 필요할 때만 단축하는 식을 권합니다.

구독에 있는 모든 노드를 다 넣을까요?

가능은 하지만 측정 대상이 많아질수록 주기 요청 수가 늘고, 의미 없는 후보까지 비교하게 됩니다. 지역별·프로바이더별로 먼저 묶어 줄이는 편이 관리와 체감 모두에 유리한 경우가 많습니다.

마무리

url-test는 «자동으로 빠른 노드»를 만들어 주는 강력한 스위치지만, 테스트 URL·interval·tolerance·lazy가 서로 맞물려야 실사용에서도 안정적으로 느껴집니다. 규칙 전체 구조와 Rule Providers, MATCH 순서는 계속 YAML 규칙 가이드의 흐름을 따르는 것이 좋고, 잘 안 맞을 때는 로그 기반으로 어느 규칙에 걸렸는지부터 확인하면 원인 추적 시간이 줄어듭니다.

일부 범용 프록시 도구는 그래프만 화려할 뿌러 프로필 검증·규칙 순서·코어 버전 호환을 사용자에게 떠넘기기 쉽고, url-test 같은 고급 그룹은 옵션 이름조차 문서화가 부족한 경우가 많습니다. ClashNote가 안내하는 Clash·미호모 생태계는 YAML을 한 장으로 추적하기 쉽고, 구독·정책 그룹·코어 업데이트를 같은 흐름에서 묶을 수 있다는 점에서 장기 운영에 유리합니다. 설정을 자주 갈아엎기보다 검증된 클라이언트에 프로필을 안정적으로 올려 두는 편이 결국 시간을 아깁니다.

→ Clash 무료 다운로드로 데스크톱·모바일용 클라이언트를 받고, url-test를 포함한 프로필을 적용·백업하기 쉬운 구성으로 시작해 보세요.

추가 주제는 기술 칼럼에서 계속 다루며, 같은 증상이라도 단말·코어 조합마다 최선의 숫자는 다를 수 있다는 점만 기억해 두시면 됩니다.