정책 그룹 부하 분산 및 장애 조치 설정

이 글은 Clash 공식 사이트에서 제공합니다. 구독 서비스는 보통 수십 개에서 수백 개의 노드를 한 번에 제공하지만, 일상 사용 경험을 실제로 결정하는 것은 Clash 설정에서 이 노드들을 어떻게 구성하느냐입니다. 정책 그룹(Proxy Group)은 단순히 「홍콩 노드를 쓸지 미국 노드를 쓸지」 선택하는 것 이상으로, url-test 자동 속도 테스트, fallback 장애 조치, load-balance 부하 분산 등의 유형을 통해 연결이 지연, 안정성, 대역폭 사이에서 자동으로 최적화되도록 합니다. 이 글에서는 각 정책 그룹의 동작 차이와 설정 요점을 체계적으로 정리하여 더 견고한 멀티 노드 솔루션을 구축하는 데 도움을 드립니다.

라우팅 체인에서 정책 그룹의 위치

규칙이 특정 트래픽을 프록시로 라우팅하기로 결정하면, 단일 노드에 직접 연결되는 것이 아니라 PROXY 또는 「노드 선택」과 같은 정책 그룹 이름을 가리킵니다. 정책 그룹 내부에는 여러 노드나 하위 정책 그룹이 포함되어 있으며, 출구를 어떻게 선택할지를 정의합니다. 수동 지정, 자동 속도 테스트, 순차 시도, 분산 부하 중 하나를 선택할 수 있습니다.

이를 이해하면 사용 경험 최적화의 핵심은 단일 노드를 끊임없이 바꾸는 것이 아니라 정책 그룹 구조에 있다는 것을 알 수 있습니다. 합리적인 그룹 구조는 수동 조작을 줄이고, 노드 장애 시 자동으로 전환하여 「새벽에 연결이 끊기고 나서야 주력 노드가 다운됐다는 걸 알게 되는」 상황을 방지합니다.

select: 수동 선택, 가장 직관적

type: select는 가장 일반적인 정책 그룹 유형으로, 사용자가 클라이언트 드롭다운 목록에서 직접 노드나 하위 그룹을 선택합니다. 「홍콩 그룹 / 미국 그룹 / 일본 그룹」처럼 명확하게 사람이 결정해야 하는 시나리오에 적합하며, 「노드 선택」 최상위 레이어의 기본 구현이기도 합니다.

완전히 제어 가능한 것이 장점이지만, 노드 품질 변화에 자동으로 적응할 수 없습니다. 보통 총 입구로 사용하며 하위 레이어에 url-test 또는 fallback 하위 그룹을 연결하여 수동과 자동을 겸합니다.

url-test: 자동 속도 테스트로 가장 빠른 노드 선택

url-test는 설정된 간격으로 그룹 내 노드에 속도 테스트 요청(주로 https://www.gstatic.com/generate_204 사용)을 보내, 지연이 가장 낮고 타임아웃이 없는 노드를 출구로 선택합니다. 구독 서비스 설정의 「자동 선택」, 「Auto」 그룹이 대부분 이 유형입니다.

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - HK-1
      - HK-2
      - JP-1
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval은 속도 테스트 주기(초)이고, tolerance는 새 노드가 현재 노드보다 몇 밀리초 더 빨라야 전환이 트리거되는지를 설정하여 빈번한 전환을 방지합니다. 「항상 가장 빠른 회선으로」를 추구하는 사용자에게 적합하지만, 속도 테스트 자체가 소량의 트래픽과 CPU를 소비합니다.

fallback: 장애 조치, 가용성 강조

fallback은 목록 순서에 따라 노드를 사용하며, 현재 노드에 도달할 수 없을 때만 다음 노드를 시도합니다. url-test가 「가장 빠른 것」을 추구하는 것과 달리, fallback은 「연결만 되면 된다」는 접근 방식으로 고가용성 백업 체인으로 매우 적합합니다.

전형적인 구조: 주력 Trojan 노드 → 백업 VMess 노드 → 마지막 보험 IPLC. health-check 파라미터와 함께 사용하면 정기적으로 노드 생존 여부를 감지하여 미리 장애 회선을 건너뛸 수 있습니다. 스트리밍 서비스 사용자에게는 빈번하게 전환되는 최고 속도 노드보다 안정적인 fallback 체인 하나가 더 편리한 경우가 많습니다.

load-balance: 부하 분산

load-balance는 그룹 내 여러 노드에 연결을 분산시키며, consistent-hashing(동일 대상 주소는 항상 같은 노드로 라우팅하여 세션 지터 감소)과 round-robin(순환 할당)을 지원합니다. 다운로드, 다중 연결 크롤러, 또는 단일 노드의 대역폭 상한을 분산해야 하는 상황에 적합합니다.

주의: 부하 분산은 「단일 연결 속도 두 배」를 보장하는 것이 아니라 여러 동시 연결을 다른 출구에 분산시키는 것입니다. 동영상 재생처럼 단일 TCP 장기 연결 시나리오에서는 효과가 제한적이므로 여전히 url-test나 수동 최적화 노드를 사용하는 것을 권장합니다.

유형	선택 로직	전형적인 사용 사례
select	사용자 수동	총 출구, 지역 그룹
url-test	최저 지연	자동 최적화, 일상 인터넷
fallback	순차 시도	연결 끊김 백업, 고가용성
load-balance	해시/라운드 로빈	다중 연결 대역폭 분산

relay와 정책 그룹 중첩

relay는 트래픽을 여러 노드를 순서대로 통과시켜(체인 프록시) 특수한 투과 요구에 사용되며, 일반 사용자는 자주 접하지 않습니다. 더 일반적인 것은 정책 그룹 중첩입니다. 최상위 select로 사용자가 「홍콩 자동」이나 「미국 자동」을 선택하고, 하위 레이어는 각각 url-test 그룹, 그 아래에 구체적인 노드가 있습니다. 이렇게 하면 수동 제어권을 유지하면서 자동 속도 테스트의 편리함도 누릴 수 있습니다.

실전 조합 권장 사항

최상위 「노드 선택」(select)에 「자동」, 「장애 조치」, 「각 지역 그룹」을 포함시키세요.
주력 그룹은 url-test를 사용하고 tolerance를 50~150ms로 설정하여 불필요한 전환을 줄이세요.
fallback 그룹을 별도로 만들어 백업으로 사용하고, 다양한 데이터센터/프로토콜 노드를 순서대로 배치하세요.
스트리밍 서비스는 규칙 레이어에서 전용 정책 그룹을 지정하여 다운로드 부하 분산 그룹과 혼용하지 마세요.
클라이언트의 속도 테스트 결과는 참고용이며, 최종적으로는 실제 시청 및 게임 경험을 기준으로 삼으세요.

정리

url-test는 속도를, fallback은 생존율을, load-balance는 동시 분산을, select는 수동 결정을 추구합니다. 네 가지 유형을 함께 사용해야 멀티 노드 구독의 진정한 가치를 발휘할 수 있습니다. 수십 개의 노드를 수동으로 하나씩 테스트하는 것보다, 10분 투자해서 정책 그룹 구조를 정돈하면 Clash가 백그라운드에서 대부분의 최적화와 전환 작업을 대신 해줄 것입니다.

적합한 클라이언트가 없으신가요? 공식 다운로드 페이지에서 Clash Verge Rev 등의 도구를 다운로드하고, 설정 가이드를 참고하여 구독 가져오기 후 프록시 페이지에서 각 정책 그룹의 효과를 확인하세요.

관련 글