Clash Meta 정책 그룹 url-test와 fallback: 자동 측정·장애 전환, lazy·tolerance까지

먼저 개념: 측정, 선택, 순서

select는 사람이 고르는 그룹이고, url-test와 fallback은 코어가 주기적 헬스 체크나 우선순위로 골라 줍니다. 둘 다 proxies 목록과 url, interval을 함께 쓰는 경우가 많지만 역할이 다릅니다. url-test는 후보 전체에 대해 같은 기준으로 RTT를 비교해 한 명의 승자를 고릅니다. fallback은 목록 위에서부터 상태가 나쁜 노드를 건너뛰며, 흔히 “주 → 예비 → 직접 연결” 같은 사고 대비 사슬을 만들 때 씁니다. 이 차이를 머리에 두면 규칙에서 어떤 그룹 이름을 찍을지가 선명해집니다.

1단계: url-test로 지연 기반 자동 노드

url-test 그룹은 url에 대한 HTTP 응답 시간을 기준으로 후보 proxies 가운데 하나를 선택합니다. 설정 파일에서 이름만 PROXY 규칙에 넣으면, 그 뒤로 나가는 트래픽은 모두 그 순간 승자 노드를 탑니다. interval은 몇 초마다 다시 재측정할지인데, 너무 짧으면 노드가 조금만 흔들려도 승자가 바뀌는 흔들림이 생기고, 너무 길면 “빠른 노드” 반영이 늦습니다. 일반 웹·API 용도로는 수백 초 단위가 흔하고, 장시간 스트리밍·음성·대형 다운로드처럼 세션 유지가 중요하면 더 긴 간격이나 아예 수동 그룹을 섞는 편이 낫습니다.

tolerance는 “새 후보가 기존 선택보다 이 정도 이상 빠를 때만 갈아탄다”는 완충입니다. 예를 들어 기본 승자 A가 120ms이고 B가 118ms라면 체감 차이는 없지만, 완충이 0에 가깝으면 매 사이클마다 A와 B가 바뀌는 플랩이 날 수 있습니다. 수십 ms 단위의 tolerance를 주면 “의미 있는 차이”가 있을 때만 전환해 TCP·TLS 세션이 자주 갈리는 것을 줄입니다.

2단계: lazy로 불필요한 측정 줄이기

lazy: true는 “이 정책 그룹이 실제로 선택되어 트래픽이 탈 때까지 헬스 체크를 미룬다”는 뜻에 가깝습니다. 구독 노드가 수십 개이고 url-test 그룹도 여러 개면, 시작 직후 전 후보에 HTTP 프로브가 돌아가며 CPU·대역·로그가 시끄러울 수 있습니다. 자주 쓰지 않는 그룹에는 lazy를 켜 두면 첫 사용 시점에만 측정이 붙습니다. 반대로 “항상 최신 지연을 유지해야 하는” 메인 출구 그룹이라면 lazy를 끄고 짧지 않은 interval로 안정적인 승자를 유지하는 편이 나을 때도 있습니다.

3단계: fallback으로 주·예비·직접 연결 사슬

fallback은 리스트 순서가 곧 우선순위입니다. 첫 번째 프록시가 헬스 체크에서 살아 있으면 그걸 쓰고, 죽었을 때만 두 번째로 넘어갑니다. 그래서 “일본 상용 노드 → 싱가포르 백업 → DIRECT” 같이 장애 시에만 의미 있는 대체를 넣기 좋습니다. DIRECT를 마지막에 두면 모든 프록시가 동시에 막혔을 때에만 국내 직접 연결로 빠져, 최소한의 연결성은 확보할 수 있습니다. 다만 직접 연결이 정책상 허용되지 않는 트래픽이라면 마지막을 다른 릴레이로 두어야 합니다.

4단계: 헬스 체크 URL(url) 고르기

측정 URL은 “내가 쓰는 노드 풀이 실제로 인터넷까지 열리는지”를 보는 용도입니다. 아주 가벼운 204 응답(generate_204 스타일)이나 소형 정적 페이지가 자주 쓰입니다. 중요한 점은 첫째, 해당 URL이 프록시 경로로 과도하게 차단·리다이렉트되지 않을 것, 둘째 응답이 너무 커서 대역을 잡아먹지 않을 것, 셋째 목표 지역/ISP와 무관한 글로벌 엣지라면 “그 지역 체감 속도”와는 다를 수 있다는 것입니다. 해외 AI·결제·스트리밍만 문제라면 규칙으로 그 도메인을 전용 그룹에 보내고, url-test의 URL은 범용 연결성 확인용으로 유지하는 구성이 흔합니다.

