Clash 정책 그룹 유형 선택 가이드: url-test, fallback, load-balance 차이 완전 정리

정책 그룹: 트래픽의 분기점

Clash 설정 파일에서 rules는 「어떤 트래픽을 누구에게 넘길지」를 결정하고, proxy-groups는 「트래픽을 받은 그룹이 최종적으로 어느 노드로 나갈지」를 결정합니다. 수동으로 선택하는 select 그룹 외에도, Clash 커널(mihomo 포함)은 세 가지 자동 정책 그룹을 제공합니다: url-test, fallback, load-balance. 셋 다 노드를 수동으로 바꿀 필요는 없지만, 자동으로 판단하는 방식은 완전히 다릅니다. 하나는 지연 시간을 보고, 하나는 생존 여부를 보고, 하나는 분산 처리를 합니다.

결론부터 말하면, 일상적인 브라우징에서 신경 쓰기 싫다면 url-test를, 확실한 메인 노드가 있고 장애 대비용 전환만 필요하다면 fallback을, 여러 회선의 대역폭을 합치고 싶다면 load-balance를 쓰면 됩니다. 이제 하나씩 자세히 살펴봅니다.

url-test: 가장 낮은 지연 시간 노드가 담당

url-test는 가장 많이 쓰이는 자동 정책 그룹입니다. 동작 방식은 두 단계로 나뉩니다. interval초마다 그룹 내 각 노드가 url에 지정된 주소로 각각 테스트 요청을 보내 왕복 시간을 기록합니다. 새 연결이 이 그룹으로 들어오면, 커널은 가장 최근 측정에서 지연 시간이 가장 낮고 검사를 통과한 노드로 연결을 넘깁니다.

두 가지 파라미터가 실사용성을 좌우합니다.

tolerance: 허용 오차, 단위는 밀리초입니다. 후보 노드가 현재 노드보다 이 값만큼 더 빨라야 전환이 발생합니다. 여러 노드의 지연 시간이 비슷할 때 허용 오차가 없으면 계속 흔들리며 연결이 반복적으로 재생성됩니다.
lazy: 활성화하면 해당 그룹에 트래픽이 흐를 때만 속도를 측정하고, 비활성화하면 interval에 따라 백그라운드에서 계속 측정합니다. 노드 수가 많은 구독은 활성화 상태를 유지해 불필요한 측정 트래픽을 줄이는 것이 좋습니다.

proxy-groups:
  - name: 자동 최적화
    type: url-test
    proxies:
      - 홍콩 01
      - 홍콩 02
      - 일본 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100
    timeout: 5000

흔한 오해 하나를 짚어보면, 지연 시간이 낮다고 속도가 빠른 것은 아닙니다. 204 테스트는 작은 요청의 왕복 시간을 재는 것으로 회선의 응답 속도만 보여줄 뿐 대역폭 크기와는 무관합니다. 대용량 파일 다운로드가 느리다면 노드를 잘못 골랐다기보다 그 노드 자체의 대역폭이 작을 가능성이 큽니다.

활용 시나리오: 같은 지역에 품질이 비슷한 노드가 여러 개 있을 때, 일상적인 웹서핑, 스트리밍, 일반 다운로드는 이 그룹이 알아서 선택하게 두면 됩니다. mihomo는 expected-status를 추가로 지원해 예상 응답 상태 코드를 지정할 수 있으며, 테스트 결과가 예상과 다르면 해당 검사를 실패로 판정해 「연결은 되지만 응답이 이상한」 회선을 걸러낼 수 있습니다.

fallback: 메인 노드가 죽어야 전환

fallback은 지연 시간을 비교하지 않고 연결 가능 여부만 판단합니다. proxies 목록의 순서를 엄격히 따르며, 항상 목록에서 헬스 체크를 통과한 첫 번째 노드를 사용합니다. 현재 노드가 연속으로 max-failed-times 횟수만큼 실패하면 사용 불가로 표시되어 트래픽이 다음 사용 가능한 노드로 자동 전환되고, 앞 순위 노드가 다시 정상화되면 자동으로 되돌아갑니다.

proxy-groups:
  - name: 장애 조치
    type: fallback
    proxies:
      - 전용선 메인
      - 백업 중계 A
      - 백업 중계 B
    url: http://www.gstatic.com/generate_204
    interval: 120
    max-failed-times: 3

url-test와의 본질적인 차이는, url-test는 「모두 사용 가능한」 노드 중 가장 빠른 것을 고르지만 fallback은 오직 순서만 따진다는 점입니다. 백업 노드의 지연 시간이 더 낮더라도 절대 먼저 전환하지 않습니다. 이는 흔한 상황과 딱 맞아떨어집니다. 메인은 비싸지만 안정적인 전용선이고 백업은 일반 회선일 때, 평소에는 단 1밀리초도 트래픽이 백업으로 새어나가는 것을 원치 않는 경우입니다.

헬스 체크 간격은 장애 감지 속도를 결정하므로, fallback의 interval은 url-test보다 짧게, 예를 들어 120초로 설정할 수 있습니다. 이보다 더 줄여도 큰 의미는 없고 테스트 트래픽과 로그 노이즈만 늘어납니다.

load-balance: 여러 회선에 연결을 분산

앞의 두 그룹은 어느 시점에든 출구 노드가 하나뿐이지만, load-balance는 그룹 내 노드들이 동시에 일하게 합니다. 새 연결마다 strategy에 지정된 전략에 따라 서로 다른 노드로 분배됩니다.

