Clash 정책 그룹 선택 가이드: url-test·fallback·load-balance 실측 비교

정책 그룹이 해결하는 것은 "어떤 노드를 쓸지"의 문제

Clash / Clash Meta(mihomo) 설정 파일에서 proxies는 사용 가능한 모든 노드를 나열한 목록이고, 실제로 트래픽의 방향을 결정하는 곳은 proxy-groups다. 규칙(rules)은 특정 연결을 어떤 정책 그룹에 넘길지만 판단하며, 그 이후 노드를 구체적으로 고르는 일은 정책 그룹 내부에서 이루어진다. 만약 select 타입의 수동 정책 그룹만 하나 만들어 두면 선택은 전적으로 사용자가 직접 클릭해야 하고, 노드가 끊겨도 자동으로 전환되지 않는다. 그래서 대부분의 설정은 자동화 정책 그룹을 추가로 준비한다 — 각자의 알고리즘에 따라 "노드 고르기"라는 작업을 사람이 아닌 프로그램에 맡기는 것이다.

mihomo가 지원하는 자동화 정책 그룹은 크게 세 가지 유형이다: url-test(자동 속도 테스트), fallback(장애 복구), load-balance(로드 밸런싱). 세 유형은 동일한 헬스체크 메커니즘을 공유하지만 판단 로직과 적합한 시나리오는 완전히 다르며, 섞어 쓰면 효과가 반감된다. 이제 파라미터, 동작 방식, 시나리오별로 하나씩 풀어서 설명한다.

url-test: 지연 시간 기준으로 가장 빠른 노드를 자동 선택

url-test는 가장 흔한 자동화 유형으로, 핵심 로직은 다음과 같다: 그룹 안의 각 노드로 주기적으로 테스트 주소를 요청해 응답 시간을 측정하고, 이후 현재 트래픽을 응답 시간이 가장 짧은 노드로 보낸다. 이는 "이렇게 많은 노드 중 지금 가장 빠른 것은 무엇인가"라는 문제를 해결하며, 지연 시간을 핵심 지표로 삼는 대부분의 일상적인 사용 환경에 적합하다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩01
      - 홍콩02
      - 싱가포르01
      - 일본01
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

• url: 속도 테스트 요청을 보낼 주소로, 보통 가볍고 204를 안정적으로 반환하는 주소를 사용해 테스트 요청 자체가 대역폭을 많이 소모하거나 차단으로 판단이 왜곡되는 것을 피한다.
• interval: 두 번의 속도 테스트 사이 간격(초 단위). 위 예시는 300초마다 한 번 측정하며, 간격이 너무 짧으면 노드에 테스트 요청이 자주 몰리고, 너무 길면 노드가 느려져도 한참 동안 전환되지 않는다.
• tolerance: 허용 오차(밀리초 단위). 새로 측정된 가장 빠른 노드가 현재 사용 중인 노드보다 이 오차 값 이상 빠를 때만 실제로 전환된다. 오차를 두는 이유는 지연 시간이 비슷한 두 노드 사이에서 전환이 반복되어 연결이 자주 끊기는 것을 막기 위해서다.
• lazy: true이면 그룹 안의 연결이 실제로 사용 중일 때만 속도 테스트가 실행되어, 대기 중일 때는 측정하지 않으므로 트래픽과 노드 부하를 줄인다. false로 설정하면 사용 여부와 관계없이 interval에 따라 정기적으로 측정한다.

주의할 점은, tolerance는 "지연 시간 임계값"이 아니라 "전환 기준값"이라는 것이다. 예를 들어 현재 사용 중인 노드의 지연 시간이 120ms이고 다른 노드가 100ms로 측정되었으며 tolerance가 50ms로 설정되어 있다면, 20ms 차이는 충분히 크지 않아 전환되지 않는다. 차이가 50ms를 넘어야 실제로 노드가 바뀐다. 이 설계는 몇 밀리초 차이로 계속 왔다 갔다 전환되는 것을 막기 위한 것이다.

fallback: 최우선 노드가 실패해야만 다음 순서로 넘어감

fallback의 판단 로직은 url-test와 완전히 다르며, 누가 가장 빠른지는 비교하지 않고 "노드의 생존 여부"만 확인한다. 그룹 내 노드는 설정된 순서대로 우선순위를 가지며, 시스템은 항상 목록에서 가장 앞에 있고 헬스체크를 통과한 노드를 우선 사용한다. 현재 사용 중인 노드의 속도 테스트가 실패(타임아웃 또는 연결 불가)할 때만 순서대로 다음 노드를 시도하여 연결 가능한 노드를 찾는다.

proxy-groups:
  - name: 장애 복구
    type: fallback
    proxies:
      - 메인노드-홍콩
      - 백업노드-싱가포르
      - 백업노드-일본
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    tolerance: 0

여기서 순서가 곧 우선순위이며, 메인노드-홍콩이 첫 번째에 있으므로 헬스체크가 정상이면 이후 노드의 지연 시간이 더 낮더라도 트래픽은 계속 그 노드로 흐른다. 이는 url-test의 "빠른 것을 쓴다"는 방식과 정반대로, fallback은 안정성과 예측 가능성을 추구한다. 이미 어떤 노드의 회선 품질이 가장 좋은지 알고 있고, 그 노드가 간혹 문제를 일으킬 때 대비책이 필요한 경우에 적합하다. 예를 들어 특정 전용선 노드에 백업 노드 한두 개를 붙여두는 상황이다.