5단계: url-test와 fallback 조합

실무에서는 “자동으로 빠른 풀 하나 고르기”와 “그 풀 전체가 막혔을 때 다음 단계”를 함께 씁니다. 예를 들어 AUTO-JP를 url-test로 두고, 그다음 fallback에서 AUTO-JP → AUTO-SG → …처럼 지역별 풀을 순서만으로 묶을 수 있습니다. 또는 리프 노드만 url-test에 넣고, 그 결과를 다시 상위 규칙의 select에서 고르게 할 수도 있습니다. 핵심은 규칙이 가리키는 최종 그룹 이름이 한눈에 읽히게 만드는 것입니다. “MATCH, PROXY” 한 줄에 거대한 fallback을 붙이기보다, 목적별(AI, MEDIA, DEFAULT)로 쪼개 두면 트래픽 유형마다 interval·tolerance를 다르게 줄 수 있습니다.

YAML 예시

아래는 필드 설명용 예시입니다. 이름·노드는 구독에 맞게 바꾸고, 클라이언트가 YAML을 검증한 뒤 반영하세요.

# Illustrative snippet — replace proxy names with your subscription
proxy-groups:
  - name: AUTO-FAST
    type: url-test
    proxies:
      - TOKYO-01
      - TOKYO-02
      - OSAKA-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: RELIABLE-EXIT
    type: fallback
    proxies:
      - AUTO-FAST
      - SINGAPORE-BACKUP
      - DIRECT
    url: http://cp.cloudflare.com/generate_204
    interval: 300

rules:
  - MATCH, RELIABLE-EXIT

AUTO-FAST는 지연 경쟁, RELIABLE-EXIT는 그 결과가 죽었을 때 다음 후보로 넘어가는 흐름입니다. 실제 프로필은 rules 상단에 도메인·GEOIP 행이 수십 줄 있으니, 위 MATCH는 예시로만 보세요.

문제 해결: 플랩, 느린 전환, 잘못된 체감

노드가 몇 초마다 바뀐다면 tolerance를 늘리고 interval을 길게 하세요. 주 노드가 죽어도 백업으로 안 간다면 헬스 URL이 막혔거나 DNS가 꼬여 fallback이 “모두 불량”으로 찍히는 경우가 많습니다. 측정은 빠른데 실제 사이트는 느리다면 브라우저 대상 도메인이 다른 ASN·지역으로 나가고 있을 수 있으니 규칙 탭과 로그의 매칭 행을 함께 봅니다. 원격 규칙 세트를 고치면서 그룹 이름이 바뀌었는데 규칙만 옛 이름을 가리키는 실수도 자주 나옵니다—rule-provider 갱신 전후를 한 번씩 확인하세요.

증상	살펴볼 곳
승자가 자주 바뀜	tolerance, interval, 후보 풀 과다
백업으로 안 넘어감	헬스 URL 차단·타임아웃, fallback 순서·이름 오타
시작 시 부하만 큼	사용 빈도 낮은 그룹에 lazy: true

FAQ

DNS 설정에도 fallback이 있는데 같나요?

아니요. DNS의 fallback 네임서버 목록은 도메인 해석 실패 시 쓰는 별도 경로이고, proxy-groups의 fallback은 프록시 연결 우선순위입니다. 문서를 볼 때 섹션을 구분해 읽으면 혼동이 줄어듭니다.

load-balance는 언제 쓰나요?

여러 노드에 연결을 분산하고 싶을 때입니다. “가장 빠른 한 줄”이 아니라 세션 나눔이 목적이므로, 단일 긴 스트림 안정성과 트레이드오프가 있습니다. 자동 단일 선택이 목표면 url-test가 먼저입니다.

실무 체크리스트

마치며

Meta 계열에서 정책 그룹은 단순히 “자동”을 켜는 스위치가 아니라, 측정 주기·허용 편차·우선순위가 함께 움직는 작은 시스템입니다. 수치를 한 번에 바꾸기보다 로그로 플랩 여부를 보며 조정하면 같은 구독이라도 체감이 달라집니다.

Clash를 무료로 내려받고 설정을 바로 시험해 보세요