Clash 정책 그룹 로드 밸런싱: load-balance·consistent-hashing으로 노드 나누기 (mihomo)

1. load-balance가 필요한 상황

구독을 가져오면 수십 개의 노드가 생기지만, 전부 url-test 한 그룹에만 넣으면 선택은 한 개입니다. 측정 URL 기준으론 가장 빠른 한 대만 쓰고, 대용량 파일이 그 한 군데로 몰릴 수 있습니다. 반면 HTTP 다운로드나 BitTorrent, 일부 P2P·CDN이 여러 커넥션을 열더라도, 동시에 여러 상류(upstream)로 흩트려 전체 대역·서버 쿼터를 나누 쓰고 싶다면 로드 밸런싱이 맞는 선택입니다. 또 같은 LAN에서 나온 트래픽은 항상 같은 프록시로 보내 쿠키·세션이 뒤섞이지 않게 하려면, 단순 랜덤이 아니라 일관 해시(consistent-hashing)로 “소스 단위”로 고정하는 패턴이 자주 쓰입니다.

mihomo 문맥에서 이 타입의 그룹 이름이 load-balance이고, strategy 키로 분배 방식을 고릅니다. 코어 버전·GUI에 따라 토글명이 다를 수 있으나, 프로필의 YAML이 사실 기준이라는 점은 비슷합니다. 아래는 개념을 잡기 위한 설명이며, 실제 프로덕트명·옵션 키는 쓰는 mihomo/클라이언트 문서를 한 번 더 확인하세요.

2. url-test·fallback과 무엇이 다른가

이미 url-test·fallback에서 다룬 것처럼, 둘은 “하나(또는 하나의 흐름)를 고른다 / 장애 시 다음으로”에 가깝습니다. load-balance는 기본 그림이 동시에 여러 후보를 쓰면서 들어오는 연결·세션을 그 묶음 위에 분배한다는 점이 다릅니다. “가장 낮은 지연만 본다”는 목적이면 url-test, “순서대로 죽을 때만 바꾼다”는 목적이면 fallback, “한 묶음 안에서 나눠 담는다”는 목적이면 load-balance로 기억하면 정리가 쉽습니다.

3. round-robin: 연결을 순서대로 분산

strategy: round-robin은 새로 잡는 연결이 생길 때마다 후보 proxies 목록을 번갈아 가리키는 방식에 가깝게 이해하시면 됩니다. 쇼핑·문서·웹캐싱이 아닌, 대역을 여러 군데로 쪼개서 받고 싶을 때(예: 다중 스레드·다운로드 매니저) “한 노드에만 쏠림”을 줄이는 데 쓰기 좋습니다. 다만 동일한 원격 IP에 대한 세션이 잠깐씩은 다른 상류로 붙을 수도 있으니, 로그인·결제처럼 IP 고정이 중요한 서비스와 섞을 때는 round-robin이 부적절한 경우가 있습니다. 그때는 아래 일관 해시를 검토하세요.

proxy-groups:
  - name: '다운-라운드로빈'
    type: load-balance
    strategy: round-robin
    proxies:
      - '노드-1'
      - '노드-2'
      - '노드-3'
# Node names must match names from proxies / subscription output
# New connections are spread across the list in a round-robin fashion

name은 이후 rules에 적을 논리적 출구 이름입니다. 구독이 노드명을 갱신하면 이 목록이 깨질 수 있으니, 프로필 검사·클라이언트의 오류 로그를 수시에 보는 것이 좋습니다. DIRECT를 끼울지 여부는 국선·누락 범위에 따라 팀·개인마다 달라집니다.

4. consistent-hashing: 출발지 기준 “고정” 분배

strategy: consistent-hashing은 해시 링을 써서, 연결(또는 흐름)을 나타내는 키(예: 소스 IP·쌍 등, 코어 구현에 따름)를 정해 점 노드 슬롯에 안정적으로 매핑합니다. 효과는 “비슷한 연결은 같은 상류로 가고, 풀 전체에는 고르게 부하가 퍼질” 가능성이 높다는 점입니다. round-robin이 매 연결마다 돌리는 데 가깝다면, 일관 해시는 식별자당 한 방향에 더 가깝다고 보면 됩니다. 그래서 쿠키·세션이 민감한 흐름이나, 한 클라이언트(한 기기)는 같은 출구를 유지한 채, 전체 풀에는 나눠 담고 싶다는 니즈와 맞물립니다. 구체 해시 키는 mihomo 버전과 문서에 따르므로, “왜 IP가 이 노드냐”를 더 깊게 보려면 해당 릴리스의 설명을 꼭 읽어야 합니다.