fallback에서 tolerance 파라미터는 큰 의미가 없다. 빠르고 느림을 비교해 전환하는 것이 아니라 "연결 가능한가"라는 이진 판단만 하기 때문에, 대부분의 설정에서는 0으로 두거나 생략해도 된다. 실제로 중요한 것은 url과 interval이며, 이 두 파라미터가 헬스체크를 얼마나 자주, 어디로 보내는지를 결정한다. 간격이 너무 길면 메인 노드에 장애가 생긴 뒤에도 한동안 트래픽이 계속 실패한 노드로 흘러간다.

load-balance: 트래픽을 여러 노드로 분산

load-balance는 또 다른 종류의 문제를 해결한다. "가장 빠른 하나를 고르는 것"이 아니라 "동시 연결을 여러 노드로 분산시키는 것"이며, 흔한 목적은 단일 노드의 대역폭 부담을 나누거나 품질이 비슷한 여러 노드에 작업을 골고루 배분해 한 노드만 계속 과부하 상태이고 다른 노드는 놀고 있는 상황을 피하는 것이다.

proxy-groups:
  - name: 로드 밸런싱
    type: load-balance
    proxies:
      - 홍콩01
      - 홍콩02
      - 홍콩03
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

strategy 파라미터가 이 유형의 핵심으로, mihomo는 두 가지 분배 알고리즘을 제공한다:

• consistent-hashing(일관 해싱): 연결의 소스 주소, 목적지 주소 등 정보를 기반으로 해시값을 계산해 특정 노드에 고정 분배한다. 같은 목적지 사이트, 같은 소스라면 대체로 항상 같은 노드로 떨어지므로, 세션이 중간에 노드가 바뀌면서 로그인 상태가 끊기거나 다운로드가 중단되는 일이 없다. 장기 연결이나 세션 유지가 필요한 상황에 적합하다.
• round-robin(라운드 로빈): 새 연결을 그룹 내 노드에 순서대로 돌아가며 분배한다. 분배는 더 균등하지만, 같은 사이트에 대한 서로 다른 요청이 다른 노드로 떨어질 수 있어 IP 일관성에 민감한 서비스(예: 로그인 상태가 IP에 묶이거나 캡차가 뜨는 사이트)에서는 문제가 생기기 쉽다.

주의할 점은, load-balance는 실패한 노드를 완전히 제외하고 전체 트래픽을 재분배하지 않는다는 것이다. 여전히 헬스체크로 노드 생존 여부를 판단하며, 실패한 노드는 잠시 건너뛰지만 분배 로직 자체는 "장애 복구 우선순위" 같은 정렬 처리를 하지 않는다. 그룹 내 노드 품질 차이가 크면 로드 밸런싱은 오히려 일부 연결을 느린 노드로 보내게 되어, url-test보다 체감 안정성이 떨어질 수 있다. 그래서 이 유형은 "노드 품질이 서로 비슷해 부담을 나누고 싶은" 상황에 더 적합하며, "노드 품질이 제각각이라 좋은 것만 쓰고 싶은" 상황에는 맞지 않는다.

세 유형 중 무엇을 선택할까: 시나리오 비교

실제 설정에서는 세 유형을 중첩해 조합할 수도 있다. 자주 쓰이는 방식은 먼저 url-test로 "자동 선택" 그룹을 만들어 기본 출구로 삼고, 우선순위가 높은 특정 서비스(예: 스트리밍, 다운로드 도구)에는 load-balance 그룹을 따로 두어 대역폭을 분산하며, 핵심 노드에는 fallback 그룹을 두어 보험처럼 쓰는 것이다. 정책 그룹끼리 서로 참조할 수도 있다 — select 그룹의 항목에는 구체적인 노드뿐 아니라 다른 정책 그룹의 이름도 넣을 수 있으므로, 상위 규칙은 가장 바깥쪽 select만 가리키게 하고 내부 자동화 로직은 하위 정책 그룹이 맡도록 하면 설정 구조가 훨씬 깔끔해진다.

흔한 오해와 점검 방법

"url-test를 설정했는데도 노드가 계속 전환되지 않는다"는 문의가 많은데, 대부분 tolerance가 너무 크게 설정되어 있거나, 그룹 내 노드 간 지연 시간 차이 자체가 미미해 시스템이 전환할 필요가 없다고 판단한 경우다. tolerance를 일시적으로 한 자릿수로 줄여 전환이 다시 일어나는지 확인해보고, 정상 작동을 확인한 뒤 적절한 값으로 되돌리면 된다. 또 하나 흔한 문제는 fallback 그룹에서 "메인 노드가 분명 연결되지 않는데도 계속 사용되는" 경우인데, 보통 interval이 너무 길어 헬스체크가 다음 주기까지 돌지 않았거나, 테스트 주소가 예상한 204가 아닌 응답을 반환해 생존으로 잘못 판단된 경우다.

또 다른 흔한 오해는 load-balance를 "더 빠른 url-test"처럼 사용하며 자동으로 최적 노드를 골라주길 기대하는 것인데, 이 유형의 설계 목표는 최적화가 아니라 분산이다. 그룹 안에 눈에 띄게 품질이 나쁜 노드가 섞여 있으면 일부 연결의 체감 품질이 떨어지므로, 이런 경우에는 느린 노드를 그룹에서 빼거나 차라리 url-test로 바꾸는 것이 낫다. 이런 문제를 점검할 때는 클라이언트 화면에서 각 노드의 현재 측정값과 정책 그룹이 실제로 선택한 노드를 확인하는 것이 좋다. 대부분의 그래픽 클라이언트(Clash Verge, Clash for Windows 계열 등)는 정책 그룹 화면에서 각 노드의 지연 시간과 현재 선택된 항목을 실시간으로 표시해주므로, 로그를 일일이 뒤지는 것보다 훨씬 직관적이다.