Clash 정책 그룹 유형 비교: url-test, fallback, load-balance는 각각 어떤 상황에 적합할까

01 · 시작점

세 가지 정책 그룹이 해결하는 문제는 서로 다르다

Clash나 Clash Meta(mihomo 코어)의 설정 파일을 처음 접할 때, proxy-groups의 type 필드를 그저 "자동 모드 하나 고르면 되는" 스위치처럼 취급하고, 문제가 생기면 다른 걸로 바꿔보는 경우가 많습니다. 이런 시행착오 방식도 통하긴 하지만 효율이 낮고, 잘못된 유형으로 바꾸면 오히려 새로운 함정에 빠지기도 합니다 — 예를 들어 낮은 지연 시간을 원했는데 "연결만 되면 된다"에 가까운 fallback을 선택해 지연이 눈에 띄게 개선되지 않거나, 대역폭 부담을 분산하려 했는데 url-test를 선택해 결국 측정 속도가 가장 빠른 한두 개 노드에 트래픽이 몰리는 경우입니다.

세 가지의 핵심 차이는 한 문장으로 정리할 수 있습니다:

• url-test는 "누가 가장 빠른가"에 관심을 두고, 지속적으로 속도를 측정해 지연 시간이 가장 낮은 노드로 자동 전환합니다.
• fallback는 "누가 쓸 수 있는가"에 관심을 두고, 설정된 순서대로 처음 발견되는 정상 노드를 사용하며 최속을 적극적으로 추구하지 않습니다.
• load-balance는 "어떻게 분배할 것인가"에 관심을 두고, 동시 요청을 알고리즘에 따라 여러 노드로 분산시키며 단일 최적화가 목표가 아닙니다.

이어서 각각의 판단 로직과 핵심 매개변수를 하나씩 살펴보겠습니다. 로직을 이해하면 유형 선택에 더 이상 시행착오가 필요 없습니다.

02 · url-test

url-test: 지연 시간 우선 자동 선택

url-test는 그룹 내 각 노드에 주기적으로 HTTP 요청을 보내(요청 대상은 url 매개변수로 지정) 응답 시간을 해당 노드의 지연 값으로 기록한 뒤, 현재 트래픽을 지연이 가장 낮은 노드로 전환합니다. "패널에 자동 측정 노드 지연을 표시"하는 식의 화면 기능 뒤에서 가장 흔히 쓰이는 구현 방식으로, 처음 접하는 자동 정책 그룹이 대개 이것입니다.

주요 매개변수 설명:

tolerance는 가장 쉽게 간과되지만 체감에 영향을 주는 매개변수입니다. 허용 오차를 설정하지 않으면 두 노드의 지연 차이가 1밀리초만 나도 전환이 발생해, 빈번한 전환이 긴 연결(영상 재생, 다운로드 작업 등)을 끊고 재연결시킬 수 있습니다. 50ms 정도의 허용 오차를 두면 "차이가 크지 않으면 바꾸지 않는다"는 의미가 되어 연결 안정성을 얻는 대신, 이론상의 절대 최적에는 도달하지 못하는 대가를 치릅니다.

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

적합한 상황: 지연에 민감하고 단일 노드로도 대역폭 요구를 충족할 수 있는 용도, 예를 들어 웹 서핑, 메신저, 게임 가속 등입니다. 능동적으로 트래픽을 나누지 않고 모든 트래픽이 기본적으로 "현재 최적" 노드 하나로 향한다는 점이 load-balance와 정반대입니다.

03 · fallback

fallback: 가용성을 보장하는 대체 메커니즘

fallback도 그룹 내 노드에 상태 검사를 하지만, 판단 로직은 "가장 빠른 것 선택"이 아니라 "순서대로 처음 쓸 수 있는 것 선택"입니다. 설정의 proxies 목록 순서가 곧 우선순위입니다. 클라이언트는 가장 앞에 있는 노드를 먼저 시도하고, 상태 검사(마찬가지로 url 매개변수로 연결성 판단)를 통과하는 한 계속 그 노드를 사용하며, 뒤쪽 노드의 지연이 더 낮다고 해서 전환하지는 않습니다. 현재 노드가 사용 불가로 판정될 때만 순서대로 다음 노드를 시도합니다.

proxy-groups:
  - name: 안정 백업
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - 메인 노드-전용선
      - 백업 노드-홍콩
      - 백업 노드-일본