proxy-groups:
  - name: '다운-일관해시'
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - '노드-A'
      - '노드-B'
      - '노드-C'
# consistent-hashing: map flows to a stable node within the set

일부 구성에선 lazy(지연 켜짐) 같은 키를 지원해, 해당 그룹이 실제로 쓰일 때만 뒤처리를 줄이는 식이 붙을 수도 있습니다(지원 여부는 사용 중인 코어 확인). 한편, “특정 사이트만 이 그룹으로”가 목적이면, 아래 rules 쪽이 더 중요합니다. 그냥 MATCH에만 걸어 두면 전부 그 정책을 타게 됩니다.

5. rules에 그룹 이름 붙이기

정책 그룹을 아무리 잘 써도, rules에 그 name이 연결되지 않으면 트래픽이 도달하지 않습니다. 일반적으로 다운로드·대용량만 따로 쪼개려면, 스토리지·P2P·툴이 쓰는 도메인·IP·프로세스 조건 뒤에 본 load-balance 그룹을 둡니다. 나머지 일상 트래픽은 기존 url-test·select 쪽이 안전한 경우가 많습니다.

rules:
  - 'DOMAIN-SUFFIX,example-cdn.com,다운-일관해시'
  - 'DOMAIN-KEYWORD,package-host,다운-라운드로빈'
  - 'MATCH,일반-출구'
# First match wins: put specific rules before MATCH

rules는 위에서 아래로이며, 첫 매칭이 승리합니다. “대용량 전용”과 “IP 고정이 필요한 웹(은행, 결제, 클라우드 콘솔 등)”이 섞이면, load-balance 쪽 규칙 범위를 지나치게 넓게 잡지 않는 것이 좋습니다. GEOIP·PROCESS-NAME 등 쓰는 키는 프로필·OS에 따라 점검이 필요합니다(Windows·macOS·Linux·Android 글을 각각 참고).

6. 운용 시 흔한 주의점

첫째, 로드 밸런싱이 “총 대역”을 늘려 주는 마법은 아닙니다. 후보 각 상류의 회선·쿼터는 그대로이며, 쪼개 쓰는 효용은 “한 서버/한 노드 쏠림을 줄이는 것” 쪽이 큽니다. 둘째, round-robin이면 짧은 시간에 출구가 달라 보일 수 있고, 지역·리스크 체크에 민감한 서비스(스트리밍, 결제)와 섞이면 안 되는 경우가 있습니다. 셋째, consistent-hashing이어도 후보 목록·노드 수가 변하면 맵이 흔들릴 수 있으니, 구독 갱신이 잦다면 감지 기준/백업 정책을 정해 두는 편이 낫습니다. 넷째, TUN·시스템 DNS·Fake-IP가 얽힌 환경에서 “이 규칙만 따로”가 안 먹는다면, 스니퍼·DNS를 함께 봐야 합니다(다른 mihomo 실전 글과 병독).

7. 정리

이미 지연과 장애 복구를 url-test·fallback에 맡기고 있다면, 그 다음 단계는 “한 줄기가 아니라, 묶음 위에 나누기”가 필요한지를 보는 것입니다. load-balance는 그때 YAML의 type으로 추가하고, strategy에 round-robin과 consistent-hashing을 구분해 넣은 뒤, rules의 위쪽 줄에 용도에 맞는 도메인·IP·앱 조건을 먼저 붙이면 됩니다. 이렇게 층을 나누어 두면, 데스크톱·CLI·mihomo를 쓰는 어떤 클라이언트로 옮겨도, 같은 정책 그룹 개념을 그대로 재사용할 수 있습니다.

앱·코어·구독이 바뀌어도, “규칙 + 그룹 + DNS” 흐름을 손에 익혀 두면 이후에 덜 헤맵니다. 설치·업데이트는 출처가 분명한 빌드로 통일해 두는 것이 좋고, 한곳에서 안정된 패키지를 내려받을 수 있으면 운용 부담이 확 줄어듭니다. 여러 OS에서 검증된 Clash는 설정만 맞으면, 부하를 나누는 로드 밸런싱까지 같은 논리로 이어갈 수 있습니다. 지금 쓰는 프로필에 load-balance 묶음을 붙이고, 다운·멀티 연결·해시 요구에 맞는지 직접 맞춰 보세요. → Clash를 무료로 내려받고, load-balance·consistent-hashing을 프로필에 직접 반영해 보세요.