consistent-hashing(기본값): 목적지 주소를 해시로 계산해 같은 사이트로 향하는 연결은 항상 같은 노드로 고정됩니다. 사이트 입장에서는 출구 IP가 안정적으로 유지되므로 일상적인 혼합 사용에 적합합니다.
round-robin: 연결마다 순서대로 노드를 돌려가며 사용합니다. 멀티 스레드 다운로드 도구가 한 번에 수십 개의 연결을 만들 때 트래픽이 균등하게 분산되어 여러 회선의 대역폭을 합칠 수 있습니다.

proxy-groups:
  - name: 로드밸런싱
    type: load-balance
    proxies:
      - 노드 A
      - 노드 B
      - 노드 C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: round-robin

대가도 명확합니다. 연결마다 서로 다른 출구 IP로 나가게 됩니다. 인터넷뱅킹, 결제, 계정 로그인처럼 IP 일관성에 민감한 서비스는 출구가 자주 바뀌면 이상 탐지에 걸리기 쉬워, 재인증을 요구받거나 심하면 로그인이 일시 제한될 수 있습니다. 안전한 방법은 규칙으로 이런 도메인을 별도로 고정 노드나 직접 연결로 지정하고, 나머지 트래픽만 로드밸런싱 그룹으로 보내는 것입니다.

세 가지 정책 그룹, 어떻게 고를까

구분	url-test	fallback	load-balance
선택 기준	가장 낮은 지연 시간	목록 순서상 첫 번째 가용 노드	전략에 따라 연결마다 분배
동시 출구	단일 노드	단일 노드	다중 노드 병렬
전환 트리거	측정 결과 변화가 허용 오차 초과	현재 노드 헬스 체크 실패	새 연결이 생성될 때마다
대표 시나리오	일상 브라우징 자동 최적화	메인-백업 이중화	멀티 스레드 다운로드, 대역폭 합산
주요 한계	지연 시간만 측정, 대역폭은 측정 안 함	백업이 빨라도 먼저 전환하지 않음	연결마다 출구 IP가 바뀜

한 줄 요약: 노드 품질이 비슷하고 신경 쓰기 싫다면 url-test, 노드에 명확한 등급이 있고 장애 대비만 필요하다면 fallback, 처리량을 우선하며 출구 IP 변동을 감수할 수 있다면 load-balance입니다. 판단이 어렵다면 우선 url-test부터 만들어 보세요. 대부분의 일상적인 요구를 충족합니다.

조합 사용법과 흔한 실수

정책 그룹은 서로 중첩해서 쓸 수 있으며, 그룹 이름 자체가 유효한 멤버로 취급됩니다. 흔한 방식은 자동 그룹을 하나의 select 그룹 안에 넣고 rules는 가장 바깥쪽 그룹만 참조하는 것입니다.

proxy-groups:
  - name: 메인 프록시
    type: select
    proxies:
      - 자동 최적화
      - 장애 조치
      - DIRECT
  - name: 자동 최적화
    type: url-test
    proxies:
      - 홍콩 01
      - 홍콩 02
      - 일본 01
    url: http://www.gstatic.com/generate_204
    interval: 300

평소에는 「자동 최적화」로 트래픽이 흐르게 두고, 고정된 출구가 필요할 때는 클라이언트의 프록시 페이지에서 「장애 조치」나 DIRECT로 수동 전환하면 되며, 규칙 파일은 한 줄도 건드릴 필요가 없습니다. mihomo 사용자는 use 필드로 proxy-providers를 참조해 구독 노드를 그룹에 일괄로 넣을 수도 있고, filter 정규식으로 필터링하면 일일이 이름을 나열하는 관리 부담을 줄일 수 있습니다.

Clash Verge Rev에서 실제로 적용하기

설정 페이지에서 대상 설정을 마우스 오른쪽 클릭 후 「파일 편집」을 선택하면 YAML을 직접 수정할 수 있고, 저장하면 즉시 핫 리로드가 적용됩니다. 프록시 페이지로 전환하면 각 정책 그룹에서 현재 선택된 노드와 실시간 지연 시간을 한눈에 확인할 수 있어 수정 후 곧바로 검증할 수 있습니다.

변경 사항이 구독 업데이트로 덮어씌워질 수 있음

구독으로 생성된 설정 파일을 직접 수정하면 다음 구독 업데이트 시 변경 사항이 덮어씌워집니다. 장기적인 커스터마이징이 필요하다면 Clash Verge Rev 설정 페이지의 병합(오버라이드) 기능을 사용해 정책 그룹을 확장 설정에 작성하고, 구독 파일 본체는 그대로 두는 것이 좋습니다.

interval은 작을수록 좋은 게 아님

테스트 간격이 너무 짧으면 수십, 수백 개의 노드가 번갈아 테스트 주소로 요청을 보내면서 CPU, 배터리, 트래픽 소모가 커지고 로그도 헬스 체크로 뒤덮입니다. 일상적으로는 300초 전후가 적절한 시작점이며, fallback은 조금 더 짧게 잡을 수 있지만 60초 미만은 권장하지 않습니다.

테스트 주소 자체가 안정적이어야 함

세 가지 그룹 모두 헬스 체크에 의존합니다. 테스트 요청은 노드를 거쳐 전송되며, 주소에 접속할 수 없으면 해당 노드는 실패로 판정됩니다. 장기적으로 안정적인 204 테스트 주소를 선택하세요. 어느 날 그룹 전체 노드가 일제히 「타임아웃」된다면, 먼저 테스트 주소의 이상을 의심하고 그다음 노드를 의심하세요.

그룹 이름 참조는 정확히 일치해야 함

rules에서 참조하는 그룹 이름은 proxy-groups의 name과 완전히 일치해야 하며, 공백 하나만 더 있어도 매칭이 실패합니다. 설정을 수정한 뒤에는 로그 페이지를 확인해 보세요. 로딩 오류가 발생하면 문제가 있는 줄을 바로 알려줍니다.