적합한 상황: 명확한 "우선 노드"(전용선, 자체 중계, 기업 내부망 출구 등)가 있고, 그 노드가 끊길 때만 자동으로 대체 경로로 전환되길 원하며, 여러 노드 간에 지연을 계속 비교하게 만들고 싶지 않은 경우입니다. 속도보다 연결 안정성이 중요한 상황, 예를 들어 장시간 온라인 상태를 유지해야 하는 원격 회의, 패킷 손실에 민감한 음성 통화, 혹은 특정 하나의 경로만 신뢰하고 나머지 노드는 비상용 백업으로만 두는 경우에 흔히 쓰입니다.

주의할 점은, interval이 상태 검사 빈도를 결정한다는 것입니다. 간격을 너무 길게 설정하면 노드가 이미 실패했는데도 클라이언트가 아직 알아채지 못해 한동안 연결 실패가 이어질 수 있고, 간격이 너무 짧으면 불필요한 검사 트래픽과 부담이 늘어납니다. 일반적으로 120~300초 정도가 균형 잡힌 범위입니다.

04 · load-balance

load-balance: 트래픽을 분산하는 로드 밸런싱

load-balance의 목표는 "최적 노드 하나"를 골라내는 것이 아니라, 서로 다른 연결 요청을 그룹 내 여러 노드로 분산시켜 트래픽이 하나의 출구에 장기간 몰리는 것을 막는 것입니다. strategy 매개변수로 분배 알고리즘을 결정하며, 흔히 쓰이는 두 가지는 다음과 같습니다:

• consistent-hashing(일관성 해싱): 연결의 소스 주소 등 정보로 해시 값을 계산해 노드를 배분하며, 같은 소스의 연결은 대개 같은 노드에 고정적으로 배정되어 세션 유지가 필요한 상황에 적합합니다.
• round-robin(라운드 로빈): 새 연결을 순서대로 다음 노드에 차례로 배정하며, 분배는 더 균등하지만 같은 소스의 연결이 항상 같은 노드로 가는 것은 보장되지 않습니다.

proxy-groups:
  - name: 분산 균형
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 노드A
      - 노드B
      - 노드C

적합한 상황: 단일 노드의 대역폭이나 동시 연결 수가 쉽게 한계에 도달하는 경우, 예를 들어 여러 기기가 하나의 구독을 함께 쓰거나 다운로드 작업이 많은 경우, 혹은 노드 자체에 동시 연결 수 제한이 있는 경우입니다. 트래픽을 여러 노드로 분산하면 단일 지점의 부담이 줄어 전체 처리량이 여러 노드 대역폭의 합에 더 가까워지며, 특정 노드 하나의 대역폭 상한에 막히지 않습니다.

05 · 비교

세 가지 유형의 매개변수 및 상황 비교

실제 설정 파일에서는 이 세 가지 유형을 완전히 조합해서 쓸 수 있으며, "하나만 골라 끝까지 쓰는" 방식이 아닙니다. 예를 들어 fallback을 가장 바깥쪽의 진입점으로 두고, 대체 경로 자체는 다시 url-test 그룹으로 구성해 여러 해외 노드 중 가장 빠른 것을 고르게 하며, 다운로드 도구만 따로 분기시키는 규칙은 다시 load-balance 그룹을 가리키게 해서 대용량 다운로드가 한 노드의 대역폭을 다 차지해 다른 앱 사용에 영향을 주지 않도록 할 수 있습니다. 이런 계층적 설계는 단일 정책 그룹보다 실제 사용 환경에 더 가깝고, 다른 사람이 공유한 복잡한 설정 파일을 볼 때도 자주 볼 수 있는 구조입니다.

또 하나 놓치기 쉬운 부분: url 매개변수가 가리키는 검사 주소 자체가 불안정하거나 속도 제한이 걸려 있으면 세 가지 정책 그룹의 판단 결과에 직접 영향을 줍니다 — url-test는 실제보다 높은 지연을 측정하고, fallback은 노드를 잘못 사용 불가로 판정할 수 있으며, load-balance의 상태 검사도 왜곡됩니다. 가볍고 응답이 빠르며 커버리지가 넓은 검사 주소를 선택하는 것이 세 가지 자동 정책 그룹 모두가 정상적으로 동작하기 위한 전제 조건이며, "자동 선택 결과가 이상하다"는 문제를 진단할 때도 검사 주소 자체의 가용성을 점검 목록에 포함해야 합니다.